最近有些场景遇到资源隔离的场景。之前自己摸索过，现在实践了。这里先要申明一下，正常来说有开发规范，并且可以落实，基本用不到隔离。以目前数据库的技术和硬件来说都行。但是遇到不可掌控的实现逻辑，想怎么写怎么写的话，还是有必要的。当然这里如果有好的硬件比如像一体机那种，另当别论。
我整理了命令如下：
在CDB操作
exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
exec DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(plan => 'test',comment => 'test');
创建资源隔离计划
然后我们创建隔离CPU的计划。
说是隔离其实是有两个层面：
一个是最低保障：就是这里的shares。可以理解为底薪。常量意味这个保底必须保证的CPU资源。
另外一个是最大上限：就是这里的utilization_limit，所有的这些加起来可以“超卖”大于100%。目前就是起到削峰填谷的作用。因为几乎不可能所有数据库都在同一时刻全部是高峰。就像一个物理机的所有虚拟机也不可能是同一时刻全部是高峰。或者再直白点，买了这个保险的，所有人全部都要赔付。太罕见了。
exec DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE (plan => 'test',profile => 'high',shares => 10,utilization_limit => 40);
exec DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE (plan => 'test',profile => 'middle',shares => 6,utilization_limit => 30);
exec DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE (plan => 'test',profile => 'low',shares => 3,utilization_limit => 20);
PDB操作，每个改自己的。
alter system set db_performance_profile=high SCOPE=BOTH;
每个数据库独立设置，即时生效。无需重启。随时调整。
CPU限制完了，限制内存。
其实PDB限制内存就是限制SGA等参数。
PDB操作，每个改自己的。
alter session set container=PDB7;
alter system set sga_target=1G SCOPE=BOTH;
即时生效，随改随用。无需重启。
最后是限制IO
PDB操作
alter session set container=PDB7;
ALTER SYSTEM SET max_iops=200 SCOPE=BOTH;
ALTER SYSTEM SET max_mbps=50 SCOPE=BOTH;
即时生效，随改随用。无需重启。
总结一下CPU、内存、IO，实测都可以、随改随用、收缩自如。即时生效，无需重启。之前只是研究怎么样，这次把生效的场景实测了一次。挺好配置。
据我所知虚拟化的时候加资源不需要重启，但是收缩资源的时候要重启服务器。
和大家讨论时候，有人提出说，当达到限制标准会限制他。这样限制以后会有副作用。有位领导说了，这哪里叫副总用，这叫起作用。我们目的就是要防止一个影响其他。
说到这里可能有朋友要问为什么不分成十几个数据库？技术上可以。但是10几个数据库必须每个按照峰值申请资源。大部分资源是浪费的。这些服务器不要钱吗？维护这些服务器就是N倍的服务钱啊。
当然SQL写好了，全在一个数据库中不同模块，不同schema。一套数据库我始终觉得99.99%的系统应该这样。各个系统之间的接口都省了。
无论什么数据库做出来的能节省运维成本的就是好的。
无论什么数据库做出来的能降低开发成本的就是好的。
