Oracle Database Resource Managerを使用したリソースの管理

26.1.3.2 リソース・コンシューマ・グループの概要

リソース・コンシューマ・グループ(コンシューマ・グループ)とは、処理要件に基づいてグループ化されたユーザー・セッションの集合です。

セッションが作成されると、そのセッションは、管理者が設定したマッピング・ルールに基づいてコンシューマ・グループに自動的にマップされます。データベース管理者(DBA)は、セッションを、異なるコンシューマ・グループに手動で切り替えることができます。同様に、アプリケーションでは、そのセッションを特定のコンシューマ・グループに切り替えるPL/SQLパッケージ・プロシージャを実行できます。

リソース・マネージャによるリソース(CPUなど)の割当て先は、コンシューマ・グループのみであるため、セッションがコンシューマ・グループのメンバーになると、そのリソース割当ては、コンシューマ・グループの割当てによって決定されます。

常にデータ・ディクショナリに存在する特別なコンシューマ・グループがあります。これらのグループは、変更したり削除することはできません。これらを次に示します。

SYS_GROUP

これは、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションの初期コンシューマ・グループです。この初期コンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールで上書きできます。
OTHER_GROUPS

このコンシューマ・グループには、コンシューマ・グループに割り当てられていないすべてのセッションが含まれます。すべてのリソース・プランにOTHER_GROUPSへのディレクティブが含まれている必要があります。

アクティブなプランに含まれるリソース・コンシューマ・グループ数は、28以内にする必要があります。

PDBのコンシューマ・グループ
CDBでは、バックグラウンド・タスクおよび管理タスクが、これらのタスクを最適に実行するリソース・マネージャのコンシューマ・グループにマップされます。

26.1.3.2.1 PDBのコンシューマ・グループ

CDBでは、バックグラウンド・タスクおよび管理タスクが、これらのタスクを最適に実行するリソース・マネージャのコンシューマ・グループにマップします。

リソース・マネージャでは、次のルールを使用して、コンシューマ・グループにタスクをマップします。

タスクは、このタスクを開始するコンテナ内のコンシューマ・グループにマップされます。

タスクがCDBルートで開始される場合、このタスクはCDBルート内のコンシューマ・グループにマップします。タスクがPDBで開始される場合、このタスクはPDB内のコンシューマ・グループにマップします。
多くのメンテナンス・タスクおよび管理タスクは、コンシューマ・グループに自動的にマップします。

たとえば、自動化されたメンテナンス・タスクはORA$AUTOTASKにマップします。特定の状況では、タスクはコンシューマ・グループにマップしますが、マッピングは変更可能です。このようなタスクとしては、RMANバックアップ、RMANイメージ・コピー、Oracle Data Pumpおよびメモリー内移入があります。

注意:

事前定義のコンシューマ・グループのマッピング・ルールの詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: リソース・コンシューマ・グループの概要

26.1.3.3 リソース・プラン・ディレクティブの概要

リソース・マネージャは、現在アクティブなリソース・プランに属するリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースをコンシューマ・グループに割り当てます。

リソース・プランとそのリソース・プラン・ディレクティブは親子関係にあります。各ディレクティブは1つのコンシューマ・グループを参照し、現在アクティブなプランの2つのディレクティブで同じコンシューマ・グループを参照することはできません。

ディレクティブには、コンシューマ・グループへのリソース割当てを制限できる複数の方法があります。たとえば、CPUにおいてコンシューマ・グループが確保できるCPU全体の割合を制御したり、コンシューマ・グループ内でアクティブにできるセッションの総数を制限できます。

CDBリソース・プランにより、そのリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースがそのPDBに割り当てられます。CDBリソース・プランとそのリソース・プラン・ディレクティブは親子関係にあります。各ディレクティブは、パフォーマンス・プロファイル内の一連のPDBまたは単一のPDBのいずれかを参照します。同じCDB内の個々のPDBおよびPDBパフォーマンス・プロファイルの両方にディレクティブを指定できます。現在アクティブなプランの2つのディレクティブで同じPDBまたは同じPDBパフォーマンス・プロファイルを参照することはできません。

リソース・マネージャによって管理されるリソース
リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。
PDBのリソース・プラン・ディレクティブ
ディレクティブは、CPUとパラレル実行サーバーの割当てを制御します。
PDBのパフォーマンス・プロファイル
PDBパフォーマンス・プロファイルは、同じ優先度およびリソース制御が指定された一連のPDBにリソース・プラン・ディレクティブを構成します。

26.1.3.3.1 リソース・マネージャによって管理されるリソース

リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。

CPU
CPUリソースを管理するために、リソース・マネージャはリソースをコンシューマ・グループに割り当て、割り当てられたものの使用されなかったCPUリソースを再配分します。特定のコンシューマ・グループに割り当てることができるCPUリソースの量に制限を設定することもできます。
Exadata I/O
管理属性を使用すると、Exadata I/OのCPUリソース割当てを指定できます。
パラレル実行サーバー
リソース・マネージャでは、データベースに対して使用可能なパラレル実行サーバーの使用を管理できます。
プログラム・グローバル領域(PGA)
PGAリソースを管理するために、リソース・マネージャは特定のコンシューマ・グループ内の各セッションに割り当てることのできるPGAメモリーの量を制限できます。
リソース集中型の問合せ
リソース集中型のセッションおよびコールは、適切に管理されない場合、パフォーマンス全体に悪影響を及ぼす可能性があります。リソース・マネージャでは、セッションまたはコールが指定量を超えるCPU、物理I/O、論理I/Oまたは経過時間を使用したときに処理を行うことができます。リソース・マネージャでは、セッションまたはコールをCPUの割当てが少ないコンシューマ・グループに切り替えたり、セッションまたはコールを終了できます。
キューイングを備えたアクティブ・セッション・プール
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが定義されます。
UNDOプール
UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールは、コンシューマ・グループが生成できる、コミットされていないトランザクションに対するUNDO合計量を制御します。
アイドル時間制限
セッションがアイドル状態のままでいられる時間(セッションが終了されるまでの時間)を指定できます。

親トピック: リソース・プラン・ディレクティブの概要

26.1.3.3.1.1 CPU

CPUリソースを管理するために、リソース・マネージャはリソースをコンシューマ・グループに割り当て、割り当てられたものの使用されなかったCPUリソースを再配分します。特定のコンシューマ・グループに割り当てることができるCPUリソースの量に制限を設定することもできます。

管理属性
管理属性では、コンシューマ・グループおよびサブプランの間でのCPUリソースの割当て方法を指定します。
使用率制限
UTILIZATION_LIMIT属性は、リソース・コンシューマ・グループのCPU使用率に絶対上限を設定する場合に使用します。この絶対的な制限により、プラン内でのCPUの再配布は無視されます。

26.1.3.3.1.1.1 管理属性

管理属性では、コンシューマ・グループおよびサブプランの間でのCPUリソースの割当て方法を指定します。

複数レベル(最大8レベル)のCPUリソース割当てによって、プラン内でCPU使用の優先度を設定できます。レベル2のコンシューマ・グループとサブプランは、レベル1に割り当てられなかったリソース、またはレベル1に割り当てられたがレベル1のコンシューマ・グループまたはサブプランで完全には使用されなかったリソースを取得します。同様に、レベル3のリソース・コンシューマには、レベル1と2の割当ての一部が残っている場合のみ、リソースが割り当てられます。リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、割合およびレベルで構成されます。複数のレベルを使用すると、優先度を設定できるのみでなく、すべての主リソースと残りのリソースの使用方法を明示的に指定できます。

管理属性MGMT_Pn(nは1から8の整数)は、複数レベルのCPUリソース割当てを指定する場合に使用します。たとえば、MGMT_P1ディレクティブ属性を使用してレベル1でCPUリソース割当てを指定し、MGMT_P2ディレクティブ属性を使用してレベル2でリソース割当てを指定します。

パラレル・ステートメント・キューイングを制御するには、管理属性とともに、並列度制限やパラレル・サーバー制限などのパラレル・ステートメント・ディレクティブ属性を使用します。パラレル・ステートメント・キューイングが使用されている場合、管理属性はどのコンシューマ・グループが次のパラレル・ステートメントを発行できるかを決定するために使用されます。たとえば、コンシューマ・グループのMGMT_P1ディレクティブ属性を80に設定した場合、そのグループが次のパラレル・ステートメントを発行する確率は80%になります。

関連項目:

パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

表26-1に、3つのレベルがある単純なリソース・プランを示します。

表26-1 3つのレベルがある単純なリソース・プラン

コンシューマ・グループ	レベル1のCPU割当て	レベル2のCPU割当て	レベル3のCPU割当て
`HIGH_GROUP`	80%
`LOW_GROUP`		50%
`MAINT_SUBPLAN`		50%
`OTHER_GROUPS`			100%

優先度の高いアプリケーションは、CPUの80%が割り当てられるHIGH_GROUPで実行されます。HIGH_GROUPはレベル1であるため、CPU使用率の優先度がありますが、最大でCPUの80%のみです。CPUの残りの20%は、レベル2のLOW_GROUPとMAINT_SUPLANによって50%ずつ共有されます。レベル1と2で未使用の割当ては、レベル3のOTHER_GROUPSで使用できます。OTHER_GROUPSには同じレベルに兄弟関係のあるコンシューマ・グループやサブプランがないため、100%が指定されます。

特定のレベル内で、CPU割当ては固定ではありません。特定のコンシューマ・グループまたはサブプランでの負荷に余裕がある場合、残りのCPUを残りのコンシューマ・グループまたはサブプランに割り当てることができます。したがって、レベルが1つのみの場合、あるコンシューマ・グループまたはサブプランが使用していない割当ては、兄弟関係のある他のコンシューマ・グループまたはサブプランに再配分できます。複数のレベルがある場合、未使用の割当ては次のレベルのコンシューマ・グループまたはサブプランに再配分されます。最後のレベルに未使用の割当てがある場合、それらの割当ては他のすべてのレベルに、それぞれに指定された割当てに比例して再配分できます。

未使用の割当ての1つのレベルから他のレベルへの再配分の例として、特定の期間で、HIGH_GROUPがCPUの25%のみを使用した場合、LOW_GROUPとMAINT_SUBPLANで75%を共有できます。レベル2での75%の未使用部分は、レベル3のOTHER_GROUPSが使用できるようになります。ただし、レベル3でOTHER_GROUPSにセッション・アクティビティがない場合は、レベル2での75%はプランの他のすべてのコンシューマ・グループおよびサブプランに比例で再配分できます。

親トピック: CPU

26.1.3.3.1.1.2 使用率制限

UTILIZATION_LIMIT属性は、リソース・コンシューマ・グループのCPU使用率に絶対上限を設定する場合に使用します。この絶対的な制限により、プラン内でのCPUの再配布は無視されます。

前の使用例で、他の部分が非アクティブであるために、LOW_GROUPがCPUの90%を取得したとします。重要ではないセッションにCPUを大量に使用させないために、LOW_GROUPがサーバーの90%を使用できないようにするとします。リソース・プラン・ディレクティブのUTILIZATION_LIMIT属性を使用して、この状況を防ぐことができます。

UTILIZATION_LIMIT属性の設定はオプションです。コンシューマ・グループに対するこの属性を省略した場合は、コンシューマ・グループが使用できるCPUの量に制限はありません。このため、他のすべてのアプリケーションがアイドル状態である場合、UTILIZATION_LIMITが設定されていないコンシューマ・グループに100%のCPUリソースを割り当てることができます。

レベルの制限を使用しないで、コンシューマ・グループのCPU使用率を制限する唯一の手段としてUTILIZATION_LIMIT属性を使用することもできます。

表26-2に、前のプランを変更したプランを示します。このプランでは、UTILIZATION_LIMITを使用して、CPU使用率の上限をLOW_GROUPの場合は75%、MAINT_SUBPLANの場合は50%、OTHER_GROUPSの場合は75%に設定します。(使用率の制限の合計が100%を超える場合があります。各制限は個別に適用されます。)

表26-2 使用率制限が適用された3つのレベルがあるリソース・プラン

コンシューマ・グループ	レベル1のCPU割当て	レベル2のCPU割当て	レベル3のCPU割当て	使用率制限
`HIGH_GROUP`	80%
`LOW_GROUP`		50%		75%
`MAINT_SUBPLAN`		50%		50%
`OTHER_GROUPS`			100%	75%

表26-2で説明する例では、HIGH_GROUPが特定の時間にCPUの10%のみを使用している場合、残りの90%をLOW_GROUPおよびMAINT_SUBPLANのコンシューマ・グループがレベル2で使用できます。LOW_GROUPがCPUの20%のみを使用している場合、70%をMAINT_SUBPLANに割り当てることができます。ただし、MAINT_SUBPLANではUTILIZATION_LIMITを50%に設定します。このため、より多くのCPUリソースが使用可能である場合も、サブプランMAINT_SUBPLANに属するコンシューマ・グループには50%を超えたCPUを割り当てることができません。

サブプランとそのサブプランに含まれているコンシューマ・グループの両方にUTILIZATION_LIMITを設定できます。このような場合、コンシューマ・グループの制限はサブプランとそのコンシューマ・グループに指定されている制限を使用して算出されます。たとえば、MAINT_SUBPLANには、コンシューマ・グループMAINT_GROUP1とMAINT_GROUP2が含まれています。MAINT_GROUP1のUTILIZATION_LIMITは40%に設定されています。ただし、MAINT_SUBPLANの制限は50%に設定されています。このため、コンシューマ・グループMAINT_GROUP1の制限は50%の40%、つまり20%になります。コンシューマ・グループとそのグループが属するサブプランの両方に制限が指定されている場合に、コンシューマ・グループのUTILIZATION_LIMITを計算する方法の例については、「例4 - コンシューマ・グループおよびサブプランに使用率制限を指定する」を参照してください。

関連項目:

親トピック: CPU

26.1.3.3.1.2 Exadata I/O

管理属性を使用すると、Exadata I/OのCPUリソース割当てを指定できます。

関連項目:

Exadataの入出力に関する管理属性の使用の詳細は、Exadataのドキュメントを参照してください。

26.1.3.3.1.3 パラレル実行サーバー

リソース・マネージャでは、データベースに対して使用可能なパラレル実行サーバーの使用を管理できます。

並列度制限
管理者は、1つのコンシューマ・グループ内での操作に対して最大並列度を制限できます。PARALLEL_DEGREE_LIMIT_P1ディレクティブ属性は、コンシューマ・グループの並列度を指定する場合に使用します。
パラレル・サーバー制限
PARALLEL_SERVER_LIMITディレクティブ属性は、特定のコンシューマ・グループが使用できるパラレル実行サーバー・プールの最大割合を指定する場合に使用します。特定のコンシューマ・グループで使用されているパラレル実行サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル実行サーバーの合計となります。
パラレル・キューのタイムアウト
PARALLEL_QUEUE_TIMEOUTディレクティブ属性を使用すると、パラレル・ステートメントがパラレル・ステートメント・キュー内でタイムアウトになるまで待機する最大時間を秒単位で指定できます。

26.1.3.3.1.3.1 並列度制限

管理者は、1つのコンシューマ・グループ内での操作に対して最大並列度を制限できます。PARALLEL_DEGREE_LIMIT_P1ディレクティブ属性は、コンシューマ・グループの並列度を指定する場合に使用します。

並列度制限は、コンシューマ・グループ内の1つの操作に対して適用されます(コンシューマ・グループ内のすべての操作の合計並列度は制限されません)。ただし、PARALLEL_DEGREE_LIMIT_P1とPARALLEL_SERVER_LIMITの両方のディレクティブ属性を組み合せて、任意の制御を行うことは可能です。PARALLEL_SERVER_LIMIT属性の詳細は、「パラレル・サーバー制限」を参照してください。

関連項目:

プロデューサ/コンシューマ操作での並列度の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

親トピック: パラレル実行サーバー

26.1.3.3.1.3.2 パラレル・サーバー制限

PARALLEL_SERVER_LIMITディレクティブ属性は、特定のコンシューマ・グループが使用できるパラレル実行サーバー・プールの最大割合を指定する場合に使用します。特定のコンシューマ・グループで使用されているパラレル実行サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル実行サーバーの合計となります。

単一のコンシューマ・グループが数多くのパラレル・ステートメントを起動することによって、使用可能なすべてのパラレル実行サーバーが使用されることがあります。この場合、別のコンシューマ・グループから優先度の高いパラレル・ステートメントが実行されても、このグループにパラレル実行サーバーを割り当てることができません。このような状況を回避するには、特定のコンシューマ・グループが使用できるパラレル実行サーバーの数を制限します。優先度の高いコンシューマ・グループに対してディレクティブPARALLEL_STMT_CRITICALをBYPASS_QUEUEに設定し、そのコンシューマ・グループのパラレル・ステートメントがパラレル・ステートメント・キューを無視するように設定することもできます。

たとえば、PARALLEL_SERVERS_TARGET初期化パラメータによって設定されたパラレル実行サーバーの合計数が32であり、コンシューマ・グループMY_GROUPのPARALLEL_SERVER_LIMITディレクティブ属性が50%に設定されているとします。このコンシューマ・グループは最大で32の50%、つまり16台のパラレル実行サーバーを使用できます。

リソース・プランで管理属性(MGMT_P1、MGMT_P2など)が設定された場合は、管理属性ごとに別々のパラレル・ステートメント・キューが先入れ先出し(FIFO)キューとして管理されます。

リソース・プランで管理属性が設定されない場合は、1つのパラレル・ステートメント・キューがFIFOキューとして管理されます。

Oracle Real Application Clusters (Oracle RAC)環境の場合、パラレル実行サーバーのターゲット数はすべてのOracle RACインスタンスでの(PARALLEL_SERVER_LIMIT * PARALLEL_SERVERS_TARGET /100)の合計となります。あるコンシューマ・グループによって、前述のように算出した数以上のパラレル実行サーバーが使用されている場合、そのコンシューマ・グループは制限値を超えているため、そのコンシューマ・グループのパラレル・ステートメントはキューされます。

コンシューマ・グループにOracle RACデータベース内で実行されているパラレル・ステートメントがない場合、最初のパラレル・ステートメントはPARALLEL_SERVER_LIMITで指定された制限を超えることができます。

注意:

Oracle Real Application Clusters (Oracle RAC)環境では、PARALLEL_SERVER_LIMIT属性が単一のインスタンスではなくクラスタ全体に適用されます。

パラレル・サーバー制限を使用したパラレル・ステートメント・キューイングの管理
PARALLEL_SERVER_LIMIT属性を使用すると、いつコンシューマ・グループからパラレル・ステートメントをキューできるかを指定できます。Oracle Databaseには、コンシューマ・グループごとにパラレル・ステートメント・キューが保持されます。

関連項目:

「リソース・プラン・ディレクティブの作成」
「パラレル・サーバー制限を使用したパラレル・ステートメント・キューイングの管理」
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

親トピック: パラレル実行サーバー

26.1.3.3.1.3.2.1 パラレル・サーバー制限を使用したパラレル・ステートメント・キューイングの管理

PARALLEL_SERVER_LIMIT属性を使用すると、いつコンシューマ・グループからパラレル・ステートメントをキューできるかを指定できます。Oracle Databaseには、コンシューマ・グループごとにパラレル・ステートメント・キューが保持されます。

コンシューマ・グループからのパラレル・ステートメントは実行されず、そのかわり、次の条件が満たされた場合に、そのコンシューマ・グループのパラレル・ステートメント・キューに追加されます。

PARALLEL_DEGREE_POLICYがAUTOに設定されています。

この初期化パラメータをAUTOに設定すると、自動並列度(Auto DOP)、パラレル・ステートメント・キューイングおよびインメモリー・パラレル実行が有効になります。

PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されているパラレル・ステートメントはただちに実行され、パラレル・ステートメント・キューに追加されません。
すべてのコンシューマ・グループのアクティブなパラレル実行サーバー数が、PARALLEL_SERVERS_TARGET初期化パラメータの設定を超えています。この条件は、PARALLEL_SERVER_LIMITを指定しているかどうかに関係なく適用されます。PARALLEL_SERVER_LIMITが指定されていない場合は、100%にデフォルト設定されます。
コンシューマ・グループのアクティブなパラレル実行サーバーの合計数およびパラレル・ステートメントの並列度が、アクティブなパラレル実行サーバーのターゲット数を超えています。

アクティブなパラレル実行サーバーのターゲット数は、次のように計算されます。

PARALLEL_SERVER_LIMIT/100 * PARALLEL_SERVERS_TARGET

注意:

すべてのセッションでパラレル実行サーバーの使用状況が監視されますが、設定したパラレル実行サーバー・ディレクティブ属性は、パラレル・ステートメント・キューイングが有効になっている(PARALLEL_DEGREE_POLICYがAUTOに設定されている)セッションにのみ影響を与えます。セッションのPARALLEL_DEGREE_POLICYがMANUALに設定されている場合、このセッションからのパラレル・ステートメントはキューされません。ただし、このようなセッションで使用されているパラレル実行サーバーは、PARALLEL_SERVER_LIMITの制限の決定に使用されるカウントに数えられます。この制限を超えても、このセッションからのパラレル・ステートメントはキューされません。

関連項目:

「パラレル・サーバー制限」

親トピック: パラレル・サーバー制限

26.1.3.3.1.3.3 パラレル・キューのタイムアウト

PARALLEL_QUEUE_TIMEOUTディレクティブ属性を使用すると、パラレル・ステートメントがパラレル・ステートメント・キュー内でタイムアウトになるまで待機する最大時間を秒単位で指定できます。

パラレル・ステートメント・キューイングを使用すると、データベースにパラレル・ステートメントを実行するほどのリソースがない場合、そのステートメントは必要なリソースが使用可能になるまでキューで待機します。ただし、パラレル・ステートメントが意図した時間よりも長くパラレル・ステートメント・キューで待機する場合があります。このような状況を回避するには、パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を指定します。

PARALLEL_QUEUE_TIMEOUT属性は、コンシューマ・グループごとに設定できます。この属性は、リソース・プランの他の管理属性(MGMT_P1、MGMT_P2など)を指定していなくても適用できます。

関連項目:

パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

注意:

パラレル・ステートメント・キューはクラスタ全体で機能するため、パラレル・ステートメント・キューに関連するすべてのディレクティブもクラスタ全体で機能します。

タイムアウトになったパラレル文の処理方法は、コンシューマ・グループごとにPQ_TIMEOUT_ACTION属性を設定することで制御できます。この属性は、次の値に設定できます。

CANCEL: 文の実行はエラーORA-07454で終了します。これは、タイムアウトになったパラレル文のデフォルトの動作です。
RUN: 文は即時実行されます。文を即時実行するためのパラレル・サーバーが不足している場合は、並列度を下げて実行するように文がダウングレードされます。

関連項目:

すべてのパラレル実行サーバー・ディレクティブ属性を組み合せて使用する方法の詳細は、「ディレクティブ属性を使用したパラレル・ステートメントの管理の例」を参照してください

親トピック: パラレル実行サーバー

26.1.3.3.1.4 プログラム・グローバル領域(PGA)

PGAリソースを管理するために、リソース・マネージャは、特定のコンシューマ・グループの各セッションに割当て可能なPGAメモリー量を制限できます。

コンシューマ・グループ内の各セッションのPGAリソースを制限するには、パッケージ・プロシージャDBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE内でsession_pga_limitパラメータを設定します。このパラメータの値は、コンシューマ・グループの各セッションに許可されるPGAメモリー容量の最大値(MB単位)です。セッションがそのコンシューマ・グループに設定されている制限を超過すると、ORA-10260エラーが発生します。この制限には、パラレル問合せスレーブおよびジョブ・キュー・プロセスが含まれます。

たとえば、不適切に記述されたPL/SQLコードは制限なしのPGA量を消費することがあります。session_pga_limitパラメータを使用してPL/SQLコードを実行するセッションを制限して、これらのセッションが過剰な量のPGAリソースを使用しないようにすることができます。

次の表は、PGA制限のある単純なリソース・プランを示しています。

表26-3 PGA制限のある単純なリソース・プラン

コンシューマ・グループ	session_pga_limit値
`HIGH_GROUP`	20
`LOW_GROUP`	10
`MAINT_SUBPLAN`	Null (制限なし)
`OTHER_GROUPS`	Null (制限なし)

このリソース・プランでは、優先度の高いアプリケーションがHIGH_GROUP内で実行され、そのグループ内の各セッションは20 MBのPGAリソースに制限されます。LOW_GROUP内の低優先度アプリケーションによって使用されるセッションは、10 MBのPGAリソースに制限されます。MAINT_SUPLAN内のメンテナンス・ジョブに使用されるセッションおよびOTHER_GROUPS内のその他のセッションは、無制限のPGAリソースを使用できます。

注意:

PGA_AGGREGATE_LIMIT初期化パラメータでインスタンス全体のPGA使用率を制限できます。

26.1.3.3.1.5 リソース集中型の問合せ

リソース集中型のセッションおよびコールは、適切に管理されない場合、パフォーマンス全体に悪影響を及ぼす可能性があります。リソース・マネージャでは、セッションまたはコールが指定量を超えるCPU、物理I/O、論理I/Oまたは経過時間を使用したときに処理を行うことができます。リソース・マネージャでは、セッションまたはコールをCPUの割当てが少ないコンシューマ・グループに切り替えたり、セッションまたはコールを終了できます。

注意:

Oracle Database 12cリリース2 (12.2)以降では、リソース・マネージャは特定のコンシューマ・グループ内の各セッションに割り当てることのできるPGAメモリーの量を制限できます。

コンシューマ・グループの自動切替え
指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。
SQLの取消しとセッションの終了
リソース・マネージャを使用すると、CPUとI/Oなどのシステム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了することができます。
実行時間制限
ある操作に許可される最大の実行時間を指定できます。

関連項目:

プログラム・グローバル領域(PGA)

26.1.3.3.1.5.1 コンシューマ・グループの自動切替え

指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。

通常、この方法は、グループ内の典型的なセッションに対するリソース使用予測を上回ったセッションを、優先度の高いコンシューマ・グループ(システム・リソースを高い比率で使用するグループ)から優先度の低いコンシューマ・グループに切り替えるために使用します。

詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。

親トピック: リソース集中型の問合せ

26.1.3.3.1.5.2 SQLの取消しとセッションの終了

リソース・マネージャを使用すると、CPUとI/Oなどのシステム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了することができます。

リソース・マネージャによって取り消されたSQL問合せは、DBMS_SQLQパッケージのサブプログラムを使用することで、それらの問合せを再実行できないように隔離を構成できます。

関連項目:

システム・リソースの消費に基づいてSQL問合せの取消しまたはセッションの終了を行うためのリソース・マネージャの構成方法の詳細は、リソース制限の設定による自動切替えの指定を参照してください。
DBMS_SQLQパッケージのサブプログラムを使用してSQL問合せの隔離設定を構成する方法の詳細は、過剰なシステム・リソースを使用するSQL文の実行計画の隔離を参照してください。

親トピック: リソース集中型の問合せ

26.1.3.3.1.5.3 実行時間制限

ある操作に許可される最大の実行時間を指定できます。

ある操作についてデータベースが見積った実行時間が、指定された最大実行時間より長い場合、その操作はエラーを出力して終了します。このエラーはトラップ可能であり、操作は再スケジュールできます。

親トピック: リソース集中型の問合せ

26.1.3.3.1.6 キューイングを備えたアクティブ・セッション・プール

コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが定義されます。

アクティブ・セッションとは、現在、トランザクションまたはSQL文を処理しているセッションです。具体的には、アクティブ・セッションは、ユーザー・エンキューを保持した状態でトランザクション内にあるか、またはオープン・カーソルを持ちつつ5秒を超える長さにわたりアイドル状態になっていないかのいずれかです。アクティブ・セッションは、セッションがブロックされている場合であっても(たとえば、I/O要求の完了の待機中など)、アクティブであるとみなされます。アクティブ・セッション・プールが一杯になると、コールの処理を試行しているセッションはキューに送られます。アクティブ・セッションが完了すると、キュー内の最初のセッションがキューから削除されて実行がスケジュールされます。また、実行キュー内のセッションがタイムアウトして、そのコールがエラーで終了されるまでの時間も指定できます。

OLTPワークロードにはアクティブ・セッションの制限を使用しないでください。また、接続プーリングまたはパラレル・ステートメント・キューイングを実装する目的でアクティブ・セッションの制限を使用しないでください。

パラレル・ステートメントを管理するには、PARALLEL_SERVER_LIMIT属性および管理属性(MGMT_P1、MGMT_P2など)とともに、パラレル・ステートメント・キューイングを使用する必要があります。

26.1.3.3.1.7 UNDOプール

UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールは、コンシューマ・グループが生成できる、コミットされていないトランザクションに対するUNDO合計量を制御します。

コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、そのUNDOを生成している現行のデータ操作言語(DML)文が終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たにデータ操作を実行できません。

26.1.3.3.1.8 アイドル時間制限

セッションがアイドル状態のままでいられる時間(セッションが終了されるまでの時間)を指定できます。

また、アイドル状態で他のセッションをブロックしているセッションに適用される、さらに厳密なアイドル時間制限も指定できます。

26.1.3.3.2 PDBのリソース・プラン・ディレクティブ

ディレクティブは、CPUとパラレル実行サーバーの割当てを制御します。

ディレクティブにより、PDBまたはPDBパフォーマンス・プロファイルごとに指定する共有値に基づいてPDBへのリソースの割当てを制御できます。共有値が高いほど、リソースは増加します。設定は、各プロファイルを使用するPDBのセットに適用されます。

たとえば、salespdbの共有値をhrpdbの共有値の2倍に設定することで、salespdbにhrpdbに割り当てられたリソースの2倍を割り当てるように指定できます。同様に、salespdbパフォーマンス・プロファイルの共有値をhrpdbパフォーマンス・プロファイルの共有値の2倍に設定することで、salespdbパフォーマンス・プロファイルにhrpdbパフォーマンス・プロファイルに割り当てられたリソースの2倍を割り当てるように指定できます。

PDBおよびPDBパフォーマンス・プロファイルに使用率制限を指定することもできます。制限はPDBまたはパフォーマンス・プロファイルへの割当てを制御します。たとえば、この制限を使用して、salespdbで確保できるCPU量を、合計CPU量のうちCDBに使用可能な割合として制御できます。

