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@]