V1.0

一、 目的

明确常用赋权操作标准流程，以及赋权过程中可能产生的风险，最大限度避免赋权操作带来的系统故障。

二、 适用范围

l 对数据库对象的授权操作，数据库对象包括表、存储过程、同义词、视图和序列等。授权类型包括查询、增删改、执行。

l 对数据库用户的系统授权操作。

三、 风险评估

l 对数据库用户进行系统授权时，需要根据实际情况进行，避免因对用户授予过高的系统权限或角色，进而使该用户存在误操作引发数据库或应用故障的风险。

l 对于存储机密数据的表的授权，需要慎重。以免泄露机密数据。

l 对于涉及同步的数据库，需要分别在同步的两端数据库执行相同的授权操作。

l 10G之前版本，grant操作需要获得Exclusive级别的library cache lock/pin。其风险主要针对于procedure、function等，对table基本无影响。若procedure正在执行时，对其本身或者其依赖的procedure、function进行授权，将阻塞其他要执行此procedure或其依赖procedure、function的会话，直到授权前正在执行的procedure结束。

l 对数据库对象授权时，不会引起依赖对象失效，但会导致library cache中与授权对象有依赖关系的游标失效，进而产生硬解析。如果对象的依赖游标过多，或执行频率较高，可能会对系统造成较大的冲击，造成CPU繁忙，latch争用严重，最常引起的latch争用有 shared pool、library cache还会有library cache pin、cursor pin s:wait x等争用出现。如果争用比较严重，甚至可能导致数据库crash。为避免此类情况出现，对于新建对象，应尽可能的先把权限授予给可能会使用到的用户；对于在使用的对象，应充分评估对象依赖游标的个数和执行次数，选择执行低峰进行操作。

l 对于grant any table，或者grant DBA/ EXP_FULL_DATABASE等涉及大量对象的系统授权操作，应该作为重大变更对待，此类操作的风险极大，务必在业务低峰期进行操作。

四、 操作流程

1. 准备工作

a) 确认此次授权是否属于正常的业务需要。

b) 若赋予的为系统权限，禁止使用with admin option选项。

c) 若赋予的为对象权限，请确认此对象在数据库中缓存的游标个数，以及每个游标在不同时段的执行频率，根据具体的情况选择合适的变更时间窗口进行授权。

d) 准备授权脚本。

e) 新建对象的授权需要走事件流程。

f) 在用对象的授权或涉及大量对象的系统授权需要走一般变更或重大变更流程。

2. 执行过程

a) 以赋权对象所在的用户登录数据库，SHOW USER检查是否连接到正确的schema。

b) 如果被依赖对象的执行频率很高，需要打开DDL TRIGGER.

c) 执行赋权脚本。

d) 查看过程若无报错，退出当前登录。

3. 验证方案,以下列举两种验证方式：

使用被赋权用户登录：

i. 验证对象权限：select owner,grantee,table_name,privilege

from user_tab_privs

where grantee=’&USER_NAME’

and table_name=’&object_name’;

ii. 验证系统权限：select username,privilege from user_sys_privs;

五、 核心对象风险

核心对象上的依赖sql往往较多，而且执行频率较高，授权操作会导致对象依赖的游标失效，进而导致硬解析风暴。应该尽量选择业务低峰期来进行核心表的赋权操作。

六、 回退方案

我们遭遇的授权操作的最大风险第一是导致的硬解析风暴，第二是授权操作涉及数据字典的修改，甚至可能会导致row cache lock的出现。对于硬解析风暴的风险，回退的方案不是revoke对象的权限，而是等待硬解析风暴过去。对于赋权操作引发的问题，要根据具体的情况而定。提前把方案一定要整理好，慎重选择变更的时间，避免出现问题。

七、 历史故障及教训

略