Zoals bij alle vragen met betrekking tot prestaties is het antwoord:"het hangt ervan af". RLS werkt door de gecontroleerde query in een buitenste query te plaatsen die de beleidsfunctie toepast als een WHERE-clausule...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
De implicaties voor de prestaties zijn dus volledig afhankelijk van wat er in de functie gebeurt.
De normale manier om deze dingen te doen, is door contextnaamruimten te gebruiken. Dit zijn vooraf gedefinieerde gebieden van sessiegeheugen die toegankelijk zijn via de functie SYS_CONTEXT(). Als zodanig zijn de kosten van het ophalen van een opgeslagen waarde uit een context verwaarloosbaar. En aangezien we normaal gesproken de naamruimten één keer per sessie vullen - bijvoorbeeld door een trigger na het aanmelden of een vergelijkbare verbindingshaak - zijn de totale kosten per query triviaal. Er zijn verschillende manieren om de naamruimte te vernieuwen, wat gevolgen kan hebben voor de prestaties, maar nogmaals, deze zijn triviaal in het algemene geheel van dingen (zie dit andere antwoord ).
De impact op de prestaties hangt dus af van wat uw functie daadwerkelijk doet. Dat brengt ons bij een overweging van uw huidige beleid:
Het goede nieuws is de uitvoering van een dergelijke functie is op zich waarschijnlijk niet duur. Het slechte nieuws is dat de voorstelling misschien nog steeds Teh Suck! hoe dan ook, als de verhouding tussen live-records en historische records ongunstig is. U zult waarschijnlijk uiteindelijk alle records ophalen en vervolgens de historische eruit filteren. De optimizer kan het RLS-predikaat in de hoofdquery duwen, maar ik denk dat dit onwaarschijnlijk is vanwege de manier waarop RLS werkt:het vermijdt het onthullen van de criteria van het beleid aan de algemene blik (waardoor het debuggen van RLS-bewerkingen een echte PITN wordt).
Uw gebruikers zullen de prijs betalen voor uw slechte ontwerpbeslissing. Het is veel beter om journaal- of geschiedenistabellen te hebben om oude records op te slaan en alleen live gegevens in de echte tabellen te bewaren. Het bewaren van historische gegevens naast levende is zelden een schaalbare oplossing.
DBMS_RLS vereist een Enterprise Edition-licentie.