CDB内の各PDBおよびPDBパフォーマンス・プロファイルに割り当てるリソースを正確に制御するために、共有と使用率制限の両方を一緒に使用できます。

関連項目:

PDBロックダウン・プロファイルの詳細は、『Oracle Database SQL言語リファレンス』を参照してください

親トピック: リソース・プラン・ディレクティブの概要

26.1.3.3.3 PDBのパフォーマンス・プロファイル

PDBパフォーマンス・プロファイルは、同じ優先度およびリソース制御が指定された一連のPDBにリソース・プラン・ディレクティブを構成します。

たとえば、Gold、SilverおよびBronzeというパフォーマンス・プロファイルを作成できます。各プロファイルには、PDBのタイプの重要性に基づいて一連の様々なディレクティブを指定します。Gold PDBはSilver PDBよりミッション・クリティカルで、Silver PDBはBronze PDBよりミッション・クリティカルです。PDBでは、DB_PERFORMANCE_PROFILE初期化パラメータを使用してパフォーマンス・プロファイルを指定します。

PDBロックダウン・プロファイルを使用して、SGA_TARGET、PGA_AGGREGATE_LIMITなど、リソースを制御するPDB初期化パラメータを指定できます。ロックダウン・プロファイルによって、PDB管理者による設定の変更が防止されます。

パフォーマンス・プロファイルとロックダウン・プロファイルには、一致した名前を使用することをお薦めします。PDBの所有者がプロファイルを切り替えることを防ぐために、PDBパフォーマンス・プロファイルをPDBロックダウン・プロファイルに配置することをお薦めします。

親トピック: リソース・プラン・ディレクティブの概要

26.1.3.4 リソース・プランについて

リソース・プランは、リソース・コンシューマ・グループへのリソースの割当て方法を指定するディレクティブのコンテナです。

各Oracle Databaseに事前定義されているリソース・プランの他に、リソース・プランは必要な数だけ作成できます。ただし、1度にアクティブにできるリソース・プランは1つのみです。リソース・プランがアクティブな場合は、その子の各リソース・プラン・ディレクティブが異なるコンシューマ・グループへのリソース割当てを制御します。各プランには、OTHER_GROUPSというコンシューマ・グループにリソースを割り当てるディレクティブが必要です。OTHER_GROUPSは、現在アクティブなプランの一部でないコンシューマ・グループに属しているすべてのセッションに適用されます。

注意:

「リソース・プラン」(または単に「プラン」)という用語はリソース・マネージャの1つの要素を示しますが、この章では、完全なリソース・プラン・スキーマ(リソース・プランの要素そのもの、そのリソース・プラン・ディレクティブ、ディレクティブによって参照されるコンシューマ・グループなど)を指す場合にも使用します。たとえば、この章でDAYTIMEリソース・プランに触れたときは、DAYTIMEというリソース・プラン要素を意味する場合も、DAYTIMEリソース・プランとそのディレクティブが定義する特定のリソース割当てスキーマを意味する場合もあります。したがって、簡潔に言えば、「DAYTIMEプランは、バッチ・アプリケーションよりも対話型アプリケーションに近い」といえます。

CDBリソース・プランの概要
PDBの共有およびリソース制限を割り当てるCDBリソース・プランを作成します。
PDBリソース・プランについて
PDBリソース・プランは、このPDB内で特定のPDBのリソースがコンシューマ・グループにどのように割り当てられるかを決定します。
例: 単純なリソース・プラン
単純なリソース・プランの例を示します。

「図26-1 CDBリソース・プランにおける共有」の説明

26.1.3.4.1 CDBリソース・プランの概要

PDBの共有およびリソース制限を割り当てるCDBリソース・プランを作成します。

PDBへのリソース割当ての共有
PDB間でリソースを割り当てるには、PDBまたはパフォーマンス・プロファイルごとに共有値を割り当てます。共有値が高いほど、パフォーマンス・プロファイルを使用する1つまたは複数のPDBに保証されるリソースは多くなります。
PDBの使用率制限
使用率制限は、特定のPDBまたは特定のPDBパフォーマンス・プロファイルのシステム・リソースの使用を制限します。
PDBのデフォルト・ディレクティブ
PDBにディレクティブを明示的に定義しない場合、PDBではPDB用のデフォルト・ディレクティブが使用されます。

親トピック: リソース・プランについて

26.1.3.4.1.1 PDBへのリソース割当ての共有

PDB間でリソースを割り当てるには、PDBまたはパフォーマンス・プロファイルごとに共有値を割り当てます。共有値が高いほど、パフォーマンス・プロファイルを使用する1つまたは複数のPDBに保証されるリソースは多くなります。

DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用してPDBの共有値を指定し、DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVEプロシージャを使用してPDBパフォーマンス・プロファイルの共有値を指定します。どちらの場合も、sharesパラメータでPDBの共有値を指定します。複数のPDBが同じPDBパフォーマンス・プロファイルを使用できます。

次の図は、CDBリソース・プランに共有値が指定された3つのPDBの例を示しています。

図26-1 CDBリソース・プランにおける共有

前述の図は、共有の合計数が7 (3+3+1)であることを示しています。PDB salespdbおよびservicespdbは、それぞれリソースの3/7が保証されていますが、PDB hrpdbはリソースの1/7が保証されています。ただし、リソースの競合がない場合は、いずれのPDBでも保証された量より多くのリソースを使用できます。

次の表は、前述の図のPDBに対する、共有値に基づくリソース割当てを示しています。表では、PDBのロードでは、割り当てられたすべてのシステム・リソースを消費することを前提としています。

表26-4 サンプルPDBへのリソース割当て

リソース	リソース割当て	関連項目
CPU	PDB `salespdb`および`servicespdb`では、同じ量のCPUリソースを使用できます。PDB `salespdb`および`servicespdb`は、それぞれPDB `hrpdb`の3倍のCPUリソースを保証されています。	このリソースの詳細は、『Oracle Database管理者ガイド』を参照してください
パラレル実行サーバー	PDB `salespdb`および`servicespdb`からキューされているパラレル問合せは、同等に選択されます。PDB `salespdb`および`servicespdb`からキューされているパラレル問合せは、PDB `hrpdb`からキューされているパラレル問合せの3倍の頻度で選択されます。	このリソースの詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: CDBリソース・プランの概要

26.1.3.4.1.2 PDBの使用率制限

使用率制限により、特定のPDBまたは特定のPDBパフォーマンス・プロファイルのシステム・リソース使用率が抑制されます。

CPUの使用率制限およびパラレル実行サーバーを指定できます。PDBの使用率制限は、CDBリソース・プランで設定されます。

次の表で、PDBの使用率制限およびPDBが使用率制限に達した場合に実行されるリソース・マネージャの処理について説明します。PDBパフォーマンス・プロファイルで指定した制限の場合、制限はPDBパフォーマンス・プロファイルを使用するすべてのPDBに適用されます。たとえば、pdb1およびpdb20にはパフォーマンス・プロファイルBRONZEがあり、BRONZEには10%に設定されている制限がある場合、pdb1には10%の制限、pdb20には10%の制限が適用されます。

表26-5 PDBの使用率制限

リソースリソース使用率制限制限に達した場合のリソース・マネージャの処理

リソース	リソース使用率制限	制限に達した場合のリソース・マネージャの処理
CPU	PDBに接続されているセッションに対するCPU使用率制限は、`DBMS_RESOURCE_MANAGER`パッケージのサブプログラムの`utilization_limit`パラメータで設定されます。`utilization_limit`パラメータによって、PDBで使用できるシステム・リソースの割合が指定されます。この値の範囲は、0から100までです。初期化パラメータ`CPU_COUNT`(上限)および`CPU_MIN_COUNT`(下限)を設定することで、PDBのCPUを制限することもできます。たとえば、PDBレベルで`CPU_COUNT`を`8`に設定し、`CPU_MIN_COUNT`を`.1`に設定した場合は、PDBで、CPUスレッドを8個までしか使用できなくなり、その時間の10%のCPUスレッドが1つ以上必要になります。`utilization_limit`および`CPU_COUNT`の両方を指定した場合は、より制限される(低い)値が施行されます。	PDBのCPU使用率が使用率制限を超えないように、リソース・マネージャによってPDBセッションが制限されます。
パラレル実行サーバー	パラレル文のキューイングを使用してPDBのパラレル実行サーバーの数を制限できます。制限に達した場合は、データベースによってパラレル問合せがキューに追加されるため、制限はキューイング・ポイントです。次のいずれかの方法で制限(キューイング・ポイント)を設定できます。 PDBで設定する`PARALLEL_SERVERS_TARGET`初期化パラメータの値 CDBリソース・マネージャ計画でPDBに設定された`parallel_server_limit`ディレクティブの値を乗算した、CDBルートの`PARALLEL_SERVERS_TARGET`初期化パラメータの設定の値たとえば、CDBルートで`PARALLEL_SERVERS_TARGET`初期化パラメータが200に設定され、PDBの`parallel_server_limit`ディレクティブが10%に設定されている場合、PDBの使用率制限は20パラレル実行サーバー(200 * .10)となります。前述の両方の方法で制限が設定されている場合は、2つのうち低い値が使用されます。`PARALLEL_SERVERS_TARGET`のデフォルト値は、『Oracle Databaseリファレンス』を参照してください。注意: CDBプランで`parallel_server_limit`ディレクティブを使用するかわりに、`PARALLEL_SERVERS_TARGET`初期化パラメータを使用することをお薦めします。	PDBで使用されるパラレル実行サーバーの数が制限を超えた場合は、リソース・マネージャがパラレル問合せをキューに追加します。注意: CDBでは、パラレル文はPDBおよびCDBレベルの両方で`PARALLEL_SERVERS_TARGET`設定に基づいてキューに追加されます。PDBで使用されるパラレル・サーバーの数がPDBのターゲットを超過したとき、またはすべてのPDBによって使用されるパラレル・サーバーの数がCDBのターゲットを超過したときに、文はキューに追加されます。

CPU

PDBに接続されているセッションに対するCPU使用率制限は、DBMS_RESOURCE_MANAGERパッケージのサブプログラムのutilization_limitパラメータで設定されます。utilization_limitパラメータによって、PDBで使用できるシステム・リソースの割合が指定されます。この値の範囲は、0から100までです。

初期化パラメータCPU_COUNT(上限)およびCPU_MIN_COUNT(下限)を設定することで、PDBのCPUを制限することもできます。たとえば、PDBレベルでCPU_COUNTを8に設定し、CPU_MIN_COUNTを.1に設定した場合は、PDBで、CPUスレッドを8個までしか使用できなくなり、その時間の10%のCPUスレッドが1つ以上必要になります。utilization_limitおよびCPU_COUNTの両方を指定した場合は、より制限される(低い)値が施行されます。

PDBのCPU使用率が使用率制限を超えないように、リソース・マネージャによってPDBセッションが制限されます。

パラレル実行サーバー

パラレル文のキューイングを使用してPDBのパラレル実行サーバーの数を制限できます。制限に達した場合は、データベースによってパラレル問合せがキューに追加されるため、制限はキューイング・ポイントです。

次のいずれかの方法で制限(キューイング・ポイント)を設定できます。

PDBで設定するPARALLEL_SERVERS_TARGET初期化パラメータの値
CDBリソース・マネージャ計画でPDBに設定されたparallel_server_limitディレクティブの値を乗算した、CDBルートのPARALLEL_SERVERS_TARGET初期化パラメータの設定の値

たとえば、CDBルートでPARALLEL_SERVERS_TARGET初期化パラメータが200に設定され、PDBのparallel_server_limitディレクティブが10%に設定されている場合、PDBの使用率制限は20パラレル実行サーバー(200 * .10)となります。

前述の両方の方法で制限が設定されている場合は、2つのうち低い値が使用されます。PARALLEL_SERVERS_TARGETのデフォルト値は、『Oracle Databaseリファレンス』を参照してください。

注意: CDBプランでparallel_server_limitディレクティブを使用するかわりに、PARALLEL_SERVERS_TARGET初期化パラメータを使用することをお薦めします。

PDBで使用されるパラレル実行サーバーの数が制限を超えた場合は、リソース・マネージャがパラレル問合せをキューに追加します。

注意: CDBでは、パラレル文はPDBおよびCDBレベルの両方でPARALLEL_SERVERS_TARGET設定に基づいてキューに追加されます。PDBで使用されるパラレル・サーバーの数がPDBのターゲットを超過したとき、またはすべてのPDBによって使用されるパラレル・サーバーの数がCDBのターゲットを超過したときに、文はキューに追加されます。

次の図は、CDBリソース・プランに共有および使用率制限が指定された3つのPDBの例を示しています。

図26-2 CDBリソース・プランにおける共有および使用率制限

「図26-2 CDBリソース・プランにおける共有および使用率制限」の説明

前述の図では、utilization_limitおよびparallel_server_limitが両方ともこれらのPDBについて100%に設定されていることから、PDB salespdbおよびservicespdbに対する使用率制限がないことを示しています。ただし、PDB hrpdbは、utilization_limitおよびparallel_server_limitが両方とも70%に設定されていることから、適用可能なシステム・リソースの70%に制限されています。

注意:

このシナリオでは、PDBのPARALLEL_SERVERS_TARGET初期化パラメータに低い制限が指定されていないことを前提としています。PDBでパラレル実行サーバーのPARALLEL_SERVERS_TARGET初期化パラメータに低い制限が指定されている場合は、より低い制限が使用されます。

関連項目:

Oracle Database管理者ガイド
CPU_COUNTの詳細は、『Oracle Databaseリファレンス』を参照してください

親トピック: CDBリソース・プランの概要

26.1.3.4.1.3 PDBのデフォルト・ディレクティブ

PDBにディレクティブを明示的に定義しない場合、PDBではPDB用のデフォルト・ディレクティブが使用されます。

次の表に、PDB用の初期デフォルト・ディレクティブの属性を示します。

表26-6 PDB用の初期デフォルト・ディレクティブ属性

ディレクティブ属性	値
`shares`	1
`utilization_limit`	100
`parallel_server_limit`	100

PDBがCDBに接続されており、ディレクティブが定義されていない場合、PDBではPDB用のデフォルト・ディレクティブが使用されます。

新しいPDBにディレクティブを新しく作成できます。また、DBMS_RESOURCE_MANAGERパッケージのUPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用して、PDB用のデフォルト・ディレクティブ属性値を変更することもできます。

PDBがCDBから切断された場合、PDBのディレクティブは保持されます。同じPDBがCDBに再接続される場合、そのPDB用に定義されたディレクティブが手動で削除されていないと、PDBではこのディレクティブが使用されます。

図26-3に、CDBリソース・プランにおけるデフォルト・ディレクティブの例を示します。

図26-3 CDBリソース・プランにおけるデフォルト・ディレクティブ

「図26-3 CDBリソース・プランにおけるデフォルト・ディレクティブ」の説明

図26-3は、デフォルトPDBディレクティブで、shareが1、utilization_limitが50%およびparallel_server_limitが50%となるよう指定されていることを示しています。CDBの一部であり、かつディレクティブが定義されていないすべてのPDBでは、デフォルトPDBディレクティブが使用されます。図26-3は、デフォルトPDBディレクティブを使用するPDB marketingpdbおよびtestingpdbを示しています。したがって、marketingpdbおよびtestingpdbは、それぞれ共有が1および使用率制限が50となります。

関連項目:

「PDBの新規CDBリソース・プラン・ディレクティブの作成」
「CDBリソース・プランにおけるPDBのデフォルト・ディレクティブの更新」
「パラレル・サーバー制限」
PDBおよびアプリケーション・コンテナの作成および削除の詳細は、Oracle Database SQL言語リファレンスを参照してください
CDBからのPDBの切断の詳細は、Oracle Database SQL言語リファレンスを参照してください

親トピック: CDBリソース・プランの概要

26.1.3.4.2 PDBリソース・プランについて

PDBリソース・プランは、このPDB内で特定のPDBのリソースがコンシューマ・グループにどのように割り当てられるかを決定します。

PDBリソース・プランは、PDBごとに割り当てられるリソース量を決定するCDBリソース・プランとは異なります。PDBリソース・プランには、次の制限が適用されます。

PDBリソース・プランは、サブプランを含むことができません。
PDBリソース・プランで、複数レベルのスケジューリング・ポリシーを使用することはできません。

以前のリリースの非CDBをアップグレードすることによってPDBを作成するときに、非CDBにリソース・プランが含まれていない場合は、これらのリソース・プランが前述の制限事項に従っていないことがあります。この場合、これらのリソース・プランは、Oracle Databaseによってこれらの要件を満たす同等のPDBリソース・プランに自動的に変換されます。元のリソース・プランおよびディレクティブは、DBA_RSRC_PLANSおよびDBA_RSRC_PLAN_DIRECTIVESビューにLEGACYステータスで記録されます。

PDBリソース・プランを作成する場合のCDBリソース・プランの要件
PDBリソース・プランを作成する場合は、CDBリソース・プランが特定の要件を満たしている必要があります。
PDBリソース・プラン: 例
CDBリソース・プランとPDBリソース・プランには、1対多の関係があります。

関連項目:

「CDBリソース・プランの概要」
リソース・プランの詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: リソース・プランについて

26.1.3.4.2.1 PDBリソース・プランを作成する場合のCDBリソース・プランの要件

PDBリソース・プランを作成する場合は、CDBリソース・プランが特定の要件を満たしている必要があります。

CDBリソース・プランのディレクティブを作成するには、DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用します。PDBリソース・プランにディレクティブを作成する場合は、同じパッケージ内のCREATE_PLAN_DIRECTIVEプロシージャを使用します。1つ以上のPDBリソース・プランを作成するときにCDBリソース・プランがない場合、CDBでは、Oracle Databaseに付属のDEFAULT_CDB_PLANが使用されます。

次の表で、CDBリソース・プランの要件および要件が満たされない場合の結果について説明します。「CDBリソース・プラン要件」列で説明されているパラメータ値は、CREATE_CDB_PLAN_DIRECTIVEプロシージャ用です。「要件が満たされない場合の結果」列で説明されているパラメータ値は、CREATE_PLAN_DIRECTIVEプロシージャ用です。

表26-7 PDBリソース・プランのためのCDBリソース・プラン要件

リソース CDBリソース・プラン要件要件が満たされない場合の結果

リソース	CDBリソース・プラン要件	要件が満たされない場合の結果
CPU	次の要件のいずれかが満たされている必要があります。共有値が、`shares`パラメータを使用してPDBに指定されている必要があります。 100を下回るCPU使用率制限が、`utilization_limit`パラメータを使用してPDBに指定されている必要があります。これらの値は、特定のPDBのディレクティブまたはデフォルト・ディレクティブに設定できます。	PDBリソース・プランのCPU割当てポリシーは規定されません。 PDBリソース・プランの`utilization_limit`パラメータで指定されたCPU制限は、規定されません。
パラレル実行サーバー	次の要件のいずれかが満たされている必要があります。共有値が、`shares`パラメータを使用してPDBに指定されている必要があります。 `parallel_server_limit`パラメータを使用して、PDBに100未満のパラレル・サーバー制限を指定する必要があります。これらの値は、特定のPDBのディレクティブまたはデフォルト・ディレクティブに設定できます。	PDBリソース・プランのパラレル実行サーバー割当てポリシーは、規定されません。 PDBリソース・プランで`parallel_server_limit`によって指定されたパラレル・サーバー制限は規定されません。ただし、PDBの`PARALLEL_SERVERS_TARGET`初期化パラメータを設定して、パラレル制限を規定できます。

CPU

次の要件のいずれかが満たされている必要があります。

共有値が、sharesパラメータを使用してPDBに指定されている必要があります。
100を下回るCPU使用率制限が、utilization_limitパラメータを使用してPDBに指定されている必要があります。

これらの値は、特定のPDBのディレクティブまたはデフォルト・ディレクティブに設定できます。

PDBリソース・プランのCPU割当てポリシーは規定されません。

PDBリソース・プランのutilization_limitパラメータで指定されたCPU制限は、規定されません。

パラレル実行サーバー

次の要件のいずれかが満たされている必要があります。

共有値が、sharesパラメータを使用してPDBに指定されている必要があります。
parallel_server_limitパラメータを使用して、PDBに100未満のパラレル・サーバー制限を指定する必要があります。

これらの値は、特定のPDBのディレクティブまたはデフォルト・ディレクティブに設定できます。

PDBリソース・プランのパラレル実行サーバー割当てポリシーは、規定されません。

PDBリソース・プランでparallel_server_limitによって指定されたパラレル・サーバー制限は規定されません。ただし、PDBのPARALLEL_SERVERS_TARGET初期化パラメータを設定して、パラレル制限を規定できます。

親トピック: PDBリソース・プランについて

26.1.3.4.2.2 PDBリソース・プラン: 例

CDBリソース・プランとPDBリソース・プランには、1対多の関係があります。

次の図に、CDBリソース・プランおよびPDBリソース・プランの例を示します。

図26-4 CDBリソース・プランおよびPDBリソース・プラン

「図26-4 CDBリソース・プランおよびPDBリソース・プラン」の説明

前述の図は、PDB servicespdbのPDBリソース・プランにおける一部のディレクティブを示しています。CDB内の他のPDBにもPDBリソース・プランを作成できます。

親トピック: PDBリソース・プランについて

26.1.3.4.3 例: 単純なリソース・プラン

単純なリソース・プランの例を示します。

図26-5は、日中にオンライン・トランザクション処理(OLTP)アプリケーションとレポート・アプリケーションを同時に実行する組織の単純なリソース・プランを示しています。現在、DAYTIMEのプランがアクティブになっており、3つのリソース・コンシューマ・グループ間でCPUリソースを割り当てます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。リソースの競合がない場合、どのグループも保証されているより多くのリソースを使用できます。たとえば、OLTPはCPUの75%を保証されていますが、リソースの競合がない場合は、最大でCPUの100%を使用できます。

図26-5 単純なリソース・プラン

「図26-5 単純なリソース・プラン」の説明

Oracle Databaseには、単純なリソース・プランを迅速に作成できるプロシージャ(CREATE_SIMPLE_PLAN)が用意されています。このプロシージャについては、「単純なリソース・プランの作成」を参照してください。

注意:

現在アクティブなリソース・プランは、CPU使用率が100%になるまで割当てを規定しません。CPU使用率が100%未満の場合、データベースはCPUによる制限を受けないため、すべてのセッションが必要なリソース割当てを獲得できるように割当てを規定する必要はありません。

さらに、割当てが規定されている場合は、あるコンシューマ・グループが使用していない割当てを、他のコンシューマ・グループが使用できます。前述の例では、OLTPグループが割当てをすべて使用していない場合、リソース・マネージャは、REPORTSグループまたはOTHER_GROUPSグループが、未使用の割当てを使用することを許可します。

親トピック: リソース・プランについて

26.1.3.5 サブプランについて

リソース・プラン・ディレクティブ(ディレクティブ)は、コンシューマ・グループを参照するかわりに、別のリソース・プランを参照できます。この場合、そのプランはサブプランと呼ばれます。

サブプラン自体に、リソースをコンシューマ・グループと他のサブプランに割り当てるディレクティブがあります。その場合、リソースの割当て方式は次のように機能します。トップレベルのリソース・プラン(現在アクティブなプラン)によって、リソースがコンシューマ・グループおよびサブプランに分割されます。次に、各サブプランによって、リソース割当て合計の一部がそのコンシューマ・グループとサブプランに割り当てられます。階層的なプランは、必要な数のサブプランを使用して作成できます。

リソース・サブプランは、リソース・プランを作成する方法と同じ方法で作成します。サブプランとしてのみ使用されるプランを作成するには、パッケージ・プロシージャDBMS_RESOURCE_MANAGER.CREATE_PLANでSUB_PLAN引数を使用します。

トップレベルのプランでは、サブプランを1回のみ参照できます。サブプランは、OTHER_GROUPSへのディレクティブを必要とせず、リソース・プランとして設定できません。

例: サブプランを含むリソース・プラン
サブプランを含むリソース・プランの例を示します。

「図26-6 サブプランを含むリソース・プラン」の説明

26.1.3.5.1 例: サブプランを含むリソース・プラン

サブプランを含むリソース・プランの例を示します。

この例では、Great Bread Companyによって、CPUリソースが図26-6のように割り当てられています。この図は、トップレベルのプラン (GREAT_BREAD)とその子すべてを示しています。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。かわりに、ディレクティブが割り当てるCPUの比率を、プラン、サブプランおよびコンシューマ・グループ間を結ぶ線に沿って表示しています。

図26-6 サブプランを含むリソース・プラン

このGREAT_BREADプランでは、次のようにリソースを割り当てます。

CPUリソースの20%をコンシューマ・グループMARKETに割り当てます。
CPUリソースの60%をサブプランSALES_TEAMに割り当てます。このサブプランでは、リソースがWHOLESALEコンシューマ・グループとRETAILコンシューマ・グループ間で均等に分割されます。
CPUリソースの20%をサブプランDEVELOP_TEAMに割り当てます。このサブプランでは、リソースがBREADコンシューマ・グループとMUFFINコンシューマ・グループ間で均等に分割されます。

サブプランまたはコンシューマ・グループは、複数の親を持つ場合があります。たとえば、MARKETグループがSALES_TEAMサブプランに含まれていた場合です。ただし、プラン内でループすることはできません。たとえば、SALES_TEAMサブプランには、GREAT_BREADプランを参照するディレクティブを設定できません。

関連項目:

複雑なリソース・プランの例は、「各種の方法を組み合せたOracle Database Resource Managerの例」を参照してください。

親トピック: サブプランについて

26.1.4 PDBリソース管理のユーザー・インタフェース

DBMS_RESOURCE_MANAGERと初期化パラメータを使用してPDBリソースを管理できます。

リソース・マネージャの管理権限の概要
リソース・マネージャを管理するために必要な権限を持っている必要があります。
CDBおよびPDBのためのDBMS_RESOURCE_MANAGER
DBMS_RESOURCE_MANAGERパッケージを使用すると、CDBとPDBについて、プラン、コンシューマ・グループおよびプラン・ディレクティブをメンテナンスできます。
PDBレベルのリソースに関する初期化パラメータ
PDBのCPU、メモリー、セッションおよびI/Oを制御するには、初期化パラメータを使用します。

親トピック: Oracle Database Resource Managerの概要

26.1.4.1 リソース・マネージャの管理権限の概要

リソース・マネージャを管理するために必要な権限を持っている必要があります。

リソース・マネージャを管理するには、システム権限ADMINISTER_RESOURCE_MANAGERが必要です。この権限(ADMINオプション付き)は、DBAロールを介してデータベース管理者に付与されます。

リソース・マネージャの管理者は、DBMS_RESOURCE_MANAGER PL/SQLパッケージ内のすべてのプロシージャを実行できます。

ADMINオプションを持つ管理者は、必要に応じて管理権限を他のユーザーまたはロールに付与できます。そうするには、DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用します。次の表に、関連するパッケージ・プロシージャの一覧を示します。

プロシージャ	説明
`GRANT_SYSTEM_PRIVILEGE`	ユーザーまたはロールに、`ADMINISTER_RESOURCE_MANAGER`システム権限を付与します。
`REVOKE_SYSTEM_PRIVILEGE`	ユーザーまたはロールから、`ADMINISTER_RESOURCE_MANAGER`システム権限を取り消します。

次のPL/SQLブロックは、ユーザーHRに管理権限を付与しますが、HRにADMINオプションは付与しません。そのため、HRはDBMS_RESOURCE_MANAGERパッケージのすべてのプロシージャを実行できますが、HRはGRANT_SYSTEM_PRIVILEGEプロシージャを使用して他のユーザーに管理権限を付与することはできません。

BEGIN
  DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE(
   GRANTEE_NAME   => 'HR',
   PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER',
   ADMIN_OPTION   => FALSE);
END;
/

この権限は、REVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消すことができます。

注意:

ADMINISTER_RESOURCE_MANAGERシステム権限の付与または取消しは、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用する場合のみ行うことができます。SQLのGRANT文またはREVOKE文によって、付与したり取り消すことはできません。

関連項目:

DBMS_RESOURCE_MANAGERパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
DBMS_RESOURCE_MANAGER_PRIVSパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ADMINオプションの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください

親トピック: PDBリソース管理のユーザー・インタフェース

26.1.4.2 CDBとPDBのDBMS_RESOURCE_MANAGER

DBMS_RESOURCE_MANAGERパッケージを使用すると、CDBとPDBについて、プラン、コンシューマ・グループおよびプラン・ディレクティブをメンテナンスできます。

次の表では、PDBでのリソースの管理に関連するプログラム・ユニットについて説明します。

表26-8 DBMS_RESOURCE_MANAGERのプログラム・ユニット

PL/SQLプログラム・ユニット	説明
`CREATE_CDB_PLAN_DIRECTIVE`	このプロシージャは、CDBリソース・プランのプラン・ディレクティブを作成します。プラン・ディレクティブでは、PDBのリソース割当てポリシーを指定します。
`CREATE_CDB_PROFILE_DIRECTIVE`	このプロシージャは、CDBリソース・プランのパフォーマンス・プロファイル・ディレクティブを作成します。ディレクティブでは、パフォーマンス・プロファイルを使用するPDBのリソース割当てポリシーを指定します。
`CREATE_CDB_PLAN`	このプロシージャは、CDBリソース・プランを定義するエントリを作成します。
`UPDATE_CDB_DEFAULT_DIRECTIVE`	このプロシージャは、CDBリソース・プランのプラン・ディレクティブを更新します。
`UPDATE_CDB_PLAN`	このプロシージャは、CDBリソース・プランを更新します。

注意:

DBMS_RESOURCE_MANAGERの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。

親トピック: PDBリソース管理のユーザー・インタフェース

26.1.4.3 PDBレベルのリソースの初期化パラメータ

初期化パラメータを使用して、PDBのCPU、メモリー、セッションおよびI/Oを制御します。

