Sorry Jack,
I didn't preserve the title ... it was copied from an internal email. Also the _ parameters are never documented in official ora docs, Metalink is good for that.
Raj
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 20, 2003 5:54 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Row level security and latch waits
Raj,
Thanks. A mention of which FM would've saved me some searching, but I
found it under "Introduction to Fine-Grained Access Control" / "Automatic
Reparse" in the "Oracle9i Application Developer's Guide - Fundamentals".
I'll have to do more investigation, since those paragraphs don't clearly
explain (at least, to me) what is meant by "the same predicate". Does that
mean that predicates with Context Variables included as bind variables will
not be reparsed if their Policy Function was created with
Static_Policy=True, and yet different sessions can reuse the parsed SQL
with their own Context values? ...or not?
Also, any idea where init parameters such as _dynamic_rls_policies and
_app_ctx_vers are fully documented? A search reveals that they're not in
any of the 9.2 docs that I've got, except for the brief mention they get in
the above-mentioned section of the Developer's Guide.
Jack C. Applewhite
Database Administrator
Austin Independent School District
Austin, Texas
512.414.9715 (wk)
512.935.5929 (pager)
[EMAIL PROTECTED]
"Jamadagni,
Rajendra" To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
<Rajendra.Jamadagn cc:
[EMAIL PROTECTED]> Subject: RE: Row level security and latch waits
Sent by:
[EMAIL PROTECTED]
com
08/20/2003 04:09
PM
Please respond to
ORACLE-L
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 !
...
--
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
