Oracle DB资源管理（2）

• 活动会话池机制

使用活动会话池功能，可以控制每个资源使用者组的最大并发活动会话数。使用此功能，由于资源的消耗与活动会话的数量成比例，所以DBA 能间接控制任何资源使用者组使用的资源量。使用活动会话池有助于减少从系统中获取资源的服务器数量，因而可以避免由于试图同时运行过多作业而导致的低效的分页、交换和其它资源损耗（如内存）。

使用活动会话填充活动会话池后，资源管理器对尝试成为活动会话的所有后续会话进行排队，直到其它活动会话完成或成为不活动会话。活动会话是事务处理、查询或并行操作中当前涉及的会话。单独的并行从属进程不被视为会话；而将整个并行操作视为一个活动会话。

每个资源使用者组只有一个队列，排队方法是先进先出(FIFO)，并带有超时。队列采用内存结构，不能直接查询。

• 设置活动会话池

使用Oracle EnterpriseManager 可以方便地配置资源计划的活动会话池设置。

例如，如果将APPUSER使用者组的活动会话的最大数量限制为50：

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.update_plan_directive(

plan => 'DEFAULT_PLAN',

group_or_subplan => 'APPUSER',

new_comment => '',

new_active_sess_pool_p1 => 50,

new_queueing_p1 => NULL,

new_parallel_degree_limit_p1 => NULL,

new_switch_group => '',

new_switch_time => NULL,

new_switch_estimate => false,

new_max_est_exec_time => NULL,

new_undo_pool => NULL,

new_max_idle_time => NULL,

new_max_idle_blocker_time => NULL,

mgmt_p1 => NULL, 

mgmt_p2 => NULL, 

mgmt_p3 => 60, 

mgmt_p4 => NULL, 

mgmt_p5 => NULL, 

mgmt_p6 => NULL, 

mgmt_p7 => NULL, 

mgmt_p8 => NULL,

switch_io_megabytes => NULL,

switch_io_reqs => NULL,

switch_for call);

dbms_resource_manager.submit_pending_area();

END; 

• 指定阈值

指定执行时间限制：

• 预先估计操作执行时间（通过基于成本的优化程序统计信息），默认值为：UNLIMITED

• 在资源使用者组级别指定最大估计执行时间

• 如果估计时间超过MAX_EST_EXEC_TIME:(ORA-07455)，则不允许启动大工作量作业

指定其它阈值：

• 使用SWITCH_IO_MEGABYTES限制会话I/O（以MB 表示）

• 使用SWITCH_IO_REQS限制会话I/O 请求

使用SWITCH_FOR_CALL返回原始使用者组（默认值：FALSE，使用者组未还原）

通过设置资源计划指令的MAX_EST_EXEC_TIME参数，可以定义任何给定时间发生的任何操作的最大估计执行时间。

• 设置了此参数后，数据库资源管理器将估计特定作业消耗的时间，该时间通过基于成本的优化程序的统计信息计算得出。

• 如果有多个计划指令引用了某个资源使用者组，则该组可能会有多个MAX_EST_EXEC_TIME。数据库资源管理器将选择所有传入值中限制性最强的那个值。

• 如果操作的估计时间超过MAX_EST_EXEC_TIME，则不启动操作并发出ORA-07455错误。这样可以消除任何占用过多系统资源的异常大的作业。

• SWITCH_IO_MEGABYTES指令指定在执行某项操作之前会话可发出的I/O 的量（以MB 为单位）。默认值为NULL，表示无限制。

• SWITCH_IO_REQS指令指定在执行某项操作之前会话可发出的I/O 请求的数量。默认值为NULL，表示无限制。

• SWITCH_FOR_CALL指令指定如果是因为SWITCH_TIME、SWITCH_IO_MEGABYTES或SWITCH_IO_REQS参数而执行某项操作，则在顶级调用结束时使用者组将还原至原始的使用者组。默认值是FALSE，表示在顶级调用结束时不还原原始的使用者组。

• 设置空闲超时

使用资源计划的“Idle Time（空闲时间）”选项卡可以设置资源计划的最大空闲超时。

“Max Idle Time (sec)（最长空闲时间(秒)）”和“Max Idle Time if Blocking Another Session (sec)（阻塞其他会话时的最大空闲时间(秒)）”分别等效于DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE过程中的NEW_MAX_IDLE_TIME和NEW_ MAX_IDLE_BLOCKER_TIME资源指令。这两项均以秒为单位。

