select privilege#,level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0
如上的sql語句頻繁執行，其實對于遞歸sql對于自己初始oracle才一年的菜鳥一般是略去不看的，eygle前輩們有時別太相信oracle內部的sql，他們很可能會成為系統性能的瓶頸，記得eygle的一個案例說到某個版本的oracle上開啟oem很可能導致后臺一個遞歸sql反復執行而影響系統運行，也建議自己和大家多去嘗試看一些oracle內部的東西。
還是先查看下基表sysauth$的定義吧
這里可以參考下oracle_home/rdbms/admin/sql.bsq的腳本，其中有關于定義oracle基表具體表結構和column的comment
create table sysauth$/* system authorization table */
( grantee#number not null,/* grantee number (user# or role#) */
privilege#number not null,/* role or privilege # */
sequence#number not null,/* unique grant sequence */
option$number)/* null = none, 1 = admin option */
還存在一個組合索引
create unique index i_sysauth1 on sysauth$(grantee#, privilege#)
看來確實是關于用戶權限的基表信息。
下面用10046來追蹤對于用戶權限的操作，以下實踐數據庫是oracle 10.2.0.0的win7服務器上
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered
SQL> grant resource,connect to test;
Grant succeeded
SQL> alter session set events '10046 trace name context off';
Session altered
截取的部分trace文件信息
select max(nvl(option$,0)) from sysauth$ where privilege#=:1 connect by grantee#=prior privilege# and privilege#>0 start with (grantee#=:2 or grantee#=1) and privilege#>0 group by privilege#
insert into sysauth$ (grantee#,privilege#,option$,sequence#) values (:1,:2,decode(:3,0,null,:3),system_grant.nextval)
這里可以看出對于test的resource，connect的授權最終是對于sysauth$基表的更新，
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered
SQL> revoke resource,connect from test;
Revoke succeeded
SQL> alter session set events '10046 trace name context off';
Session altered
部分的trace文件信息
delete from sysauth$ where grantee#=:1 and privilege#=:2
delete from defrole$ where user#=:1 and role#=:2 and not exists (select null from sysauth$ where grantee#=1 and privilege#=:2)
看出revoke用戶權限時實則也是對sysauth$基表的更新，期間還更新刪除了了defrole$基表的數據信息。
可能是對于系統用戶授權較為頻繁導致AWR表報中對于sysauth$訪問較頻繁，由于沒有實際的環境但是從這點倒是可以讓我們更好的了解oracle用戶授權機制。
[@more@]
