Както при всички въпроси, свързани с производителността, отговорът е „зависи“. RLS работи, като опакова контролираната заявка във външна заявка, която прилага функцията на правилата като клауза WHERE...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Така че последиците от производителността зависят изцяло от това, което влиза във функцията.
Нормалният начин за правене на тези неща е да се използват контекстни пространства от имена. Това са предварително дефинирани области от паметта на сесията, достъпни чрез функцията SYS_CONTEXT(). Като такава цената за извличане на съхранена стойност от контекст е незначителна. И тъй като обикновено бихме попълвали пространствата от имена веднъж на сесия - да речем чрез тригер след влизане или подобна кука за връзка - общата цена на заявка е тривиална. Има различни начини за опресняване на пространството от имена, което може да има последици за производителността, но отново те са тривиални в общата схема на нещата (вижте този друг отговор ).
Така че въздействието върху производителността зависи от това какво всъщност прави вашата функция. Което ни води до разглеждане на вашата действителна политика:
Добрата новина е изпълнението на такава функция е малко вероятно да бъде скъпо само по себе си. Лошата новина е, че изпълнението все още може да е Teh Suck! както и да е, ако съотношението на записи на живо към исторически записи е неблагоприятно. Вероятно в крайна сметка ще извлечете всички записи и след това ще филтрирате историческите. Оптимизаторът може да вкара RLS предиката в основната заявка, но мисля, че е малко вероятно поради начина, по който работи RLS:той избягва разкриването на критериите на политиката пред общия поглед (което прави отстраняването на грешки в RLS операциите истински PITN).
Вашите потребители ще платят цената на вашето лошо дизайнерско решение. Много по-добре е да имате таблици за журналиране или история, за да съхранявате стари записи и да съхранявате само живи данни в реалните таблици. Запазването на исторически записи наред с живите рядко е мащабно решение.
DBMS_RLS изисква лиценз за Enterprise Edition.