NEW_MAX_IDLE_TIME指定会话既不处于执行状态也不处于等待I/O 状态的时间。会话超过指定的时限后，PMON进程将强制终止会话并清除其状态。除了限制会话的最大空闲时间外，还可以限制空闲会话阻塞其它会话的时间。通过NEW_MAX_IDLE_BLOCKER_TIME资源指令可以设置允许某个阻塞其它会话的会话处于空闲状态的秒数，以便强制实施此限制。还可以指定UNLIMITED值，表示不设置最大时间。默认值为NULL，表示无限制。这些设置提供了比概要文件更为精细的控制。在概要文件中，单一的值无法区分阻塞会话和非阻塞会话。

在示例中，PMON进程会终止空闲时间超过600 秒的会话。PMON进程还会终止空闲时间超过300 秒并且阻塞其它会话的会话。PMON每分钟检查一次这些限制，如果发现有会话超出了其中一个限制，便强制终止该会话并清除其所有资源。

• 限制数据库级别的CPU 占用率

数据库合并要求：

• 应用程序彼此孤立

• 性能一致

CPU 指令可用于：

• 为每个应用程序指定一个最小的CPU 分配

• 指定应该如何重新分配未使用的分配

• 指定MAX_UTILIZATION_LIMIT属性以便对CPU 

占用率实施绝对上限（这将覆盖计划内部的任何CPU 重新分配）

• 良好的候选应用程序：自动维护任务

对于并行数据库会话：数据库合并要求应用程序彼此孤立。当一个应用程序的工作量增加时，这种增加不应影响其它应用程序。此外，每个应用程序的性能还应保持一致。

固定策略CPU 资源管理

使用资源计划指令的MAX_UTILIZATION_LIMIT属性，可以对资源使用者组的CPU 占用率设置绝对上限。该绝对限制会覆盖计划内部的任何CPU 重新分配。

注：数据库合并的良好候选应用程序是自动维护任务，因为当前这些应用程序可占用100% 的服务器CPU 资源。您可以为每个自动任务使用者组设置一个最大限制。

• 限制数据库级别的CPU 占用率

MAX_UTILIZATION_LIMIT指令可限制应用程序的CPU 消耗。可以设置最小和最大边界，如图中所示。

图中的PL/SQL 示例在级别1 上为APP_1 使用者组指定了一个CPU 分配资源的最小值百分比(50%)。该示例还指定了同一使用者组允许的最大绝对CPU 占用率百分比(60%)。

示例使用了DB_CONSOLIDATION_PLAN计划。

可以为示例表中的每个使用者组执行类似命令。

注：在Oracle Database11gR2 之前的发行版中，隐式的最大占用率限制设置为100%。

• 限制服务器级别的CPU 占用率：实例限制

• 在运行多个数据库实例的多CPU 服务器上管理CPU 分配

• 启用实例限制功能：

– 启用任意CPU 资源计划。

alter system set resource_manager_plan='default_plan';

– 指定实例可随时使用的CPU 的最大数目。

alter system set cpu_count=4;

两种方法：

– 超量配置：每个实例的CPU 限制的总和超过实际的CPU 数目。

– 分区：每个实例的CPU 限制的总和等于实际的CPU数目。

因为许多测试、开发和小型生产数据库无法充分利用它们所在的服务器，所以服务器合并提供了一种可能的替代方法。使用服务器合并，可以通过在服务器上运行多个数据库实例来更充分地利用资源。但是，这可能会导致CPU 争用以及由于一个实例上的工作量激增而带来的负面影响。

实例限制是一种方法，该方法使用CPU_COUNT初始化参数来限制实例可使用的CPU 数目。此外，还可以利用资源管理器基于实例的资源计划为数据库会话分配CPU。

通过启用以下内容，分两步配置实例限制：

• 资源管理器，用于限制数据库实例消耗的CPU 的量

• CPU_COUNT参数，指定数据库实例可在任意时间使用的CPU 的最大量（限制），而不是实际的量

默认情况下，CPU 资源管理器假定数据库实例可使用服务器上的所有CPU。要启用实例限制，任何具有CPU 指令的资源计划皆可使用。

• 实例限制示例

超量配置方法：此方法适用于非关键性数据库和低负载、非关键性的生产系统。虽然实例相互影响彼此的性能，但是在任意给定的时间，都会有一个或多个实例可能处于闲置状态或者负载较低。

虽然数据库实例可相互影响彼此的性能，但是实例限制能够限制这种影响，并有助于提供可预测的性能。在左边的示例中，全部四个实例均将CPU_COUNT设置为4，数据库实例在任意时间点可占用的CPU 的最大百分比为数据库实例自己的限值除以所有活动数据库的限值总和。在本示例中，一个实例将能够消耗4 (4 + 4 + 4 + 4) = 25% 的CPU。如果只有两个实例处于活动状态，则一个实例将能够消耗4 (4 + 4) = 50% 的CPU。

