使用Oracle资源管理器打造稳定、高效的核心银行数据库
关键字：Oracle Resource Manager、Resource Consumer Groups、rman
前言
Oracle的DRM(Database Resource Manager)可以基于应用的需要在用户或应用程序中分配可用的系统资源，目前DRM在国际上已经被广泛用于生产的数据库，但在国内应用的还比较少，可能是国内的DBA对DRM还需要一个接受过程。本文探讨使用DRM来合理调配核心银行系统数据库的资源，打造一个稳定、高效的核心银行数据库。
建立资源分配计划(ITSTREETS)
用OEM（Oracle Enterprise Manager）建立一个名为ITSTREETS的资源分配计划：
根据银行应用的特点，把用户分成6个组，下面按照优先级的从高到低的顺序说明如下：
Ø SYS_GROUP：包括了sys和system两个用户，主要用于系统的维护，这个权限应该是最高的，不然资源紧张时可能无法进行系统维护。
Ø ONLINE_GROUP:包括了用于处理联机交易的用户，银行的联机交易主要包括：柜员、ATM的存取款、转账交易，保障联机交易能被快速地处理对于维护银行的声誉是非常必要的，因此这类用户应该有较高的优先级。
Ø BATCH_GROUP: 包括了用于处理批量交易的用户，银行的批量交易主要包括：批量的代理业务（如代发工资、代收水电费等）、生成各类报表、滚积数等，这类交易的实时性要求并不高，不应和联机交易争资源，因此它们的优先级应比ONLINE_GROUP的优先级略低。
Ø OTHER_GROUPS:包括所有不属于目前活动计划中的用户。
Ø AUTO_TASK_CONSUMER_GROUP:Oracle提供的自动执行的任务的资源组。
Ø LOW_GROUP:Oracle提供
的，优先级低的用户组。
可以在OEM的Consumer Groups和Consumer Group Mappings中将相应的用户对应到这些资源组中，过程就不一一描述了。
ITSTREETS计划创建完成后，通过OEM激活启用此计划。
对不同优先级用户资源竞争的测试
用level 1的用户运行一个较消耗资源的笛卡尔集查询：
18:44:13 SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where s.sid = (select sid from sys.v_$mystat where rownum = 1);
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
SYS SYS_GROUP sqlplus@
18:44:13 SQL> select count(*) from dba_objects,dba_objects;
level 2的用户同时运行：
18:44:14 SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where s.sid = (select sid from sys.v_$mystat where rownum = 1);
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
ONLINE_USA ONLINE_GROUP sqlplus@
18:44:15 SQL> select count(*) from dba_objects,dba_objects;
看看OEM的Resource Monitors中看看资源竞争的情况：
从分析上图：
在左边的饼图中可以看出，CPU的资源基本都被SYS_GROUP给占用了。
从右边的柱状图和下面的列表中可以看出，优先级低的ONLINE_GROUP和OTHER_GROUPS有大量的CPU Wait Time。
等SYS_GROUP的SQL执行完成后，再看看资源竞争的情况：
从图中可以看出：资源都被level 2的ONLINE_GROUP占用，而level 4的OTHER_GROUP没有占用到CPU的资源，有大量的CPU Waite Time。
注意：监控资源时，先点击reset键，清除历史数据。
对于ONLINE_GROUP中消耗CPU过多的SQL的处理
这样的资源分配计划，保证了ONLINE_GROUP的用户有较高的优先级，在CPU资源的竞争中处于有利的地位。银行的ONLINE_GROUP用户中运行SQL主要是完成记账功能，通常不应该出现运行时间很长的SQL,但仍可能由于应用开发的失误出现这样的SQL，而影响了正常的业务，对于这样的SQL，可以在资源计划中设定策略拒绝运行，例如：在ONLINE_GROUP中拒绝预计运行时间超过10分钟的SQL（包括PL/SQL的存储过程）：
测试一下：
SQL> select count(*) from dba_objects,dba_objects;
select count(*) from dba_objects,dba_objects
*
ERROR at line 1:
ORA-07455: estimated execution time (2953 secs), exceeds limit (600 secs)
但在ONLINE_GROUP中也有可能一些运行时间较长的SQL是正常的，如柜员的扎账，但这类SQL也不应该和为储户服务的SQL竞争资源，可以把它降级到BATCH_GROUP的级别运行，运行完成后再回到原来的级别。这里设定超过5分钟的SQL（包括PL/SQL的存储过程）降级运行：
测试一下：
用ONLINE_GROUP的用户运行SQL:
21:25:58 SQL> conn online_usa/online_usa;
Connected.
21:26:06 SQL> select count(*) from dba_objects,dba_segments;
COUNT(*)
----------
206769564
21:26:41 SQL> 21:26:41 SQL>
监控RESOURCE_CONSUMER_GROUP的变化情况：
21:26:09 SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where username='ONLINE_USA';
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
ONLINE_USA ONLINE_GROUP sqlplus@
21:26:10 SQL>
21:26:20 SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where username='ONLINE_USA';
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
ONLINE_USA BATCH_GROUP sqlplus@
21:26:22 SQL>
21:26:45 SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where username='ONLINE_USA';
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
ONLINE_USA ONLINE_GROUP sqlplus@
21:26:46 SQL>
请注意观察上面SQL的时间点，可以看到，在SQL运行前RESOURCE_CONSUMER_GROUP是ONLINE_GROUP，运行中是BATCH_GROUP，运行完成后以又回到ONLINE_GROUP。
在具体设定运行多长时间的SQL应该拒绝，运行多长时间的SQL应该降级时，建议先参考一下AWR的报告，找到一个合适的值。如果不是很有把握，通常设大一些比较保险。
用ORM解决Oracle自动运行的任务和应用竞争资源的问题
Oracle
它们运行的窗口组是：SYS.MAINTENANCE_WINDOW_GROUP，包括两个窗口：
WEEKNIGHT_WINDOW：
Repeat By Weeks
Interval (Weeks) 1
Days of Week Monday,Tuesday,Wednesday,Thursday,Friday
Repeat Time Hour:10 Minute:00 Second:00 PM
Duration (min) 8hour(s)0minute(s)
和
WEEKEND_WINDOW
Repeat By Weeks
Interval (Weeks) 1
Days of Week Saturday
Repeat Time Hour:12 Minute:00 Second:00 AM
Duration (min) 48hour(s)0minute(s)
也就是平时晚上8个小时和周末48小时。这些自动运行的任务是比较消耗资源的，因此Oracle安排在晚上和周末进行，但仍然可能会对应用有影响。据说有客户因为这些Oracle设定的自动运行任务和应用竞争资源而起诉Oracle公司，因此Oracle在推出新的
有的DBA为了解决这个问题，干脆把这些任务停了，而选择恰当的时间窗口，用类似crontab之类的OS层的工具来调用这些任务，但对于银行需要提供7×24小时服务的应用来说其实没有适当的窗口可以让这些后台的任务影响应用的运行。因此我们在ITSTREETS资源计划中把运行这此任务的资源组AUTO_TASK_CONSUMER_GROUP设置在level 5比较恰当，不会和应用产生资源的竞争。
我们可以测试一下，在OEM中激活用激活窗口的方式进行测试
在EM中选Administration->选Windows->选中WEEKNIGHT_WINDOW->再选open->Force Open选Yes。
此时查一下资源组的情况：
SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where username is not null;
USERNAME RESOURCE_CONSUM PROGRAM
--------------- --------------- ------------------------------
SYSMAN OTHER_GROUPS OMS
SYSMAN OTHER_GROUPS OMS
SYSMAN OTHER_GROUPS OMS
SYS SYS_GROUP OMS
SYS AUTO_TASK_CONSU oracle@
MER_GROUP
SYSMAN OTHER_GROUPS OMS
ONLINE_USA ONLINE_GROUP sqlplus@
SYS SYS_GROUP sqlplus@
从上面可以看出，多了一个AUTO_TASK_CONSUMER_GROUP资源组，是后台JOB运行的。资源管理计划ITSTREETS会把这些任务放在level 5中运行，不会和前面4个level产生资源竞争，因此对应用没有什么影响。
用ORM解决rman备份占用资源过多的问题
Rman备份也是很消耗资源工作，笔者前段时间就遇到了这样的问题，有个应用每天rman备份时应用就连不上来了。查了一下，原来rman备份的策略设定了4个通道同时并行的备份，把CPU的资源都消耗光了。这样的问题，可以通过减少备份的并行度和限制每个通道的速率的方式来解决，如：CONFIGURE CHANNEL DEVICE TYPE DISK RATE
但这样大大延长了备份的时间，不利用资源的充分利用，用ORM可以很好地解决这个问题。设定把这类的工作按程序名（rman）映射到level 6的LOW_GROUP中，这样它的优先级最低，其它的用户都可以“欺负”它，把它的资源夺走。
还要设定映射的优先级，应用如果先按OracleUser进行映射就会映射到SYS_GROUP了，成了level 1，应该把按Client Program映射的方法的优先级设定成高于按Oracle User进行映射。这样rman就映射到level 6中了。
但这样设定了没有效，查一下：
SQL> select * from DBA_RSRC_GROUP_MAPPINGS where attribute = 'CLIENT_PROGRAM';
ATTRIBUTE VALUE CONSUMER_GROU STATUS
--------------- -------------------- ------------- ----------
CLIENT_PROGRAM RMAN LOW_GROUP
原来Oracle把rman变成RMAN了，自动换成大写了，当然对不上，这是oracle的一个BUG（在Oracle
这样就设定好了，备份的工作再也不会和应用抢资源了，保障了前台应用稳定高效地运行。
其它类似的sqlldr、exp等也可以这样设定。
临时运行的任务的资源策略的设定
DBA有时需要临时运行一些很消耗资源的任务，如回收表空间、重建索引等。由于这些任务太消耗资源，如果不进行资源使用的控制，数据库在运行这些任务时，基本无法提供对外的正常服务。此时应根据具体情况降低运行这些任务的session使用资源的优先级。
下面是在不同级别资源组中切换的一个例子。
SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where s.sid = (select sid from sys.v_$mystat where rownum = 1);
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
SYS SYS_GROUP sqlplus@
－――――当前是level 1的SYS_GROUP，下面进行切换
SQL> SQL> DECLARE
old_grp VARCHAR2(32);
2 BEGIN
3 DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP (
4 new_consumer_group => 'ONLINE_GROUP',
5 old_consumer_group => old_grp,
6 initial_group_on_error => FALSE );
7 END;
8 9 /
PL/SQL procedure successfully completed.
SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where s.sid = (select sid from sys.v_$mystat where rownum = 1);
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
SYS ONLINE_GROUP sqlplus@
－――――切换成了level 2的ONLINE_GROUP，现在可以执行与ONLINE_GROUP资源组相匹配的工作了
SQL>
DECLARE
SQL> old_grp VARCHAR2(32);
2 BEGIN
3 DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP (
4 new_consumer_group => 'LOW_GROUP',
5 old_consumer_group => old_grp,
6 initial_group_on_error => FALSE );
7 END;
8 /
9
PL/SQL procedure successfully completed.
SQL> select username,RESOURCE_CONSUMER_GROUP,PROGRAM from sys.v_$session s where s.sid = (select sid from sys.v_$mystat where rownum = 1);
USERNAME RESOURCE_CONSUMER_GROU PROGRAM
--------------- ---------------------- ------------------------------
SYS LOW_GROUP sqlplus@
SQL> SQL>/
－――――又切换成了LOW_GROUP，现在级别最低，做什么都不会影响其它的用户了！
注意：但这种切换方法对rman备份没有用，因为rman在分配通道时会新建一个session，不继承当前session的资源组，因此rman仍应采用前面的方法进行资源组的映射。
取消ORM
在生产上使用ORM应当很小心，考虑全面，如果出现问题可以用下面的命令快速取消ORM：
alter system set resource_manager_plan='';
