Jack,
This is from TFM ...
<manual>
Starting from 9i, queries against Fine Grained Access enabled objects always execute the policy function to make sure most up to date predicate is used for each policy. For example, in case of the time based policy function, in which queries are only allowed between 8am-5pm, an execute of a cursor that is parsed at noon would result in an execution of the policy function at the execution time to make sure policy function is consulted again for the query.
There are only two exceptions to this rule. One is to specify STATIC_POLICY=TRUE when adding the policy to indicate that the policy function always returns the same predicate. Another one is for users whose security policies do not return different predicate within a database session, the init.ora parameter _dynamic_rls_policies can be set to FALSE to reduce the execution overhead.
</manual>
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 20, 2003 4:09 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: Row level security and latch waits
I got the 9.2 docs and this is in the Concepts manual:
"Dynamic Predicates
The function or package that implements the security policy you create
returns a predicate (a WHERE condition). This predicate controls access as
set out by the policy. Rewritten queries are fully optimized and shareable.
"
"Fully optimized and shareable" sure sounds like the queries are parsed
after the predicate is added.
I couldn't find any init parameter similar to what you mentioned.
Does anyone have a concrete reference regarding parsing of FGAC-modified
queries?
Thanks.
Jack C. Applewhite
Database Administrator
Austin Independent School District
Austin, Texas
512.414.9715 (wk)
512.935.5929 (pager)
[EMAIL PROTECTED]
Connor McDonald
<[EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
uk> cc:
Sent by: Subject: Re: Re: Row level security and latch waits
[EMAIL PROTECTED]
.com
08/20/2003 10:21
AM
Please respond to
ORACLE-L
My understanding was that the rls predicate was added
at parse time (hence the importance of the contexts
and avoiding things like 'sysdate')
But also if I remember correctly, this behaviour was
changed in v9 to process the security function with
each execution (and hence probably increase the amount
of parsing going on).
You might want to have a play the the
"_dynamic_policies" parameter (or something like that)
which can be used to revert the 8i behaviour (which
should reduce parsing to a degree)
hth
connor
...
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
*********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************1