分区方法：此方法适用于关键生产系统。它能够防止实例互相影响，并且提供可预测的性能。

实例限制可对CPU 资源进行分区，确保所有CPU 限值的总和不超过CPU 的总数。在右边的示例中，如果四个数据库实例共享一个具有16 个CPU 的服务器，则它们的限值可设置为8、4、2 和2。通过将CPU 资源专用于某个数据库实例，分区提供两个优点：

• 一个数据库实例的CPU 负载不会影响另一个数据库实例的CPU 负载。

• 每个数据库实例的CPU 资源是固定的，从而使性能的预测更加准确。

• 监视实例限制

查看CPU_COUNT参数的值：

SELECT value FROM v$parameter WHERE name ='cpu_count' 

AND (isdefault = 'FALSE' OR ismodified !='FALSE');

确认资源管理器的状态：

SELECT name FROM v$rsrc_plan 

WHERE is_top_plan = 'TRUE' AND cpu_managed= 'ON';

管理限制：

SELECT begin_time,consumer_group_name, 

cpu_consumed_time, cpu_wait_time 

FROM v$rsrcmgrmetric_history 

ORDER BY begin_time;

SELECT name, consumed_cpu_time,cpu_wait_time 

FROM v$rsrc_consumer_group;

• 如果未设置CPU_COUNT参数，第一个查询不会返回任何值。

• 如果第二个查询未返回任何行，表明资源管理器未管理CPU。如果返回了行，则表明存在活动的计划。

实例限制通过限制前台进程来限制前台进程的CPU 消耗。当前台进程在“resmgr:cpuquantum”等待事件中等待时，将限制该前台进程。

可以通过两种方法监视限制的量：

• V$RSRCMGRMETRIC_HISTORY视图显示过去一小时中每一分钟CPU 的消耗量(CPU_CONSUMED_TIME)和限制量(CPU_WAIT_TIME)。值以毫秒为单位进行显示。

• V$RSRC_CONSUMER_GROUP视图显示自CPU 资源管理启用以来CPU 的消耗量(CPU_CONSUMED_TIME)和限制量(CPU_WAIT_TIME)。时间以毫秒为单位进行显示。

• 资源使用者组映射

通过提供会话属性和使用者组之间的映射，可以将数据库资源管理器配置为自动将使用者组分配到会话。此外，还可以指定映射的优先级，从而指示在冲突时优先使用哪个映射。

有两种类型的会话属性：登录属性和运行时属性。登录属性（图中所示的“Attribute Mappings（属性映射）”列表中的最后五项）只在会话登录时有意义，此时数据库资源管理器将确定会话的初始使用者组。而会话登录后可以根据其运行时属性分配到其它使用者组。

在Database Control 主页中，导航到“Server（服务器）”选项卡页，然后单击“Resource Manager（资源管理器）”部分中的“Resource Consumer Group Mappings（资源使用者组映射）”链接。对于每个属性，设置由标识会话的方法（如用户名）和使用者组所组成的映射。根据需要，添加或删除每个资源使用者组类别所对应的行，并在相应组中输入用于标识用户、客户机、模块或服务的文本。使用“Priorities（优先级）”选项卡，可以建立冲突的属性映射之间的优先级顺序。使用导航箭头（幻灯片中突出显示）可以按重要性从

高到低的顺序设置优先级。列表顶部的映射优先级最高。

使用EM DatabaseControl，可以单击“Show SQL（显示SQL）”按钮，方便地查看操作生成的SQL。

以下示例为客户机OS 用户授予了比客户机程序更高的优先级：

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.set_consumer_group_mapping(

dbms_resource_manager.oracle_user,

'SCOTT',

'LOW_GROUP'

);

dbms_resource_manager.set_consumer_group_mapping_pri(

EXPLICIT => 1, SERVICE_MODULE_ACTION=> 2,

SERVICE_MODULE => 3,

MODULE_NAME_ACTION => 4,

MODULE_NAME => 5,

SERVICE_NAME => 6,

ORACLE_USER => 7,

CLIENT_OS_USER => 8,

CLIENT_PROGRAM => 9,

CLIENT_MACHINE => 10

);

dbms_resource_manager.submit_pending_area();

END; 

• 激活资源计划

使用Oracle EnterpriseManager 的“Plans（计划）”页可以管理资源计划。要激活计划，请选择所要激活的计划，在“Actions（操作）”下拉列表中选择“Activate（激活）”，然后单击“Go（执行）”。选定的计划将成为实例的当前最高计划。

使用RESOURCE_MANAGER_PLAN初始化参数

