Oracle多租户环境中如何有效管理PDB资源？

来源：Vuejs教程作者：小师妹头衔：草根站长

导读：本期聚焦于小师妹创作的《Oracle多租户环境中如何有效管理PDB资源？》，敬请观看详情。单个PDB的CPU突发会不会把整个CDB实例拖垮？在Oracle多租户架构中，所有PDB共享同一组后台进程、内存区域和I/O带宽，资源竞争几乎无法避免。本文直接切入Oracle Resource Manager在PDB级别的隔离机制，解释CDB资源计划与PDB资源计划如何协同工作，并给出创建计划指令、设置份额、限制CPU使用率、配置消费组的完整PL/SQL脚本。同时覆盖I/O资源管理参数和关键监控视图，帮助DBA避免一个PDB的批量任务影响其他租户的响应时间，实现可预测的服务质量。

在Oracle多租户数据库中，多个PDB共享CDB实例的CPU、内存、会话和I/O资源。如果一个PDB内部出现失控的批量作业或大量并发查询，它可能快速耗尽实例级别的CPU和I/O能力，导致其他PDB中的交易型业务响应时间急剧上升。Oracle Resource Manager为此提供了两级资源管理框架：在CDB级别管理PDB之间的资源竞争，在PDB级别管理单个租户内部消费组之间的资源竞争。通过定义资源计划、计划指令和消费组映射，DBA可以精确控制每个PDB能够获得的最大CPU比例、并行度上限、活动会话数量以及I/O吞吐量。

资源管理的核心对象包括CDB资源计划、CDB计划指令、PDB资源计划、PDB计划指令以及消费组。CDB资源计划由多条指令组成，每条指令面向一个PDB或PDB组，指定其资源份额、并行服务器上限、内存限制以及I/O限制。PDB资源计划则在单个PDB内部生效，控制不同消费组之间的CPU和I/O分配。两种计划可以同时启用，但最终给到某个会话的资源上限由两级限制共同决定。

CDB资源计划与PDB资源计划的关系

CDB资源计划管理整个容器数据库范围内的资源分配。当DBA创建一个CDB资源计划时，实际上是在定义CDB实例中各个PDB对应的资源消费组之间的竞争规则。每个PDB在CDB层面都被视为一个独立的资源消费组，CDB计划指令通过SHARES、UTILIZATION_LIMIT、PARALLEL_SERVER_LIMIT等参数来描述该PDB可以获得的资源比例。SHARES是一个相对权重值，当多个PDB争用CPU时，Oracle根据各自SHARES的比例来分配CPU时间片。例如PDB1的SHARES为3，PDB2的SHARES为1，那么在CPU压力较大时，PDB1大约能获得75%的CPU资源，PDB2获得25%。

UTILIZATION_LIMIT则是一个绝对上限，它限制了PDB可以占用的实例CPU百分比。该参数取值1到100，例如设置为50表示该PDB最多只能使用实例总CPU的50%，即使其他PDB处于空闲状态，这个限制也不会被突破。PARALLEL_SERVER_LIMIT用于限制PDB内所有并行执行服务器进程占用的实例总并行服务器数量的百分比，避免单个PDB的并行查询耗尽整个实例的并行资源。

PDB资源计划的作用范围仅限于单个可插拔数据库内部。它允许DBA在PDB内部创建多个消费组，将不同类型的工作负载映射到不同消费组，并为每个消费组分配CPU、I/O等资源。PDB资源计划不能突破CDB计划给该PDB设定的资源上限。例如CDB计划指令将PDB1的UTILIZATION_LIMIT设为50，那么PDB1内部无论定义多宽松的PDB资源计划，其整体CPU使用都不会超过实例总CPU的50%。

创建CDB资源计划与计划指令

创建CDB资源计划需要使用DBMS_RESOURCE_MANAGER包，并在挂起区域中完成所有定义，最后统一验证并提交。挂起区域相当于一个暂存区，只有提交后才会实际生效。下面的PL/SQL块演示了如何创建一个简单的CDB资源计划，为三个PDB分别设置不同的资源份额和CPU上限。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
    plan    => 'CDB_LIMIT_PLAN',
    comment => 'CDB resource plan for PDB isolation'
  );

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'CDB_LIMIT_PLAN',
    pluggable_database    => 'PDB1',
    shares                => 3,
    utilization_limit     => 50,
    parallel_server_limit => 30
  );

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'CDB_LIMIT_PLAN',
    pluggable_database    => 'PDB2',
    shares                => 1,
    utilization_limit     => 20,
    parallel_server_limit => 10
  );

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'CDB_LIMIT_PLAN',
    pluggable_database    => 'PDB3',
    shares                => 2,
    utilization_limit     => 30,
    parallel_server_limit => 20
  );

  DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