PDBのCPU関連の初期化パラメータ
CPU_COUNT初期化パラメータは、PDBで使用可能なCPUスレッドの数を指定します。
PDBのメモリー関連の初期化パラメータ
複数の初期化パラメータでPDBのSGAおよびPGAの使用を制御します。
PDBのセッション関連の初期化パラメータ
PDBでセッションがリソースを消費する方法は、複数の初期化パラメータによって制御されます。
PDBのI/O関連の初期化パラメータ
MAX_IOPSおよびMAX_MBPS初期化パラメータは、PDBで生成されるディスクI/Oを制限します。

親トピック: PDBリソース管理のユーザー・インタフェース

26.1.4.3.1 PDBのCPU関連の初期化パラメータ

CPU_COUNT初期化パラメータには、PDBで使用できるCPUスレッドの数を指定します。

CPUスレッドという用語は、CPUコアでの実行のスレッドを指します。たとえば、サーバーに4個のCPUソケットがある場合があります。ソケットの各CPUには2つのコアがあり、合計で8コアになります。各CPUコアがマルチスレッド化されていて、各コアに2つの実行スレッドがある場合、そのサーバーのCPUスレッドは合計16個になります。

CPUリソース管理がCDBに対して有効になっている場合は、PDBレベルのCPU_MIN_COUNTおよびCPU_COUNT初期化パラメータによって、PDBのCPUリソースが管理されます。CPUリソース管理は、たとえばdefault_cdb_planがCDBレベルで設定されている場合に有効になります。CPUリソース・マネージャは、CPU_COUNTおよびPDBレベルのutilization_limitディレクティブ(存在する場合)の低い方に応じて、PDBのCPUを制限します。CDBリソース・プランにデフォルト以外のディレクティブが設定された共有または使用率制限がない場合、CPUリソース・マネージャはPDBレベルのCPU_MIN_COUNTを使用して、CDBリソース・プランのPDBの共有を設定します。

注意:

CPU_COUNTおよびCPU_MIN_COUNTでは、スレッドを取得する必要がある場所、つまり、特定のCPUまたはコアを指定しません。

表26-9 PDBでのCPU使用率を制御する初期化パラメータ

初期化パラメータ説明 PDBレベルでのデフォルト値

初期化パラメータ	説明	PDBレベルでのデフォルト値
`CPU_COUNT`	PDBで一度に使用できる、CPUスレッドの最大数を指定します。 0 (ゼロ)以外の値に設定すると、Oracle Databaseでは、実際のCPU数ではなくこの数が使用されるため、動的なCPU再構成が無効になります。 `CPU_COUNT`は、そのCDBプランで`utilization_limit`ディレクティブと同じように機能します。ただし、`CPU_COUNT`による制限は、使用率ではなくCPUスレッド数で表されます。`utilization_limit`および`CPU_COUNT`の両方を指定した場合は、より低い制限が適用されます。注意: PDBが新しいコンテナに接続される場合、`CPU_COUNT`の設定は、接続したPDBに残ります。	`0`。この場合、Oracle Databaseで、オペレーティング・システムによって報告されるCPUの数が継続的に監視され、現在の数が使用されます。
`CPU_MIN_COUNT`	PDBのCPUスレッドの最小数を指定します。有効な値は`0.1`から`CPU_COUNT`設定までです。この値は`0.05`の倍数である必要があります。この値は、`1`より小さい場合は、PDBでスレッドが必要とされる時間の最小の割合を示します。たとえば、`0.1`と設定した場合は、PDBに10秒の間に1秒以上CPUスレッドが必要になるということを表します。データベース・インスタンスでオープンされているすべてのPDBにわたるPDBレベルの`CPU_MIN_COUNT`設定の合計が、CDBレベルの`CPU_MIN_COUNT`設定を超える場合は、CDBのサブスクライブが上限を超えます。たとえば、100個のPDBを含む単一インスタンスCDBで`CPU_MIN_COUNT`が`8`であり、各PDBで`CPU_MIN_COUNT`設定が`.1`である場合は、CDBのサブスクライブが上限を超えます。最小CPUは、CDBのサブスクライブが上限を超えていない場合のみ保証されます。	`CPU_COUNT`

CPU_COUNT

PDBで一度に使用できる、CPUスレッドの最大数を指定します。

0 (ゼロ)以外の値に設定すると、Oracle Databaseでは、実際のCPU数ではなくこの数が使用されるため、動的なCPU再構成が無効になります。

CPU_COUNTは、そのCDBプランでutilization_limitディレクティブと同じように機能します。ただし、CPU_COUNTによる制限は、使用率ではなくCPUスレッド数で表されます。utilization_limitおよびCPU_COUNTの両方を指定した場合は、より低い制限が適用されます。

注意: PDBが新しいコンテナに接続される場合、CPU_COUNTの設定は、接続したPDBに残ります。

0。この場合、Oracle Databaseで、オペレーティング・システムによって報告されるCPUの数が継続的に監視され、現在の数が使用されます。

CPU_MIN_COUNT

PDBのCPUスレッドの最小数を指定します。

有効な値は0.1からCPU_COUNT設定までです。この値は0.05の倍数である必要があります。この値は、1より小さい場合は、PDBでスレッドが必要とされる時間の最小の割合を示します。たとえば、0.1と設定した場合は、PDBに10秒の間に1秒以上CPUスレッドが必要になるということを表します。

データベース・インスタンスでオープンされているすべてのPDBにわたるPDBレベルのCPU_MIN_COUNT設定の合計が、CDBレベルのCPU_MIN_COUNT設定を超える場合は、CDBのサブスクライブが上限を超えます。たとえば、100個のPDBを含む単一インスタンスCDBでCPU_MIN_COUNTが8であり、各PDBでCPU_MIN_COUNT設定が.1である場合は、CDBのサブスクライブが上限を超えます。最小CPUは、CDBのサブスクライブが上限を超えていない場合のみ保証されます。

CPU_COUNT

26.1.4.3.2 PDBのメモリー関連の初期化パラメータ

いくつかの初期化パラメータによって、PDBのSGA使用量およびPGA使用量を制御します。

PDBが現在のコンテナである場合は、次の表の初期化パラメータによって現在のPDBのメモリー使用が制御されます。これらのパラメータの1つ以上がPDBに対して設定されている場合は、そのCDBおよび他のPDBがそれらの操作に対して十分なメモリーを持っていることを確認します。

次の表に示す初期化パラメータは、次の条件を満たす場合にのみPDBのメモリー使用量を制御します。

NONCDB_COMPATIBLE初期化パラメータが、CDBルートでFALSEに設定されている。
CDBルートにMEMORY_TARGET初期化パラメータが設定されていないか、0 (ゼロ)が設定されている。

表26-10 PDBのメモリー使用を制御する初期化パラメータ

初期化パラメータ	説明(PDBレベルで設定する場合)	PDBレベルでのデフォルト
`DB_CACHE_SIZE`	PDBについて、保証される最小バッファ・キャッシュ・サイズを設定します。このパラメータは、PDBレベルではオプションです。 `SGA_TARGET`初期化パラメータを設定しない場合、またはCDBレベルで`DB_CACHE_SIZE`初期化パラメータを設定している場合は、次の要件を満たす必要があります。 PDBに設定された`DB_CACHE_SIZE`の値は、CDBレベルの`DB_CACHE_SIZE`値の50%以下にする必要があります。 CDB内のすべてのPDBにおける`DB_CACHE_SIZE`値の合計が、CDBレベルでの`DB_CACHE_SIZE`値の50%以下にする必要があります。 CDBレベルで`SGA_TARGET`を設定する場合は、エラーを回避するために、次の要件を満たす必要があります。 PDB内の`DB_CACHE_SIZE`および`SHARED_POOL_SIZE`の値は、PDBの`SGA_TARGET`値の50%以下にする必要があります。 PDBの`DB_CACHE_SIZE`と`SHARED_POOL_SIZE`を足した値が、CDBレベルで`SGA_TARGET`値の50%以下である必要があります。 CDB内のすべてのPDBの`DB_CACHE_SIZE`と`SHARED_POOL_SIZE`を足した合計が、CDBレベルの`SGA_TARGET`値の50%以下である必要があります。	なし
`SHARED_POOL_SIZE`	PDBについて、保証される最小共有プール・サイズを設定します。 `SGA_TARGET`初期化パラメータを設定しないが、`SHARED_POOL_SIZE`初期化パラメータをCDBレベルで設定している場合、次の要件を満たす必要があります。 PDBに設定された`SHARED_POOL_SIZE`の値は、CDBレベルの`SHARED_POOL_SIZE`値の50%以下にする必要があります。 CDB内のすべてのPDBにおける`SHARED_POOL_SIZE`値の合計は、CDBレベルの`SHARED_POOL_SIZE`値の50%以下にする必要があります。 CDBレベルで`SGA_TARGET`初期化パラメータが0 (ゼロ)以外の値に設定されている場合は、エラーを回避するために、次の要件を満たす必要があります。 PDB内の`DB_CACHE_SIZE`および`SHARED_POOL_SIZE`の値は、PDBの`SGA_TARGET`値の50%以下にする必要があります。 PDBの`DB_CACHE_SIZE`と`SHARED_POOL_SIZE`を足した値が、CDBレベルで`SGA_TARGET`値の50%以下である必要があります。 CDB内のすべてのPDBの`DB_CACHE_SIZE`と`SHARED_POOL_SIZE`を足した合計が、CDBレベルの`SGA_TARGET`値の50%以下である必要があります。	なし PDBレベルでこのパラメータを設定しない場合は、PDBで使用できる共有プール容量の上限はなく、そうでない場合は、CDBの共有プール・サイズです。
`SGA_MIN_SIZE`	PDBの最小SGAサイズを設定します。この設定は、次の要件を満たしている必要があります。 CDBルートで`SGA_TARGET`初期化パラメータが設定されていないか`0` (ゼロ)が設定されている必要があります。そうでない場合は、PDBで`SGA_MIN_SIZE`を設定しても効果はありません。 CDBルートの`SGA_TARGET`の設定の50%以下である必要があります。 PDBの`SGA_TARGET`の設定の50%以下である必要があります。すべてのPDBの`SGA_MIN_SIZE`設定の合計が、CDBルートの`SGA_TARGET`の設定の50%以下である必要があります。 CDBレベルで`SGA_MIN_SIZE`を設定しても効果はないということを覚えておいてください。	`0`
`SGA_TARGET`	PDBの最大SGAサイズを設定します。 PDBでは、CDBルートで`SGA_TARGET`初期化パラメータが0 (ゼロ)以外の値に設定されている場合にのみ、PDBレベルの`SGA_TARGET`設定が強制適用されます。PDBの`SGA_TARGET`設定は、CDBルートの`SGA_TARGET`設定以下である必要があります。	CDBレベルでの`SGA_TARGET`に、PDBレベルの`CPU_COUNT`/CDBレベルの`CPU_COUNT`の比率を乗じた値
`PGA_AGGREGATE_LIMIT`	PDBの最大PGAサイズを設定します。 `PGA_AGGREGATE_LIMIT`を手動で設定した場合、その値が次の要件を満たしている必要があります。 CDBルートの`PGA_AGGREGATE_LIMIT`の設定以下である必要があります。 PDBの`PGA_AGGREGATE_TARGET`の設定の2倍以上である必要があります。	CDBレベルでの`PGA_AGGREGATE_LIMIT`に、PDBレベルの`CPU_COUNT`/CDBレベルの`CPU_COUNT`の比率を乗じた値
`PGA_AGGREGATE_TARGET`	PDBのターゲット集計PGAサイズを設定します。 `PGA_AGGREGATE_TARGET`を手動で設定した場合、その値が次の要件を満たしている必要があります。 CDBレベルで設定されている`PGA_AGGREGATE_TARGET`値以下である必要があります。 CDBレベルで設定されている`PGA_AGGREGATE_LIMIT`初期化パラメータ値の50%以下である必要があります。 PDBに設定されている`PGA_AGGREGATE_LIMIT`値の50%以下である必要があります。	CDBレベルでの`PGA_AGGREGATE_TARGET`に、PDBレベルの`CPU_COUNT`/CDBレベルの`CPU_COUNT`の比率を乗じた値

例26-1 PDBで使用可能な最大平均PGAメモリーの設定

PDBを現在のコンテナとして、次のSQL文を実行して、メモリーとSPFILEの両方でPGA_AGGREGATE_LIMIT初期化パラメータを90MBに設定します。

ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 90M SCOPE = BOTH;

例26-2 PDBの最大SGAサイズの設定

PDBを現在のコンテナとして、次のSQL文を実行して、メモリーとSPFILEの両方でSGA_MIN_SIZE初期化パラメータを500MBに設定します。

ALTER SYSTEM SET SGA_MIN_SIZE = 500M SCOPE = BOTH;

26.1.4.3.3 PDBのセッション関連の初期化パラメータ

いくつかの初期化パラメータによって、PDBにおいてセッションでリソースがどのように消費されるかを制御します。

表26-11 PDBのセッション使用を制御する初期化パラメータ

初期化パラメータ説明(PDBレベルで設定する場合) PDBレベルでのデフォルト

初期化パラメータ	説明(PDBレベルで設定する場合)	PDBレベルでのデフォルト
`SESSIONS`	PDBで使用できる最大セッション数を設定します。 PDBで、その`SESSIONS`パラメータで構成されている数を超えてセッションを使用しようとすると、`ORA-00018`エラー・メッセージが生成されます。PDBの場合、`SESSIONS`パラメータでは再帰セッションはカウントされないため、10%の調整は必要になりません。 PDBの`SESSIONS`パラメータを変更できるのはそのPDBのみです。CDBレベルで設定されている`SESSIONS`値より大きい値は設定できません。	CDBレベルでの`SESSIONS`に、PDBレベルの`CPU_COUNT`/CDBレベルの`CPU_COUNT`の比率を乗じた値
`MAX_IDLE_TIME`	セッションをアイドル状態にしておける最長時間(分数)を指定します。その最大値に達すると、Oracle Databaseによって自動的にセッションが終了されます。	`0` (未設定)
`MAX_IDLE_BLOCKER_TIME`	セッションがアイドル状態になってから終了候補になるまでの時間(分数)を設定します。このパラメータを使用すると、アイドル状態のセッションは、それによって別のセッションがブロックされている場合は終了されます。Oracle Databaseでは、次のいずれかの状況でブロックされているセッションが対象とみなされます。そのセッションによって、別のセッションに必要なロックが保持されている。そのセッションがパラレル操作であり、そのコンシューマ・グループ、PDBまたはCDBでそのパラレル・サーバー上限に達するかパラレル操作がキューに入れられている。そのセッションのPDBまたはデータベース・インスタンスが、そのセッション制限またはプロセス制限に到達しようとしている。 `MAX_IDLE_TIME`と異なり、`MAX_IDLE_BLOCKER_TIME`では、リソースはそれらが必要になったときにのみ終了されます。	`0` (未設定)

SESSIONS

PDBで使用できる最大セッション数を設定します。

PDBで、そのSESSIONSパラメータで構成されている数を超えてセッションを使用しようとすると、ORA-00018エラー・メッセージが生成されます。PDBの場合、SESSIONSパラメータでは再帰セッションはカウントされないため、10%の調整は必要になりません。

PDBのSESSIONSパラメータを変更できるのはそのPDBのみです。CDBレベルで設定されているSESSIONS値より大きい値は設定できません。

CDBレベルでのSESSIONSに、PDBレベルのCPU_COUNT/CDBレベルのCPU_COUNTの比率を乗じた値

MAX_IDLE_TIME

セッションをアイドル状態にしておける最長時間(分数)を指定します。その最大値に達すると、Oracle Databaseによって自動的にセッションが終了されます。

0 (未設定)

MAX_IDLE_BLOCKER_TIME

セッションがアイドル状態になってから終了候補になるまでの時間(分数)を設定します。

このパラメータを使用すると、アイドル状態のセッションは、それによって別のセッションがブロックされている場合は終了されます。Oracle Databaseでは、次のいずれかの状況でブロックされているセッションが対象とみなされます。

そのセッションによって、別のセッションに必要なロックが保持されている。
そのセッションがパラレル操作であり、そのコンシューマ・グループ、PDBまたはCDBでそのパラレル・サーバー上限に達するかパラレル操作がキューに入れられている。
そのセッションのPDBまたはデータベース・インスタンスが、そのセッション制限またはプロセス制限に到達しようとしている。

MAX_IDLE_TIMEと異なり、MAX_IDLE_BLOCKER_TIMEでは、リソースはそれらが必要になったときにのみ終了されます。

0 (未設定)

26.1.4.3.4 PDBのI/O関連の初期化パラメータ

MAX_IOPSおよびMAX_MBPS初期化パラメータは、PDBで生成されるディスクI/Oを制限します。

大量のディスクI/Oはパフォーマンス低下の原因となることがあります。不適切に設計されたSQL、大量トランザクションでの索引や表のスキャンなど、複数の要因によりディスクI/Oが過剰になることがあります。あるPDBによるディスクI/O量が多い場合は、それによって他のPDBのパフォーマンスが低下する可能性があります。

次の初期化パラメータの一方または両方を使用して、特定のPDBで生成されるI/Oを制限します。

MAX_IOPS初期化パラメータは、毎秒のI/O操作の数を制限します。
MAX_IOPS初期化パラメータは、毎秒のI/O操作のMB数を制限します。

単一のPDBに対して前述の両方の初期化パラメータを設定した場合、Oracle Databaseは両方の制限を強制します。MAX_IOPSおよびMAX_IOPSによる制限は、I/Oリソース管理(IORM)を使用してPDB間のI/Oを管理するOracle Exadataでは適用されません。

CDBルートが現在のコンテナであるときに、これらの初期化パラメータを設定した場合、値はCDB内のすべてのコンテナのデフォルト値になります。アプリケーション・ルートが現在のコンテナであるときに、これらの初期化パラメータを設定した場合、値はアプリケーション・コンテナ内のすべてのアプリケーションPDBのデフォルト値になります。PDBまたはアプリケーションPDBが現在のコンテナであるときに、これらの初期化パラメータを設定した場合、その設定はCDBルートまたはアプリケーション・ルートのデフォルト設定より優先されます。

両方の初期化パラメータのデフォルトは0(ゼロ)です。これらの初期化パラメータがPDBで0 (ゼロ)に設定されていて、CDBルートで0に設定されている場合、PDBのI/O制限はありません。これらの初期化パラメータがアプリケーションPDBで0 (ゼロ)に設定されていて、アプリケーション・ルートで0に設定されている場合、アプリケーションPDBのI/O制限はありません。

制御ファイルやパスワード・ファイルに対するI/O操作などのクリティカルなI/O操作は、制限の対象にならず、制限に達した場合も実行を継続します。ただし、I/O操作数およびI/O操作のMB数の計算では、クリティカルなI/O操作を含むすべてのI/O操作がカウントされます。

DBA_HIST_RSRC_PDB_METRICビューを使用して、PDBに対して合理的なI/O制限を計算できます。制限を計算する際には、IOPS、IOMBPS、IOPS_THROTTLE_EXEMPTおよびIOMBPS_THROTTLE_EXEMPT列の値を考慮します。rsmgr:io rate limit待機イベントは、制限に達したことを示します。

例26-3 PDBによって生成されるI/Oの制限

PDBを現在のコンテナとして、次のSQL文を実行し、メモリーとSPFILEの両方でMAX_IOPS初期化パラメータを毎秒1,000 I/O操作の制限に設定します。

ALTER SYSTEM SET MAX_IOPS = 1000 SCOPE = BOTH;

例26-4 PDBによって生成されるI/OのMB数の制限

PDBを現在のコンテナとして、次のSQL文を実行し、メモリーとSPFILEの両方でMAX_MBPS初期化パラメータを毎秒200MBのI/Oの制限に設定します。

ALTER SYSTEM SET MAX_MBPS = 200 SCOPE = BOTH;

関連項目:

システム・レベルでのPDBの変更の詳細は、Oracle Database SQL言語リファレンスを参照してください
MAX_IOPS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
MAX_MBPS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

26.2 Oracle Database Resource Managerの有効化とプランの切替え

Oracle Database Resource Manager(リソース・マネージャ)を有効にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。

デフォルトでは、次の状況を除き、リソース・マネージャは有効になっていません。

この項の後半で説明されている、事前定義済メンテナンス・ウィンドウの間。
INMEMORY_SIZE初期化パラメータを0より大きい値に設定することでOracle Database In-Memoryが有効になっているとき。

テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランがmydb_planとして設定されます。

RESOURCE_MANAGER_PLAN = mydb_plan

DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャまたはALTER SYSTEM文を使用して、リソース・マネージャをアクティブ化(または解除)したり、現行のトップレベル・プランを変更することもできます。

次のSQL文は、トップレベルのプランをmydb_planに設定し、リソース・マネージャをアクティブ化します(アクティブ化されていない場合)。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';

指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。

Oracle Schedulerのウィンドウでのリソース・マネージャの自動有効化

リソース・プランを指定するOracle Schedulerのウィンドウがオープン状態の場合、リソース・マネージャは自動的にアクティブ化されます。スケジューラのウィンドウがクローズ状態の場合、そのウィンドウに関連付けられているリソース・プランは無効で、スケジューラのウィンドウがオープンする前に実行されていたリソース・プランが再度有効になります。(ウィンドウのオープン前に有効なリソース・プランがなかった場合、リソース・マネージャは無効になります。)したがって、ウィンドウのリソース・プランはあらゆるインスタンスで有効になります。

デフォルトでは、MAINTENANCE_WINDOW_GROUPウィンドウ・グループのメンバーである事前定義済のスケジューラ・ウィンドウであり、DEFAULT_MAINTENANCE_PLANリソース・プランを指定するメンテナンス・ウィンドウの間に一連の自動化されたメンテナンス・タスクが実行されることに注意してください。そのため、リソース・マネージャは、メンテナンス・ウィンドウ中にデフォルトでアクティブ化されます。必要な場合は、これらのメンテナンス・ウィンドウを変更して、別のリソース・プランを使用できます。

注意:

メンテナンス・ウィンドウに関連付けられたプランを変更する場合は、サブプランORA$AUTOTASKが新しいプランに含まれていることを確認してください。

関連項目:

Oracle Schedulerのウィンドウでのプラン切替えの無効化

場合によっては、スケジューラのウィンドウ境界でのリソース・マネージャ・プランの自動変更は、望ましくない可能性があります。たとえば、終了する必要のある重要なタスクがあり、リソース・マネージャ・プランにタスクの優先度を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、スケジューラのウィンドウはプランの設定後にアクティブになるため、タスクの実行中にリソース・マネージャ・プランが変更される可能性があります。

この状況を回避するには、次のSQL文に示すように、RESOURCE_MANAGER_PLAN初期化パラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:」を付加します。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';

接頭辞FORCEを使用することで、現行のリソース・プランの変更は、データベース管理者がRESOURCE_MANAGER_PLAN初期化パラメータの値を変更した場合のみ可能であることを示します。この制限を解除するには、プラン名の前に「FORCE:」を付加せずに、そのコマンドを再実行します。

DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャには同様の機能があります。

関連項目:

DBMS_RESOURCE_MANAGER.SWITCH_PLANの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

リソース・マネージャの無効化

リソース・マネージャを無効にするには、次のステップを完了します。

次のSQL文を発行します。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';

すべてのOracle Schedulerのウィンドウからリソース・マネージャの関連を削除します。

そのためには、resource_plan属性のリソース・プランを参照するすべてのスケジューラのウィンドウについて、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、resource_planを空の文字列('')に設定します。SYSユーザーでログインしていない場合は、SYSスキーマ名を使用してウィンドウ名を修飾します。スケジューラのウィンドウは、DBA_SCHEDULER_WINDOWSデータ・ディクショナリ・ビューで表示できます。詳細は、「ウィンドウの変更」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

注意:

デフォルトでは、すべてのメンテナンス・ウィンドウがDEFAULT_MAINTENANCE_PLANリソース・プランを参照します。リソース・マネージャを完全に無効にするには、すべてのメンテナンス・ウィンドウを変更してこのプランを削除する必要があります。ただし、自動化メンテナンス・タスクによるリソース使用が規制されなくなるため、他のセッションのパフォーマンスに悪影響を与える可能性があることに注意してください。メンテナンス・ウィンドウの詳細は、「自動データベース・メンテナンス・タスクの管理」を参照してください。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.3 リソース・コンシューマ・グループへのセッションの割当て

データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法があります。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager(リソース・マネージャ)では、そのセッションに対するリソース割当てが管理の対象となります。

注意:

コンシューマ・グループに割り当てられていないセッションは、コンシューマ・グループOTHER_GROUPSに配置されます。

リソース・コンシューマ・グループへのセッション割当ての概要
リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。
初期リソース・コンシューマ・グループの割当て
セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。
コンシューマ・グループへのセッションのマッピング・ルールの指定
コンシューマ・グループへのセッションのマッピング・ルールを作成し、優先順位を付けることができます。
リソース・コンシューマ・グループの切替え
セッションのリソース・コンシューマ・グループを切り替えることができます。
コンシューマ・グループの自動切替えの指定
特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。
スイッチ特権の付与と取消し
ユーザーまたはアプリケーションがセッションを指定されたリソース・コンシューマ・グループに切り替えるには、スイッチ特権が必要です。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.3.1 リソース・コンシューマ・グループへのセッション割当ての概要

リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。

これを行うために、マッピング・ルールを作成すると、セッションの起動時に、セッション属性に基づいてリソース・マネージャによって自動的に各セッションがコンシューマ・グループに割り当てられるようにすることができます。セッションがその初期コンシューマ・グループに割り当てられ実行された後は、プロシージャをコールして、セッションを別のコンシューマ・グループに手動で切り替えることができます。この操作は、リソースを過剰に使用しているセッションを、よりリソース割当ての制限されたコンシューマ・グループに移動する必要がある場合などに実行します。また、ユーザーおよびアプリケーションにスイッチ特権を付与して、ユーザーおよびアプリケーションが、あるコンシューマ・グループから別のコンシューマ・グループに自分のセッションを切り替えることができるようにすることができます。

セッション属性に変更がある場合やセッションが指定のリソース使用制限を超える場合は、あるコンシューマ・グループから別の(通常は優先度の低い)コンシューマ・グループにセッションを自動的に切り替えることもできます。

26.3.2 初期リソース・コンシューマ・グループの割当て

セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。

マッピング・ルールの構成方法は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。

26.3.3 コンシューマ・グループへのセッションのマッピング・ルールの指定

コンシューマ・グループへのセッションのマッピング・ルールを作成し、優先順位を付けることができます。

コンシューマ・グループへのセッションのマッピング・ルールの概要
セッションの初期コンシューマ・グループを指定し、セッション属性が変更された場合に別のコンシューマ・グループにセッションを動的に切り替えることができます。
コンシューマ・グループのマッピング・ルールの作成
セッション属性と値のペアをコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。
コンシューマ・グループのマッピング・ルールの変更と削除
コンシューマ・グループ・マッピング・ルールを変更するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、新しいコンシューマ・グループを指定します。
マッピング・ルールの優先度の作成
競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。

26.3.3.1 コンシューマ・グループへのセッションのマッピング・ルールの概要

セッションの初期コンシューマ・グループを指定し、セッション属性が変更された場合に別のコンシューマ・グループにセッションを動的に切り替えることができます。

コンシューマ・グループへのセッションのマッピング・ルールを作成すると、次のことができます。

セッションの初期コンシューマ・グループをセッション属性に基づいて指定できます。
リソース・マネージャを使用して、実行中のセッションをセッション属性の変更に基づいて別のコンシューマ・グループに動的に切り替えることができます。

このマッピング・ルールは、セッション属性(ユーザー名、セッションがデータベースへの接続に使用したサービス、クライアント・プログラムの名前など)に基づいています。

マッピング・ルール間の競合を解決するために、リソース・マネージャでは、各ルールが優先度別に順序付けされます。たとえば、ユーザーSCOTTがSALESサービスを使用してデータベースに接続すると仮定します。あるマッピング・ルールには、ユーザーSCOTTがMED_PRIORITYコンシューマ・グループで起動することが記載され、別のルールには、SALESサービスに接続するセッションはHIGH_PRIORITYコンシューマ・グループで起動することが記載されている場合、この競合は、マッピング・ルールの優先度によって解決されます。

マッピング・ルールの基本になるセッション属性には、ログイン属性とランタイム属性の2つのタイプがあります。ログイン属性が有効なのは、セッションのログイン時、つまり、リソース・マネージャによってセッションの初期コンシューマ・グループが決定されるときのみです。ランタイム属性は、セッションのログイン中とログイン後に適用されます。ランタイム属性のいずれかを変更することによって、ログイン済セッションを別のコンシューマ・グループに再割当てできます。

コンシューマ・グループへのセッションの自動割当てを構成するには、SET_CONSUMER_GROUP_MAPPINGおよびSET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。これらのプロシージャに対してはペンディング・エリアを使用する必要があります。(ペンディング・エリアを作成してプロシージャを実行し、必要に応じてペンディング・エリアの妥当性をチェックしてから、そのペンディング・エリアを発行する必要があります。ペンディング・エリアの使用例は、「複雑なリソース・プランの作成」を参照してください。)

セッションは、マッピング・ルールを介して様々な時点で特定のコンシューマ・グループに自動的に切り替えられます。

最初のセッションのログイン時には、マッピング・ルールが評価されてそのセッションの初期グループが判別されます。
セッション属性が新しい値に動的に変更されると(可能性があるのはランタイム属性のみ)、マッピング・ルールが再評価され、セッションが別のコンシューマ・グループに切り替わる場合があります。

事前定義のコンシューマ・グループ・マッピング・ルール

各Oracle Databaseには、事前定義のコンシューマ・グループ・マッピング・ルールのセットがあります。

「リソース・コンシューマ・グループの概要」で説明したように、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションは、最初にSYS_GROUPコンシューマ・グループにマップされます。
データ・ポンプを使用してデータ・ロードを実行するセッションまたはRMANを使用してバックアップまたはコピー操作を実行するセッションは、表26-19で指定されている事前定義のコンシューマ・グループに自動的にマップされます。

DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらの事前定義のマッピング・ルールを変更または削除できます。

26.3.3.2 コンシューマ・グループのマッピング・ルールの作成

セッション属性と値のペアをコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。

このプロシージャのパラメータは、次のとおりです。

