oracle sysauth,sysauth$基表的用户权限的一点分析

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$基表的数据信息。