1.0/db_1
System name: Linux
Node name: dw
Release: 2.6.9-55.0.2.0.1.EL
Version: #1 Mon Jun 25 14:24:38 PDT 2007
Machine: i686
Instance name: dw
Redo thread mounted by this instance: 1
Oracle process number: 40
Unix process pid: 31128, image: oracle@dw (TNS V1-V3)
*** 2007-08-12 12:48:37.852
*** SESSION ID:(120.9389) 2007-08-12 12:48:37.852
*** CLIENT ID:() 2007-08-12 12:48:37.852
*** SERVICE NAME:(SYS$USERS) 2007-08-12 12:48:37.852
*** MODULE NAME:(SQL*Plus) 2007-08-12 12:48:37.852
*** ACTION NAME:() 2007-08-12 12:48:37.852
-------------------------------------------------------------
Logon user : DGRANT
Table/View : HR.EMPLOYEES
Policy name : EMP_SELECT_RESTRICT
Policy function: VPD.GET_PREDICATES.EMP_SELECT_RESTRICT
RLS view :
SELECT "EMPLOYEE_ID","FIRST_NAME","LAST_NAME",
"EMAIL","PHONE_NUMBER",
"HIRE_DATE","JOB_ID","SALARY","COMMISSION_PCT","MANAGER_ID",
"DEPARTMENT_ID" FROM "HR"."EMPLOYEES"
"EMPLOYEES" WHERE (EMPLOYEE_ID = 199 OR MANAGER_ID = 199)
-------------------------------------------------------------
The user??™s original SQL statement plus the appended predicate are clearly shown in the trace
file. The downside to using this method is that while a user may be able to access dynamic
performance views, a developer might not normally have access to the user dump directory on
the server itself. As a result, the DBA may need to be involved when trying to debug predicate
problems.
Be sure to turn off tracing when you??™re done debugging to reduce the overhead and disk
space associated with tracing operations (or just log off!):
SQL> alter session set events '10730 trace name context off';
Session altered.
Pages:
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544