Wie bei allen Fragen zur Leistung lautet die Antwort "es kommt darauf an". RLS funktioniert, indem es die kontrollierte Abfrage in eine äußere Abfrage einschließt, die die Richtlinienfunktion als WHERE-Klausel anwendet...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Die Auswirkungen auf die Leistung hängen also vollständig davon ab, was in die Funktion einfließt.
Der normale Weg, diese Dinge zu tun, ist die Verwendung von Kontext-Namespaces. Dies sind vordefinierte Bereiche des Sitzungsspeichers, auf die über die Funktion SYS_CONTEXT() zugegriffen wird. Daher sind die Kosten für das Abrufen eines gespeicherten Werts aus einem Kontext vernachlässigbar. Und da wir die Namespaces normalerweise einmal pro Sitzung füllen würden – beispielsweise durch einen After-Logon-Trigger oder einen ähnlichen Verbindungshaken – sind die Gesamtkosten pro Abfrage trivial. Es gibt verschiedene Möglichkeiten, den Namensraum zu aktualisieren, was Auswirkungen auf die Leistung haben könnte, aber auch diese sind im Gesamtschema trivial (siehe diese andere Antwort ).
Die Auswirkungen auf die Leistung hängen also davon ab, was Ihre Funktion tatsächlich tut. Das bringt uns zu einer Betrachtung Ihrer aktuellen Politik:
Die gute Nachricht ist die Hinrichtung einer solchen Funktion ist an sich wahrscheinlich nicht kostspielig. Die schlechte Nachricht ist, dass die Leistung immer noch Teh Suck sein kann! sowieso, wenn das Verhältnis von Live-Aufzeichnungen zu historischen Aufzeichnungen ungünstig ist. Sie werden wahrscheinlich alle Aufzeichnungen abrufen und dann die historischen herausfiltern. Der Optimierer könnte das RLS-Prädikat in die Hauptabfrage verschieben, aber ich denke, dass dies aufgrund der Art und Weise, wie RLS funktioniert, unwahrscheinlich ist:Es vermeidet es, die Kriterien der Richtlinie für den allgemeinen Blick offenzulegen (was das Debuggen von RLS-Operationen zu einem echten PITN macht).
Ihre Benutzer werden den Preis für Ihre schlechte Designentscheidung zahlen. Es ist viel besser, Journaling- oder Verlaufstabellen zu haben, um alte Aufzeichnungen zu speichern und nur Live-Daten in den echten Tabellen zu behalten. Die Aufbewahrung historischer Aufzeichnungen neben Live-Aufzeichnungen ist selten eine skalierbare Lösung.
DBMS_RLS erfordert eine Enterprise Edition-Lizenz.