パラメータ	説明
`ATTRIBUTE`	セッション属性タイプ。パッケージ定数として指定されています。
`VALUE`	属性の値。
`CONSUMER_GROUP`	この属性と値のペアのマッピング先のコンシューマ・グループ。

ATTRIBUTEには、次のいずれかを指定できます。

属性	タイプ	説明
`ORACLE_USER`	ログイン	Oracle Databaseユーザー名。
`SERVICE_NAME`	ログイン	クライアントが接続の確立に使用したデータベース・サービス名。
`CLIENT_OS_USER`	ログイン	ログインしているクライアントのオペレーティング・システム・ユーザー名。
`CLIENT_PROGRAM`	ログイン	サーバーへのログインに使用されたクライアント・プログラム名。
`CLIENT_MACHINE`	ログイン	クライアントが接続に使用しているコンピュータ名。
`CLIENT_ID`	ログイン	セッションのクライアント識別子クライアント識別子のセッション属性は、`DBMS_SESSION.SET_IDENTIFIER`プロシージャで設定します。
`MODULE_NAME`	ランタイム	`DBMS_APPLICATION_INFO.SET_MODULE`プロシージャによる設定、またはそれに相当するOCI属性の設定に従って現在実行されているアプリケーション内のモジュール名。
`MODULE_NAME_ACTION`	ランタイム	次のプロシージャのいずれかによる設定、またはそれに相当するOCI属性の設定に従って実行されている現行モジュールと処理の組合せ。 `DBMS_APPLICATION_INFO.SET_MODULE` `DBMS_APPLICATION_INFO.SET_ACTION` この属性にはモジュール名を指定し、その後ろにピリオド(.)および処理名を順に続けます(`module_name.action_name`)。
`SERVICE_MODULE`	ランタイム	`service_name.module_name`の書式によるサービス名およびモジュール名の組合せ。
`SERVICE_MODULE_ACTION`	ランタイム	`service_name.module_name.action_name`の書式によるサービス名、モジュール名および処理名の組合せ。
`ORACLE_FUNCTION`	ランタイム	RMANまたはデータ・ポンプ操作。有効な値は`DATALOAD`、`BACKUP`および`COPY`です。これらの値それぞれに事前定義のマッピングがあります。セッションでこれらの機能のいずれかを実行している場合、事前定義のコンシューマ・グループに自動的にマップされます。詳細は、表26-19を参照してください。

たとえば、次のPL/SQLブロックでは、ログインするたびに、ユーザーSCOTTがDEV_GROUPコンシューマ・グループにマップされます。

BEGIN
  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING  
     (DBMS_RESOURCE_MANAGER.ORACLE_USER, 'SCOTT', 'DEV_GROUP');
END;
/

この場合も、SET_CONSUMER_GROUP_MAPPINGプロシージャを実行する前にペンディング・エリアを作成する必要があります。

SET_CONSUMER_GROUP_MAPPINGプロシージャではvalueパラメータでほとんどの属性の値に対してワイルドカードを使用できます。ワイルドカードを使用して値を指定するには、SQLのLIKE演算子と同じセマンティクスを使用します。具体的には、ワイルドカードは次のセマンティクスを使用します。

%は、複数文字のワイルドカード
_は、1文字のワイルドカード
\は、ワイルドカードをエスケープする

ワイルドカードが使用できるのは、属性が次のいずれかの場合のみです。

CLIENT_OS_USER
CLIENT_PROGRAM
CLIENT_MACHINE
MODULE_NAME
MODULE_NAME_ACTION
SERVICE_MODULE
SERVICE_MODULE_ACTION

親トピック: コンシューマ・グループへのセッションのマッピング・ルールの指定

26.3.3.3 コンシューマ・グループのマッピング・ルールの変更と削除

コンシューマ・グループ・マッピング・ルールを変更するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、新しいコンシューマ・グループを指定します。

ルールを削除するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、NULLのコンシューマ・グループを指定します。

親トピック: コンシューマ・グループへのセッションのマッピング・ルールの指定

26.3.3.4 マッピング・ルールの優先度の作成

競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。

各属性に、1(最も高い重要度)から12(最も低い重要度)の一意の整数を設定するには、SET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。次の例は、この優先度の設定方法を示しています。

BEGIN
  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_PROGRAM => 8,
    CLIENT_OS_USER => 9,
    CLIENT_MACHINE => 10,
    CLIENT_ID => 11);
END;
/

この例では、データベース・ユーザー名の優先度は7(重要度が低い)に設定され、モジュール名の優先度は5(重要度が高い)に設定されています。

注意:

SET_CONSUMER_GROUP_MAPPING_PRIでは、疑似属性EXPLICITを引数として含める必要があります。これは、1に設定する必要があります。これは、明示的なコンシューマ・グループの切替えに最も高い優先度が指定されていることを示します。『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』で詳細に説明されている次のパッケージ・プロシージャを使用して、コンシューマ・グループを明示的に切り替えます。

DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER

マッピング・ルールの優先度がどのように機能するかを示すために、引き続き前の例を使用して、DEV_GROUPコンシューマ・グループへのユーザーSCOTTのマッピングの他に、次のようなモジュール名のマッピング・ルールがあると仮定します。

BEGIN
  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
     (DBMS_RESOURCE_MANAGER.MODULE_NAME, 'EOD_REPORTS', 'LOW_PRIORITY');
END;
/

ユーザーSCOTTのセッションのアプリケーションによって、モジュール名がEOD_REPORTSに設定された場合、そのセッションはLOW_PRIORITYコンシューマ・グループに再割当てされます。これは、モジュール名マッピングの方が、データベース・ユーザー・マッピングより優先度が高いためです。

セッション属性の現在の優先度を確認するには、ビューDBA_RSRC_MAPPING_PRIORITYを問い合せます。

関連項目:

DBMS_APPLICATION_INFO.SET_MODULEプロシージャによるモジュール名の設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
「スイッチ特権の付与と取消し」

親トピック: コンシューマ・グループへのセッションのマッピング・ルールの指定

26.3.4 リソース・コンシューマ・グループの切替え

セッションのリソース・コンシューマ・グループを切り替えることができます。

手動によるリソース・コンシューマ・グループの切替え
実行中のセッションのリソース・コンシューマ・グループを変更できます。
ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化
管理者は、ユーザーがDBMS_SESSIONパッケージのSWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、現在のコンシューマ・グループを切り替えられるように、スイッチ特権をユーザーに付与できます。

26.3.4.1 手動によるリソース・コンシューマ・グループの切替え

実行中のセッションのリソース・コンシューマ・グループを変更できます。

手動によるリソース・コンシューマ・グループの切替えについて
DBMS_RESOURCE_MANAGER PL/SQLパッケージには、管理者が実行中のセッションのリソース・コンシューマ・グループを変更できるように、2つのプロシージャが用意されています。
単一のセッションの切替え
SWITCH_CONSUMER_GROUP_FOR_SESSプロシージャは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。このプロシージャを使用すると、セッションの優先度を実質的に変更できます。
ユーザーの全セッションの切替え
SWITCH_CONSUMER_GROUP_FOR_USERプロシージャは、指定したユーザー名に関連するすべてのセッションのリソース・コンシューマ・グループを変更します。

親トピック: リソース・コンシューマ・グループの切替え

26.3.4.1.1 手動によるリソース・コンシューマ・グループの切替えについて

DBMS_RESOURCE_MANAGER PL/SQLパッケージには、管理者が実行中のセッションのリソース・コンシューマ・グループを変更できるように、2つのプロシージャが用意されています。

この2つのプロシージャでは、コーディネータのセッションに対応付けられたパラレル実行サーバー・セッションのコンシューマ・グループも変更できます。これらのプロシージャで行った変更は永続的ではなく、現行セッションのみに影響します。ユーザーの初期コンシューマ・グループも変更されません。

あるユーザーがCPUを過剰に使用している場合は、そのユーザーのセッションを停止(終了)するかわりに、ユーザーのコンシューマ・グループをリソースの割当てが低いグループに変更できます。

親トピック: 手動によるリソース・コンシューマ・グループの切替え

26.3.4.1.2 単一のセッションの切替え

SWITCH_CONSUMER_GROUP_FOR_SESSプロシージャは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。このプロシージャを使用すると、セッションの優先度を実質的に変更できます。

次のPL/SQLブロックは、特定のセッションを新しいコンシューマ・グループに切り替えます。セッション識別子(SID)は17、セッション・シリアル番号(SERIAL#)は12345、新しいコンシューマ・グループはHIGH_PRIORITYコンシューマ・グループです。

BEGIN
  DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345',
   'HIGH_PRIORITY');
END;
/

SID、セッション・シリアル番号、およびセッションの現行リソース・コンシューマ・グループは、V$SESSIONビューを使用して確認できます。

関連項目:

V$SESSIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: 手動によるリソース・コンシューマ・グループの切替え

26.3.4.1.3 ユーザーの全セッションの切替え

SWITCH_CONSUMER_GROUP_FOR_USERプロシージャは、指定したユーザー名に関連するすべてのセッションのリソース・コンシューマ・グループを変更します。

次のPL/SQLブロックは、ユーザーHRに属しているすべてのセッションをLOW_GROUPコンシューマ・グループに切り替えます。

BEGIN
  DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('HR',
    'LOW_GROUP'); 
END;
/

親トピック: 手動によるリソース・コンシューマ・グループの切替え

26.3.4.2 ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化

管理者は、ユーザーがDBMS_SESSIONパッケージのSWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、現在のコンシューマ・グループを切り替えられるように、スイッチ特権をユーザーに付与できます。

ユーザーが対話型セッション(SQL*Plusなど)でこのプロシージャを実行するか、アプリケーションでこのプロシージャをコールすることで、セッションを切り替え、実質的にその優先度を動的に変更できます。

ユーザーは、SWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、スイッチ特権があるコンシューマ・グループにのみ切り替えることができます。他のプロシージャからこのプロシージャがコールされた場合、ユーザーはコール側のプロシージャの所有者がスイッチ特権を持っているコンシューマ・グループに切り替えることができます。

このプロシージャのパラメータは、次のとおりです。

パラメータ説明

パラメータ	説明
`NEW_CONSUMER_GROUP`	切替え先のコンシューマ・グループ。
`OLD_CONSUMER_GROUP`	切替え元のコンシューマ・グループの名前が戻ります。このパラメータは、後で元のコンシューマ・グループに再び切り替えるときに使用できます。
`INITIAL_GROUP_ON_ERROR`	切替えエラー発生時の動作を制御します。 `TRUE`に設定すると、エラーが発生した場合にユーザーは初期コンシューマ・グループに切り替わります。 `FALSE`の場合は、そのままエラーが出力されます。

NEW_CONSUMER_GROUP

切替え先のコンシューマ・グループ。

OLD_CONSUMER_GROUP

切替え元のコンシューマ・グループの名前が戻ります。このパラメータは、後で元のコンシューマ・グループに再び切り替えるときに使用できます。

INITIAL_GROUP_ON_ERROR

切替えエラー発生時の動作を制御します。

TRUEに設定すると、エラーが発生した場合にユーザーは初期コンシューマ・グループに切り替わります。

FALSEの場合は、そのままエラーが出力されます。

次のSQL*Plusセッションは、新しいコンシューマ・グループへの切替え方法を示しています。出力パラメータold_groupの値が出力されているため、変更前のコンシューマ・グループ名がどのように保存されているかがわかります。

SET serveroutput on
DECLARE
    old_group varchar2(30);
BEGIN
  DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('BATCH_GROUP', old_group, FALSE);
  DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group);
END;
/

次の行が出力されます。

OLD GROUP = OLTP_GROUP

リソース・マネージャでは、セッションをすでに配置されているコンシューマ・グループに切り替えるためにSWITCH_CURRENT_CONSUMER_GROUPプロシージャがコールされている場合でも、切替えが発生したとみなされます。

注意:

リソース・マネージャは、一般的なデータベース・ユーザー名を使用してアプリケーションにログインしている環境でも機能します。DBMS_SESSIONパッケージは、セッションの開始時、または特定のモジュールがコールされたときにセッションのコンシューマ・グループ割当てを切り替えるために使用できます。

関連項目:

「スイッチ特権の付与と取消し」
DBMS_SESSIONパッケージのその他の例と詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: リソース・コンシューマ・グループの切替え

26.3.5 コンシューマ・グループの自動切替えの指定

特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。

自動切替えは、セッション属性が変更された結果、新規マッピング・ルールが有効になった場合、または、セッションが、そのコンシューマ・グループに設定されているCPU、物理I/Oまたは論理I/Oリソースの使用制限を超えた場合、またはそのコンシューマ・グループに設定されている経過時間制限を超えた場合に行われることがあります。

マッピング・ルールを使用した自動切替えの指定
セッションの実行中にセッション属性が変更されると、コンシューマ・グループへのセッションのマッピング・ルールが再評価されます。新しいルールが有効になると、セッションが別のコンシューマ・グループに移動されることがあります。
リソース制限の設定による自動切替えの指定
指定された制限を超えるCPUリソース、物理I/Oリソースまたは論理I/Oリソースを使用する、リソース集中型のセッションまたはコールを管理できます。リソース集中型のセッションはSQL問合せ、リソース集中型のコールはPL/SQLコールです。

26.3.5.1 マッピング・ルールを使用した自動切替えの指定

セッションの実行中にセッション属性が変更されると、コンシューマ・グループへのセッションのマッピング・ルールが再評価されます。新しいルールが有効になると、セッションが別のコンシューマ・グループに移動されることがあります。

詳細は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。

親トピック: コンシューマ・グループの自動切替えの指定

26.3.5.2 リソース制限の設定による自動切替えの指定

指定された制限を超えるCPUリソース、物理I/Oリソースまたは論理I/Oリソースを使用する、リソース集中型のセッションまたはコールを管理できます。リソース集中型のセッションはSQL問合せ、リソース集中型のコールはPL/SQLコールです。

コンシューマ・グループに対してリソース・プラン・ディレクティブを作成する場合は、そのグループのセッションに対してCPU、物理I/Oまたは論理I/Oリソースの使用制限を指定できます。物理I/Oと論理I/Oの制限は別々に指定できます。経過時間の制限を指定することもできます。SWITCH_FOR_CALLリソース・プラン・ディレクティブがFALSEに設定されている場合、リソース・マネージャはセッションの開始からこれらの制限を強制します。SWITCH_FOR_CALLリソース・プラン・ディレクティブがTRUEに設定されている場合、リソース・マネージャはSQL操作またはPL/SQLブロックの開始からこれらの制限を強制します。

その後、単一のセッションまたはコールが制限のいずれかを超過した場合に実行する処理を指定できます。次のような処理が考えられます。

セッションを指定のコンシューマ・グループに動的に切り替えます。

通常、ターゲット・コンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。
セッションを停止(終了)します。
セッションの現行のSQL文を中止します。
セッションに関する情報を記録しますが、セッションに関するその他の処理は実行しません。

このタイプのセッション自動切替えに関連するリソース・プラン・ディレクティブの属性は、次のとおりです。

SWITCH_GROUP
SWITCH_TIME
SWITCH_ESTIMATE
SWITCH_IO_MEGABYTES
SWITCH_IO_REQS
SWITCH_FOR_CALL
SWITCH_IO_LOGICAL
SWITCH_ELAPSED_TIME

これらの属性の詳細は、「リソース・プラン・ディレクティブの作成」を参照してください。

切替えは、実行中でリソースを使用しているセッション(ユーザー入力またはCPUサイクルを待機中でないセッション)に対して行われます。セッションが切り替えられた後は、アイドル状態になるまでターゲット・コンシューマ・グループで継続され、アイドル状態になると、元のコンシューマ・グループに切替えが戻されます。ただし、SWITCH_FOR_CALLがTRUEに設定されている場合、リソース・マネージャは、セッションがアイドル状態になるまで待機して元のリソース・コンシューマ・グループにセッションを戻す処理を行いません。かわりに、現在のトップレベルのコールが完了すると、セッションは戻されます。PL/SQLの場合、トップレベルのコールは、1つのコールとして処理されるPL/SQLブロック全体です。SQLの場合、トップレベルのコールは、個々のSQL文です。

SWITCH_FOR_CALLは、中間層のサーバーがセッション・プーリングを使用している3層アプリケーションの場合に有効です。

新しいグループのアクティブ・セッション・プールが一杯の場合も、切り替えたセッションは引き続き実行できます。このような状況では、コンシューマ・グループは、アクティブ・セッション・プールで指定された数より多いセッションを実行できます。

SWITCH_FOR_CALLがFALSEの場合、リソース・マネージャは、コールの間隔が一定の時間を超えたセッションをアイドル状態とみなします。この時間間隔は数秒で、設定できません。

次に、リソース制限に基づいた自動切替えの例を示します。これらの例を実行する前に、ペンディング・エリアを作成する必要があります。

例1

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッション内のコールのCPU時間が5秒を超えるとそのグループのすべてのセッションをLOW_GROUPコンシューマ・グループに切り替えます。この例は、予想外に時間がかかる問合せによって過剰なリソースが使用されないようにします。通常、切替え先のコンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'OLTP',
   COMMENT          => 'OLTP group',
   MGMT_P1          => 75,
   SWITCH_GROUP     => 'LOW_GROUP',
   SWITCH_TIME      => 5);
END;
/

例2

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッションで物理I/O要求が10,000を超えるか転送されたデータが2,500 MBを超えると、そのグループのすべてのセッションを一時的にLOW_GROUPコンシューマ・グループに切り替えます。問題を引き起こしているトップレベルのコールが完了すると、セッションは元のグループに戻されます。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN                => 'DAYTIME',
   GROUP_OR_SUBPLAN    => 'OLTP',
   COMMENT             => 'OLTP group',
   MGMT_P1             => 75,
   SWITCH_GROUP        => 'LOW_GROUP',
   SWITCH_IO_REQS      => 10000,
   SWITCH_IO_MEGABYTES => 2500,
   SWITCH_FOR_CALL     => TRUE);
END;
/

例3

次のPL/SQLブロックはREPORTINGグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはCPUタイムが60秒を超えるすべてのセッションを停止(終了)します。この例は、リソース集中型の問合せによって過剰なリソースが使用されないようにします。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'REPORTING',
   COMMENT          => 'Reporting group',
   MGMT_P1          => 75,
   SWITCH_GROUP     => 'KILL_SESSION',
   SWITCH_TIME      => 60);
END;
/

この例では、予約済のコンシューマ・グループ名KILL_SESSIONがSWITCH_GROUPで指定されています。そのため、切替え基準が満たされると、セッションは終了します。その他の予約済のコンシューマ・グループ名は、CANCEL_SQLとLOG_ONLYです。CANCEL_SQLを指定した場合、切替え基準が満たされると現在のコールは取り消されますが、セッションは終了しません。LOG_ONLYを指定した場合、セッションに関する情報がリアルタイムSQL監視で記録されますが、セッションに関する特定の処理は実行されません。

例4

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッションで論理I/O要求が100を超えると、そのグループのすべてのセッションを一時的にLOW_GROUPコンシューマ・グループに切り替えます。問題を引き起こしているトップレベルのコールが完了すると、セッションは元のグループに戻されます。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN                => 'DAYTIME',
   GROUP_OR_SUBPLAN    => 'OLTP',
   COMMENT             => 'OLTP group',
   MGMT_P1             => 75,
   SWITCH_GROUP        => 'LOW_GROUP',
   SWITCH_IO_LOGICAL   => 100,
   SWITCH_FOR_CALL     => TRUE);
END;
/

例5

次のPL/SQLブロックはOLTPグループのリソース・プラン・ディレクティブを作成し、そのディレクティブはセッション内のコールが5分(300秒)を超えると、そのグループのすべてのセッションを一時的にLOW_GROUPコンシューマ・グループに切り替えます。問題を引き起こしているトップレベルのコールが完了すると、セッションは元のグループに戻されます。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN                => 'DAYTIME',
   GROUP_OR_SUBPLAN    => 'OLTP',
   COMMENT             => 'OLTP group',
   MGMT_P1             => 75,
   SWITCH_GROUP        => 'LOW_GROUP',
   SWITCH_FOR_CALL     => TRUE,
   SWITCH_ELAPSED_TIME => 300);
END;
/

関連項目:

「リソース・プラン・ディレクティブの作成」
論理I/Oの詳細は、「リソース・マネージャが提供するワークロード管理のソリューション」を参照してください

親トピック: コンシューマ・グループの自動切替えの指定

26.3.6 スイッチ特権の付与と取消し

ユーザーまたはアプリケーションがセッションを指定されたリソース・コンシューマ・グループに切り替えるには、スイッチ特権が必要です。

スイッチ特権の付与と取消しについて
DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり取り消すことができます。スイッチ特権を使用すると、ユーザーまたはアプリケーションが、指定されているリソース・コンシューマ・グループにセッションを切り替えることができるようになります。
スイッチ特権の付与
GRANT_SWITCH_CONSUMER_GROUPプロシージャを使用して、特定のコンシューマ・グループに切り替えるための権限をユーザーに付与できます。
スイッチ特権の取消し
REVOKE_SWITCH_CONSUMER_GROUPプロシージャを使用して、特定のコンシューマ・グループに切り替えるためのユーザーの権限を取り消すことができます。

26.3.6.1 スイッチ特権の付与と取消しについて

DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり取り消すことができます。スイッチ特権を使用すると、ユーザーまたはアプリケーションが、指定されているリソース・コンシューマ・グループにセッションを切り替えることができるようになります。

このパッケージでは、スイッチ特権を取り消すこともできます。次の表に、関連するパッケージ・プロシージャの一覧を示します。

プロシージャ	説明
`GRANT_SWITCH_CONSUMER_GROUP`	ユーザー、ロールまたは`PUBLIC`に、指定したリソース・コンシューマ・グループに切り替える許可を付与します。
`REVOKE_SWITCH_CONSUMER_GROUP`	ユーザー、ロールまたは`PUBLIC`から、指定したリソース・コンシューマ・グループに切り替える許可を取り消します。

OTHER_GROUPSでは、スイッチ特権がPUBLICに付与されています。したがって、すべてのユーザーに、このコンシューマ・グループに対するスイッチ特権が自動的に付与されます。

次の切替えには明示的なスイッチ特権は必要ありません。

DBMS_RESOURCE_MANAGERパッケージのSET_CONSUMER_GROUP_MAPPINGプロシージャによって指定されたコンシューマ・グループ・マッピングがあり、このマッピングのために、セッションは、異なるコンシューマ・グループに切り替わります。「コンシューマ・グループのマッピング・ルールの作成」を参照してください。
リソース・プラン・ディレクティブのswitch_groupパラメータの設定に基づいて切替え条件が満たされたとき、コンシューマ・グループの自動切替えが行われます。

その他のすべての場合、セッションをコンシューマ・グループに切り替えるには、明示的なスイッチ特権が必要となります。

関連項目:

親トピック: スイッチ特権の付与と取消し

26.3.6.2 スイッチ特権の付与

GRANT_SWITCH_CONSUMER_GROUPプロシージャを使用して、特定のコンシューマ・グループに切り替えるための権限をユーザーに付与できます。

次の例では、コンシューマ・グループOLTPに切り替える権限をユーザーSCOTTに付与しています。

BEGIN
  DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
   GRANTEE_NAME   => 'SCOTT',
   CONSUMER_GROUP => 'OLTP',
   GRANT_OPTION   =>  TRUE);
END;
/

ユーザーSCOTTには、OLTPのスイッチ特権を他のユーザーに付与する許可も付与されます。

特定のリソース・コンシューマ・グループに切り替えるロールに権限を付与すると、そのロールを付与されたユーザーおよびそのロールを有効にしているユーザーは、各自のセッションをそのコンシューマ・グループに切り替えることができます。

特定のコンシューマ・グループに切り替える許可をPUBLICに付与すると、だれでもそのグループに切り替えることができます。

GRANT_OPTION引数がTRUEの場合、コンシューマ・グループのスイッチ特権が付与されたユーザーは、そのコンシューマ・グループのスイッチ特権を他のユーザーに付与することもできます。

親トピック: スイッチ特権の付与と取消し

26.3.6.3 スイッチ特権の取消し

REVOKE_SWITCH_CONSUMER_GROUPプロシージャを使用して、特定のコンシューマ・グループに切り替えるためのユーザーの権限を取り消すことができます。

次の例では、コンシューマ・グループOLTPに切り替えるユーザーSCOTTの権限を取り消しています。

BEGIN
  DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP (
   REVOKEE_NAME   => 'SCOTT', 
   CONSUMER_GROUP => 'OLTP');
END;
/

特定のコンシューマ・グループに対するユーザーのスイッチ特権を取り消した場合は、そのユーザーがそのコンシューマ・グループに手動で切り替えようとすると失敗します。このユーザーのセッションは、自動的にOTHER_GROUPSに割り当てられます。

コンシューマ・グループに対するスイッチ特権をロールから取り消すと、そのロールを介してのみコンシューマ・グループのスイッチ特権を与えられているユーザーは、そのコンシューマ・グループに切り替えることができなくなります。

コンシューマ・グループに対するスイッチ特権をPUBLICから取り消すと、直接またはロールを介してスイッチ特権を明示的に割り当てられているユーザー以外は、そのコンシューマ・グループに切り替えることができなくなります。

親トピック: スイッチ特権の付与と取消し

26.4 リソース・プランの管理

リソース・マネージャは、マルチテナント・コンテナ・データベース(CDB)内のプラガブル・データベース(PDB)にリソースを割り当てます。

この章では、次の前提条件を満たしていることを前提としています。

CDBを構成および管理する方法について理解しています。

注意:

この章のタスクは、SQL*PlusまたはOracle SQL Developerを使用して実行できます。
リソース・マネージャは、Oracle Enterprise Manager Cloud Control (Cloud Control)のグラフィカル・ユーザー・インタフェースで管理することもできます。
単純にするために、この章ではPDB、アプリケーション・ルートおよびアプリケーションPDBを「PDB」と呼びます。

CDBリソース・プランの管理
CDBでは、PDBの優先度のレベルが異なる場合があります。CDBリソース・プランを作成し、これらの優先度に従ってPDBごとにリソースを分配できます。
PDBリソース・プランの管理
個々のPDBのリソース・プランを作成し、有効化および変更できます。
単純なリソース・プランの作成
CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。
複雑なリソース・プランの作成
複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.4.1 CDBリソース・プランの管理

CDBでは、PDBの優先度のレベルが異なる場合があります。CDBリソース・プランを作成し、これらの優先度に従ってPDBごとにリソースを分配できます。

PDBを管理するためのCDBリソース・プランの作成
個々のPDBにCDBリソース・プランを作成し、プランに対してディレクティブを定義するには、DBMS_RESOURCE_MANAGERパッケージを使用します。
PDBを管理するためのCDBリソース・プランの作成: 使用例
この使用例では、個々のPDBのCDBリソース・プランの作成に必要な各ステップを示します。
PDBパフォーマンス・プロファイルを使用したCDBリソース・プランの作成
DBMS_RESOURCE_MANAGERパッケージを使用してPDBパフォーマンス・プロファイルのCDBリソース・プランを作成し、プランに対してディレクティブを定義します。プロファイルを使用する各PDBには、CDBリソース・プラン・ディレクティブが採用されます。
PDBパフォーマンス・プロファイルに対するCDBリソース・プランの作成: 使用例
この使用例では、PDBパフォーマンス・プロファイルのCDBリソース・プランの作成に必要な各ステップを示します。
CDBリソース・プランの有効化
ルートのRESOURCE_MANAGER_PLAN初期化パラメータを設定して、CDBに対してリソース・マネージャを有効化します。
CDBリソース・プランの変更
CDBリソース・プランの変更には、プランの更新、PDBのプラン・ディレクティブの作成、更新または削除、デフォルト・ディレクティブの更新などのタスクが含まれます。
CDBリソース・プランの無効化
ルートのRESOURCE_MANAGER_PLAN初期化パラメータを解除して、CDBに対してリソース・マネージャを無効化します。
CDBのプランおよびディレクティブに関する情報の表示
CDBリソース・プラン、CDBリソース・プラン・ディレクティブおよびCDBにおける事前定義のリソース・プランに関する情報を表示できます。

親トピック: リソース・プランの管理

26.4.1.1 PDBを管理するためのCDBリソース・プランの作成

個々のPDBにCDBリソース・プランを作成し、プランに対してディレクティブを定義するには、DBMS_RESOURCE_MANAGERパッケージを使用します。

個々のPDBのCDBリソース・プランの一般的な作成ステップは、次のとおりです。

CREATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを作成します。
CREATE_CDB_PLANプロシージャを使用して、CDBリソース・プランを作成します。
CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBにディレクティブを作成します。
(オプション) UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用して、デフォルトPDBディレクティブを更新します。
VALIDATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを検証します。
SUBMIT_PENDING_AREAプロシージャを使用して、ペンディング・エリアを発行します。

親トピック: CDBリソース・プランの管理

26.4.1.2 PDBを管理するためのCDBリソース・プランの作成: 使用例

この使用例では、個々のPDBのCDBリソース・プランの作成に必要な各ステップを示します。

この使用例では、newcdbという名前のCDBにCDBリソース・プランを作成する場合を想定しています。プランには、PDBごとにディレクティブを含めます。また、この使用例では、デフォルト・ディレクティブおよびAutoTaskディレクティブも更新します。

ディレクティブは、DBMS_RESOURCE_MANAGERパッケージ内の各種プロシージャを使用して定義されます。各ディレクティブの属性は、これらのプロシージャのパラメータを使用して定義されます。表26-12で、プランにおけるディレクティブのタイプについて説明します。

表26-12 CDBリソース・プランにおけるPDBディレクティブの属性

ディレクティブ属性説明関連項目

ディレクティブ属性	説明	関連項目
`shares`	CPUリソースおよびパラレル実行サーバー・リソースのリソース割当ての共有。	「PDBへのリソース割当ての共有」
`utilization_limit`	CPUのリソース使用率制限。	「PDBの使用率制限」
`parallel_server_limit`	パラレル文をキューイングするまでに、PDBで使用できるパラレル実行サーバーの最大割合。 PDBに対して`parallel_server_limit`ディレクティブが指定されている場合、制限は、CDBルートの`PARALLEL_SERVERS_TARGET`値を`CREATE_CDB_PLAN_DIRECTIVE`プロシージャの`parallel_server_limit`パラメータの値で乗算した値になります。注意: CDBプランで`parallel_server_limit`ディレクティブを使用するかわりに、`PARALLEL_SERVERS_TARGET`初期化パラメータを使用することをお薦めします。	「PDBの使用率制限」