实例的计划是使用RESOURCE_MANAGER_PLAN数据库初始化参数定义的。此参数指定用于此实例的最高计划。如果没有指定计划，则不为实例激活资源管理器。

使用ALTER SYSTEM语句可以激活、停用或更改当前最高计划。使用此命令更改资源计划时，更改将立即生效。

如果在参数文件中设置了参数，并且未在数据库中定义指定的计划，则不能使用该参数文件打开数据库。此时将返回以下错误：

ORA-07452: specified resource manager plandoes not exist in the data dictionary

如果遇到此错误，则必须先修改参数以显示正确值，然后才能重新启动实例。

• 数据库资源管理器信息

若干数据字典视图可用于检查实例中声明的资源计划、使用者组和计划指令。本节讨论了可以从这些视图中获取的一些有用信息。

使用下列查询可获取有关数据库中定义的资源计划的信息：

sys@TEST0924> SELECT plan,num_plan_directives, status, mandatory FROM dba_rsrc_plans;

PLAN                          NUM_PLAN_DIRECTIVESSTATUS                        MAN

------------------------------------------------- ------------------------------ ---

DSS_PLAN                                                  8                               NO

ETL_CRITICAL_PLAN                                      8                              NO

MIXED_WORKLOAD_PLAN                            6                               NO

ORA$AUTOTASK_SUB_PLAN                           3                              YES

APPQOS_PLAN                                            8                              YES

DEFAULT_MAINTENANCE_PLAN                        4                              YES

DEFAULT_PLAN                                           4                              YES

INTERNAL_QUIESCE                                       2                              YES

INTERNAL_PLAN                                             1                              YES

ORA$AUTOTASK_HIGH_SUB_PLAN                      4                              YES

10 rows selected.

ACTIVE状态表示计划已经提交并且可供使用，而PENDING状态表示计划已经创建，但仍在暂挂区。

如果为mandatory列分配了YES值，则不能删除计划。

• 监视资源管理器

可以在会话级别监视数据库资源管理器的运行。此功能已集成在自动数据库诊断监视程序(ADDM) 中。

使用EM DatabaseControl 可以用不同的方法来管理和监视资源管理器。在“Server（服务器）”选项卡页上，单击“Resource Manager（资源管理器）”部分中的“Statistics（统计信息）”链接。

“Resource Monitors Statistics（资源监视器统计信息）”页显示一组描述活动资源计划当前状态的统计信息和图表。您可以查看当前活动计划的统计信息。

对于资源使用率，可以查看“消耗的CPU”、“每秒I/O 请求”和“每秒发出的I/O MB”。

另一图表显示“资源管理器导致等待”。还有“Queued Sessions（排队的会话）”、“AutomaticReprioritization（自动重设优先级）”以及空闲时间的统计信息。

• 监视资源管理器

• V$SESSION：包含显示会话的当前组的resource_consumer_group列

• V$RSRC_PLAN：显示活动资源计划的视图

• V$RSRC_CONSUMER_GROUP：包含所有活动组统计信息的视图

CPU 使用率

可以提供有关Oracle DB CPU 占用率信息的视图至少有以下三种：

• 如果运行的是Oracle DB 资源管理器，V$RSRC_CONSUMER_GROUP可以基于每个使用者组显示CPU 占用率的统计信息。此视图显示与当前活动的资源使用者组相关

的数据。

• V$SYSSTAT显示所有会话的Oracle DB CPU 使用率。“CPU used by this session（此会话使用的CPU）”统计信息显示所有会话使用的CPU 总计。

• V$SESSTAT显示每个会话的Oracle DB CPU 使用率。可以使用此视图确定占用CPU 最多的特定会话。

V$RSRC_CONSUMER_GROUP视图

下面简要描述了此视图中的部分列：

• name：使用者组的名称。

• active_sessions：此使用者组中的当前活动会话数。

• execution_waiters：等待时间片断的活动会话数。

• requests：此使用者组中累计执行的请求数。

• cpu_wait_time：会话等待CPU 的累计时间。

• consumed_cpu_time：所有会话累计消耗的CPU 时间。

没有任何视图可以直接显示活动会话池队列，但是可以通过以下对象获取一些信息：

• V$SESSION：current_queue_duration列显示会话的排队时间，如果会话当前没有排队，则显示0（零）。

• V$RSRC_CONSUMER_GROUP：queue_length列显示每个使用者组中当前排队的会话数。

• 小结

• 配置数据库资源管理器

• 访问和创建资源计划

• 创建使用者组

• 指定用于向使用者组分配资源的指令

• 将使用者组映射到计划

• 激活资源计划

• 监视资源管理器