简单描述如何实现在同一台服务器上不同的应用之间进行资源划分。
这里介绍资源管理器的方式。
无论是Exadata还是ODA，服务器的配置都越来越强大。因此都存在着把多个应用集中到一起的需求。
对于Exadata而言，一般来说部署的应用数据量大，并发应用高，很少会有多个应用同时部署在一个数据库服务器上的需求，反而经常是需要RAC中的多个节点同时支持某个应用，因此对于Exadata来说，应用资源划分的解决方案是SERVER POOL。
而ODA则和Exadata不同，由于ODA受扩展性，磁盘容量以及配置的限制，因此把多个应用集成到ODA上，那么这些应用多半都是小应用，考虑到ODA只有两个节点组成的RAC，因此对于ODA来说，如何在同一个服务器上给各个应用划分资源，而尽量减少应用之间的相互干扰就是十分有意义的事情了。
除了利用操作系统上的解决方案外，Oracle提供了两种方式的解决方案。一个是通过把多个应用分布到多个数据库中，通过限制每个数据库可以使用的CPU数量实现，即INSTANCE STAGE；另一个是把所有的应用集中到一个数据库，通过数据库的资源管理器实现资源的划分。
如果要使用资源管理器来分配资源，那么需要将所有的应用集中到同一个数据库中，然后根据用户、访问方式以及主机名的不同来设定不同的资源组，并将CPU资源按照一定的比例分配给不同的资源组。
在ODA上使用SWINGBENCH进行压力测试，选择100G的订单环境进行测试，当并发达到6000左右时，ODA两个服务器的CPU基本跑满，前端SWINGBENCH开始出现连接超时的情况，说明当前这种压力已经是服务器所能支持的最大值了。
此时，如果数据库中存在其他的应用，那么这些应用势必会受到压力测试的影响，应用访问的效率必然严重下降。
下面看一个简单的例子，数据库中存在两个用户分布对应两个不同的应用，可以通过下面的方法来给不同的应用分配CPU时间片资源：
SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); 3 DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); 4 DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'SOE_GROUP',COMMENT => 'soe first group'); 5 DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'S2_GROUP', COMMENT => 'soe2 group'); 6 DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(ATTRIBUTE => DBMS_RESOURCE_MANAGER.ORACLE_USER, VALUE => 'SOE', CONSUMER_GROUP => 'SOE_GROUP'); 7 DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(ATTRIBUTE => DBMS_RESOURCE_MANAGER.ORACLE_USER, VALUE => 'SOE2', CONSUMER_GROUP => 'S2_GROUP'); 8 DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); 9 DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); 10 END; 11 / PL/SQL PROCEDURE successfully completed. SQL> BEGIN 2 DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(GRANTEE_NAME => 'SOE', CONSUMER_GROUP => 'SOE_GROUP', GRANT_OPTION => FALSE); 3 DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(GRANTEE_NAME => 'SOE2', CONSUMER_GROUP => 'S2_GROUP', GRANT_OPTION => FALSE); 4 END; 5 / PL/SQL PROCEDURE successfully completed. SQL> BEGIN 2 DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); 3 DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); 4 DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'SWINGBENCH_TEST',COMMENT => 'soe plan'); 5 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'SWINGBENCH_TEST', GROUP_OR_SUBPLAN => 'SOE_GROUP',COMMENT => 'soe', MGMT_P1 => 75); 6 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'SWINGBENCH_TEST', GROUP_OR_SUBPLAN => 'S2_GROUP',COMMENT => 'soe2', MGMT_P1 => 25); 7 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'SWINGBENCH_TEST', GROUP_OR_SUBPLAN => 'OTHER_GROUPS',COMMENT => 'soe3', MGMT_P2 => 100); 8 DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); 9 DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); 10 END; 11 / PL/SQL PROCEDURE successfully completed. SQL> SHOW parameter resource_manager_plan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string DEFAULT_PLAN SQL> ALTER system SET resource_manager_plan=SWINGBENCH_TEST; System altered. SQL> SHOW parameter resource_manager_plan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string SWINGBENCH_TEST |
关于资源管理器这里就不多介绍了，简单描述一下上面的设置。首先创建两个消费组，将SOE用户映射到SOE_GROUP，将SOE2映射到S2_GROUP。对SOE和SOE2用户授权，使其拥有切换到对应消费组的权限。最后进行CPU时间片的分配，75%的资源分配给SOE_GROUP，25%的资源分配给S2_GROUP。
这时再次SWINGBENCH进行压力测试，分别使用SOE和SOE2执行相同的压力测试，并发连接3000。对于连接SOE用户的测试程序，3000的并发并未造成系统的超时。但是SOE2用户的连接由于配置的CPU时间片资源只有系统的1/4，因此在3000连接的时候出现了大量的连接超时会话，压力测试程序已经基本上没有响应了。
使用资源管理器和INSTANCE STAGE并不只是一个数据库和多个数据库的区别，事实上二者的还有一个主要的区别就是CPU使用的划分上。对于INSTANCE STAGE而言，分配了多少CPU_COUNT，那么这个实例就只能使用这么多CPU资源，即使整个服务器上只有当前一个数据库在运行，即使系统的IDLE再高，这个实例所使用的CPU也不会超过CPU_COUNT的限制。而资源管理器则完全不同，事实上即使SOE2用户配置了25%的CPU时间片，如果数据库中只有这个用户的会话，那么这个用户可以使用100%的CPU资源。事实上资源管理器的配置效果一般在主机CPU达到100%的时候才能明显的体现出来。
两种资源的划分方法很难说哪种更优一些，如果根据资源如何划分来考虑多个数据库还是多个SCHEMA的话，那么多个数据库设置CPU_COUNT更适合服务器上还存在其他应用的情况，而使用资源管理器更有利于最大程度上来使用CPU的资源。