0

If we use Oracle Row Level Security(RLS) to hide some records - Are there any Performance Implications - will it slow down my SQL Queries? The Oracle Package for this is: DBMS_RLS.

I plan to add: IS_HISTORICAL=T/F to some tables. And then using RLS, hide the records which have value of IS_HISTORICAL=T.

The SQL Queries we use in application are quite complex, with inner/outer joins, subqueries, correlated subqueries etc.

Of the 200 odd tables, about 50 of them will have this RLS Policy (to hide records by IS_HISTORICAL=T) applied on them. Rest of the 150 tables are child tables of these 50 Tables, so RLS is implicit on them.

Any License implications?

Thanks.

4

1 回答 1

2

"Are there any Performance Implications - will it slow down my SQL Queries? "

As with all questions relating to performance the answer is, "it depends". RLS works by wrapping the controlled query in an outer query which applies the policy function as a WHERE clause...

select /*+ rls query */ * from ( 
    select /*+ your query */ ... from t23 
    where whatever = 42 )
where rls_policy.function_t23 = 'true'

So the performance implications rest entirely on what goes in the function.

The normal way of doing these things is to use context namespaces. These are predefined areas of session memory accessed through the SYS_CONTEXT() function. As such the cost of retrieving a stored value from a context is negligible. And as we would normally populate the namespaces once per session - say by an after logon trigger or a similar connection hook - the overall cost per query is trivial. There are different ways of refreshing the namespace which might have performance implications but again these are trivial in the overall schem of things (see this other answer).

So the performance impact depends on what your function actually does. Which brings us to a consideration of your actual policy:

"this RLS Policy (to hide records by IS_HISTORICAL=T)"

The good news is the execution of such a function is unlikely to be costly in itself. The bad news is the performance may still be Teh Suck! anyway, if the ratio of live records to historical records is unfavourable. You will probably end up retrieving all the records and then filtering out the historical ones. The optimizer might push the RLS predicate into the main query but I think it's unlikely because of the way RLS works: it avoids revealing the criteria of the policy to the general gaze (which makes debugging RLS operations a real PITN).

Your users will pay the price of your poor design decision. It is much better to have journalling or history tables to store old records and keep only live data in the real tables. Retaining historical records alongside live ones is rarely a solution which scales.

"Any License implications?"

DBMS_RLS requires an Enterprise Edition license.

于 2013-02-19T09:18:05.337 回答