shares

CPUリソースおよびパラレル実行サーバー・リソースのリソース割当ての共有。

「PDBへのリソース割当ての共有」

utilization_limit

CPUのリソース使用率制限。

parallel_server_limit

パラレル文をキューイングするまでに、PDBで使用できるパラレル実行サーバーの最大割合。

PDBに対してparallel_server_limitディレクティブが指定されている場合、制限は、CDBルートのPARALLEL_SERVERS_TARGET値をCREATE_CDB_PLAN_DIRECTIVEプロシージャのparallel_server_limitパラメータの値で乗算した値になります。

注意: CDBプランでparallel_server_limitディレクティブを使用するかわりに、PARALLEL_SERVERS_TARGET初期化パラメータを使用することをお薦めします。

表26-13で、CDBリソース・プランにより、表26-12で説明されているディレクティブ属性を使用してリソースがそのPDBにどのように割り当てられるかについて説明します。

表26-13 CDBリソース・プランにおけるPDBのサンプル・ディレクティブ

PDB	sharesディレクティブ	utilization_limitディレクティブ	parallel_server_limitディレクティブ
`salespdb`	3	無制限	無制限
`servicespdb`	3	無制限	無制限
`hrpdb`	1	70	70
デフォルト	1	50	50
AutoTask	1	75	75

PDB salespdbおよびservicespdbは、CDB内の他のPDBよりも重要です。したがって、これらに対しては、高い共有(3)、無制限のCPU使用率リソースおよび無制限のパラレル実行サーバー・リソースが確保されます。

デフォルト・ディレクティブは、特定のディレクティブが定義されていないPDBに適用されます。この使用例では、CDBに、デフォルト・ディレクティブを使用する複数のPDBが含まれていると想定しています。この使用例では、デフォルト・ディレクティブを更新します。

さらに、この使用例では、自動タスク・ディレクティブも更新します。自動タスク・ディレクティブは、ルート・メンテナンス・ウィンドウで実行される自動メンテナンス・タスクに適用されます。

CDBリソース・プランを作成する手順は、次のとおりです。

次のCREATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを作成します。
```
exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
```
次のCREATE_CDB_PLANプロシージャを使用して、newcdb_planという名前のCDBリソース・プランを作成します。
```
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
    plan    => 'newcdb_plan',
    comment => 'CDB resource plan for newcdb');
END;
/
```

CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBにCDBリソース・プラン・ディレクティブを作成します。各ディレクティブにより、特定のPDBへのリソースの割当て方法が指定されます。

表26-13で、この使用例のPDB salespdb、servicespdbおよびhrpdbのディレクティブについて説明します。次のプロシージャを実行して、これらのディレクティブを作成します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    pluggable_database    => 'salespdb', 
    shares                => 3, 
    utilization_limit     => 100,
    parallel_server_limit => 100);
END;
/

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    pluggable_database    => 'servicespdb', 
    shares                => 3, 
    utilization_limit     => 100,
    parallel_server_limit => 100);
END;
/

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    pluggable_database    => 'hrpdb', 
    shares                => 1, 
    utilization_limit     => 70,
    parallel_server_limit => 70);
END;
/

このCDB内の他のすべてのPDBでは、デフォルトPDBディレクティブが使用されます。

PDBの現在のデフォルトCDBリソース・プラン・ディレクティブが要件を満たしていない場合、UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用してディレクティブを更新します。

デフォルト・ディレクティブは、特定のディレクティブが定義されていないPDBに適用されます。詳細は、「PDBのデフォルト・ディレクティブ」を参照してください。

表26-13で、この使用例のPDBで使用されているデフォルト・ディレクティブについて説明します。次のプロシージャを実行して、デフォルト・ディレクティブを更新します。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_DEFAULT_DIRECTIVE(
    plan                      => 'newcdb_plan', 
    new_shares                => 1, 
    new_utilization_limit     => 50,
    new_parallel_server_limit => 50);
END;
/
```
次のVALIDATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを検証します。
```
exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
```
次のSUBMIT_PENDING_AREAプロシージャを使用して、ペンディング・エリアを発行します。
```
exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
```

親トピック: CDBリソース・プランの管理

26.4.1.3 PDBパフォーマンス・プロファイルを使用するCDBリソース・プランの作成

DBMS_RESOURCE_MANAGERパッケージを使用してPDBパフォーマンス・プロファイルのCDBリソース・プランを作成し、プランに対してディレクティブを定義します。プロファイルを使用する各PDBには、CDBリソース・プラン・ディレクティブが採用されます。

PDBパフォーマンス・プロファイルのあるCDBリソース・プランの一般的な作成ステップは、次のとおりです。

CREATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを作成します。
CREATE_CDB_PLANプロシージャを使用して、CDBリソース・プランを作成します。
CREATE_CDB_PROFILE_DIRECTIVEプロシージャを使用して、PDBパフォーマンス・プロファイルのディレクティブを作成します。
(オプション) UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用して、デフォルトPDBディレクティブを更新します。
VALIDATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを検証します。
SUBMIT_PENDING_AREAプロシージャを使用して、ペンディング・エリアを発行します。
プロファイルを使用する各PDBについて、DB_PERFORMANCE_PROFILE初期化パラメータを設定し、プロファイル名を指定します。

親トピック: CDBリソース・プランの管理

26.4.1.4 PDBパフォーマンス・プロファイルに対するCDBリソース・プランの作成: 使用例

この使用例では、PDBパフォーマンス・プロファイルに対するCDBリソース・プランの作成に必要な各ステップを示します。

この使用例では、newcdbという名前のCDBにCDBリソース・プランを作成する場合を想定しています。プランには、PDBパフォーマンス・プロファイルごとにディレクティブを含めます。また、この使用例では、デフォルト・ディレクティブおよびAutoTaskディレクティブも更新します。

CDBリソース・プランで、各プロファイルに名前を付けます。各PDBで、DB_PERFORMANCE_PROFILE初期化パラメータを設定して、PDBが使用するPDBパフォーマンス・プロファイルを指定します。

ディレクティブは、DBMS_RESOURCE_MANAGERパッケージ内の各種プロシージャを使用して定義されます。各ディレクティブの属性は、これらのプロシージャのパラメータを使用して定義されます。次の表で、プランにおけるディレクティブのタイプについて説明します。

表26-14 CDBリソース・プランにおけるPDBパフォーマンス・プロファイル・ディレクティブの属性

ディレクティブ属性説明関連項目

ディレクティブ属性	説明	関連項目
`shares`	CPUリソースおよびパラレル実行サーバー・リソースのリソース割当ての共有。	「PDBへのリソース割当ての共有」
`utilization_limit`	CPUのリソース使用率制限。	「PDBの使用率制限」
`parallel_server_limit`	PDBで使用できるパラレル実行サーバーの最大割合。 PDBパフォーマンス・プロファイルに対して`parallel_server_limit`ディレクティブが指定されている場合、制限は、CDBルートの`PARALLEL_SERVERS_TARGET`初期化パラメータの設定値を`CREATE_CDB_PROFILE_DIRECTIVE`プロシージャの`parallel_server_limit`パラメータの値で乗算した値になります。	「PDBの使用率制限」

shares

CPUリソースおよびパラレル実行サーバー・リソースのリソース割当ての共有。

「PDBへのリソース割当ての共有」

utilization_limit

CPUのリソース使用率制限。

parallel_server_limit

PDBで使用できるパラレル実行サーバーの最大割合。

PDBパフォーマンス・プロファイルに対してparallel_server_limitディレクティブが指定されている場合、制限は、CDBルートのPARALLEL_SERVERS_TARGET初期化パラメータの設定値をCREATE_CDB_PROFILE_DIRECTIVEプロシージャのparallel_server_limitパラメータの値で乗算した値になります。

「コンシューマ・グループのマッピング・ルールの作成」

次の表で、CDBリソース・プランにより、表26-14で説明されているディレクティブ属性を使用してリソースがそのPDBパフォーマンス・プロファイルにどのように割り当てられるかについて説明します。

表26-15 CDBリソース・プランにおけるPDBパフォーマンス・プロファイルのサンプル・ディレクティブ

PDB	sharesディレクティブ	utilization_limitディレクティブ	parallel_server_limitディレクティブ
`gold`	3	無制限	無制限
`silver`	2	40	40
`bronze`	1	20	20
デフォルト	1	10	10
AutoTask	2	60	60

PDBパフォーマンス・プロファイルに対してCDBリソース・プランを作成する手順は、次のとおりです。

プロファイルを使用する各PDBについて、DB_PERFORMANCE_PROFILE初期化パラメータをそのPDBが使用するプロファイルの名前に設定します。
1. ALTER SYSTEM文を実行してパラメータを設定します。
  
  たとえば、PDBを現在のコンテナとして、次のSQL文を実行します。
```
ALTER SYSTEM SET DB_PERFORMANCE_PROFILE=gold SCOPE=spfile;
```
2. PDBをクローズします。
```
ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE;
```
3. PDBをオープンします。
```
ALTER PLUGGABLE DATABASE OPEN;
```
次のCREATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを作成します。
```
exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
```
次のCREATE_CDB_PLANプロシージャを使用して、newcdb_planという名前のCDBリソース・プランを作成します。
```
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
    plan    => 'newcdb_plan',
    comment => 'CDB resource plan for newcdb');
END;
/
```

表26-13は、このシナリオのgold、silverおよびbronzeプロファイルのディレクティブを示しています。次のプロシージャを実行して、これらのディレクティブを作成します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    profile               => 'gold', 
    shares                => 3, 
    utilization_limit     => 100,
    parallel_server_limit => 100);
END;
/

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    profile               => 'silver', 
    shares                => 2, 
    utilization_limit     => 40,
    parallel_server_limit => 40);
END;
/

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    profile               => 'bronze', 
    shares                => 1, 
    utilization_limit     => 20,
    parallel_server_limit => 20);
END;
/

このCDB内の他のすべてのPDBでは、デフォルトPDBディレクティブが使用されます。

PDBの現在のデフォルトCDBリソース・プラン・ディレクティブが要件を満たしていない場合、UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用してディレクティブを更新します。

デフォルト・ディレクティブは、特定のディレクティブが定義されていないPDBに適用されます。

表26-13で、この使用例のPDBで使用されているデフォルト・ディレクティブについて説明します。次のプロシージャを実行して、デフォルト・ディレクティブを更新します。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_DEFAULT_DIRECTIVE(
    plan                      => 'newcdb_plan', 
    new_shares                => 1, 
    new_utilization_limit     => 10,
    new_parallel_server_limit => 10);
END;
/
```
次のVALIDATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを検証します。
```
exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
```
次のSUBMIT_PENDING_AREAプロシージャを使用して、ペンディング・エリアを発行します。
```
exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
```

関連項目:

「PDBのデフォルト・ディレクティブ」

親トピック: CDBリソース・プランの管理

26.4.1.5 CDBリソース・プランの有効化

ルートのRESOURCE_MANAGER_PLAN初期化パラメータを設定して、CDBに対してリソース・マネージャを有効化します。

このパラメータにより、CDBの現行インスタンスに使用されるトップレベルのプランが指定されます。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。

前提条件

CDBが存在し、PDBを含んでいる必要があります。DBMS_RESOURCE_MANAGERパッケージを使用するタスクを完了するには、ADMINISTER_RESOURCE_MANAGERシステム権限が必要です。

CDBリソース・プランを有効化する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。
次のいずれかのアクションを実行します。
- ALTER SYSTEM文を使用して、RESOURCE_MANAGER_PLAN初期化パラメータをCDBリソース・プランに設定します。
  
  次の例では、ALTER SYSTEM文を使用して、CDBリソース・プランをnewcdb_planに設定しています。
```
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'newcdb_plan';
```
- テキスト形式の初期化パラメータ・ファイルで、RESOURCE_MANAGER_PLAN初期化パラメータをCDBリソース・プランに設定し、CDBを再起動します。
  
  次の例では、初期化パラメータ・ファイルのCDBリソース・プランをnewcdb_planに設定しています。
```
RESOURCE_MANAGER_PLAN = 'newcdb_plan'
```

関連項目:

CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
Oracle Schedulerを使用してCDBリソース・プランの変更をスケジュールする方法の詳細は、Oracle Schedulerの概念を参照してください

親トピック: CDBリソース・プランの管理

26.4.1.6 CDBリソース・プランの変更

CDBリソース・プランの変更には、プランの更新、PDBのプラン・ディレクティブの作成、更新または削除、デフォルト・ディレクティブの更新などのタスクが含まれます。

CDBリソース・プランの更新
UPDATE_CDB_PLANプロシージャを使用すると、CDBリソース・プランを更新して、そのコメントを変更できます。
PDBのCDBリソース・プラン・ディレクティブの管理
PDBのCDBリソース・プラン・ディレクティブを作成、更新および削除できます。
PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの管理
PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを作成、更新および削除できます。
CDBリソース・プランにおけるPDBのデフォルト・ディレクティブの更新
UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用して、CDBリソース・プランでPDBのデフォルト・ディレクティブを更新できます。デフォルト・ディレクティブは、特定のディレクティブが定義されていないPDBに適用されます。
CDBリソース・プランにおけるメンテナンス・タスクのデフォルト・ディレクティブの更新
UPDATE_CDB_AUTOTASK_DIRECTIVEプロシージャを使用して、CDBリソース・プランでAutoTaskディレクティブを更新できます。自動タスク・ディレクティブは、ルート・メンテナンス・ウィンドウで実行される自動メンテナンス・タスクに適用されます。
CDBリソース・プランの削除
DELETE_CDB_PLANプロシージャを使用して、CDBリソース・プランを削除できます。

親トピック: CDBリソース・プランの管理

26.4.1.6.1 CDBリソース・プランの更新

UPDATE_CDB_PLANプロシージャを使用すると、CDBリソース・プランのコメントを変更して更新できます。

前提条件

CDBリソース・プランを更新する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

UPDATE_CDB_PLANプロシージャを実行して、new_commentパラメータに新しいコメントを入力します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのコメントが変更されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_PLAN(
    plan        => 'newcdb_plan',
    new_comment => 'CDB plan for PDBs in newcdb');
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

親トピック: CDBリソース・プランの変更

26.4.1.6.2 PDBのCDBリソース・プラン・ディレクティブの管理

PDBのCDBリソース・プラン・ディレクティブを作成、更新および削除できます。

PDBの新規CDBリソース・プラン・ディレクティブの作成
CDBにPDBを作成する場合、CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBにCDBリソース・プラン・ディレクティブを作成できます。このディレクティブにより、新しいPDBへのリソースの割当て方法が指定されます。
PDBのCDBリソース・プラン・ディレクティブの更新
UPDATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBのCDBリソース・プラン・ディレクティブを更新できます。このディレクティブにより、PDBへのリソースの割当て方法が指定されます。
PDBのCDBリソース・プラン・ディレクティブの削除
DELETE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBのCDBリソース・プラン・ディレクティブを削除できます。

親トピック: CDBリソース・プランの変更

26.4.1.6.2.1 PDBの新規CDBリソース・プラン・ディレクティブの作成

CDBにPDBを作成する場合、CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBにCDBリソース・プラン・ディレクティブを作成できます。このディレクティブにより、新しいPDBへのリソースの割当て方法が指定されます。

前提条件

PDBに新しいCDBリソース・プラン・ディレクティブを作成する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

CREATE_CDB_PLAN_DIRECTIVEプロシージャを実行して、新しいPDBに適切な値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのoperpdbという名前のPDBにリソースが割り当てられます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    pluggable_database    => 'operpdb', 
    shares                => 1, 
    utilization_limit     => 20,
    parallel_server_limit => 30);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

親トピック: PDBのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.2.2 PDBのCDBリソース・プラン・ディレクティブの更新

UPDATE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBのCDBリソース・プラン・ディレクティブを更新できます。このディレクティブにより、PDBへのリソースの割当て方法が指定されます。

前提条件

PDBのCDBリソース・プラン・ディレクティブを更新する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

UPDATE_CDB_PLAN_DIRECTIVEプロシージャを実行して、PDBに新しいリソース割当て値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのoperpdbという名前のPDBに対するリソース割当てが更新されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_PLAN_DIRECTIVE(
    plan                      => 'newcdb_plan', 
    pluggable_database        => 'operpdb', 
    new_shares                => 1, 
    new_utilization_limit     => 10,
    new_parallel_server_limit => 20);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

親トピック: PDBのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.2.3 PDBのCDBリソース・プラン・ディレクティブの削除

DELETE_CDB_PLAN_DIRECTIVEプロシージャを使用して、PDBのCDBリソース・プラン・ディレクティブを削除できます。

PDBを切断または削除すると、PDBのディレクティブが削除される場合があります。ただし、ディレクティブは保持でき、将来PDBがCDBに接続された場合に、既存のディレクティブがPDBに適用されます。

前提条件

PDBのCDBリソース・プラン・ディレクティブを削除する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DELETE_CDB_PLAN_DIRECTIVEプロシージャを実行して、CDBリソース・プランおよびPDBを指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのoperpdbという名前のPDBに対するディレクティブが削除されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.DELETE_CDB_PLAN_DIRECTIVE(
    plan               => 'newcdb_plan', 
    pluggable_database => 'operpdb');
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

親トピック: PDBのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.3 PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの管理

PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを作成、更新および削除できます。

PDBパフォーマンス・プロファイルの新規CDBリソース・プラン・ディレクティブの作成
新規PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブは、CREATE_CDB_PROFILE_DIRECTIVEプロシージャを使用して作成できます。ディレクティブにより、新しいプロファイルを使用するすべてのPDBのリソースの割当て方法を指定します。
PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの更新
UPDATE_CDB_PROFILE_DIRECTIVEプロシージャを使用して、PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを更新します。このディレクティブにより、PDBパフォーマンス・プロファイルを使用するPDBへのリソースの割当て方法が指定されます。
PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの削除
DELETE_CDB_PROFILE_DIRECTIVEプロシージャを使用して、PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを削除できます。

親トピック: CDBリソース・プランの変更

26.4.1.6.3.1 PDBパフォーマンス・プロファイルの新規CDBリソース・プラン・ディレクティブの作成

新規PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブは、CREATE_CDB_PROFILE_DIRECTIVEプロシージャを使用して作成できます。ディレクティブにより、新しいプロファイルを使用するすべてのPDBのリソースの割当て方法を指定します。

前提条件

PDBパフォーマンス・プロファイルに新しいCDBリソース・プラン・ディレクティブを作成する手順:

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

CREATE_CDB_PROFILE_DIRECTIVEプロシージャを実行して、新しいPDBパフォーマンス・プロファイルに適切な値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのcopperという名前のPDBパフォーマンス・プロファイルにリソースが割り当てられます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    profile               => 'copper', 
    shares                => 1, 
    utilization_limit     => 20,
    parallel_server_limit => 30);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

注意:

PDBで新規プロファイルを使用するには、PDBのDB_PERFORMANCE_PROFILE初期化パラメータがプロファイル名に設定されている必要があります。

関連項目:

「CDBリソース・プランの概要」
CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください

親トピック: PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.3.2 PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの更新

UPDATE_CDB_PROFILE_DIRECTIVEプロシージャを使用して、PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを更新します。このディレクティブにより、PDBパフォーマンス・プロファイルを使用するPDBへのリソースの割当て方法が指定されます。

PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを更新する手順:

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

UPDATE_CDB_PROFILE_DIRECTIVEプロシージャを実行して、PDBパフォーマンス・プロファイルに新しいリソース割当て値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのcopperという名前のPDBパフォーマンス・プロファイルに対するリソース割当てが更新されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_PROFILE_DIRECTIVE(
    plan                      => 'newcdb_plan', 
    profile                   => 'copper', 
    new_shares                => 1, 
    new_utilization_limit     => 10,
    new_parallel_server_limit => 20);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

「CDBリソース・プランの概要」
CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください

親トピック: PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.3.3 PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの削除

DELETE_CDB_PROFILE_DIRECTIVEプロシージャを使用して、PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを削除できます。

PDBでパフォーマンス・プロファイルを使用しない場合は、プロファイルのディレクティブを削除できます。

前提条件

PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブを削除する手順:

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DELETE_CDB_PROFILE_DIRECTIVEプロシージャを実行して、CDBリソース・プランおよびPDBパフォーマンス・プロファイルを指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランのoperpdbという名前のPDBに対するディレクティブが削除されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.DELETE_CDB_PLAN_DIRECTIVE(
    plan    => 'newcdb_plan', 
    profile => 'operpdb');
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
「CDBリソース・プランの概要」

親トピック: PDBパフォーマンス・プロファイルのCDBリソース・プラン・ディレクティブの管理

26.4.1.6.4 CDBリソース・プランにおけるPDBのデフォルト・ディレクティブの更新

UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを使用して、CDBリソース・プランでPDBのデフォルト・ディレクティブを更新できます。デフォルト・ディレクティブは、特定のディレクティブが定義されていないPDBに適用されます。

前提条件

CDBリソース・プランでPDBのデフォルトディレクティブを更新する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

UPDATE_CDB_DEFAULT_DIRECTIVEプロシージャを実行して、適切なデフォルトのリソース割当て値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランにおけるPDBのデフォルト・ディレクティブが更新されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_DEFAULT_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    new_shares            => 2, 
    new_utilization_limit => 40);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

「PDBのデフォルト・ディレクティブ」
「CDBリソース・プランの概要」
CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください

親トピック: CDBリソース・プランの変更

26.4.1.6.5 CDBリソース・プランにおけるメンテナンス・タスクのデフォルト・ディレクティブの更新

UPDATE_CDB_AUTOTASK_DIRECTIVEプロシージャを使用して、CDBリソース・プランでAutoTaskディレクティブを更新できます。自動タスク・ディレクティブは、ルート・メンテナンス・ウィンドウで実行される自動メンテナンス・タスクに適用されます。

前提条件

CDBリソース・プランでメンテナンス・タスクのAutoTaskディレクティブを更新する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

UPDATE_CDB_AUTOTASK_DIRECTIVEプロシージャを実行して、適切なAutoTaskのリソース割当て値を指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランにおけるメンテナンス・タスクのAutoTaskディレクティブが更新されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_CDB_AUTOTASK_DIRECTIVE(
    plan                  => 'newcdb_plan', 
    new_shares            => 2, 
    new_utilization_limit => 60);
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

コンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
「CDBリソース・プランの概要」

親トピック: CDBリソース・プランの変更

26.4.1.6.6 CDBリソース・プランの削除

DELETE_CDB_PLANプロシージャを使用して、CDBリソース・プランを削除できます。

リソース・プランを無効にする必要があります。CDBリソース・プランが必要なくなった場合は、このプランを削除できます。異なるCDBリソース・プランを有効化したり、CDBに対してリソース・マネージャを無効化できます。

前提条件

CDBリソース・プランを削除する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

DELETE_CDB_PLANプロシージャを実行して、CDBリソース・プランを指定します。

たとえば、次のプロシージャを実行すると、newcdb_plan CDBリソース・プランが削除されます。
```
BEGIN
  DBMS_RESOURCE_MANAGER.DELETE_CDB_PLAN(
    plan => 'newcdb_plan');
END;
/
```

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

「CDBリソース・プランの概要」
コンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
「CDBリソース・プランの有効化」
「CDBリソース・プランの無効化」

親トピック: CDBリソース・プランの変更

26.4.1.7 CDBリソース・プランの無効化

RESOURCE_MANAGER_PLAN初期化パラメータの設定を解除して、CDBに対してリソース・マネージャを無効化します。

PDB間およびPDB内のいずれの場合もCPUの管理を有効化するには、PDBの共有または使用率制限を指定するCDBリソース・プランが必要です。PDBの共有または使用率制限が指定されたリソース・プランが有効で、CDBリソース・プランが指定されていない場合、CDBリソース・プランはDEFAULT_CDB_PLANに設定されます。この設定では、すべてのPDBに等しい共有が提供され、使用率制限は指定されません。CDB全体のCPUリソース管理を無効化するには、RESOURCE_MANAGER_PLANをORA$INTERNAL_CDB_PLANに設定します。

前提条件

CDBリソース・プランを無効化する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがルートであることを確認します。
次のいずれかのアクションを実行します。
- ALTER SYSTEM文を使用して、CDBに対してRESOURCE_MANAGER_PLAN初期化パラメータの設定を解除します。
  
  次の例では、ALTER SYSTEM文を使用して、RESOURCE_MANAGER_PLAN初期化パラメータの設定を解除しています。
```
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
```
- 初期化パラメータ・ファイルで、RESOURCE_MANAGER_PLAN初期化パラメータの設定を解除し、CDBを再起動します。
  
  次の例では、初期化パラメータ・ファイルのRESOURCE_MANAGER_PLAN初期化パラメータの設定を解除しています。
```
RESOURCE_MANAGER_PLAN = 
```

関連項目:

コンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
Oracle Multitenant管理者ガイド
データベースの起動の詳細は、Oracle Multitenant管理者ガイドを参照してください

親トピック: CDBリソース・プランの管理

26.4.1.8 CDBのプランおよびディレクティブに関する情報の表示

CDBリソース・プラン、CDBリソース・プラン・ディレクティブおよびCDBにおける事前定義のリソース・プランに関する情報を表示できます。

CDBリソース・プランの表示
DBA_CDB_RSRC_PLANSビューを使用して、CDBに定義されているすべてのCDBリソース・プランを表示する例を示します。
CDBリソース・プラン・ディレクティブの表示
DBA_CDB_RSRC_PLAN_DIRECTIVESビューを使用して、CDB内のすべてのCDBリソース・プランで定義されたすべてのディレクティブを表示する例を示します。

関連項目:

Oracle Database Resource Managerの監視の詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: CDBリソース・プランの管理

26.4.1.8.1 CDBリソース・プランの表示

DBA_CDB_RSRC_PLANSビューを使用して、CDBに定義されているすべてのCDBリソース・プランを表示する例を示します。

DEFAULT_CDB_PLANは、Oracle Databaseに付属しています。使用要件に応じて、このデフォルト・プランを使用できます。

CDBリソース・プランを表示する手順は、次のとおりです。

SQL*PlusまたはSQL Developerを起動し、CDBルートにログインします。

次の問合せを実行します。

COLUMN PLAN FORMAT A30
COLUMN STATUS FORMAT A10
COLUMN COMMENTS FORMAT A35
 
SELECT PLAN, STATUS, COMMENTS 
FROM   DBA_CDB_RSRC_PLANS 
ORDER BY PLAN;

出力は次のようになります。

PLAN                     STATUS      COMMENTS
------------------------ ----------- ----------------------------
DEFAULT_CDB_PLAN                     Default CDB plan
DEFAULT_MAINTENANCE_PLAN             Default CDB maintenance plan
NEWCDB_PLAN                          CDB plan for PDBs in newcdb
ORA$INTERNAL_CDB_PLAN                Internal CDB plan

注意:

ペンディング・エリア内のプランのステータスはPENDINGです。ペンディング・エリア内のプランは編集中です。ペンディング・エリアに存在しないすべてのプランのステータスは、NULLです。

関連項目:

「CDBリソース・プランの概要」

親トピック: CDBのプランおよびディレクティブに関する情報の表示

26.4.1.8.2 CDBリソース・プラン・ディレクティブの表示

DBA_CDB_RSRC_PLAN_DIRECTIVESを使用して、CDB内のすべてのCDBリソース・プランで定義されたすべてのディレクティブを表示する例を示します。

DEFAULT_CDB_PLANは、Oracle Databaseに付属のデフォルトCDBプランです。DEFAULT_CDB_PLANでは、各PDBに共有が1および使用率制限が100と指定されています。CDBリソース・プランにCPUディレクティブが構成されていない、つまりsharesおよびutilization_limitsディレクティブが設定解除されている場合は、CPUリソース・マネージャによって、PDBレベルのCPU_MIN_COUNTおよびCPU_COUNTパラメータを使用してCPUが管理されます。ORA$DEFAULT_PDB_DIRECTIVEは、PDBのデフォルト・ディレクティブです。

CDBリソース・プラン・ディレクティブを表示する手順は、次のとおりです。

SQL*PlusまたはSQL Developerを起動し、CDBルートにログインします。

次の問合せを実行します。

COLUMN PLAN HEADING 'Plan' FORMAT A24
COLUMN PLUGGABLE_DATABASE HEADING 'Pluggable Database' FORMAT A25
COLUMN SHARES HEADING 'Shares' FORMAT 999
COLUMN UTILIZATION_LIMIT HEADING 'Utilization|Limit' FORMAT 999
COLUMN PARALLEL_SERVER_LIMIT HEADING 'Parallel|Server|Limit' FORMAT 999
 
SELECT PLAN, 
       PLUGGABLE_DATABASE, 
       SHARES, 
       UTILIZATION_LIMIT,
       PARALLEL_SERVER_LIMIT
  FROM DBA_CDB_RSRC_PLAN_DIRECTIVES
  ORDER BY PLAN;

出力は次のようになります。

                                                                      Parallel
                                                          Utilization   Server
Plan                     Pluggable Database        Shares       Limit    Limit
------------------------ ------------------------- ------ ----------- --------
DEFAULT_CDB_PLAN         ORA$DEFAULT_PDB_DIRECTIVE      1         100      100
DEFAULT_CDB_PLAN         ORA$AUTOTASK                              90      100
DEFAULT_MAINTENANCE_PLAN ORA$AUTOTASK                              90      100
DEFAULT_MAINTENANCE_PLAN ORA$DEFAULT_PDB_DIRECTIVE      1         100      100
NEWCDB_PLAN              HRPDB                          1          70       70
NEWCDB_PLAN              SALESPDB                       3         100      100
NEWCDB_PLAN              ORA$DEFAULT_PDB_DIRECTIVE      1          50       50
NEWCDB_PLAN              ORA$AUTOTASK                   1          75       75 
NEWCDB_PLAN              SERVICESPDB                    3         100      100

