ITPub博客

首页 > 数据库 > Oracle > sysauth$基表的用户权限的一点分析

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

原创 Oracle 作者:dotaddjj 时间:2012-02-27 22:42:01 0 删除 编辑

源于itpub的一篇帖子http://www.itpub.net/thread-1581904-1-1.html说到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$基表的数据信息。

可能是对于系统用户授权较为频繁导致AWR表报中对于sysauth$访问较频繁,由于没有实际的环境但是从这点倒是可以让我们更好的了解oracle用户授权机制。

[@more@]

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/25362835/viewspace-1057464/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    220
  • 访问量
    1662971