2.Oracle PDB官方解读- PDB资源管理
会话使用不同的应用程序，但是后台使用相同的平台，导致竞争计算资源。
-
- 并发会话的数量
- CPU
- 使用ORACLE 并行服务的进程数量
- 文件IO
- 使用SGA和分配PGA
- 网络IO
一些客户想要对这些资源竞争进行完全控制，因此他们使用非CDB的方式，而是使用虚拟机，充分发挥操作系统虚拟化。但是这样的操作节省的费用超过了统一管理带来的开销。很多客户通过投资回报比发现，统一管理的投资回报比最大，因此使用基于SCHEMA的整合。
基于SCHEMA的整合可以使用资源管理。但是需要仔细制定计划，策略和训练，每个应用后端只能被那个为这个应用创建的服务使用。
对于基于SCHEMA的整合，只有人才知道应用后端的界限；ORACLE不知道这个。
使用基于PDB整合，PDB提供了一个功能强大的机制可以让管理员告诉ORACLE界限在哪里。每个应用后台安装在各自的PDB，一个应用后端对应一个PDB。
资源管理在多租户中进行了加强，实现通过CDB层面来管理PDB的资源竞争。
- CDB层级
在12.1的CDB层级，控制包括
- 并发会话数量
- CPU
- 并行服务进程
- FILE IO （Exadata）
不能控制网络IO
PDB关于RAC的亲和度，可以用来粗颗粒度控制SGA和PGA内存。
- 共享和封顶模式
资源管理实现了基于两点的工业级别：share和cap.
每个竞争者都被分配了一些贡献个资源，从0到一个正整数（但是任何操作10个数字可能没有用）。同一时刻，只有一些竞争者是激活的。每个激活的竞争者获取 n/t 被管理的资源，
N是被分配到竞争者的共享资源数量，T是总共被分配到当前竞争者的共享资源。
任何竞争者 可以设定一个cap。是一个从0到1 的因子，也是百分比。一个设置CAP的的竞争者不会获得比这个因子更多的资源。当然，竞争者可能获得比限定因子的资源少的，取决于当前资源分配。
Share的价值是明显的，这是资源管理的必要条件。
CAP的价值在 多个竞争者逐步增加到计划的数量的时候会体现。它确保可实现最终计划，而不用设置错误的异常。用户对于性能提升是很高心的，如果只是将一个应用从一个机器移到另一个高功能，未限定，最初只有一个应用的机器上。但是，由于内存有限，越来越多的因公移动到整合的机器上后，发现应用的性能，越来越差了。所以有必要进行限制应用的性能，从第一个迁移到整合机器，到最后完成整个。
在PDBs 的资源管理之间，当一个PDB创建的时候，它被默认分配了一个共享而没有限制。
- CDB层面 管理会话、CPU、ORACLE并行和文件IO
当一个计划制定或修改，会立马影响所有当前的会话。
会话限制是通过设置sessions 初始化参数的。
CPU和FILE IO 通过使用 shares和caps机制来管理的。
细颗粒度会话调用每100ms操作一次。
-
- 举例
从CDB层面配置一个share给PDB1，三个shares给PDB2。
DBMS_Resource_Manager.Create_CDB_Plan(
'My_Plan', 'some comment');
DBMS_Resource_Manager.Create_CDB_Plan_Directive(
'My_Plan', 'PDB1', Shares => 1);
DBMS_Resource_Manager.Create_CDB_Plan_Directive(
'My_Plan', 'PDB2', Shares => 3);
设置上限，PDB1 20%, PDB2 50%。
使用ORALCE并行服务进程 也可以通过同样的shares模型来控制。参数parallel_degree_policy初始化参数必须设置为AUTO。 足够多的SQL语句并行执行让整个机器繁忙，SQL语句的排队避免了并行度降级。CAP有自己独立的参数 parallel_server_limit参数在DBMS_RESOURSE_MANAGER中create_cdb_plan_directive 子程序，new_parallel_server_limit 参数在 update_cdb_pan_directive 子程序。
- PDB对RAC实例的亲和度
PDB的打开模式可以是MOUNTED,READ OLY或READ WRITE。当一个CDB有8个PDB配置成RAC数据库，使用8个实例。那个每个PDB可以被一个RAC 实例打开，每个RAC实例打开一个PDB。 这样提供了最大的资源隔离。这个也和PDB 共享SGA和后台进行的高度整合进行了妥协。
一个合理的PDB对RAC实例的亲和度使用是，一个CDB有几百个PDBs或者更多。前25%的处理能力亲和到75%的RAC实例，剩余的75%处理能力留给 25%的RAC 实例。