前述の出力は、「PDBを管理するためのCDBリソース・プランの作成: 使用例」で作成されて「CDBリソース・プランの変更」で変更された、newcdb_planのディレクティブを示しています。

関連項目:

親トピック: CDBのプランおよびディレクティブに関する情報の表示

26.4.2 PDBリソース・プランの管理

個々のPDBのリソース・プランを作成し、有効化および変更できます。

PDBリソース・プランの作成
PDBリソース・プランは、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して作成します。
PDBリソース・プランの有効化
現在のコンテナがPDBの場合、ALTER SYSTEM文を使用してRESOURCE_MANAGER_PLAN初期化パラメータをプランに設定し、PDBリソース・プランを有効化します。
PDBリソース・プランの変更
PDBリソース・プランを変更するには、DBMS_RESOURCE_MANAGERパッケージを使用します。
PDBリソース・プランの無効化
PDBのRESOURCE_MANAGER_PLAN初期化パラメータの設定を解除して、PDBリソース・プランを無効化します。

親トピック: リソース・プランの管理

26.4.2.1 PDBリソース・プランの作成

PDBリソース・プランは、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して作成します。

PDBリソース・プランの作成に必要なステップの概要は、次のとおりです。

SQL*Plusで、現在のコンテナがPDBであることを確認します。
CREATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを作成します。
CREATE_CONSUMER_GROUPプロシージャを使用して、コンシューマ・グループを作成、変更または削除します。
SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、セッションをコンシューマ・グループにマップします。
CREATE_PLANプロシージャを使用して、PDBリソース・プランを作成します。
CREATE_PLAN_DIRECTIVEプロシージャを使用して、PDBリソース・プラン・ディレクティブを作成します。
VALIDATE_PENDING_AREAプロシージャを使用して、ペンディング・エリアを検証します。
SUBMIT_PENDING_AREAプロシージャを使用して、ペンディング・エリアを発行します。

現在のコンテナがPDBであり、これらのステップを完了する場合に必要な権限がユーザーに付与されていることを確認してください。これらのステップの完了の詳細は、『Oracle Database管理者ガイド』を参照してください。

CREATE_SIMPLE_PLANプロシージャを使用して、多くの状況に対応できる単純なリソース・プランを作成することもできます。単純なリソース・プランの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

注意:

PDBリソース・プランに適用されるいくつかの制限事項があります。詳細は、「PDBリソース・プランについて」を参照してください。

親トピック: PDBリソース・プランの管理

26.4.2.2 PDBリソース・プランの有効化

現在のコンテナがPDBの場合、ALTER SYSTEM文を使用してRESOURCE_MANAGER_PLAN初期化パラメータをプランに設定し、PDBリソース・プランを有効化します。

このパラメータがプランに指定されていない場合、PDBリソース・プランはPDBに対して有効化されません。

前提条件

PDBリソース・プランを有効化する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがPDBであることを確認します。
ALTER SYSTEM文を使用して、RESOURCE_MANAGER_PLAN初期化パラメータをPDBリソース・プランに設定します。

PDBリソース・プランの変更は、Oracle Schedulerを使用してスケジュールすることもできます。

例26-5 PDBリソース・プランの有効化

次の例では、PDBリソース・プランをsalespdb_planに設定しています。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'salespdb_plan';

関連項目:

CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
システム・レベルでのPDBの変更については、Oracle Multitenant管理者ガイドを参照してください
Oracle Schedulerを使用してPDBリソース・プランの変更をスケジュールする方法の詳細は、Oracle Schedulerの概念を参照してください

親トピック: PDBリソース・プランの管理

26.4.2.3 PDBリソース・プランの変更

PDBリソース・プランを変更するには、DBMS_RESOURCE_MANAGERパッケージを使用します。

前提条件

PDBリソース・プランを変更する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがPDBであることを確認します。

ペンディング・エリアを作成します。

exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

次のタスクのうち1つ以上を完了して、PDBリソース・プランを変更します。
- UPDATE_CONSUMER_GROUPプロシージャを使用して、コンシューマ・グループを更新します。
- DELETE_CONSUMER_GROUPプロシージャを使用して、コンシューマ・グループを削除します。
- UPDATE_PLANプロシージャを使用して、リソース・プランを更新します。
- DELETE_PLANプロシージャを使用して、リソース・プランを削除します。
- UPDATE_PLAN_DIRECTIVEプロシージャを使用して、リソース・プラン・ディレクティブを更新します。
- DELETE_PLAN_DIRECTIVEプロシージャを使用して、リソース・プラン・ディレクティブを削除します。

ペンディング・エリアを検証します。

exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

ペンディング・エリアを発行します。

exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

関連項目:

「PDBリソース・プランについて」
CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
コンシューマ・グループのタスクを完了するための手順については、コンシューマ・グループ、プランおよびディレクティブのメンテナンスを参照してください

親トピック: PDBリソース・プランの管理

26.4.2.4 PDBリソース・プランの無効化

PDBのRESOURCE_MANAGER_PLAN初期化パラメータの設定を解除して、PDBリソース・プランを無効化します。

前提条件

PDBリソース・プランを無効化する手順は、次のとおりです。

SQL*Plusで、現在のコンテナがPDBであることを確認します。
ALTER SYSTEM文を使用して、PDBのRESOURCE_MANAGER_PLAN初期化パラメータの設定を解除します。

例26-6 PDBリソース・プランの無効化

次の例では、PDBリソース・プランを無効化しています。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';

関連項目:

システム・レベルでのPDBの変更については、Oracle Multitenant管理者ガイドを参照してください
CDBのコンテナへのアクセスの詳細は、『Oracle Multitenant管理者ガイド』を参照してください

親トピック: PDBリソース・プランの管理

26.4.3 単純なリソース・プランの作成

CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。

このプロシージャでは、1回のプロシージャ・コールの実行で、コンシューマ・グループを作成し、そのグループにリソースを割り当てることができます。このプロシージャを使用する際は、ペンディング・エリアの作成、各コンシューマ・グループの個別作成、リソース・プラン・ディレクティブの指定のために、後述のプロシージャをコールする必要はありません。

CREATE_SIMPLE_PLANプロシージャには、次の引数を指定します。

パラメータ	説明
`SIMPLE_PLAN`	計画の名前。
`CONSUMER_GROUP1`	1番目のグループのコンシューマ・グループ名
`GROUP1_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP2`	2番目のグループのコンシューマ・グループ名
`GROUP2_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP3`	3番目のグループのコンシューマ・グループ名
`GROUP3_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP4`	4番目のグループのコンシューマ・グループ名
`GROUP4_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP5`	5番目のグループのコンシューマ・グループ名
`GROUP5_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP6`	6番目のグループのコンシューマ・グループ名
`GROUP6_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP7`	7番目のグループのコンシューマ・グループ名
`GROUP7_PERCENT`	このグループに割り当てるCPUリソース
`CONSUMER_GROUP8`	8番目のグループのコンシューマ・グループ名
`GROUP8_PERCENT`	このグループに割り当てるCPUリソース

このプロシージャでは、最大8個のコンシューマ・グループを指定できます。サポート対象のリソース割当て方法は、CPUによる方法のみです。プランでは、EMPHASIS CPU割当てポリシー(デフォルト)が使用され、各コンシューマ・グループでは、ROUND_ROBINスケジューリング・ポリシー(これもデフォルト)が使用されます。プラン内の指定された各コンシューマ・グループには、レベル2のCPUパーセンテージが割り当てられます。このプランには、SYS_GROUP(ユーザーSYSおよびSYSTEM用にシステムによって定義された初期コンシューマ・グループ)とOTHER_GROUPSも暗黙的に含まれています。SYS_GROUPコンシューマ・グループには、レベル1でCPUの100%が割り当てられ、OTHER_GROUPSには、レベル3でCPUの100%が割り当てられます。

例: CREATE_SIMPLE_PLANプロシージャを使用した単純なプランの作成

次のスクリプトは、ユーザー指定の2つのコンシューマ・グループを備えた単純なリソース・プランを作成するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'SIMPLE_PLAN1',
   CONSUMER_GROUP1 => 'MYGROUP1', GROUP1_PERCENT => 80,
   CONSUMER_GROUP2 => 'MYGROUP2', GROUP2_PERCENT => 20);
END;
/

この文を実行すると、次のプランが作成されます。

コンシューマ・グループ	レベル1	レベル2	レベル3
`SYS_GROUP`	100%	-	-
`MYGROUP1`	-	80%	-
`MYGROUP2`	-	20%	-
`OTHER_GROUPS`	-	-	100%

関連項目:

EMPHASIS CPU割当てポリシーの詳細は、「リソース・プランの作成」を参照してください
ROUND_ROBINスケジューリング・ポリシーの詳細は、「リソース・コンシューマ・グループの作成」を参照してください
「リソース・マネージャの要素」

親トピック: リソース・プランの管理

26.4.4 複雑なリソース・プランの作成

複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。

複雑なリソース・プランの作成に必要なステップの概要は、次のとおりです。

注意:

複雑なリソース・プランとは、DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLANプロシージャでは作成できないリソース・プランを指します。

ステップ1: ペンディング・エリアを作成します。

ステップ2: コンシューマ・グループを作成、変更または削除します。

ステップ3: コンシューマ・グループにセッションをマップします。

ステップ4: リソース・プランを作成します。

ステップ5: リソース・プラン・ディレクティブを作成します。

ステップ6: ペンディング・エリアの妥当性をチェックします。

ステップ7: ペンディング・エリアを発行します。

これらのステップは、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して完了します。

ペンディング・エリアの概要
ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。
ペンディング・エリアの作成
ペンディング・エリアはCREATE_PENDING_AREAプロシージャを使用して作成します。
リソース・コンシューマ・グループの作成
リソース・コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUPプロシージャを使用します。
コンシューマ・グループへのセッションのマッピング
SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、コンシューマ・グループにセッションをマップできます。
リソース・プランの作成
リソース・プランを作成するには、CREATE_PLANプロシージャを使用します。
リソース・プラン・ディレクティブの作成
リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVEプロシージャを使用します。各ディレクティブはプランまたはサブプランに属しており、リソースをコンシューマ・グループまたはサブプランに割り当てます。
ペンディング・エリアの妥当性チェック
ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREAをコールして、そのペンディング・エリアの妥当性を確認できます。
ペンディング・エリアの発行
変更の妥当性チェックを完了した後は、SUBMIT_PENDING_AREAプロシージャをコールして変更内容をアクティブにします。
ペンディング・エリアのクリア
CLEAR_PENDING_AREAプロシージャを使用して、ペンディング・エリアをいつでもクリアできます。

関連項目:

事前定義のコンシューマ・グループ・マッピング・ルール
DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
「リソース・マネージャの要素」

親トピック: リソース・プランの管理

26.4.4.1 ペンディング・エリアの概要

ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。

ペンディング・エリアを作成すると、データベースによってペンディング・エリアが初期化され、既存のプランがペンディング・エリアにコピーされて、既存のプランを更新できるようになります。

ヒント:

ペンディング・エリアを作成した後、DBA_RSRC_PLANSデータ・ディクショナリ・ビューを問い合せてすべてのプランをリストすると、各プランについて2つのコピー(PENDINGステータスが付いているコピーと付いていないコピー)が表示されます。PENDINGステータスのプランには、ペンディング・エリアの作成後に実行した変更内容が反映されています。保留中の変更は、コンシューマ・グループの場合はDBA_RSRC_CONSUMER_GROUPSを使用して、リソース・プラン・ディレクティブの場合はDBA_RSRC_PLAN_DIRECTIVESを使用して表示できます。詳細は、「リソース・マネージャのデータ・ディクショナリ・ビュー」を参照してください。

変更を追加した後のペンディング・エリアは、発行する前に妥当性をチェックします。発行すると、保留中の変更内容がすべてデータ・ディクショナリに適用され、ペンディング・エリアはクリアされ、解除されます。

最初にペンディング・エリアを作成せずにプランを作成、更新または削除しようとすると(つまり、コンシューマ・グループまたはリソース・プラン・ディレクティブを作成、更新または削除しようとすると)、エラー・メッセージが表示されます。

ペンディング・エリアを発行しても、新しく作成したプランはアクティブ化されません(新しいプランまたは更新後のプランの情報がデータ・ディクショナリに格納されるだけです)。ただし、現在アクティブなプランを変更した場合、そのプランは新しいプラン定義で再アクティブ化されます。リソース・プランをアクティブ化する方法の詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。

ペンディング・エリアを作成した後は、そのペンディング・エリアを発行またはクリアするか、ログアウトするまで、他のユーザーはペンディング・エリアを作成できません。

親トピック: 複雑なリソース・プランの作成

26.4.4.2 ペンディング・エリアの作成

ペンディング・エリアはCREATE_PENDING_AREAプロシージャを使用して作成します。

例: ペンディング・エリアの作成

次のスクリプトは、ペンディング・エリアを作成して初期化するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
END;
/

親トピック: 複雑なリソース・プランの作成

26.4.4.3 リソース・コンシューマ・グループの作成

リソース・コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUPプロシージャを使用します。

次のパラメータを指定できます。

パラメータ	説明
`CONSUMER_GROUP`	コンシューマ・グループに割り当てる名前。
`COMMENT`	任意のコメント。
`CPU_MTH`	非推奨。`MGMT_MTH`を使用してください。
`MGMT_MTH`	コンシューマ・グループのセッション間でCPUを分配するためのリソース割当て方法。デフォルトは`'ROUND-ROBIN'`で、ラウンドロビン・スケジューラを使用して、セッションの適切な実行を保証します。`'RUN-TO-COMPLETION'`では、長時間実行セッションを他のセッションより先にスケジュールすることを指定します。この設定によって、長時間実行セッション(バッチ処理など)をより早く完了できるようになります。

例: リソース・コンシューマ・グループの作成

次のスクリプトは、グループ内のセッションにリソースを割り当てるデフォルトの方法(ROUND-ROBIN)を使用して、OLTPというコンシューマ・グループを作成するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
   CONSUMER_GROUP => 'OLTP',
   COMMENT        => 'OLTP applications');
END;
/

関連項目:

親トピック: 複雑なリソース・プランの作成

26.4.4.4 コンシューマ・グループへのセッションのマッピング

SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、コンシューマ・グループにセッションをマップできます。

次のパラメータを指定できます。

パラメータ	説明
`ATTRIBUTE`	パッケージ定数として指定されているセッション属性タイプ。
`VALUE`	属性の値
`CONSUMER_GROUP`	コンシューマ・グループの名前。

例: コンシューマ・グループへのセッションのマップ

次のスクリプトは、oeユーザーをOLTPコンシューマ・グループにマップするPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(  
    ATTRIBUTE      => DBMS_RESOURCE_MANAGER.ORACLE_USER, 
    VALUE          => 'OE', 
    CONSUMER_GROUP => 'OLTP');
END;
/

関連項目:

親トピック: 複雑なリソース・プランの作成

26.4.4.5 リソース・プランの作成

リソース・プランを作成するには、CREATE_PLANプロシージャを使用します。

次の表のパラメータを指定できます。最初の2つのパラメータは必須です。他のパラメータはオプションです。

パラメータ	説明
`PLAN`	グループに割り当てる名前。
`COMMENT`	任意の内容を表現するコメント。
`CPU_MTH`	非推奨。`MGMT_MTH`を使用してください。
`ACTIVE_SESS_POOL_MTH`	アクティブ・セッション・プールのリソース割当て方法。デフォルトの`ACTIVE_SESS_POOL_ABSOLUTE`は、選択できる唯一の方法です。
`PARALLEL_DEGREE_LIMIT_MTH`	デフォルトは`PARALLEL_DEGREE_LIMIT_ABSOLUTE`で制限を指定するリソース割当て方法で、これは使用可能な唯一の方法です。
`QUEUEING_MTH`	キューイングのリソース割当て方法。キュー内の非アクティブ・セッションをキューから削除し、アクティブ・セッション・プールに追加する順序を制御します。デフォルトは`FIFO_TIMEOUT`で、これは使用可能な唯一の方法です。
`MGMT_MTH`	各コンシューマ・グループまたは各サブプランが取得するCPUの量を指定するためのリソース割当て方法。デフォルトの方法`'EMPHASIS'`は単一レベルまたは複数レベルのプラン用の方法で、コンシューマ・グループ間でのCPUの分配方法の指定にパーセンテージを使用します。`'RATIO'`は単一レベルのプラン用の方法で、CPUの分配方法の指定に割合を使用します。
`SUB_PLAN`	`TRUE`の場合は、プランをトップレベルのプランとして使用できません。サブプランとしてのみ使用できます。デフォルトは`FALSE`です。

例: リソース・プランの作成

次のスクリプトは、DAYTIMEというリソース・プランを作成するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN    => 'DAYTIME',
   COMMENT => 'More resources for OLTP applications');
END;
/

RATIO CPU割当て方法の概要
RATIO方法は、単一レベルのCPU割当てのみを使用する単純なプランを対象にした、代替のCPU割当て方法です。

親トピック: 複雑なリソース・プランの作成

26.4.4.5.1 RATIO CPU割当て方法の概要

RATIO方法は、単一レベルのCPU割当てのみを使用する単純なプランを対象にした、代替のCPU割当て方法です。

パーセンテージのかわりに、各コンシューマ・グループに与えるCPUの割合に対応する数を指定します。RATIO方法を使用するには、CREATE_PLANプロシージャのMGMT_MTH引数に'RATIO'を設定します。この方法を使用するプランの例は、「リソース・プラン・ディレクティブの作成」を参照してください。

関連項目:

親トピック: リソース・プランの作成

26.4.4.6 リソース・プラン・ディレクティブの作成

リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVEプロシージャを使用します。各ディレクティブはプランまたはサブプランに属しており、リソースをコンシューマ・グループまたはサブプランに割り当てます。

注意:

リソース・プランとそのサブプランに属するディレクティブ全体で1回のみ、特定のサブプランを指定できます。

特定のコンシューマ・グループに対するディレクティブは、トップレベルのプランとそのサブプランで指定できます。ただし、リソース・プランとそのサブプランに対するディレクティブ全体で1回のみ、特定のコンシューマ・グループを指定することをお薦めします。

次のパラメータを指定できます。

