简单描述如何实现在同一台服务器上不同的应用之间进行资源划分。
这里介绍INSTANCE STAGE的方式。
无论是Exadata还是ODA，服务器的配置都越来越强大。因此都存在着把多个应用集中到一起的需求。
对于Exadata而言，一般来说部署的应用数据量大，并发应用高，很少会有多个应用同时部署在一个数据库服务器上的需求，反而经常是需要RAC中的多个节点同时支持某个应用，因此对于Exadata来说，应用资源划分的解决方案是SERVER POOL。
而ODA则和Exadata不同，由于ODA受扩展性，磁盘容量以及配置的限制，因此把多个应用集成到ODA上，那么这些应用多半都是小应用，考虑到ODA只有两个节点组成的RAC，因此对于ODA来说，如何在同一个服务器上给各个应用划分资源，而尽量减少应用之间的相互干扰就是十分有意义的事情了。
除了利用操作系统上的解决方案外，Oracle提供了两种方式的解决方案。一个是通过把多个应用分布到多个数据库中，通过限制每个数据库可以使用的CPU数量实现，即INSTANCE STAGE；另一个是把所有的应用集中到一个数据库，通过数据库的资源管理器实现资源的划分。
对于INSTANCE STAGE其实很简单，就是通过设置初始化参数CPU_COUNT来限制每个数据库可以使用的CPU数量。当然并不是只要设置了CPU_COUNT就可以生效，这个参数生效的一个前提似乎启用了资源管理器。
虽然INSTANCE STAGE也要用资源管理器，但是资源如何划分并不是通过资源管理器中的设置实现的，使用资源管理区是需要Oracle启用资源划分的功能，从而使得CPU_COUNT参数发挥作用。无论是修改CPU_COUNT初始化参数还是开启资源管理区，都是可以动态生效的。
在ODA上使用SWINGBENCH进行压力测试，选择100G的订单环境进行测试，当并发达到6000左右时，ODA两个服务器的CPU基本跑满，前端SWINGBENCH开始出现连接超时的情况，说明当前这种压力已经是服务器所能支持的最大值了。
此时，如果服务器上存在另一数据库，那么连接这个数据库的应用势必会受到压力测试数据库和应用的影响，应用访问的效率必然严重下降。
而如果部署了INSTANCE STAGE，则可以最大程度上避免这个问题。比如在进行压力测试的数据库上设置：
SQL> SHOW parameter cpu_count NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ cpu_count INTEGER 24 SQL> ALTER system SET cpu_count=8 scope=BOTH; System altered. SQL> SHOW parameter cpu_count NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ cpu_count INTEGER 8 SQL> SHOW parameter resource_manager_plan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string SQL> ALTER system SET resource_manager_plan=DEFAULT_PLAN; System altered. SQL> SHOW parameter plan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string DEFAULT_PLAN |
这时再次使用SWINGBENCH进行压力测试，发现当并发达到2000后，就可以逐渐出现连接超时的情况，即使把并发增加到6000，压力测试端出现大量的超时的情况下，数据库上CPU的利用率也一直维持在30%左右，还有将近70%的IDLE。
显然这时其他的数据库在进行操作时不会受到压力测试数据库的影响。对于多个服务器上存在多个数据库的情况，可以根据应用的不同，把服务器的CPU划分给各个数据库实例，从而避免这些数据库之间的相互影响。