Som med alle spørgsmål vedrørende ydeevne er svaret, "det afhænger". RLS fungerer ved at indpakke den kontrollerede forespørgsel i en ydre forespørgsel, der anvender politikfunktionen som en WHERE-sætning...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Så præstationsimplikationerne hviler udelukkende på, hvad der foregår i funktionen.
Den normale måde at gøre disse ting på er at bruge kontekstnavneområder. Disse er foruddefinerede områder af sessionshukommelsen, der tilgås via SYS_CONTEXT()-funktionen. Som sådan er omkostningerne ved at hente en lagret værdi fra en kontekst ubetydelige. Og da vi normalt ville udfylde navneområderne én gang pr. session - f.eks. med en efter-logon-trigger eller en lignende forbindelseshook - er den samlede pris pr. forespørgsel triviel. Der er forskellige måder at opdatere navnerummet på, som kan have præstationsimplikationer, men igen er disse trivielle i det overordnede skema (se dette andet svar ).
Så præstationspåvirkningen afhænger af, hvad din funktion rent faktisk gør. Hvilket bringer os til en overvejelse af din faktiske politik:
Den gode nyhed er henrettelsen af en sådan funktion er usandsynligt, at det er dyrt i sig selv. Den dårlige nyhed er, at præstationen muligvis stadig er Teh Suck! alligevel, hvis forholdet mellem live-optegnelser og historiske optegnelser er ugunstigt. Du ender sandsynligvis med at hente alle optegnelserne og derefter filtrere de historiske fra. Optimeringsværktøjet kan skubbe RLS-prædikatet ind i hovedforespørgslen, men jeg tror, det er usandsynligt på grund af den måde, RLS fungerer på:den undgår at afsløre kriterierne for politikken for det generelle blik (hvilket gør fejlfinding af RLS-operationer til en rigtig PITN).
Dine brugere betaler prisen for din dårlige designbeslutning. Det er meget bedre at have journalførings- eller historietabeller til at gemme gamle poster og kun opbevare live data i de rigtige tabeller. At bevare historiske optegnelser sammen med live er sjældent en løsning, der skaleres.
DBMS_RLS kræver en Enterprise Edition-licens.