パラメータ	説明
`PLAN`	ディレクティブが属しているリソース・プランの名前。
`GROUP_OR_SUBPLAN`	リソースを割り当てるコンシューマ・グループまたはサブプランの名前。
`COMMENT`	任意のコメント。
`CPU_P1`	非推奨。`MGMT_P1`を使用してください。
`CPU_P2`	非推奨。`MGMT_P2`を使用してください。
`CPU_P3`	非推奨。`MGMT_P3`を使用してください。
`CPU_P4`	非推奨。`MGMT_P4`を使用してください。
`CPU_P5`	非推奨。`MGMT_P5`を使用してください。
`CPU_P6`	非推奨。`MGMT_P6`を使用してください。
`CPU_P7`	非推奨。`MGMT_P7`を使用してください。
`CPU_P8`	非推奨。`MGMT_P8`を使用してください。
`ACTIVE_SESS_POOL_P1`	コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を指定します。他のセッションは、非アクティブ・セッション・キューで実行を待機します。デフォルトは`UNLIMITED`です。
`QUEUEING_P1`	非アクティブ・セッション・キュー内で実行を待機しているセッションがタイムアウトしてコールが中止されるまでの時間を秒数で指定します。デフォルトは`UNLIMITED`です。
`PARALLEL_DEGREE_LIMIT_P1`	任意の操作の並列度を制限します。デフォルトは`UNLIMITED`です。
`SWITCH_GROUP`	切替え基準が満たされた場合に、セッションの切替え先になるコンシューマ・グループを指定します。グループ名が`CANCEL_SQL`の場合は、切替え基準が満たされると、現在のコールは取り消されます。グループ名が`CANCEL_SQL`の場合は、`SWITCH_FOR_CALL`パラメータは常に`TRUE`に設定され、ユーザー指定の設定は無効になります。グループ名が`KILL_SESSION`の場合は、切替え基準が満たされると、そのセッションは強制終了します。グループ名が`LOG_ONLY`の場合は、セッションに関する情報がリアルタイムSQL監視で記録されますが、セッションに関する特定の処理は実行されません。 `NULL`の場合、セッションは切り替えられず、追加のロギングは実行されません。デフォルトは`NULL`です。このパラメータが`NULL`に設定され、他の切替えパラメータが`NULL`以外に設定された場合は、エラーが返されます。注意: `CANCEL_SQL`、`KILL_SESSION`および`LOG_ONLY`は、予約済のコンシューマ・グループ名です。これらのいずれかの名前でコンシューマ・グループを作成しようとすると、エラーが発生します。
`SWITCH_TIME`	処理が実行されるまでにコールが実行可能な時間をCPU秒数で指定します。デフォルトは`UNLIMITED`です。処理は`SWITCH_GROUP`で指定されます。
`SWITCH_ESTIMATE`	`TRUE`の場合は、各コールの実行時間が見積られ、実行時間の見積りが`SWITCH_TIME`を超える場合は、コールを開始する前にセッションを`SWITCH_GROUP`に切り替えます。デフォルトは`FALSE`です。実行時間の見積りはオプティマイザから取得されます。見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。一般的に、統計には±10分未満の誤差があると考えてください。
`MAX_EST_EXEC_TIME`	コールに許可される最大の実行時間をCPU秒数で指定します。あるコールに対するオプティマイザの見積り実行時間が`MAX_EST_EXEC_TIME`を超える場合、そのコールは実行されず、`ORA-07455`が発行されます。オプティマイザが判断しない場合は、このディレクティブの効果はありません。デフォルトは`UNLIMITED`です。見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。
`UNDO_POOL`	コンシューマ・グループで生成される、コミットされていないトランザクションのUNDO合計量の最大値をKBで設定します。デフォルトは`UNLIMITED`です。
`MAX_IDLE_TIME`	セッションの最大アイドル時間を秒数で示します。デフォルトは`NULL`で、無制限を意味します。
`MAX_IDLE_BLOCKER_TIME`	ブロックしているセッションの最大アイドル時間を秒数で示します。デフォルトは`NULL`で、無制限を意味します。
`SWITCH_TIME_IN_CALL`	非推奨。`SWITCH_FOR_CALL`を使用してください。
`MGMT_P1`	`MGMT_MTH`パラメータが`EMPHASIS`に設定されているプランの場合は、レベル1のCPUパーセンテージを指定します。`MGMT_MTH`パラメータが`RATIO`に設定されている場合は、CPU使用の比重を指定します。`MGMT_Pn`パラメータのデフォルトはすべて`NULL`です。
`MGMT_P2`	`EMPHASIS`の場合は、レベル2のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P3`	`EMPHASIS`の場合は、レベル3のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P4`	`EMPHASIS`の場合は、レベル4のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P5`	`EMPHASIS`の場合は、レベル5のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P6`	`EMPHASIS`の場合は、レベル6のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P7`	`EMPHASIS`の場合は、レベル7のCPUパーセンテージを指定します。`RATIO`には適用しません。
`MGMT_P8`	`EMPHASIS`の場合は、レベル8のCPUパーセンテージを指定します。`RATIO`には適用しません。
`SWITCH_IO_MEGABYTES`	処理が実行される前に、セッションで移動(読取りおよび書込み)できる物理I/Oのサイズ(MB)を指定します。デフォルトは`UNLIMITED`です。処理は`SWITCH_GROUP`で指定されます。
`SWITCH_IO_REQS`	処理が実行される前にセッションが実行できる物理I/O要求の数を指定します。デフォルトは`UNLIMITED`です。処理は`SWITCH_GROUP`で指定されます。
`SWITCH_FOR_CALL`	`TRUE`の場合は、`SWITCH_TIME`、`SWITCH_IO_MEGABYTES`または`SWITCH_IO_REQS`に基づいて別のコンシューマ・グループに自動的に切り替えたセッションが、トップレベルのコールが完了した時に当初のコンシューマ・グループに戻されます。デフォルトは`NULL`です。
`PARALLEL_QUEUE_TIMEOUT`	パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を秒単位で指定します。この時間を超えると、タイムアウトします。
`PARALLEL_SERVER_LIMIT`	特定のコンシューマ・グループが使用できるパラレル実行サーバー・プールの最大割合を指定します。特定のコンシューマ・グループで使用されているパラレル実行サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル実行サーバーの合計となります。
`UTILIZATION_LIMIT`	コンシューマ・グループに許可する最大CPU使用率を指定します。この値は、すべてのレベルのCPU割当て(`MGMT_P1`から`MGMT_P8`)よりも優先され、未使用の割当てが再配分されるときの合計CPU使用率の制限にも適用されます。この属性を指定して、`MGMT_P1`から`MGMT_P8`を`NULL`にしておくことができます。
`SWITCH_IO_LOGICAL`	`SWITCH_GROUP`によって指定された処理をトリガーする論理I/O要求の数。他の切替えディレクティブと同様に、`SWITCH_FOR_CALL`が`TRUE`の場合、論理I/O要求の数はコールの開始から累積されます。それ以外の場合、論理I/O要求の数は、セッションの間中累積されます。
`SWITCH_ELAPSED_TIME`	処理をトリガーする経過時間(秒単位)は、`SWITCH_GROUP`で指定されます。他の切替えディレクティブと同様に、`SWITCH_FOR_CALL`が`TRUE`の場合、経過時間はコールの開始から累積されます。そうでない場合、経過時間はセッションの間累積される。
`SHARES`	マルチテナント・コンテナ・データベース(CDB)内のプラガブル・データベース(PDB)間にリソースを割り当てます。また、非CDBまたはPDB内のコンシューマ・グループ間でもリソースを割り当てます。『Oracle Multitenant管理者ガイド』を参照してください。
`PARALLEL_STMT_CRITICAL`	コンシューマ・グループのパラレル・ステートメントが重要かどうかを指定します。 `BYPASS_QUEUE`が指定されている場合、コンシューマ・グループのパラレル・ステートメントは重要となります。これらの文はパラレル・キューを無視し、即座に処理されます。 `FALSE`または`NULL`(デフォルト)が指定されている場合、コンシューマ・グループのパラレル・ステートメントは重要となりません。これらの文は必要なときにパラレル・キューに追加されます。
`SESSION_PGA_LIMIT`	特定のコンシューマ・グループ内の各セッションに割り当てることのできる最大PGAメモリーの量をMB単位で指定します。セッションが制限を超えた場合、プロセスは`ORA-10260`エラーで終了します。

例1

次のスクリプトは、プランDAYTIMEのリソース・プラン・ディレクティブを作成するPL/SQLブロックです。(DAYTIMEプランおよびOLTPコンシューマ・グループがペンディング・エリアに作成済であることを前提としています。)

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'OLTP',
   COMMENT          => 'OLTP group',
   MGMT_P1          => 75);
END;
/

このディレクティブは、レベル1でのCPUリソースの75%をOLTPコンシューマ・グループに割り当てます。

REPORTINGコンシューマ・グループを作成し、次のPL/SQLブロックを実行することもできます。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN                     => 'DAYTIME', 
   GROUP_OR_SUBPLAN         => 'REPORTING',
   COMMENT                  => 'Reporting group',
   MGMT_P1                  => 15,
   PARALLEL_DEGREE_LIMIT_P1 => 8,
   ACTIVE_SESS_POOL_P1      => 4,
   SESSION_PGA_LIMIT        => 20);

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN                     => 'DAYTIME', 
   GROUP_OR_SUBPLAN         => 'OTHER_GROUPS',
   COMMENT                  => 'This one is required',
   MGMT_P1                  => 10);
END;
/

このプランでは、コンシューマ・グループREPORTINGに対して操作の最大並列度が8に設定されていますが、他のコンシューマ・グループの並列度に制限はありません。また、このREPORTINGグループには、同時にアクティブにできるセッションの最大数が4に設定されています。各セッションでは、最大20 MBのPGAメモリーを使用できます。

例2

この例では、CPUの割当てにRATIO方式を使用し、使用率ではなく比率を使用します。アプリケーション・スイートで、「Gold」、「Silver」および「Bronze」の3つのサービス・レベルをクライアントに提供しているものとします。3つのコンシューマ・グループをGOLD_CG、SILVER_CGおよびBRONZE_CGという名前で作成し、次のリソース・プランを作成します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PLAN
   (PLAN             => 'SERVICE_LEVEL_PLAN',
    MGMT_MTH         => 'RATIO', 
    COMMENT          => 'Plan that supports three service levels');

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
   (PLAN             => 'SERVICE_LEVEL_PLAN',
    GROUP_OR_SUBPLAN => 'GOLD_CG', 
    COMMENT          => 'Gold service level customers',
    MGMT_P1          => 10);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
   (PLAN             => 'SERVICE_LEVEL_PLAN',
    GROUP_OR_SUBPLAN => 'SILVER_CG', 
    COMMENT          => 'Silver service level customers',  
    MGMT_P1          => 5);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
   (PLAN             => 'SERVICE_LEVEL_PLAN',
    GROUP_OR_SUBPLAN => 'BRONZE_CG', 
    COMMENT          => 'Bronze service level customers',
    MGMT_P1          => 2);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE
    (PLAN            => 'SERVICE_LEVEL_PLAN', 
    GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
    COMMENT          => 'Lowest priority sessions',
    MGMT_P1          => 1);
END;
/

CPU割当ての割合は、GOLD_CG、SILVER_CG、BRONZE_CGおよびOTHER_GROUPSコンシューマ・グループに対して、それぞれ10:5:2:1の割合です。

セッションがGOLD_CGおよびSILVER_CGコンシューマ・グループにのみ存在する場合、CPU割当ての割合は、この2つのグループ間で10:5になります。

リソース・プラン・ディレクティブの競合
このことは許可されますが、トップレベルのプランおよびそのいずれのサブプランからも同じコンシューマ・グループが参照されないようにすることをお薦めします。

親トピック: 複雑なリソース・プランの作成

26.4.4.6.1 競合するリソース・プラン・ディレクティブ

このことは許可されますが、トップレベルのプランおよびそのいずれのサブプランからも同じコンシューマ・グループが参照されないようにすることをお薦めします。

トップレベルのプランと複数のサブプランから同じコンシューマ・グループを参照する場合があります。このような場合は、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されます。

同様に、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されている場合、ディレクティブが競合します。このことは許可されますが、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されないようにすることをお薦めします。

関連項目:

親トピック: リソース・プラン・ディレクティブの作成

26.4.4.7 ペンディング・エリアの妥当性チェック

ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREAをコールして、そのペンディング・エリアの妥当性を確認できます。

従う必要がある規則は、次のとおりです。これらの規則が妥当性チェック・プロシージャによってチェックされます。

プランにループを含めることはできません。ループが発生するのは、サブプランに、プラン階層ではそのサブプランの上位になるプランを参照するディレクティブが含まれている場合です。たとえば、サブプランはトップレベルのプランを参照できません。
プラン・ディレクティブで参照されるプランやリソース・コンシューマ・グループは、すべて存在している必要があります。
すべてのプランに、プランまたはリソース・コンシューマ・グループを指すプラン・ディレクティブが必要です。
特定のレベルの全パーセンテージの合計は、100以下であることが必要です。
アクティブなインスタンスで現在トップレベルのプランとして使用されているプランは、削除できません。
次のパラメータは、リソース・コンシューマ・グループを参照するプラン・ディレクティブでのみ使用できます。他のリソース・プランを参照するプラン・ディレクティブでは使用できません。
- ACTIVE_SESS_POOL_P1
- MAX_EST_EXEC_TIME
- MAX_IDLE_BLOCKER_TIME
- MAX_IDLE_TIME
- PARALLEL_DEGREE_LIMIT_P1
- QUEUEING_P1
- SESSION_PGA_LIMIT
- SWITCH_ESTIMATE
- SWITCH_FOR_CALL
- SWITCH_GROUP
- SWITCH_IO_MEGABYTES
- SWITCH_IO_REQS
- SWITCH_TIME
- UNDO_POOL
- UTILIZATION_LIMIT
アクティブなプランに含まれるリソース・コンシューマ・グループ数は、28以内にする必要があります。また、プランは最大28の子を持つことができます。
プランとリソース・コンシューマ・グループには、異なる名前を使用する必要があります。
アクティブなプラン内のどこかに、OTHER_GROUPSのプラン・ディレクティブが存在する必要があります。これによって、現在のアクティブ・プラン内に含まれるコンシューマ・グループのいずれにも属していないセッションに、OTHER_GROUPSのディレクティブで指定したリソースが割り当てられます。

これらの規則のいずれかに違反すると、VALIDATE_PENDING_AREAからエラー・メッセージが返されます。その場合は、変更を加えて問題を修正し、プロシージャを再度コールできます。

プラン・ディレクティブによって参照されない孤立したコンシューマ・グループを作成できます。これによって、当面は使用しないものの、将来的に実装するプランの一部になる、コンシューマ・グループを作成できます。

例: ペンディング・エリアの妥当性チェック

次のスクリプトは、ペンディング・エリアの妥当性をチェックするPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
END;
/

関連項目:

「ペンディング・エリアの概要」

親トピック: 複雑なリソース・プランの作成

26.4.4.8 ペンディング・エリアの発行

変更の妥当性チェックを完了した後は、SUBMIT_PENDING_AREAプロシージャをコールして変更内容をアクティブにします。

SUBMITプロシージャでは妥当性チェックも実行されるため、妥当性チェック・プロシージャを別個にコールする必要はありません。ただし、プランを大幅に変更している場合は、通常、変更の妥当性チェックを段階的に実施する方が問題のデバッグ作業が容易になります。ペンディング・エリア内のすべての変更について妥当性チェックが成功するまで、変更は発行されません(つまり、アクティブになりません)。

SUBMIT_PENDING_AREAプロシージャは、変更の妥当性チェックとコミットに成功すると、ペンディング・エリアをクリア(解除)します。

注意:

VALIDATE_PENDING_AREAが正常に終了しても、SUBMIT_PENDING_AREAのコールが失敗する場合があります。これが起こるのは、VALIDATE_PENDING_AREAをコールしてからSUBMIT_PENDING_AREAをコールするまでの間に、削除しようとしているプランがインスタンスによってロードされた場合などです。

例: ペンディング・エリアの発行

次のスクリプトは、ペンディング・エリアを発行するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

関連項目:

「ペンディング・エリアの概要」

親トピック: 複雑なリソース・プランの作成

26.4.4.9 ペンディング・エリアのクリア

CLEAR_PENDING_AREAプロシージャを使用して、ペンディング・エリアをいつでもクリアできます。

次のスクリプトは、変更のすべてをペンディング・エリアからクリアし、ペンディング・エリアを解除するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/

CLEAR_PENDING_AREAをコールした後、再び変更を実施するには、その前にCREATE_PENDING_AREAプロシージャをコールする必要があります。

関連項目:

「ペンディング・エリアの概要」

親トピック: 複雑なリソース・プランの作成

26.5 各種の方法を組み合せたOracle Database Resource Managerの例

リソース・マネージャでリソースを割り当てる方法を例で示します。

複数レベルのプランの例
複数レベルのプランの例を示します。
使用率制限の属性を使用した例
UTILIZATION_LIMITディレクティブ属性を使用すると、アプリケーションのCPU使用率を制限できます。この属性の一般的な使用例として、データベース統合をあげることができます。
各種のリソース割当て方法を使用した例
各種のリソース割当て方法を使用した例を示します。
ディレクティブ属性を使用したパラレル・ステートメントの管理の例
ディレクティブ属性を使用したパラレル・ステートメントの管理の例を示します。
オラクル社が提供する複合ワークロード・プラン
Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN (バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.5.1 複数レベルのプランの例

複数レベルのプランの例を示します。

次のスクリプトは、図26-7に示されている複数レベルのプランを作成するPL/SQLブロックです。デフォルトのリソース割当て方法の設定は、すべてのプランとリソース・コンシューマ・グループに使用されます。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'bugdb_plan', 
   COMMENT => 'Resource plan/method for bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'maildb_plan', 
   COMMENT => 'Resource plan/method for mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'mydb_plan', 
   COMMENT => 'Resource plan/method for bug and mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Online_group', 
   COMMENT => 'Resource consumer group/method for online bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Batch_group', 
   COMMENT => 'Resource consumer group/method for batch job bug users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Bug_Maint_group',
   COMMENT => 'Resource consumer group/method for users sessions for bug db maint');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Users_group', 
   COMMENT => 'Resource consumer group/method for mail users sessions');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Postman_group',
   COMMENT => 'Resource consumer group/method for mail postman');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'Mail_Maint_group', 
   COMMENT => 'Resource consumer group/method for users sessions for mail db maint');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
   GROUP_OR_SUBPLAN => 'Online_group',
   COMMENT => 'online bug users sessions at level 1', MGMT_P1 => 80, MGMT_P2=> 0);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan', 
   GROUP_OR_SUBPLAN => 'Batch_group', 
   COMMENT => 'batch bug users sessions at level 1', MGMT_P1 => 20, MGMT_P2 => 0,
   PARALLEL_DEGREE_LIMIT_P1 => 8);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan', 
   GROUP_OR_SUBPLAN => 'Bug_Maint_group',
   COMMENT => 'bug maintenance users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan', 
   GROUP_OR_SUBPLAN => 'OTHER_GROUPS', 
   COMMENT => 'all other users sessions at level 3', MGMT_P1 => 0, MGMT_P2 => 0,
   MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan', 
   GROUP_OR_SUBPLAN => 'Postman_group',
   COMMENT => 'mail postman at level 1', MGMT_P1 => 40, MGMT_P2 => 0);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
   GROUP_OR_SUBPLAN => 'Users_group',
   COMMENT => 'mail users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 80);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
   GROUP_OR_SUBPLAN => 'Mail_Maint_group',
   COMMENT => 'mail maintenance users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 20);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
   GROUP_OR_SUBPLAN => 'OTHER_GROUPS', 
   COMMENT => 'all other users sessions at level 3', MGMT_P1 => 0, MGMT_P2 => 0,
   MGMT_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan', 
   GROUP_OR_SUBPLAN => 'maildb_plan', 
   COMMENT=> 'all mail users sessions at level 1', MGMT_P1 => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan', 
   GROUP_OR_SUBPLAN => 'bugdb_plan', 
   COMMENT => 'all bug users sessions at level 1', MGMT_P1 => 70);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

妥当性チェックはSUBMIT_PENDING_AREAによって暗黙的に実行されるので、直前のVALIDATE_PENDING_AREAのコールはオプションです。

図26-7 複数レベルのプラン・スキーマ

「図26-7 複数レベルのプラン・スキーマ」の説明

このプラン・スキーマでは、次のようにCPUリソースが割り当てられています。

mydb_planでは、CPUの30%がmaildb_planサブプランに割り当てられ、70%がbugdb_planサブプランに割り当てられます。サブプランは両方ともレベル1です。mydb_plan自体にはレベル1の下にレベルがないため、レベル1で一方のサブプランが使用していないリソース割当ては、その兄弟サブプランが使用できます。したがって、maildb_planがCPUの20%のみを使用する場合、CPUの80%はbugdb_planが使用できます。
maildb_planおよびbugdb_planでは、レベル1、2および3で割当てを定義します。これらのサブプランの各レベルは、その親プランmydb_planのレベルから独立しています。つまり、プラン・スキーマのすべてのプランとサブプランには、独自のレベル1、レベル2、レベル3などがあります。
maildb_planに割り当てられたCPUの30%について、その40%(実質的にはCPU合計の12%)はレベル1のPostman_groupに割り当てられます。Postman_groupにはレベル1で兄弟がないため、レベル1では暗黙的に60%が残っています。この60%は、レベル2のUsers_groupとMail_Maint_groupがそれぞれ80%と20%の割合で共有します。この60%の他に、Users_groupとMail_Maint_groupは、レベル1のPostman_groupが使用していないリソース(40%の一部)も使用できます。
複数レベルのプランの場合、未使用のリソースは同じレベルの兄弟ではなく、次の下位レベルのコンシューマ・グループまたはサブプランに再割当てされるため、レベル2のUsers_groupとMail_Maint_groupのどちらでも使用されないCPUリソースはOTHER_GROUPSに割り当てられます。したがって、Users_groupが80%ではなく70%しか使用していない場合に、残りの10%をMail_Maint_groupが使用することはできません。この10%は、レベル3のOTHER_GROUPSのみが使用できます。
bugdb_planサブプランに割り当てられたCPUの70%は、そのコンシューマ・グループに同様に割り当てられます。Online_groupまたはBatch_groupがその割当てのすべてを使用していない場合、残りはBug_Maint_groupが使用できます。Bug_Maint_groupがその割当てのすべてを使用していない場合、残りはOTHER_GROUPSに割り当てられます。

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

26.5.2 使用率制限の属性を使用した例

UTILIZATION_LIMITディレクティブ属性を使用すると、アプリケーションのCPU使用率を制限できます。この属性の一般的な使用例として、データベース統合をあげることができます。

データベースの統合では、次の処理が必要になる場合があります。

あるアプリケーションが別のアプリケーションのパフォーマンスに及ぼす影響を管理します。

このパフォーマンスの影響を管理する方法として、アプリケーションごとにコンシューマ・グループを作成し、各コンシューマ・グループにリソースを割り当てる方法をあげることができます。
各アプリケーションの使用率を制限します。

一般的に、CPUリソースの特定の使用率を各コンシューマ・グループに割り当てること以外に、グループごとに最大CPU使用率を制限することが必要になる場合があります。この制限によって、他のすべてのコンシューマ・グループがアイドル状態のときに、あるコンシューマ・グループがすべてのCPUリソースを使用することを回避できます。

場合によっては、他のアプリケーションからのワークロードに関係なく、すべてのアプリケーション・ユーザーに一貫性のあるパフォーマンスを提供することが必要になる場合があります。そのためには、リソース・プランのコンシューマ・グループごとに使用率制限を指定します。

次の例は、UTILIZATION_LIMITリソース・プラン・ディレクティブ属性を使用して次のことを行う方法を示しています。

データベースCPU使用率の合計の制限
リソース集中型の問合せの隔離
アプリケーションのCPU使用率の制限
メンテナンス・ウィンドウの期間中のCPU使用率の制限

例1: 全体的なデータベースCPU使用率の制限

この例では、データベース負荷にかかわらず、Oracle Databaseからのシステム・ワークロードはCPUの90%を超えません。サーバーを共有する他のアプリケーション用にCPUの10%を残します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'MAXCAP_PLAN',
    COMMENT => 'Limit overall database CPU');
   
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN              => 'MAXCAP_PLAN',
    GROUP_OR_SUBPLAN  => 'OTHER_GROUPS',
    COMMENT           => 'This group is mandatory',
    UTILIZATION_LIMIT => 90);

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

OTHER_GROUPSのプラン・ディレクティブ以外のプラン・ディレクティブはないため、すべてのセッションはOTHER_GROUPSにマップされます。

例2: リソース集中型の問合せの検査

この例では、リソース集中型の問合せは使用率制限が20%のコンシューマ・グループに切り替えられ、ユーザーが介入するまでに使用されるリソース量は制限されます。リソース集中型の問合せとは、ここでは10分を超えるCPU時間を必要とする問合せとします。セッション・マッピング・ルールによってすべてのセッションはSTART_GROUPで開始されると想定します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'START_GROUP',
     COMMENT        => 'Sessions start here');
   
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'QUARANTINE_GROUP',
     COMMENT        => 'Sessions switched here to quarantine them');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'Quarantine_plan',
    COMMENT => 'Quarantine runaway queries');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN                  => 'Quarantine_plan',
    GROUP_OR_SUBPLAN      => 'START_GROUP',
    COMMENT               => 'Max CPU 10 minutes before switch',
    MGMT_P1               => 75,
    switch_group          => 'QUARANTINE_GROUP',
    switch_time           => 600);
  
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN                  => 'Quarantine_plan',
    GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
    COMMENT               => 'Mandatory',
    MGMT_P1               => 25);
  
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN                  => 'Quarantine_plan',
    GROUP_OR_SUBPLAN      => 'QUARANTINE_GROUP',
    COMMENT               => 'Limited CPU',
    MGMT_P2               => 100,
    UTILIZATION_LIMIT     => 20);

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

注意:

QUARANTINE_GROUPの使用率制限を0(ゼロ)に設定して、リソース集中型の問合せを完全に検査できますが、このようにしないことをお薦めします。他のセッションが必要とするリソース(PGAメモリー、ロックなど)をリソース集中型の問合せが保持している場合、0(ゼロ)を割り当てる設定によりデッドロックが発生する場合があります。

例3: アプリケーションのCPUの制限

この例では、アプリケーション・セッションはマッピング・ルールによって4つのアプリケーション・グループのいずれかにマップされると想定します。各アプリケーション・グループには30%の使用率制限が割り当てられています。これにより、1つのアプリケーションのCPU使用率は30%に制限されます。UTILIZATION_LIMIT値の合計が100%を超えていますが、このことはすべてのアプリケーションが同時にアクティブにはならない状況において許容されます。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
   
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
     CONSUMER_GROUP => 'APP1_GROUP',
     COMMENT        => 'Apps group 1');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP2_GROUP',
     COMMENT        => 'Apps group 2');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP3_GROUP',
     COMMENT        => 'Apps group 3');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP4_GROUP',
     COMMENT        => 'Apps group 4');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'apps_plan',
    COMMENT => 'Application consolidation');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'apps_plan',
    GROUP_OR_SUBPLAN      => 'APP1_GROUP',
    COMMENT               => 'Apps group 1',
    UTILIZATION_LIMIT     => 30);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'apps_plan',
    GROUP_OR_SUBPLAN      => 'APP2_GROUP',
    COMMENT               => 'Apps group 2',
    UTILIZATION_LIMIT     => 30);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'apps_plan',
    GROUP_OR_SUBPLAN      => 'APP3_GROUP',
    COMMENT               => 'Apps group 3',
    UTILIZATION_LIMIT     => 30);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'apps_plan',
    GROUP_OR_SUBPLAN      => 'APP4_GROUP',
    COMMENT               => 'Apps group 4',
    UTILIZATION_LIMIT     => 30);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'apps_plan',
    GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
    COMMENT               => 'Mandatory',
    UTILIZATION_LIMIT     => 20);
 
  DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

4つすべてのアプリケーション・グループが割り当てられたCPU(この例では30%)を完全に使用できる場合は、各アプリケーション・グループに割り当てられる最小CPUは、すべてのアプリケーション・グループの制限全体に占めるアプリケーション・グループの制限の比率として計算されます。この例では、4つすべてのアプリケーション・グループに使用率制限として30%が割り当てられています。このため、4つすべてのグループがそれぞれの制限を完全に使用する場合、各グループに対するCPU割当ては30/(30+30+30+30)で25%になります。

例4 - コンシューマ・グループおよびサブプランに使用率制限を指定する

次の例では、図26-8に示すように、サブプランおよびそのサブプラン内のコンシューマ・グループに対してUTILIZATION_LIMITを設定した場合に、使用率制限がどのように計算されるかについて説明します。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。

図26-8 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン

「図26-8 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン」の説明

次のPL/SQLブロックは、図26-8で説明するプランを作成します。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP1_GROUP',
     COMMENT        => 'Group for application #1');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP2_OLTP_GROUP',
     COMMENT        => 'Group for OLTP activity in application #2');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP2_ADHOC_GROUP',
     COMMENT        => 'Group for ad-hoc queries in application #2');
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (
     CONSUMER_GROUP => 'APP2_REPORT_GROUP',
     COMMENT        => 'Group for reports in application #2');
   DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'APPS_PLAN',
    COMMENT => 'Plan for managing 3 applications');
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'APP2_SUBPLAN',
    COMMENT => 'Subplan for managing application #2',
    SUB_PLAN => TRUE);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN    => 'APP2_REPORTS_SUBPLAN',
    COMMENT => 'Subplan for managing reports in application #2',
    SUB_PLAN => TRUE);

  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APPS_PLAN',
    GROUP_OR_SUBPLAN      => 'APP1_GROUP',
    COMMENT               => 'Limit CPU for application #1 to 40%',
    UTILIZATION_LIMIT     => 40);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APPS_PLAN',
    GROUP_OR_SUBPLAN      => 'APP2_SUBPLAN',
    COMMENT               => 'Limit CPU for application #2 to 40%',
    UTILIZATION_LIMIT     => 40);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APP2_SUBPLAN',
    GROUP_OR_SUBPLAN      => 'APP2_OLTP_GROUP',
    COMMENT               => 'Limit CPU for OLTP to 90% of application #2',
    UTILIZATION_LIMIT     => 90);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APP2_SUBPLAN',
    GROUP_OR_SUBPLAN      => 'APP2_REPORTS_SUBPLAN',
    COMMENT               => 'Subplan for ad-hoc and normal reports for application #2');
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APP2_REPORTS_SUBPLAN',
    GROUP_OR_SUBPLAN      => 'APP2_ADHOC_GROUP',
    COMMENT               => 'Limit CPU for ad-hoc queries to 50% of application #2 reports',
    UTILIZATION_LIMIT     => 50);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APP2_REPORTS_SUBPLAN',
    GROUP_OR_SUBPLAN      => 'APP2_REPORT_GROUP',
    COMMENT               => 'Limit CPU for reports to 50% of application #2 reports',
    UTILIZATION_LIMIT     => 50);
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    PLAN                  => 'APPS_PLAN',
    GROUP_OR_SUBPLAN      => 'OTHER_GROUPS',
    COMMENT               => 'No directives for default users');
   DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

この例では、コンシューマ・グループAPP1_GROUPおよびサブプランAPP2_SUBPLANの最大CPU使用率は、40%に設定されます。コンシューマ・グループAPP2_ADHOC_GROUPおよびAPP2_REPORT_GROUPの制限は、50%に設定されます。

サブプランAPP2_REPORTS_SUBPLANに指定されている制限がないため、その親サブプランAPP2_SUBPLANの制限を継承して40%になります。コンシューマ・グループAPP2_REPORT_GROUPの絶対上限は、その親サブプランの50%として計算され、その結果、40%の50%、つまり20%になります。

同じく、コンシューマ・グループAPP2_ADHOC_GROUPはサブプランAPP2_REPORTS_SUBPLANに含まれているため、その制限は親サブプランの割合として計算されます。コンシューマ・グループAPP2_ADHOC_GROUPの使用率制限は40%の50%、つまり20%になります。

コンシューマ・グループAPP2_OLTP_GROUPの最大CPU使用率は、90%に設定されます。APP2_OLTP_GROUPの親サブプランAPP2_SUBPLANの制限は40%です。このため、グループAPP2_OLTP_GROUPの絶対上限は40%の90%、つまり36%になります。

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

26.5.3 各種のリソース割当て方法を使用した例

各種のリソース割当て方法を使用した例を示します。

ここで示す例は、パッケージ化されたEnterprise Resource Planning(ERP)またはCustomer Relationship Management(CRM)アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理(OLTP)の適切な応答時間を得ることにあります。

次の表にプランがまとめられています。

グループ CPUリソース割当て% パラレル文のキューイングコンシューマ・グループの自動切替え最大見積り実行時間 UNDOプール各セッションのPGA制限

グループ	CPUリソース割当て%	パラレル文のキューイング	コンシューマ・グループの自動切替え	最大見積り実行時間	UNDOプール	各セッションのPGA制限
`oltp`	60%	--	切替え先グループ: `batch` 切替え時間: 3秒	--	200K	20M
`batch`	30%	パラレル・サーバー制限: 8 パラレル・キューのタイムアウト: 600秒	--	3600秒	--	--
`OTHER_GROUPS`	10%	--	--	--	--	--

oltp

60%

切替え先グループ: batch

切替え時間: 3秒

200K

20M

batch

30%

パラレル・サーバー制限: 8

パラレル・キューのタイムアウト: 600秒

3600秒

OTHER_GROUPS

10%

次の文は、この表のプランをerp_planという名前で作成します。

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'erp_plan', 
  COMMENT => 'Resource plan/method for ERP Database');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'oltp', 
  COMMENT => 'Resource consumer group/method for OLTP jobs');
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(CONSUMER_GROUP => 'batch', 
  COMMENT => 'Resource consumer group/method for BATCH jobs');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan', 
  GROUP_OR_SUBPLAN => 'oltp', COMMENT => 'OLTP sessions', MGMT_P1 => 60, 
  SWITCH_GROUP => 'batch', SWITCH_TIME => 3, UNDO_POOL => 200, 
  SWITCH_FOR_CALL => TRUE, SESSION_PGA_LIMIT => 20);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan', 
  GROUP_OR_SUBPLAN => 'batch', COMMENT => 'BATCH sessions', MGMT_P1 => 30, 
  PARALLEL_SERVER_LIMIT => 8, PARALLEL_QUEUE_TIMEOUT => 600, 
  MAX_EST_EXEC_TIME => 3600);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan', 
  GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'mandatory', MGMT_P1 => 10);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

26.5.4 ディレクティブ属性を使用したパラレル・ステートメントの管理の例

ディレクティブ属性を使用したパラレル・ステートメントの管理の例を示します。

一般的に、データ・ウェアハウス環境は、リソース要件が様々に異なる多様なユーザーで構成されています。処理要件が共通するユーザーは、コンシューマ・グループにグループ化されます。コンシューマ・グループURGENT_GROUPは、経営陣に重要な情報を提供するためのレポートを実行するユーザーで構成されています。このグループは、多数のパラレル問合せを生成します。コンシューマ・グループETL_GROUPに属するユーザーは、ソース・システムからデータをインポートし、抽出、変換、ロード(ETL)の各操作を実行します。グループOTHER_GROUPSには、非定型問合せを実行するユーザーが含まれています。パフォーマンスを最適に保つと同時に、このような多様なユーザー・グループの要件を管理する必要があります。

次のディレクティブ属性を使用すると、パラレル・ステートメントの実行を管理および最適化できます。

MGMT_Pn
PARALLEL_SERVER_LIMIT
PARALLEL_STMT_CRITICAL
PARALLEL_QUEUE_TIMEOUT
PQ_TIMEOUT_ACTION
PARALLEL_DEGREE_LIMIT_P1
SHARES

注意:

MGMT_Pn管理属性とSHARES属性では、パラレル文キューから実行するパラレル文を選択する方法を制御します。あるコンシューマ・グループのパラレル・ステートメントを別のグループよりも優先させるには、そのグループの管理属性の値を大きくします。
マルチテナント環境では、詳細なワークロードごとの管理が必要な場合、SHARES属性を使用して、パラレル文のキューイング・リソースを含むプラガブル・データベース(PDB)のリソース割当ての共有を指定できます。また、前述した別のディレクティブ属性を使用することもできます。

表26-16に、データ・ウェアハウス・ユーザーのニーズを管理するために使用可能なプランDW_PLANのリソース割当てを示します。このプランには、コンシューマ・グループURGENT_GROUP、ETL_GROUPおよびOTHER_GROUPSが含まれています。この例は、1つのアプリケーションまたはコンシューマ・グループですべての使用可能なパラレル実行サーバーを使用しないことが確実である場合のディレクティブ属性の使用例を示しています。

表26-16 パラレル・ステートメント・ディレクティブが設定されたリソース・プラン

コンシューマ・グループ	レベル1のCPU割当て	レベル2のCPU割当て	レベル3のCPU割当て	PARALLEL_DEGREE_LIMIT_P1	PARALLEL_SERVER_LIMIT	PARALLEL_QUEUE_TIMEOUT
`URGENT_GROUP`	100%			12
`ETL_GROUP`		100%		8	50%
`OTHER_GROUPS`			100%	2	50%	360

この例では、パラメータPARALLEL_SERVERS_TARGET初期化パラメータが64に設定されており、使用可能なパラレル実行サーバーの数が64台ということになります。パラレル・ステートメントの実行に使用できるパラレル実行サーバーの総数は64で、それを超えると、PARALLEL_DEGREE_POLICYがAUTOに設定されたURGENT_GROUPセッションはパラレル・ステートメント・キューに追加されます。ETL_GROUPおよびOTHER_GROUPSのPARALLEL_SERVER_LIMIT属性は50%で、これらのグループが使用できるパラレル実行サーバーの最大数は64の50%、つまり各グループとも32台のパラレル実行サーバーを使用できます。

コンシューマ・グループからのパラレル・ステートメントがキューされるのは、PARALLEL_DEGREE_POLICYパラメータがAUTOに設定され、コンシューマ・グループのアクティブなサーバーの総数がPARALLEL_SERVERS_TARGETよりも高くなっている場合のみです。PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されている場合、パラレル・ステートメントは、十分な数のパラレル実行サーバーが使用できるときにのみ、実行されます。このようなパラレル・ステートメントで使用されるパラレル実行サーバーは、コンシューマ・グループで使用されるパラレル実行サーバーの総数にカウントされます。ただし、パラレル・ステートメントはパラレル・ステートメント・キューに追加されません。

ヒント:

優先度が低いアプリケーションの場合、PARALLEL_DEGREE_LIMIT_P1およびPARALLEL_SERVER_LIMITに小さい値を設定するのが一般的です。

URGENT_GROUPにはレベル1で100%が割り当てられているため、そのパラレル・ステートメントはパラレル・ステートメント・キューの他のコンシューマ・グループよりも前に常にデキューされます。URGENT_GROUPにはPARALLEL_SERVER_LIMITディレクティブ属性がありませんが、このグループのセッションによって発行された文は、その文を実行できるだけのパラレル実行サーバーが使用可能でない場合にはキューされます。

URGENT_GROUPのリソース・プラン・ディレクティブを作成するときは、PARALLEL_STMT_CRITICALパラメータをBYPASS_QUEUEに設定できます。この設定では、コンシューマ・グループからのパラレル・ステートメントは、パラレル・ステートメント・キューを無視して即座に処理されます。ただし、パラレル実行サーバーの数がPARALLEL_SERVERS_TARGET初期化パラメータの設定を超えることがあり、PARALLEL_MAX_SERVERS初期化パラメータで設定された制限に達した場合、並列度が低くなることがあります。

PARALLEL_DEGREE_LIMIT_P1で表される並列度は、URGENT_GROUPの場合12に設定されます。したがって、URGENT_GROUPの各パラレル・ステートメントは最大で12台のパラレル実行サーバーを使用できます。同様に、ETL_GROUPの各パラレル・ステートメントは最大で8台のパラレル実行サーバーを使用でき、OTHER_GROUPSの各パラレル・ステートメントは2台のパラレル実行サーバーを使用できます。

たとえば、ある時間にパラレル・ステートメントがETL_GROUPからのみ実行され、このパラレル・ステートメントによって、このグループで使用可能な32台のパラレル実行サーバーのうち26台が使用されているとします。このコンシューマ・グループからのセッションのPARALLEL_DEGREE_POLICYは、AUTOに設定されています。別のパラレル・ステートメントがPARALLEL_DEGREE_LIMIT_P1属性が8の設定でETL_GROUPから起動されても、ETL_GROUPで使用可能なパラレル実行サーバーは、32-26=6パラレル実行サーバーであるので、この問合せはすぐには実行されません。新しいパラレル・ステートメントは、必要な数のパラレル実行サーバーがETL_GROUPで使用可能になるまでキューで待機します。

ETL_GROUPのパラレル・ステートメントの実行中、OTHER_GROUPSからパラレル・ステートメントが開始されたとします。このグループでは32台のパラレル実行サーバーを使用できるので、パラレル・ステートメントは実行されます。

OTHER_GROUPSのPARALLEL_QUEUE_TIMEOUT属性は、360に設定されています。このため、このグループからのパラレル・ステートメントは、360秒間のみパラレル実行サーバーのキューに残ることができます。この時間が経過すると、パラレル・ステートメントはキューから削除され、エラーORA-07454が返されます。

26.5.5 オラクル社が提供する複合ワークロード・プラン

Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN (バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。

MIXED_WORKLOAD_PLANは、次のように定義されています。

グループまたはサブプラン	CPUリソース割当て
グループまたはサブプラン	レベル1	レベル2	レベル3	コンシューマ・グループの自動切替え	最大並列度
`BATCH_GROUP`			100%
`INTERACTIVE_GROUP`		85%		切替え先グループ: `BATCH_GROUP` 切替え時間: 60秒コールに対する切替え: `TRUE`	1
`ORA$AUTOTASK`		5%
`OTHER_GROUPS`		5%
`SYS_GROUP`	100%

このプランのINTERACTIVE_GROUPは短いトランザクションを対象にしているため、60秒を超えるCPU時間を使用するコールは、長いバッチ操作を対象にしたBATCH_GROUPに自動的に切り替わります。

使用環境に適する場合は、この事前定義済のプランを使用できます。(このプランは変更したり、使用しない場合に削除できます。)BATCH_GROUPおよびINTERACTIVE_GROUPの名前に特別な意味はありません。この名前はグループの用途を反映しているだけで、ユーザーは任意に、これらのグループにアプリケーション・セッションをマップし、それに応じてCPUリソースの割当て使用率を調整して、使用する対話型アプリケーションおよびバッチ・アプリケーションにあわせた適切なリソース管理を実現できます。たとえば、対話型アプリケーションをINTERACTIVE_GROUPコンシューマ・グループの下で実行するには、ユーザー名、サービス名、プログラム名、モジュール名または処理に基づいて、このコンシューマ・グループに対話型アプリケーションのユーザー・セッションをマップする必要があります(「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照)。同じように、BATCH_GROUPにバッチ・アプリケーションをマップする必要があります。最後に、このプランを有効にする必要があります(「Oracle Database Resource Managerの有効化とプランの切替え」を参照)。

このプランの他のリソース・コンシューマ・グループとサブプランについては、表26-17および表26-18を参照してください。

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

26.6 単一サーバーにおける複数のデータベース・インスタンスの管理

Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。

インスタンス・ケージングの概要
各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。
インスタンス・ケージングの有効化
CPUディレクティブでリソース・プランを作成し、CPU_COUNT初期化パラメータを設定することで、インスタンス・ケージングの使用を有効にできます。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.6.1 インスタンス・ケージングについて

各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。

1台のマルチCPU搭載サーバーで複数のOracle Databaseインスタンスを実行するように決定することがあります。その代表的な理由は、サーバーの統合、つまり使用できるハードウェア・リソースをより効率的に使用するためです。1台のサーバーで複数のインスタンスが実行されている場合、インスタンスはCPUリソースを競い合います。1つのリソース集中型のデータベース・インスタンスが、他のインスタンスのパフォーマンスを大きく低下させる場合があります。たとえば、16個のCPUのシステムで4つのデータベース・インスタンスが存在する場合に、ある1つのデータベース・インスタンスに大きな負荷がかかっている間、オペレーティング・システムによって、このインスタンスの実行にCPUの大半が使用される可能性があります。これにより、他の3つのインスタンスのパフォーマンスが低下することがあります。このようなCPU割当ては、オペレーティング・システムのみによって決定され、通常はユーザーが制御することはできません。

前の例で、インスタンス・ケージングを使用して4つのインスタンスそれぞれのCPU数を4に制限すると、1つのインスタンスによって他のインスタンスが妨害される可能性が低くなります。4つのCPUに制約されると、インスタンスはCPUにバインドされます。このとき、リソース・マネージャによって、インスタンスに対して設定したリソース・プランに基づき、様々なデータベース・セッション間でのCPUの割当てが開始されます。このように、インスタンス・ケージングとリソース・マネージャによって、単一サーバーで複数のインスタンスを管理する簡単で効果的な方法が提供されます。

サーバーのインスタンス・ケージングには、次の2つの一般的なアプローチがあります。

オーバーサブスクライブ: このアプローチは、開発システムやテスト・システムなどの重要度の低いデータベースや、負荷が少なく、かつ重要度の低い本番システムに対して使用します。このアプローチでは、各インスタンスのCPU制限の合計がシステム上の実際のCPU数を超過します。たとえば、4つのデータベース・インスタンスがある4 CPUシステムで、各インスタンスを3つのCPUに制限します。この方法でサーバーがオーバーサブスクライブされると、インスタンスが相互にパフォーマンスに影響を及ぼします。ただし、インスタンス・ケージングによってその影響は制限され、パフォーマンスはある程度予測可能になります。ただし、インスタンスの1つに高負荷の期間がある場合、CPUでそれを処理できます。1つ以上のインスタンスが頻繁にアイドルまたは低負荷になる可能性があるため、このアプローチは重要度の低いシステムに適切です。
パーティション化: このアプローチは、インスタンスが相互に妨害しないようにする必要がある、重要な本番システムに適しています。すべての割当ての合計がサーバー上のCPU数と等しくなるようにCPUを割り当てます。たとえば、16 CPUサーバー・システムで、最初のインスタンスに8つのCPU、2番目のインスタンスに4つのCPU、残りの2つのインスタンスに2つずつのCPUを割り当てます。CPUリソースを各データベース・インスタンス専用にすることによって、1つのインスタンスへの負荷が別のインスタンスに影響を及ぼすことがなくなり、各インスタンスは想定したとおりに実行されます。

使用率制限が適用されたインスタンス・ケージングの使用

リソース・プランでインスタンス・ケージングを有効にし、使用率制限を設定した場合、絶対上限は割り当てられたCPUリソースの割合として計算されます。

たとえば、インスタンス・ケージングを有効にし、CPU_COUNTを4に設定し、コンシューマ・グループの使用率制限が50%である場合、コンシューマ・グループは4つのCPUの最大50%、つまり2つのCPUを使用できます。

親トピック: 単一サーバーにおける複数のデータベース・インスタンスの管理

26.6.2 インスタンス・ケージングの有効化

CPUディレクティブでリソース・プランを作成し、CPU_COUNT初期化パラメータを設定することで、インスタンス・ケージングの使用を有効にできます。

インスタンス・ケージングを有効化するには、サーバー上の各インスタンスに対して次の処理を実行します。

リソース・プランを割り当てることでリソース・マネージャを有効化し、MGMT_P1からMGMT_P8のパラメータを使用してリソース・プランにCPUディレクティブがあるようにします。

手順については、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。
cpu_count初期化パラメータを設定します。
これは動的パラメータであり、次の文を使用して設定できます。
```
ALTER SYSTEM SET CPU_COUNT = 4;
```

親トピック: 単一サーバーにおける複数のデータベース・インスタンスの管理

26.7 コンシューマ・グループ、プランおよびディレクティブのメンテナンス

Oracle Database Resource Manager (リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスできます。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。

コンシューマ・グループの更新
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。
コンシューマ・グループの削除
DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。
プランの更新
プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。
プランの削除
DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。
リソース・プラン・ディレクティブの更新
プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。
リソース・プラン・ディレクティブの削除
リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。

関連項目:

事前定義のコンシューマ・グループ・マッピング・ルール
DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.7.1 コンシューマ・グループの更新

コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。

コンシューマ・グループを更新する手順:

ペンディング・エリアを作成します。
UPDATE_CONSUMER_GROUPプロシージャを実行します。

引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。
ペンディング・エリアを発行します。

26.7.2 コンシューマ・グループの削除

DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。

コンシューマ・グループを削除する手順:

ペンディング・エリアを作成します。
DELETE_CONSUMER_GROUPプロシージャを実行します。
ペンディング・エリアを発行します。

コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてOTHER_GROUPSが割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはOTHER_GROUPSに切り替わります。

リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。

26.7.3 プランの更新

プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。

プランを更新する手順:

ペンディング・エリアを作成します。
UPDATE_PLANプロシージャを実行します。たとえば、次のスクリプトは、COMMENTパラメータを更新するPL/SQLブロックです。
```
BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_PLAN(
   PLAN => 'DAYTIME',
   NEW_COMMENT => '50% more resources for OLTP applications');
