Som med alla frågor som rör prestanda är svaret "det beror på". RLS fungerar genom att linda den kontrollerade frågan i en yttre fråga som tillämpar policyfunktionen som en WHERE-sats...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Så prestandans implikationer vilar helt på vad som händer i funktionen.
Det normala sättet att göra dessa saker är att använda kontextnamnrymder. Dessa är fördefinierade områden i sessionsminnet som nås via SYS_CONTEXT()-funktionen. Som sådan är kostnaden för att hämta ett lagrat värde från ett sammanhang försumbar. Och eftersom vi normalt skulle fylla namnområdena en gång per session - t.ex. med en trigger efter inloggning eller en liknande anslutningshak - är den totala kostnaden per fråga trivial. Det finns olika sätt att uppdatera namnutrymmet som kan ha prestandaimplikationer, men dessa är återigen triviala i det övergripande upplägget (se detta andra svar ).
Så prestandan påverkan beror på vad din funktion faktiskt gör. Vilket leder oss till en övervägande av din faktiska policy:
De goda nyheterna är utförandet av en sådan funktion är osannolikt att vara kostsamt i sig. De dåliga nyheterna är att prestandan fortfarande kan vara Teh Suck! hur som helst, om förhållandet mellan liveskivor och historiska skivor är ogynnsamt. Du kommer antagligen att sluta med att hämta alla poster och sedan filtrera bort de historiska. Optimeraren kan trycka in RLS-predikatet i huvudfrågan, men jag tror att det är osannolikt på grund av hur RLS fungerar:den undviker att avslöja kriterierna för policyn för allmänheten (vilket gör felsökning av RLS-operationer till en riktig PITN).
Dina användare kommer att betala priset för ditt dåliga designbeslut. Det är mycket bättre att ha journalföring eller historiktabeller för att lagra gamla poster och bara behålla livedata i de riktiga tabellerna. Att behålla historiska rekord tillsammans med live är sällan en lösning som skalar.
DBMS_RLS kräver en Enterprise Edition-licens.