Como con todas las preguntas relacionadas con el rendimiento, la respuesta es "depende". RLS funciona envolviendo la consulta controlada en una consulta externa que aplica la función de política como una cláusula WHERE...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
Por lo tanto, las implicaciones de rendimiento se basan completamente en lo que sucede en la función.
La forma normal de hacer estas cosas es usar espacios de nombres de contexto. Estas son áreas predefinidas de la memoria de sesión a las que se accede a través de la función SYS_CONTEXT(). Como tal, el costo de recuperar un valor almacenado de un contexto es insignificante. Y como normalmente rellenaríamos los espacios de nombres una vez por sesión, por ejemplo, mediante un activador posterior al inicio de sesión o un gancho de conexión similar, el costo total por consulta es trivial. Hay diferentes formas de actualizar el espacio de nombres que pueden tener implicaciones en el rendimiento, pero nuevamente, estas son triviales en el esquema general de las cosas (ver esta otra respuesta ).
Por lo tanto, el impacto en el rendimiento depende de lo que realmente haga su función. Lo que nos lleva a una consideración de su política actual:
La buena noticia es la ejecución de tal función es poco probable que sea costosa en sí misma. ¡La mala noticia es que la actuación aún puede ser Teh Suck! de todos modos, si la proporción de registros vivos a registros históricos es desfavorable. Probablemente terminará recuperando todos los registros y luego filtrando los históricos. El optimizador podría insertar el predicado RLS en la consulta principal, pero creo que es poco probable debido a la forma en que funciona RLS:evita revelar los criterios de la política a la mirada general (lo que hace que la depuración de operaciones RLS sea un PITN real).
Sus usuarios pagarán el precio de su mala decisión de diseño. Es mucho mejor tener tablas de diario o de historial para almacenar registros antiguos y mantener solo datos en vivo en las tablas reales. Retener registros históricos junto con los vivos rara vez es una solución escalable.
DBMS_RLS requiere una licencia de Enterprise Edition.