END;
/
```
引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。
ペンディング・エリアを発行します。

26.7.4 プランの削除

DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。

計画を削除する手順は、次のとおりです。

ペンディング・エリアを作成します。
DELETE_PLAN_CASCADEプロシージャを実行します。たとえば、次のスクリプトは、great_breadプランとそのディレクティブを削除するPL/SQLブロックです。
```
BEGIN
  DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'great_bread');
END;
/
```
引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。

削除したディレクティブが参照していたリソース・コンシューマ・グループは削除されませんが、great_breadプランとの関連は解除されます。

DELETE_PLAN_CASCADEプロシージャは、指定のプランとその子孫すべて(プラン・ディレクティブ、および必須のマークが付けられていないサブプランとリソース・コンシューマ・グループ)を削除します。エラーが発生したDELETE_PLAN_CASCADEはロールバックされ、プランは変更されません。

現在アクティブなプランは削除できません。
ペンディング・エリアを発行します。

26.7.5 リソース・プラン・ディレクティブの更新

プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。

リソース・プラン・ディレクティブを更新する手順:

ペンディング・エリアを作成します。

UPDATE_PLAN_DIRECTIVEプロシージャを実行します。

次の例ではディレクティブにコメントを追加します。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
         PLAN             => 'SIMPLE_PLAN1',
         GROUP_OR_SUBPLAN => 'MYGROUP1',
         NEW_COMMENT      => 'Higher priority'
        );
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

コメントをクリアする(NULLにする)には、NULL文字列('')を渡します。数値のディレクティブ・パラメータをクリアする(0またはNULLにする)には、新しい値を-1に設定します。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
  DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
         PLAN                  => 'SIMPLE_PLAN1',
         GROUP_OR_SUBPLAN      => 'MYGROUP1',
         NEW_MAX_EST_EXEC_TIME => -1
        );
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

UPDATE_PLAN_DIRECTIVEプロシージャの引数を指定しない場合、ディレクティブ内の対応パラメータは変更されません。

ペンディング・エリアを発行します。

26.7.6 リソース・プラン・ディレクティブの削除

リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。

リソース・プラン・ディレクティブを削除する手順:

ペンディング・エリアを作成します。
DELETE_PLAN_DIRECTIVEプロシージャを実行します。
ペンディング・エリアを発行します。

26.8 データベース・リソース・マネージャの構成とステータスの表示

Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。

リソース・マネージャのビューについて
動的パフォーマンス・ビューのセットにより、Oracle Database Resource Manager設定の結果を監視できます。
ユーザーまたはロールに権限付与されたコンシューマ・グループの表示
DBA_RSRC_CONSUMER_GROUP_PRIVSビューには、ユーザーまたはロールに付与されているコンシューマ・グループが表示されます。
プラン情報の表示
DBA_RSRC_PLANSビューを使用して、データベースに定義されているすべてのリソース・プランを表示する例を示します。
セッションの現行コンシューマ・グループの表示
V$SESSIONビューを使用すれば、セッションに現在割り当てられているコンシューマ・グループを表示できます。
現在アクティブなプランの表示
V$RSRC_PLANビューには現在アクティブなプランが表示されます。
Oracle Database Resource Managerで管理されるPDBの監視
動的パフォーマンス・ビューのセットにより、PDBに対するOracle Database Resource Managerの設定結果を監視できます。

関連項目:

すべての静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: Oracle Database Resource Managerを使用したリソースの管理

26.8.1 リソース・マネージャのビューについて

動的パフォーマンス・ビューのセットにより、Oracle Database Resource Manager設定の結果を監視できます。

次の動的パフォーマンス・ビューは、Oracle Database Resource Managerの設定結果の監視に役立ちます。

これらのビューには、次の情報が表示されます。

現在のステータス情報
リソース・プランのアクティブ化の履歴
リソース・コンシューマ・グループとセッションによるリソース使用とCPU待ちに関する現在の統計と履歴の統計

さらに、履歴統計は、DBA_HIST_RSRC_PLANおよびDBA_HIST_RSRC_CONSUMER_GROUPの各ビューを介して表示できます。これらのビューには、それぞれV$RSRC_PLAN_HISTORYとV$RSRC_CONS_GROUP_HISTORYの自動ワークロード・リポジトリ(AWR)スナップショットが含まれています。

チューニングに役立つように、V$RSRCMGRMETRICおよびV$RSRCMGRMETRIC_HISTORYの各ビューには、過去1時間に、CPU待ちに費やした時間とCPUの使用量が、コンシューマ・グループごとに分単位で表示されます。Cloud Controlでは、これらのメトリックも「リソース・マネージャ統計」ページでグラフィカルに表示できます。

リソース・マネージャを使用可能にすると、リソース・マネージャによってリソース使用率に関する統計が自動的に記録され、リアルタイムSQL監視およびリソース・マネージャの動的パフォーマンス・ビューを使用して、それらの統計を検証できます。

リアルタイムSQL監視を使用するには、Cloud Controlで「SQLモニター」ページにアクセスするか、またはV$SQL_MONITORビューおよび他の関連するビューを問い合せます。V$SQL_MONITORビューには、リソース・マネージャによってコンシューマ・グループについて実行された最後の処理に関する情報も、RM_CONSUMER_GROUP、RM_LAST_ACTION、RM_LAST_ACTION_REASONおよびRM_LAST_ACTION_TIMEの列に含まれます。

また、次の動的パフォーマンス・ビューにはリソース使用率に関する統計が含まれています。

V$RSRCMGRMETRIC
V$RSRCMGRMETRIC_HISTORY
V$RSRC_CONSUMER_GROUP
V$RSRC_CONS_GROUP_HISTORY

関連項目:

リアルタイムSQL監視の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

V$RSRC_PLAN

このビューには、現在アクティブなリソース・プランとそのサブプランが表示されます。

SELECT name, is_top_plan FROM v$rsrc_plan;
 
NAME                             IS_TOP_PLAN
-------------------------------- -----------
DEFAULT_PLAN                     TRUE
ORA$AUTOTASK                     FALSE
ORA$AUTOTASK_HIGH_SUB_PLAN       FALSE

IS_TOP_PLANがTRUEのプランは、現在アクティブな(トップレベルの)プランです。他のプランは、トップレベルのプランのサブプランか、リスト内の他のサブプランのサブプランです。

このビューには、その他に次の情報なども含まれます。

INSTANCE_CAGING列に、インスタンス・ケージングが有効であるかどうかが表示されます。
CPU_MANAGED列に、CPUが管理されているかどうかが表示されます。
PARALLEL_EXECUTION_MANAGED列に、パラレル・ステートメント・キューイングが有効であるかどうかが表示されます。

関連項目:

V$RSRC_CONSUMER_GROUP

V$RSRC_CONSUMER_GROUPビューは、CPU、I/O、パラレル実行サーバーなど、使用されているリソースを監視する場合に使用します。また、CPUリソースの管理、リソース集中型の問合せの管理、パラレル・ステートメント・キューイングなどに関連する統計を監視する場合にも使用できます。すべての統計は、プランがアクティブ化された時点からの累積です。

SELECT name, active_sessions, queue_length,
  consumed_cpu_time, cpu_waits, cpu_wait_time
  FROM v$rsrc_consumer_group;

NAME               ACTIVE_SESSIONS QUEUE_LENGTH CONSUMED_CPU_TIME  CPU_WAITS CPU_WAIT_TIME
------------------ --------------- ------------ ----------------- ---------- -------------
OLTP_ORDER_ENTRY                 1            0             29690        467          6709
OTHER_GROUPS                     0            0           5982366       4089         60425
SYS_GROUP                        1            0           2420704        914         19540
DSS_QUERIES                      4            2           4594660       3004         55700

前述の問合せ結果では、DSS_QUERIESコンシューマ・グループには、アクティブ・セッション・プールに4つのセッションがあり、2つのセッションがキューでアクティブ化を待機しています。

このビューの主な測定値はCPU_WAIT_TIMEです。この測定値は、リソース管理のために、コンシューマ・グループのセッションがCPUの割当てを待機していた合計時間を示します。この測定値には、ラッチまたはエンキューの競合、I/O待機などに起因する待機は含まれません。

注意:

STATISTICS_LEVEL初期化パラメータがALLまたはTYPICALに設定されている場合、V$RSRC_CONSUMER_GROUPビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

V$RSRC_SESSION_INFO

このビューを使用して、1つ以上のセッションのステータスを監視します。このビューには、リソース・マネージャによるセッションへの影響が表示されます。次の情報が提供されます。

セッションが現在属しているコンシューマ・グループ。
セッションが当初属していたコンシューマ・グループ。
コンシューマ・グループへのセッションのマップに使用されたセッション属性。
セッションの状態(RUNNING、WAIT_FOR_CPU、QUEUEDなど)。
メトリックに関する現在の統計と累積の統計(CPU使用、待機時間、待ち行列時間、使用されるアクティブなパラレル・サーバーの数など)。現在の統計には、セッションが現在のコンシューマ・グループに所属してからの統計が反映されています。累積の統計には、セッションが作成された以降に所属したすべてのコンシューマ・グループでの統計が反映されています。

SELECT se.sid sess_id, co.name consumer_group, 
 se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time
 FROM v$rsrc_session_info se, v$rsrc_consumer_group co
 WHERE se.current_consumer_group_id = co.id;

SESS_ID CONSUMER_GROUP     STATE     CPU_TIME CPU_WAIT_TIME QUEUED_TIME
------- ------------------ -------- --------- ------------- -----------
    113 OLTP_ORDER_ENTRY   WAITING     137947         28846           0
    135 OTHER_GROUPS       IDLE        785669         11126           0
    124 OTHER_GROUPS       WAITING      50401         14326           0
    114 SYS_GROUP          RUNNING        495             0           0
    102 SYS_GROUP          IDLE         88054            80           0
    147 DSS_QUERIES        WAITING     460910        512154           0

このビューのCPU_WAIT_TIMEには、V$RSRC_CONSUMER_GROUPビューと同様の意味がありますが、個々のセッションに適用されます。

このビューとV$SESSIONビューを結合して、さらに詳細なセッションに関する情報を表示できます。

関連項目:

V$RSRC_PLAN_HISTORY

このビューには、インスタンスでリソース・プランがいつ有効または無効になったかが表示されます。各リソース・プランのアクティブ化または解除には連番が割り当てられます。このビューの各エントリについては、プランの各コンシューマ・グループに対応するエントリがV$RSRC_CONS_GROUP_HISTORYビューにあり、コンシューマ・グループの累積統計が表示されます。この2つのビューは、それぞれのSEQUENCE#列で結合しています。

SELECT sequence# seq, name plan_name,
to_char(start_time, 'DD-MON-YY HH24:MM') start_time,
to_char(end_time, 'DD-MON-YY HH24:MM') end_time, window_name
FROM v$rsrc_plan_history;

 SEQ PLAN_NAME                  START_TIME      END_TIME        WINDOW_NAME
---- -------------------------- --------------- --------------- ----------------
   1                            29-MAY-07 23:05 29-MAY-07 23:05
   2 DEFAULT_MAINTENANCE_PLAN   29-MAY-07 23:05 30-MAY-07 02:05 TUESDAY_WINDOW
   3                            30-MAY-07 02:05 30-MAY-07 22:05
   4 DEFAULT_MAINTENANCE_PLAN   30-MAY-07 22:05 31-MAY-07 02:05 WEDNESDAY_WINDOW
   5                            31-MAY-07 02:05 31-MAY-07 22:05
   6 DEFAULT_MAINTENANCE_PLAN   31-MAY-07 22:05                 THURSDAY_WINDOW

PLAN_NAMEの下のNULL値は、プランがアクティブにならなかったことを示します。

このビューのAWRスナップショットはDBA_HIST_RSRC_PLANビューに格納されます。

関連項目:

V$RSRC_CONS_GROUP_HISTORY

このビューは、時間の経過とともに、リソースがコンシューマ・グループ間でどのように共有されていたかを理解するのに役立ちます。sequence#列は、V$RSRC_PLAN_HISTORYビューの同名の列に対応しています。そのため、コンシューマ・グループ統計の各行について、アクティブであったプランを判別できます。

SELECT sequence# seq, name, cpu_wait_time, cpu_waits,
consumed_cpu_time FROM v$rsrc_cons_group_history;
 
 SEQ NAME                      CPU_WAIT_TIME  CPU_WAITS CONSUMED_CPU_TIME
---- ------------------------- ------------- ---------- -----------------
   2 SYS_GROUP                         18133        691          33364431
   2 OTHER_GROUPS                      51252        825         181058333
   2 ORA$AUTOTASK_MEDIUM_GROUP            21          5           4019709
   2 ORA$AUTOTASK_URGENT_GROUP            35          1            198760
   2 ORA$AUTOTASK_STATS_GROUP              0          0                 0
   2 ORA$AUTOTASK_SPACE_GROUP              0          0                 0
   2 ORA$AUTOTASK_SQL_GROUP                0          0                 0
   2 ORA$AUTOTASK_HEALTH_GROUP             0          0                 0
   4 SYS_GROUP                         40344         85          42519265
   4 OTHER_GROUPS                     123295       1040         371481422
   4 ORA$AUTOTASK_MEDIUM_GROUP             1          4           7433002
   4 ORA$AUTOTASK_URGENT_GROUP         22959        158          19964703
   4 ORA$AUTOTASK_STATS_GROUP              0          0                 0
      .
      .

このビューのAWRスナップショットはDBA_HIST_RSRC_CONSUMER_GROUPビューに格納されます。コンシューマ・グループ統計の各履歴セットについて、アクティブであったプランを判別するには、DBA_HIST_RSRC_CONSUMER_GROUPとDBA_HIST_RSRC_PLANを併用します。

注意:

STATISTICS_LEVEL初期化パラメータがALLまたはTYPICALに設定されている場合、V$RSRC_CONS_GROUP_HISTORYビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

『Oracle Databaseリファレンス』
AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

V$RSRCMGRMETRIC

このビューを使用すると、セッション数の観点または過去1分間の使用状況の観点から、CPUメトリックをミリ秒単位で追跡できます。各コンシューマ・グループのリアルタイムなメトリックが提供されるため、ワークロードの実行中に、CPUリソースの使用状況を継続的に監視する場合に非常に便利です。

このビューを使用すると、コンシューマ・グループの最大CPU使用率と平均CPU使用率を、使用したCPU時間、CPU待ち時間、CPUを消費しているセッションの平均数、CPU割当てを待機しているセッションの数など他のコンシューマ・グループ設定と比較できます。たとえば、コンシューマ・グループが使用したCPUリソースの量およびコンシューマ・グループがリソース割当てを待機した期間を表示できます。または、各コンシューマ・グループから実行されているセッションの数とアクティブなセッションの総数とを対比できます。

CPU使用率でCPUの消費量を追跡するには、CPU_UTILIZATION_LIMIT列およびAVG_CPU_UTILIZATION列を使用します。AVG_CPU_UTILIZATION列には、コンシューマ・グループによるサーバーのCPUの平均使用率が表示されます。CPU_UTILIZATION_LIMIT列は、コンシューマ・グループが使用できるサーバーのCPUの最大割合を表します。この制限は、UTILIZATION_LIMITディレクティブ属性を使用して設定されます。

SELECT consumer_group_name, cpu_utilization_limit,
avg_cpu_utilization FROM v$rsrcmgrmetric;

CPUの消費量および制限量をミリ秒単位で追跡するには、CPU_CONSUMED_TIME列およびCPU_TIME_WAIT列を使用します。NUM_CPUS列は、リソース・マネージャが管理しているCPUの数を表します。

SELECT consumer_group_name, cpu_consumed_time,
cpu_wait_time, num_cpus FROM v$rsrcmgrmetric;

CPUの消費量および制限量をセッションの数で追跡するには、RUNNING_SESSIONS_LIMIT、AVG_RUNNING_SESSIONS、AVG_WAITING_SESSIONSの各列を使用します。RUNNING_SESSIONS_LIMIT列には、特定のコンシューマ・グループからいつでも実行できるセッションの最大数が表示されます。この制限は、コンシューマ・グループまたはコンシューマ・グループが含まれているサブプランに設定するUTILIZATION_LIMITディレクティブ属性で定義されます。コンシューマ・グループごとに、AVG_RUNNING_SESSIONS列にはCPUを消費しているセッションの平均数が表示され、AVG_WAITING_SESSIONS列にはCPUを待機しているセッションの平均数が表示されます。

SELECT sequence#, consumer_group_name, running_sessions_limit,
avg_running_sessions, avg_waiting_sessions FROM v$rsrcmgrmetric;

パラレル・ステートメントおよびコンシューマ・グループのパラレル・サーバーの使用を追跡するには、AVG_ACTIVE_PARALLEL_STMTS、AVG_QUEUED_PARALLEL_STMTS、AVG_ACTIVE_PARALLEL_SERVERS、AVG_QUEUED_PARALLEL_SERVERSおよびPARALLEL_SERVERS_LIMIT列を使用します。AVG_ACTIVE_PARALLEL_STMTSとAVG_ACTIVE_PARALLEL_SERVERSには、実行されているパラレル・ステートメントの平均数、およびパラレル・ステートメントによって使用されるパラレル・サーバーの平均数が表示されます。AVG_QUEUED_PARALLEL_STMTSとAVG_QUEUED_PARALLEL_SERVERSには、キュー内のパラレル・ステートメントの平均数、およびキュー内のパラレル・ステートメントによって要求されたパラレル・サーバーの平均数が表示されます。PARALLEL_SERVERS_LIMITには、コンシューマ・グループで使用できるパラレル・サーバーの数が表示されます。

SELECT avg_active_parallel_stmts, avg_queued_parallel_stmts, 
avg_active_parallel_servers, avg_queued_parallel_servers, parallel_servers_limit
FROM v$rsrcmgrmetric;

注意:

STATISTICS_LEVEL初期化パラメータがALLまたはTYPICALに設定されている場合、V$RSRCMGRMETRICビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

V$RSRCMGRMETRIC_HISTORY

V$RSRCMGRMETRIC_HISTORYの各列は、V$RSRCMGRMETRICと同じビューです。これらのビューの唯一の違いは、V$RSRCMGRMETRICには過去1分間のみのメトリックが含まれているのに対して、V$RSRCMGRMETRIC_HISTORYには過去60分間のメトリックが含まれていることです。

注意:

STATISTICS_LEVEL初期化パラメータがALLまたはTYPICALに設定されている場合、V$RSRCMGRMETRIC_HISTORYビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

26.8.2 ユーザーまたはロールに権限付与されたコンシューマ・グループの表示

DBA_RSRC_CONSUMER_GROUP_PRIVSビューには、ユーザーまたはロールに付与されているコンシューマ・グループが表示されます。

具体的には、ユーザーまたはロールが属することが許可されているグループ、または切替え可能なグループが表示されます。たとえば、次に示すビューの場合、ユーザーSCOTTは常にSALESコンシューマ・グループで開始され、特定の付与によってMARKETINGグループに切り替えることが可能であり、さらにDEFAULT_CONSUMER_GROUP (OTHER_GROUPS)グループとLOW_GROUPグループはPUBLICに付与されているので、これらのグループに切り替えることができます。また、SCOTTは他のユーザーにSALESグループを付与できますが、MARKETINGグループは付与できません。

SELECT * FROM dba_rsrc_consumer_group_privs;

GRANTEE            GRANTED_GROUP                  GRANT_OPTION INITIAL_GROUP
------------------ ------------------------------ ------------ -------------
PUBLIC             DEFAULT_CONSUMER_GROUP         YES          YES
PUBLIC             LOW_GROUP                      NO           NO
SCOTT              MARKETING                      NO           NO
SCOTT              SALES                          YES          YES
SYSTEM             SYS_GROUP                      NO           YES

SCOTTには、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用してこれらのグループに切り替える機能がすでに付与されています。

26.8.3 プラン情報の表示

DBA_RSRC_PLANSビューを使用して、データベースに定義されているすべてのリソース・プランを表示する例を示します。

すべてのプランのステータスは、ペンディング・エリアに存在しないことを意味するNULLです。

注意:

ペンディング・エリア内のプランのステータスはPENDINGです。ペンディング・エリア内のプランは編集中です。

SELECT plan,status,comments FROM dba_rsrc_plans;

PLAN                        STATUS   COMMENTS
--------------------------- -------- ----------------------------------------
DSS_PLAN                             Example plan for DSS workloads that prio...
ETL_CRITICAL_PLAN                    Example plan for DSS workloads that prio...
MIXED_WORKLOAD_PLAN                  Example plan for a mixed workload that p...
DEFAULT_MAINTENANCE_PLAN             Default plan for maintenance windows tha...
DEFAULT_PLAN                         Default, basic, pre-defined plan that pr...
INTERNAL_QUIESCE                     Plan for quiescing the database.  This p...
INTERNAL_PLAN                        Internally-used plan for disabling the r...
.
.
.

26.8.4 セッションの現行コンシューマ・グループの表示

V$SESSIONビューを使用すれば、セッションに現在割り当てられているコンシューマ・グループを表示できます。

次の例では、V$SESSIONビューを問い合せます。

SELECT sid,serial#,username,resource_consumer_group FROM v$session;

SID    SERIAL#  USERNAME                  RESOURCE_CONSUMER_GROUP
-----  -------  ------------------------  --------------------------------
   11       136 SYS                       SYS_GROUP
   13     16570 SCOTT                     SALES
   ...

26.8.5 現在アクティブなプランの表示

V$RSRC_PLANビューには現在アクティブなプランが表示されます。

この例では、mydb_plan (「複数レベルのプランの例」の例で作成したもの)をトップレベルのプランに設定します。次に、V$RSRC_PLANビューを問い合せて、現在アクティブなプランを表示します。このビューには、現在のトップレベルのプランとそのすべての子サブプランが表示されます。

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = mydb_plan;

System altered.

SELECT name, is_top_plan FROM v$rsrc_plan;

NAME             IS_TOP_PLAN
----------------------------
MYDB_PLAN        TRUE
MAILDB_PLAN      FALSE
BUGDB_PLAN       FALSE

26.8.6 Oracle Database Resource Managerで管理されるPDBの監視

一連の動的パフォーマンス・ビューにより、Oracle Database Resource ManagerによるPDBの設定の結果を監視できます。

PDBに対するリソース・マネージャのビューについて
ビューを使用して、PDBに対するOracle Database Resource Managerの設定の結果を監視できます。
PDBのCPU使用率の監視
V$RSRCPDBMETRICビューを使用すると、セッション数の観点または過去1分間の使用状況の観点から、CPUメトリックをミリ秒単位で追跡できます。
PDBパラレル実行の監視
V$RSRCPDBMETRICビューを使用すると、PDBに対するパラレル・ステートメントとパラレル・サーバーの使用を追跡できます。
PDBによって生成されるI/Oの監視
V$RSRCPDBMETRICビューを使用すると、PDBで生成されるI/Oの量を追跡できます。
PDBのメモリー使用率の監視
V$RSRCPDBMETRICビューを使用すると、PDBで使用されるメモリー量を追跡できます。