Comme pour toutes les questions relatives aux performances, la réponse est "ça dépend". RLS fonctionne en enveloppant la requête contrôlée dans une requête externe qui applique la fonction de politique comme une clause WHERE...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Ainsi, les implications en termes de performances reposent entièrement sur ce qui se passe dans la fonction.
La façon normale de faire ces choses est d'utiliser des espaces de noms de contexte. Ce sont des zones prédéfinies de la mémoire de session accessibles via la fonction SYS_CONTEXT(). En tant que tel, le coût de récupération d'une valeur stockée à partir d'un contexte est négligeable. Et comme nous remplirions normalement les espaces de noms une fois par session - par exemple par un déclencheur après la connexion ou un crochet de connexion similaire - le coût global par requête est insignifiant. Il existe différentes manières de rafraîchir l'espace de noms qui peuvent avoir des implications sur les performances, mais encore une fois, elles sont triviales dans le schéma général des choses (voir cette autre réponse ).
Ainsi, l'impact sur les performances dépend de ce que votre fonction fait réellement. Ce qui nous amène à examiner votre politique actuelle :
La bonne nouvelle est l'exécution d'une telle fonction est peu susceptible d'être coûteuse en elle-même. La mauvaise nouvelle est que la performance est peut-être encore Teh Suck! quoi qu'il en soit, si le rapport entre les enregistrements vivants et les enregistrements historiques est défavorable. Vous finirez probablement par récupérer tous les enregistrements, puis filtrer les historiques. L'optimiseur peut pousser le prédicat RLS dans la requête principale mais je pense que c'est peu probable en raison du fonctionnement de RLS :cela évite de révéler les critères de la politique au regard général (ce qui fait du débogage des opérations RLS un véritable PITN).
Vos utilisateurs paieront le prix de votre mauvaise décision de conception. Il est bien préférable d'avoir des tables de journalisation ou d'historique pour stocker les anciens enregistrements et ne conserver que les données réelles dans les tables réelles. Conserver les archives historiques à côté des archives vivantes est rarement une solution évolutive.
DBMS_RLS nécessite une licence Enterprise Edition.