上述代码首先清空并创建挂起区域，然后创建名为CDB_LIMIT_PLAN的CDB资源计划。CREAT_CDB_PLAN_DIRECTIVE过程为每个PDB定义指令，pluggable_database参数指定目标PDB名称。注意PDB名称是大小写敏感的，如果PDB创建时使用了带引号的名称，这里必须完全匹配。提交之前调用VALIDATE_PENDING_AREA检查配置是否正确，如果存在无效指令会抛出异常，此时可以修正后再次验证。

计划提交后，还需要激活它。可以通过初始化参数RESOURCE_MANAGER_PLAN来指定实例启动时自动启用的资源计划，也可以使用ALTER SYSTEM命令动态切换。例如执行ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'CDB_LIMIT_PLAN';即可立即启用。如果希望该计划在实例重启后仍然生效，需要同时修改SPFILE中的参数值。

PDB内部的消费组与资源计划配置

在单个PDB内部，Resource Manager同样可以发挥精细控制的作用。一个PDB中通常会运行多种工作负载，比如在线事务处理、报表查询、批量加载等。通过创建不同的消费组，并将会话按照服务名、模块名、操作名或客户端程序映射到相应消费组，就能为不同负载设置独立的资源上限。PDB资源计划的创建仍然通过DBMS_RESOURCE_MANAGER包完成，但使用的过程不同。

下面的示例在PDB1内部创建两个消费组OLTP_GROUP和BATCH_GROUP，然后创建一个PDB资源计划PDB_PLAN_LIMIT，并为两个消费组设置CPU资源分配。其中OLTP_GROUP获得70%的CPU份额，BATCH_GROUP获得30%。同时限制BATCH_GROUP的最大并行度为10。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'OLTP_GROUP',
    comment        => 'Online transaction processing group'
  );

  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'BATCH_GROUP',
    comment        => 'Batch and reporting group'
  );

  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    plan    => 'PDB_PLAN_LIMIT',
    comment => 'PDB level resource plan'
  );

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan             => 'PDB_PLAN_LIMIT',
    group_or_subplan => 'OLTP_GROUP',
    mgmt_p1          => 70,
    parallel_degree_limit_p1 => 20
  );

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan             => 'PDB_PLAN_LIMIT',
    group_or_subplan => 'BATCH_GROUP',
    mgmt_p1          => 30,
    parallel_degree_limit_p1 => 10
  );

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan             => 'PDB_PLAN_LIMIT',
    group_or_subplan => 'OTHER_GROUPS',
    mgmt_p1          => 0
  );

  DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

PDB资源计划中必须为OTHER_GROUPS消费组定义指令，否则验证会失败。OTHER_GROUPS是系统自动创建的默认消费组，所有未被其他规则映射的会话都会进入该组。在上面的示例中，我们给OTHER_GROUPS设置了0的CPU份额，这意味着如果OLTP_GROUP和BATCH_GROUP已经占满资源，其他会话将无法获得额外CPU时间。

为了让会话自动进入指定消费组，需要配置消费组映射规则。使用SET_CONSUMER_GROUP_MAPPING过程可以基于服务名、模块名、操作名等属性将会话路由到目标消费组。下面的代码将所有通过服务名BATCH_SVC连接的会话映射到BATCH_GROUP。

BEGIN
  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    attribute      => DBMS_RESOURCE_MANAGER.SERVICE_NAME,
    value          => 'BATCH_SVC',
    consumer_group => 'BATCH_GROUP'
  );
END;
/

映射规则可以设置优先级，当多个规则同时匹配一个会话时，Oracle按照优先级从高到低应用。常见属性包括CLIENT_OS_USER、CLIENT_PROGRAM、MODULE_NAME、SERVICE_NAME、ORACLE_USER等。合理设计映射规则能够让资源管理自动化，减少手动切换消费组的操作。

