Thanks for that information.

It’s always interesting to see how features that individually can be very helpful don’t always work when you combine them. It’s one of the commonest types of problem that I find in my consultancy work.

From bug 4947170:

The problem stems from the fact that VPD builds a view to replace the table reference. The view text does not select the ORA_ROWSCN pseudo column from the underlying table even if the outer query block references it resulting in ORA-904.

An enhancement request 6609789 has been raised and Oracle is working a solution.

Oracle provide the following workaround – since the ora_rowscn is available inside the policy function, add a dummy predicate as follows:
||' AND f_ora_rowscn('||object_name||'.ORA_ROWSCN) = 1'

CREATE OR REPLACE FUNCTION f_ora_rowscn( ROWSCN IN NUMBER )
RETURN NUMBER
AS
BEGIN
DBMS_SESSION.SET_CONTEXT( 'STORE_ROWSCN', 'ROWSCN', ROWSCN ) ;
RETURN 1 ;
END ;
/

CREATE CONTEXT store_rowscn USING f_ora_rowscn ;

Also, to get the row_scn for each row, make it row dependant:

CREATE OR REPLACE FUNCTION get_rowscn ( ROW IN ROWID ) RETURN VARCHAR2
AS
BEGIN
RETURN SYS_CONTEXT( 'STORE_ROWSCN', 'ROWSCN' ) ;
END;
/

Now to fetch the row scn in your application, use get_rowscn:

SELECT t.*, get_rowscn( t.ROWID ) "ORA_ROWSCN" FROM test_table t ;

Thanks for supplying that information.

Do you know if the latching activity was caused by calls to the security functions, or by the fact that you can end up with a long chain of child cursors for the same SQL statement – which would all be covered by the same latch – when you use RLS ?

Thanks for that – it’s the type of comment that might save someone days of pointless effort.

Thanks for the comments, and especially the bug numbers, it’s the type of information that could be very helpful to anyone who finds this blog entry.
Nice to know that the Oracle developers have tried to take out the selectivity issues in 10g. (Of course there’s no perfect solution with the extra predicates; sometimes you will want a different plan, sometimes you won’t – it depends on the data, number of “private databases”, and different granularities of privilege)

The performance issue(s) for us are usually a side effect of OLS’ impact on the optimizer resulting in poor plans. When we were on 9.2.0.x we discovered through some testing/10053 digging that the optimizer can’t evaluate the predicates added by OLS (bug: 5674756,4200369). The default filter factor for a predicate that can’t be evaluated is 0.05, which was being added to multiple predicates on each protected table. In our implementation the number of rows being filtered by OLS is generally small, or at least much smaller than 0.05 or (0.05*0.05) would filter. This would of course raise havoc on estimated cardinalities and resulting execution plans.

For 9.2.0.x to 10.2.x the bug was fixed by Oracle using a filter factor of 1.0 for OLS predicates instead of the default 0.05, resulting in plans that were typically identical to not having OLS at all. This has been much better over all, but we occasionally still have issues crop up where the plan for a labeled user is changed negatively compared to the same plan for a user with READ privilege that bypasses the policy.

Metalink note : 761921.1

Regards