I/O资源限制与监控手段

CPU并不是多租户环境中唯一需要管理的资源。PDB上的大规模数据加载或全表扫描可能产生极高的I/O吞吐，拖慢整个存储系统，进而影响其他PDB的数据访问延迟。Oracle Resource Manager支持在CDB计划指令和PDB计划指令中设置I/O限制参数，包括MAX_IOPS和MAX_MBPS。MAX_IOPS限制每秒I/O操作次数，MAX_MBPS限制每秒I/O吞吐量，单位是兆字节每秒。这两个参数可以在CREAT_CDB_PLAN_DIRECTIVE或CREAT_PLAN_DIRECTIVE过程中添加。

例如，给PDB2设置每秒最多2000次I/O操作和每秒100MB的吞吐量，可以在创建CDB计划指令时加入max_iops和max_mbps参数。I/O限制功能依赖于Oracle数据库的I/O资源管理器，在Exadata或普通文件系统上都可以工作，但需要设置相应的统计收集机制。启用I/O资源管理后，Oracle会监控每个PDB或消费组的I/O请求并强制实施限制，超出限制的I/O请求会被延迟处理。

监控资源使用情况是调整计划的基础。视图V$RSRC_PDB_METRIC记录每个PDB的CPU使用时间、等待时间、I/O请求数等指标；V$RSRCMGRMETRIC则提供消费组级别的资源消耗统计。下面的查询可以查看各个PDB的CPU分配百分比和实际平均CPU利用率。

SELECT pdb_name,
       cpu_consumed_time,
       avg_cpu_utilization,
       iops,
       mbps
FROM   V$RSRC_PDB_METRIC
ORDER BY pdb_name;

通过这些监控数据，DBA可以判断某个PDB是否频繁触达资源上限，或者某个消费组是否长期处于饥饿状态。如果发现CPU利用率持续接近UTILIZATION_LIMIT设定的值，可能需要调整计划指令中的限制参数。如果某个PDB的I/O延迟明显升高，可以检查MAX_IOPS是否设置过低，或者存储子系统本身是否已经饱和。

常见配置错误与最佳实践

在实施PDB资源管理时，有几个常见的配置误区值得注意。第一是忘记提交挂起区域。很多DBA在创建计划指令后直接查询数据字典，发现配置没有生效，原因就是没有执行SUBMIT_PENDING_AREA。第二是CDB资源计划与PDB资源计划重复设置CPU限制，导致资源被过度约束。例如CDB级别将PDB1的UTILIZATION_LIMIT设为50，PDB内部又将某个消费组的CPU限制设为40，那么该消费组最多只能使用实例总CPU的20%。第三是资源计划启用后没有验证实际效果，仅凭理论值进行判断，最终导致关键业务响应变慢。

最佳实践建议从保守的限制值开始，逐步收紧或放宽。对于生产环境，可以先为所有PDB设置相同的SHARES值，然后根据业务优先级调整权重。关键交易型PDB应该设置较高的SHARES和较低的UTILIZATION_LIMIT，以保证突发负载时仍有资源可用。批量处理型PDB则可以设置较低的SHARES，但允许其在系统空闲时使用更多资源。I/O限制参数在OLTP环境中尤其重要，因为存储争用往往比CPU争用更隐蔽。

此外，建议为每个PDB设置默认打开的PDB资源计划，这样PDB在每次打开时自动启用内部计划，避免因遗漏手动启用而导致消费组规则失效。可以使用ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'PDB_PLAN_LIMIT' SCOPE = BOTH;在PDB内部执行，或在CDB中使用ALTER PLUGGABLE DATABASE语句配合初始化参数实现。定期检查V$RSRC_PDB_METRIC和V$RSRCMGRMETRIC视图，结合AWR报告中的资源等待事件，评估资源计划是否达到了预期的隔离效果，并根据实际负载动态优化各项参数。

Oracle PDB资源管理多租户数据库 Resource Manager修改时间：2026-08-19 10:47:41

免责声明：已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰，观点力求客观中立。本站旨在免费分享，内容仅供个人学习、研究或参考使用。若引用了第三方作品，版权归原作者所有。如内容涉及您的权益，请联系我们处理。