1. データベース管理者ガイド
  2. データベース・リソースの管理とタスクのスケジューリング
  3. Oracle Database Resource Managerを使用したリソースの管理

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

Oracle Database Resource Manager(リソース・マネージャ)を使用して、データベースのリソース割当てを管理できます。

注意:

この章では、PL/SQLパッケージ・プロシージャを使用してリソース・マネージャを管理する方法について説明します。リソース・マネージャをより簡単に管理するには、Oracle Enterprise Manager Cloud Control (Cloud Control)のグラフィカル・ユーザー・インタフェースを使用します。Cloud Controlを使用したリソース・マネージャの管理の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

Cloud Controlでリソース・マネージャを使用するには:

  1. データベース・ホームページにアクセスします。

  2. 「管理」メニューから、「リソース・マネージャ」を選択します。

  • Oracle Database Resource Managerについて
    Oracle Database Resource Manager (リソース・マネージャ)を使用すると、システム・リソースやデータベース・リソースを求めて競合するデータベース内の複数のワークロードを管理できます。
  • リソース・コンシューマ・グループへのセッションの割当て
    データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法があります。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager(リソース・マネージャ)では、そのセッションに対するリソース割当てが管理の対象となります。
  • リソース・マネージャによって管理されるリソースのタイプ
    リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。
  • 単純なリソース・プランの作成
    CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。
  • 複雑なリソース・プランの作成
    複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。
  • Oracle Database Resource Managerの有効化とプランの切替え
    Oracle Database Resource Manager(リソース・マネージャ)を有効にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。
  • 各種の方法を組み合せたOracle Database Resource Managerの例
    リソース・マネージャでリソースを割り当てる方法を例で示します。
  • 単一サーバーにおける複数のデータベース・インスタンスの管理
    Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。
  • コンシューマ・グループ、プランおよびディレクティブのメンテナンス
    Oracle Database Resource Manager (リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスできます。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。
  • データベース・リソース・マネージャの構成とステータスの表示
    Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。
  • Oracle Database Resource Managerの監視
    動的パフォーマンス・ビューのセットにより、Oracle Database Resource Manager設定の結果を監視できます。
  • オペレーティング・システムのリソース制御との相互作用
    多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。たとえば、HP社のProcess Resource Managerや、Solaris Containers、ZonesおよびResource Poolsなどがあります。
  • Oracle Database Resource Managerの参照情報
    リソース・マネージャには、事前定義済のリソース・プラン、コンシューマ・グループおよびコンシューマ・グループ・マッピング・ルールが含まれます。リソース・マネージャ構成に関する情報をデータ・ディクショナリ・ビューに問い合せることができます。

親トピック: データベース・リソースの管理とタスクのスケジューリング

27.1 Oracle Database Resource Managerについて

Oracle Database Resource Manager (リソース・マネージャ)を使用すると、システム・リソースやデータベース・リソースを求めて競合するデータベース内の複数のワークロードを管理できます。

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

27.1.1 リソース・マネージャが提供するワークロード管理のソリューション

リソース・マネージャでは、ハードウェア・リソースの割当て方法をデータベースで厳密に制御できます。

データベース・リソースの割当てがオペレーティング・システムによって決定される場合は、次のようなワークロードの管理に関する問題が生じることがあります。

  • 過度のオーバーヘッド

    過剰なオーバーヘッドは、サーバー・プロセスの数が多いときに、Oracle Databaseサーバー・プロセス間でオペレーティング・システムのコンテキストが切り替わることによって発生します。

  • 非効率的なスケジューリング

    オペレーティング・システムは、データベース・サーバーがラッチを保持している間にデータベース・サーバーのスケジュールを解除しますが、これは非効率的です。

  • 不適当なリソースの割当て

    オペレーティング・システムはタスク間の優先度付けができないため、すべてのアクティブなプロセスの間で均等にリソースを分配します。

  • パラレル実行サーバーやアクティブ・セッションなど、データベース固有のリソースを管理できない

リソース・マネージャは、ハードウェア・リソースの割当て方法をデータベースで厳密に制御することによって、これらの問題を克服します。複数のコンカレント・ユーザー・セッションがあり、各セッションでは異なる優先度のジョブが実行される環境では、すべてのセッションが同等に処理されるわけではありません。リソース・マネージャを使用すると、セッション属性に基づいてセッションを複数のグループに分類し、それらのグループに対して、アプリケーション環境のハードウェア利用が最適化されるようにリソースを配分できます。

リソース・マネージャを使用すると、次のことが可能になります。

  • システムにかかる負荷やユーザー数に関係なく、特定のセッションのCPUが最小量になることを保証します。

  • 様々なユーザーおよびアプリケーションに、比率を指定してCPU時間を割り当てて、使用可能なCPUを分配します。データ・ウェアハウスの場合は、バッチ・ジョブよりもリレーショナル・オンライン分析処理(ROLAP)アプリケーションへの割当て率を高くできます。

  • ユーザー・グループのメンバーが実行する処理の並列度を制限します。

  • パラレル・ステートメント・キュー内のパラレル・ステートメントの順序を管理します。優先度の低いユーザー・グループからのパラレル・ステートメントよりも前に、重要なアプリケーションからのパラレル・ステートメントをエンキューできます。

  • ユーザー・グループが使用できるパラレル実行サーバーの数を制限します。これにより、使用可能なすべてのパラレル実行サーバーが1つのユーザー・グループにのみ割り当てられることを回避できます。

  • アクティブ・セッション・プールを作成します。アクティブ・セッション・プールは、ユーザー・グループ内で同時にアクティブにできる指定された最大数のユーザー・セッションで構成されています。最大数を超える追加セッションは実行待ちのキューに送られますが、キューで待機しているジョブが終了するまでのタイムアウト周期を指定できます。アクティブ・セッション・プールによって、リソースについて実際に競合するセッションの総数が制限されるため、アクティブなセッションの進行を早めることができます。

  • リソースの監視

    リソース・マネージャを使用可能にすると、リソース・マネージャによってリソース使用率に関する統計が自動的に記録され、リアルタイムSQL監視およびリソース・マネージャの動的パフォーマンス・ビュー(V$RSRC_*ビュー)を使用して、それらの統計を検証できます。リアルタイムSQL監視およびリソース・マネージャの動的パフォーマンス・ビューの詳細は、「Oracle Database Resource Managerの監視」を参照してください。

  • ユーザーのグループに属する各セッションによって使用されるPGAメモリーの量を制限します。

  • 次の方法でリソース集中型のセッションまたはコールを管理します。

    • セッションまたはコールによって使用されるCPU、物理I/O、論理I/Oまたは経過時間が指定量を超過している状況を検出し、自動的に、セッションまたはコールを終了するか、リソースの割当てが少ない、あるいはグループが使用できるCPUの割合に制限があるコンシューマ・グループに切り替えます。

      論理I/Oは、バッファI/Oとも呼ばれ、バッファ・キャッシュ内でのバッファの読取りおよび書込みを表しています。要求されたバッファがメモリーにない場合、データベースでは物理I/Oを実行してディスクまたはフラッシュ・キャッシュからメモリーにバッファをコピーし、次に論理I/Oを実行して、キャッシュされたバッファを読み取ります。

    • リアルタイムSQL監視を使用して、指定量を超えるCPU、物理I/O、論理I/Oまたは経過時間を使用するSQL文に関する詳細情報を記録します。

    • 自動ワークロード・リポジトリ(AWR)を使用して、指定量を超えるCPU、物理I/O、論理I/Oまたは経過時間を使用するSQL文の永続レコードを分析します。

    • セッションに関連するその他の処理を実行しないで、リソース集中型のセッションに関する情報をログに記録します。

  • ある操作に対するオプティマイザの見積り実行時間が指定された制限を超える場合は、その操作が実行されないようにします。

  • セッションのアイドル時間を制限します。この制限は、他のセッションをブロックしているセッションのみに限定することもできます。

  • ワークロード要件の変更に基づいて、データベースで様々なリソース・プランを使用できます。インスタンスを停止して再起動しなくても、たとえば、昼間のリソース・プランから夜間のリソース・プランに変更するなど、リソース・プランを動的に変更できます。リソース・プランの変更は、Oracle Schedulerを使用してスケジュールすることもできます。詳細は、「Oracle Schedulerの概要」を参照してください。

親トピック: Oracle Database Resource Managerについて

27.1.2 リソース・マネージャの要素

リソース・マネージャには、管理できる複数の要素が含まれます。

親トピック: Oracle Database Resource Managerについて

27.1.2.1 リソース・マネージャの要素について

リソース・マネージャの要素には、リソース・コンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブが含まれます。

要素 説明

リソース・コンシューマ・グループ

リソースの要件に基づいてグループ化されたセッションのグループ。リソース・マネージャは、個々のセッションではなくリソース・コンシューマ・グループにリソースを割り当てます。

リソース・プラン

リソース・コンシューマ・グループへのリソースの割当て方法を指定するディレクティブのコンテナ。特定のリソース・プランをアクティブ化することで、データベースによるリソースの割当て方法を指定します。

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

リソース・コンシューマ・グループを特定のプランに関連付け、そのリソース・コンシューマ・グループに対するリソースの割当て方法を指定します。

これらの要素の作成とメンテナンスには、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用します。要素は、データ・ディクショナリ内の表に格納されます。要素に関する情報は、データ・ディクショナリ・ビューを使用して表示できます。

27.1.2.2 リソース・コンシューマ・グループについて

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

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

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

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

  • SYS_GROUP

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

  • OTHER_GROUPS

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

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

27.1.2.3 リソース・プラン・ディレクティブについて

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

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

ディレクティブには、コンシューマ・グループへのリソース割当てを制限できる複数の方法があります。たとえば、CPUにおいてコンシューマ・グループが確保できるCPU全体の割合を制御したり、コンシューマ・グループ内でアクティブにできるセッションの総数を制限できます。詳細は、「リソース・マネージャによって管理されるリソースのタイプ」を参照してください。

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

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

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

注意:

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

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

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

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

図27-1 単純なリソース・プラン

図27-1の説明が続きます
「図27-1 単純なリソース・プラン」の説明

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

注意:

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

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

27.1.2.6 サブプランについて

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

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

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

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

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

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

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

図27-2 サブプランを含むリソース・プラン

図27-2の説明が続きます
「図27-2 サブプランを含むリソース・プラン」の説明

この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の例」を参照してください。

親トピック: リソース・マネージャの要素

27.1.3 リソース・マネージャの管理権限について

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

リソース・マネージャを管理するには、システム権限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文によって、付与したり取り消すことはできません。

関連項目:

親トピック: Oracle Database Resource Managerについて

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

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

注意:

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

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

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

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

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

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

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

27.2.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を使用してバックアップまたはコピー操作を実行するセッションは、表27-7で指定されている事前定義のコンシューマ・グループに自動的にマップされます。

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

27.2.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です。これらの値それぞれに事前定義のマッピングがあります。セッションでこれらの機能のいずれかを実行している場合、事前定義のコンシューマ・グループに自動的にマップされます。詳細は、表27-7を参照してください。

たとえば、次の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

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

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

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

27.2.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を問い合せます。

関連項目:

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

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

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

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

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

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

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

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

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

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

27.2.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リファレンス』を参照してください。

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

27.2.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;
/
27.2.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の場合は、そのままエラーが出力されます。

次の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パッケージは、セッションの開始時、または特定のモジュールがコールされたときにセッションのコンシューマ・グループ割当てを切り替えるために使用できます。

関連項目:

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

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

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

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

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

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

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

27.2.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;
/

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

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

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

親トピック: リソース・コンシューマ・グループへのセッションの割当て

27.2.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パラメータの設定に基づいて切替え条件が満たされたとき、コンシューマ・グループの自動切替えが行われます。

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

27.2.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の場合、コンシューマ・グループのスイッチ特権が付与されたユーザーは、そのコンシューマ・グループのスイッチ特権を他のユーザーに付与することもできます。

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

27.3 リソース・マネージャによって管理されるリソースのタイプ

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

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

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

27.3.1 CPU

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

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.3.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およびパーティショニング・ガイド』を参照してください。

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

表27-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

27.3.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属性を使用することもできます。

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

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

コンシューマ・グループ レベル1のCPU割当て レベル2のCPU割当て レベル3のCPU割当て 使用率制限

HIGH_GROUP

80%

LOW_GROUP

50%

75%

MAINT_SUBPLAN

50%

50%

OTHER_GROUPS

100%

75%

表27-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 - コンシューマ・グループおよびサブプランに使用率制限を指定する」を参照してください。

27.3.2 Exadata I/O

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

関連項目:

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.3.3 パラレル実行サーバー

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

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.3.3.1 並列度制限

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

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

関連項目:

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

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

27.3.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属性が単一のインスタンスではなくクラスタ全体に適用されます。

関連項目:

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

27.3.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

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

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

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

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

関連項目:

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

注意:

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

パラレル・ステートメントがタイムアウトすると、ステートメントの実行は次のエラー・メッセージで終了します。

ORA-07454: queue timeout, n second(s), exceeded

ワークロード単位で細かく管理する場合は、次のディレクティブ属性を使用する必要があります。

  • MGMT_Pn

    管理属性は、パラレル・ステートメント・キューから実行するパラレル・ステートメントをどのように選択するかを制御します。あるコンシューマ・グループのパラレル・ステートメントを別のグループよりも優先させるには、そのグループの管理属性の値を大きくします。

  • PARALLEL_SERVER_LIMIT

  • PARALLEL_QUEUE_TIMEOUT

  • PARALLEL_DEGREE_LIMIT_P1

関連項目:

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

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

27.3.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制限のある単純なリソース・プランを示しています。

表27-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使用率を制限できます。

親トピック: リソース・マネージャによって管理されるリソースのタイプ

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

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

注意:

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

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

関連項目:

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

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

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

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

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

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

ディレクティブを指定すると、システム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了できます。

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

27.3.5.3 実行時間制限

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

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

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

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

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

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

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.3.7 UNDOプール

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

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.3.8 アイドル時間制限

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

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

親トピック: リソース・マネージャによって管理されるリソースのタイプ

27.4 単純なリソース・プランの作成

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%

関連項目:

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

27.5 複雑なリソース・プランの作成

複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。

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

注意:

複雑なリソース・プランとは、DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLANプロシージャでは作成できないリソース・プランを指します。

ステップ1: ペンディング・エリアを作成します。

ステップ2: コンシューマ・グループを作成、変更または削除します。

ステップ3: コンシューマ・グループにセッションをマップします。

ステップ4: リソース・プランを作成します。

ステップ5: リソース・プラン・ディレクティブを作成します。

ステップ6: ペンディング・エリアの妥当性をチェックします。

ステップ7: ペンディング・エリアを発行します。

これらのステップは、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して完了します。

関連項目:

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

27.5.1 ペンディング・エリアについて

ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。

ペンディング・エリアを作成すると、データベースによってペンディング・エリアが初期化され、既存のプランがペンディング・エリアにコピーされて、既存のプランを更新できるようになります。

ヒント:

ペンディング・エリアを作成した後、DBA_RSRC_PLANSデータ・ディクショナリ・ビューを問い合せてすべてのプランをリストすると、各プランについて2つのコピー(PENDINGステータスが付いているコピーと付いていないコピー)が表示されます。PENDINGステータスのプランには、ペンディング・エリアの作成後に実行した変更内容が反映されています。保留中の変更は、コンシューマ・グループの場合はDBA_RSRC_CONSUMER_GROUPSを使用して、リソース・プラン・ディレクティブの場合はDBA_RSRC_PLAN_DIRECTIVESを使用して表示できます。詳細は、「リソース・マネージャのデータ・ディクショナリ・ビュー」を参照してください。

変更を追加した後のペンディング・エリアは、発行する前に妥当性をチェックします。発行すると、保留中の変更内容がすべてデータ・ディクショナリに適用され、ペンディング・エリアはクリアされ、解除されます。

最初にペンディング・エリアを作成せずにプランを作成、更新または削除しようとすると(つまり、コンシューマ・グループまたはリソース・プラン・ディレクティブを作成、更新または削除しようとすると)、エラー・メッセージが表示されます。

ペンディング・エリアを発行しても、新しく作成したプランはアクティブ化されません(新しいプランまたは更新後のプランの情報がデータ・ディクショナリに格納されるだけです)。ただし、現在アクティブなプランを変更した場合、そのプランは新しいプラン定義で再アクティブ化されます。リソース・プランをアクティブ化する方法の詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。

ペンディング・エリアを作成した後は、そのペンディング・エリアを発行またはクリアするか、ログアウトするまで、他のユーザーはペンディング・エリアを作成できません。

親トピック: 複雑なリソース・プランの作成

27.5.2 ペンディング・エリアの作成

ペンディング・エリアはCREATE_PENDING_AREAプロシージャを使用して作成します。

例: ペンディング・エリアの作成

次のスクリプトは、ペンディング・エリアを作成して初期化するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
END;
/

親トピック: 複雑なリソース・プランの作成

27.5.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;
/

関連項目:

親トピック: 複雑なリソース・プランの作成

27.5.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;
/

関連項目:

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

親トピック: 複雑なリソース・プランの作成

27.5.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割当て方法です。

親トピック: 複雑なリソース・プランの作成

27.5.5.1 RATIO CPU割当て方法について

RATIO方法は、単一レベルのCPU割当てのみを使用する単純なプランを対象にした、代替のCPU割当て方法です。

パーセンテージのかわりに、各コンシューマ・グループに与えるCPUの割合に対応する数を指定します。RATIO方法を使用するには、CREATE_PLANプロシージャのMGMT_MTH引数に'RATIO'を設定します。この方法を使用するプランの例は、「リソース・プラン・ディレクティブの作成」を参照してください。

27.5.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内のコンシューマ・グループ間でもリソースを割り当てます。

「CDBリソース・プラン」を参照してください。

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になります。

親トピック: 複雑なリソース・プランの作成

27.5.6.1 競合するリソース・プラン・ディレクティブ

このことは許可されますが、トップレベルのプランおよびそのいずれのサブプランからも同じコンシューマ・グループが参照されないようにすることをお薦めします。

トップレベルのプランと複数のサブプランから同じコンシューマ・グループを参照する場合があります。このような場合は、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されます。

同様に、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されている場合、ディレクティブが競合します。このことは許可されますが、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されないようにすることをお薦めします。

27.5.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;
/

関連項目:

「ペンディング・エリアについて」

親トピック: 複雑なリソース・プランの作成

27.5.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;
/

関連項目:

「ペンディング・エリアについて」

親トピック: 複雑なリソース・プランの作成

27.5.9 ペンディング・エリアのクリア

CLEAR_PENDING_AREAプロシージャを使用して、ペンディング・エリアをいつでもクリアできます。

次のスクリプトは、変更のすべてをペンディング・エリアからクリアし、ペンディング・エリアを解除するPL/SQLブロックです。

BEGIN
  DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/

CLEAR_PENDING_AREAをコールした後、再び変更を実施するには、その前にCREATE_PENDING_AREAプロシージャをコールする必要があります。

関連項目:

「ペンディング・エリアについて」

親トピック: 複雑なリソース・プランの作成

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

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

デフォルトでは、後で説明するように、事前に構成されているメンテナンス・ウィンドウの期間中を除き、リソース・マネージャは有効ではありません。

テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランが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パッケージおよびタイプ・リファレンス』を参照してください。

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

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

  1. 次のSQL文を発行します。
    ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
  2. すべての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を使用したリソースの管理

27.7 各種の方法を組み合せたOracle Database Resource Managerの例

リソース・マネージャでリソースを割り当てる方法を例で示します。

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

27.7.1 複数レベルのプランの例

複数レベルのプランの例を示します。

次のスクリプトは、図27-3に示されている複数レベルのプランを作成する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のコールはオプションです。

図27-3 複数レベルのプラン・スキーマ

図27-3の説明が続きます
「図27-3 複数レベルのプラン・スキーマ」の説明

このプラン・スキーマでは、次のように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の例

27.7.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 - コンシューマ・グループおよびサブプランに使用率制限を指定する

次の例では、図27-4に示すように、サブプランおよびそのサブプラン内のコンシューマ・グループに対してUTILIZATION_LIMITを設定した場合に、使用率制限がどのように計算されるかについて説明します。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。

図27-4 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン

図27-4の説明が続きます
「図27-4 サブプランおよびコンシューマ・グループに最大使用率が設定されたリソース・プラン」の説明

次のPL/SQLブロックは、図27-4で説明するプランを作成します。 

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の例

27.7.3 各種のリソース割当て方法を使用した例

各種のリソース割当て方法を使用した例を示します。

ここで示す例は、パッケージ化されたEnterprise Resource Planning(ERP)またはCustomer Relationship Management(CRM)アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理(OLTP)の適切な応答時間を得ることにあります。

次の表にプランがまとめられています。

グループ CPUリソース割当て% パラレル文のキューイング コンシューマ・グループの自動切替え 最大見積り実行時間 UNDOプール 各セッションのPGA制限

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の例

27.7.4 ディレクティブ属性を使用したパラレル・ステートメントの管理の例

ディレクティブ属性を使用したパラレル・ステートメントの管理の例を示します。

一般的に、データ・ウェアハウス環境は、リソース要件が様々に異なる多様なユーザーで構成されています。処理要件が共通するユーザーは、コンシューマ・グループにグループ化されます。コンシューマ・グループURGENT_GROUPは、経営陣に重要な情報を提供するためのレポートを実行するユーザーで構成されています。このグループは、多数のパラレル問合せを生成します。コンシューマ・グループETL_GROUPに属するユーザーは、ソース・システムからデータをインポートし、抽出、変換、ロード(ETL)の各操作を実行します。グループOTHER_GROUPSには、非定型問合せを実行するユーザーが含まれています。パフォーマンスを最適に保つと同時に、このような多様なユーザー・グループの要件を管理する必要があります。

次のディレクティブ属性を使用すると、パラレル・ステートメントの実行を管理および最適化できます。

  • MGMT_Pn

  • PARALLEL_SERVER_LIMIT

  • PARALLEL_STMT_CRITICAL

  • PARALLEL_QUEUE_TIMEOUT

  • PARALLEL_DEGREE_LIMIT_P1

表27-4に、データ・ウェアハウス・ユーザーのニーズを管理するために使用可能なプランDW_PLANのリソース割当てを示します。このプランには、コンシューマ・グループURGENT_GROUP、ETL_GROUPおよびOTHER_GROUPSが含まれています。この例は、1つのアプリケーションまたはコンシューマ・グループですべての使用可能なパラレル実行サーバーを使用しないことが確実である場合のディレクティブ属性の使用例を示しています。

表27-4 パラレル・ステートメント・ディレクティブが設定されたリソース・プラン

コンシューマ・グループ レベル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が返されます。

関連項目:

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

27.7.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の有効化とプランの切替え」を参照)。

このプランの他のリソース・コンシューマ・グループとサブプランについては、表27-5および表27-6を参照してください。

親トピック: 各種の方法を組み合せたOracle Database Resource Managerの例

27.8 単一サーバーにおける複数のデータベース・インスタンスの管理

Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。

  • インスタンス・ケージングについて
    各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。
  • インスタンス・ケージングの有効化
    CPUディレクティブでリソース・プランを作成し、CPU_COUNT初期化パラメータを設定することで、インスタンス・ケージングの使用を有効にできます。

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

27.8.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を使用できます。

親トピック: 単一サーバーにおける複数のデータベース・インスタンスの管理

27.8.2 インスタンス・ケージングの有効化

CPUディレクティブでリソース・プランを作成し、CPU_COUNT初期化パラメータを設定することで、インスタンス・ケージングの使用を有効にできます。

インスタンス・ケージングを有効化するには、サーバー上の各インスタンスに対して次の処理を実行します。

  1. リソース・プランを割り当てることでリソース・マネージャを有効化し、MGMT_P1からMGMT_P8のパラメータを使用してリソース・プランにCPUディレクティブがあるようにします。

    手順については、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。

  2. cpu_count初期化パラメータを設定します。

    これは動的パラメータであり、次の文を使用して設定できます。

    ALTER SYSTEM SET CPU_COUNT = 4;

親トピック: 単一サーバーにおける複数のデータベース・インスタンスの管理

27.9 コンシューマ・グループ、プランおよびディレクティブのメンテナンス

Oracle Database Resource Manager (リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスできます。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。

関連項目:

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

27.9.1 コンシューマ・グループの更新

コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。

コンシューマ・グループを更新するには:

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

  2. UPDATE_CONSUMER_GROUPプロシージャを実行します。

    引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。

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

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

27.9.2 コンシューマ・グループの削除

DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。

コンシューマ・グループを削除するには:

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

  2. DELETE_CONSUMER_GROUPプロシージャを実行します。

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

コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてOTHER_GROUPSが割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはOTHER_GROUPSに切り替わります。

リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

27.9.3 プランの更新

プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。

プランを更新するには:

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

  2. UPDATE_PLANプロシージャを実行します。たとえば、次のスクリプトは、COMMENTパラメータを更新するPL/SQLブロックです。 

    BEGIN
  DBMS_RESOURCE_MANAGER.UPDATE_PLAN(
   PLAN => 'DAYTIME',
   NEW_COMMENT => '50% more resources for OLTP applications');
END;
/

    引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。

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

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

27.9.4 プランの削除

DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。

計画を削除するには:

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

  2. 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はロールバックされ、プランは変更されません。

    現在アクティブなプランは削除できません。

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

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

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

プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。

リソース・プラン・ディレクティブを更新するには:

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

  2. 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プロシージャの引数を指定しない場合、ディレクティブ内の対応パラメータは変更されません。

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

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

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

リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。

リソース・プラン・ディレクティブを削除するには:

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

  2. DELETE_PLAN_DIRECTIVEプロシージャを実行します。

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

関連トピック

親トピック: コンシューマ・グループ、プランおよびディレクティブのメンテナンス

27.10 データベース・リソース・マネージャの構成とステータスの表示

Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。

関連項目:

すべての静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

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

27.10.1 ユーザーまたはロールに権限付与されたコンシューマ・グループの表示

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パッケージを使用してこれらのグループに切り替える機能がすでに付与されています。

親トピック: データベース・リソース・マネージャの構成とステータスの表示

27.10.2 プラン情報の表示

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...
.
.
.

親トピック: データベース・リソース・マネージャの構成とステータスの表示

27.10.3 セッションの現行コンシューマ・グループの表示

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
   ...

親トピック: データベース・リソース・マネージャの構成とステータスの表示

27.10.4 現在アクティブなプランの表示

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

親トピック: データベース・リソース・マネージャの構成とステータスの表示

27.11 Oracle Database Resource Managerの監視

動的パフォーマンス・ビューのセットにより、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列に、パラレル・ステートメント・キューイングが有効であるかどうかが表示されます。

関連項目:

『Oracle Databaseリファレンス』

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ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

『Oracle Databaseリファレンス』

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ビューに格納されます。

関連項目:

『Oracle Databaseリファレンス』

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ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

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ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

『Oracle Databaseリファレンス』

V$RSRCMGRMETRIC_HISTORY

V$RSRCMGRMETRIC_HISTORYの各列は、V$RSRCMGRMETRICと同じビューです。これらのビューの唯一の違いは、V$RSRCMGRMETRICには過去1分間のみのメトリックが含まれているのに対して、V$RSRCMGRMETRIC_HISTORYには過去60分間のメトリックが含まれていることです。

注意:

STATISTICS_LEVEL初期化パラメータがALLまたはTYPICALに設定されている場合、V$RSRCMGRMETRIC_HISTORYビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。

関連項目:

『Oracle Databaseリファレンス』

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

27.12 オペレーティング・システムのリソース制御との相互作用

多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。たとえば、HP社のProcess Resource Managerや、Solaris Containers、ZonesおよびResource Poolsなどがあります。

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

27.12.1 オペレーティング・システムのリソース制御を使用するためのガイドライン

オペレーティング・システムのリソース制御を使用する場合は、ガイドラインに従います。

オペレーティング・システムによるリソース制御をOracle Databaseと併用する場合は、次のガイドラインに従って慎重に使用する必要があります。

  • 1つのノードに複数のインスタンスがあり、それらの間でリソースを配分する場合は、各インスタンスを専用のオペレーティング・システム・リソース・マネージャ・グループまたは管理対象エンティティに割り当てる必要があります。管理対象エンティティの複数のインスタンスを実行するには、インスタンス・ケージングを使用して管理対象エンティティ内のCPUリソースをインスタンス間で配分する方法を管理します。Oracle Database Resource Managerは、CPUリソースを管理するときに、各インスタンスに対するCPUリソースが一定量であると予測します。インスタンス・ケージングを使用しない場合は、使用可能なCPUリソースは管理対象エンティティ内のCPUの数と同じであると予測します。インスタンス・ケージングを使用する場合、使用可能なCPUリソースはCPU_COUNT初期化パラメータの値と同じであると予測します。CPUリソースが想定よりも少ない場合、Oracle Database Resource Managerはリソース・プランでのリソース割当ての強制が有効になりません。インスタンス・ケージングの詳細は、「単一サーバーにおける複数のデータベース・インスタンスの管理」を参照してください。

  • インスタンスのすべてのプロセスを実行している専用エンティティが、1つの優先度(リソース使用)レベルで実行されている必要があります。

  • 専用エンティティに割り当てたCPUリソースは、数分に1回の割合を超える頻度では変更できません。

    オペレーティング・システムのリソース・マネージャによって、Oracleインスタンスに割り当てられているCPUリソースが急激に変更された場合、Oracle Database Resource ManagerがCPUリソースを効果的に管理できないことがあります。特に、Oracleインスタンスに割り当てられているCPUリソースが2、3分未満の間隔で頻繁に変更されると、Oracleでは2、3分ごとにしかこのような変更をチェックしないため、Oracleで観測されない可能性があります。このような場合、Oracle Database Resource Managerで、実際の使用可能量より多くのCPUリソースが使用できると判断されて多すぎるプロセスがスケジュールされたり、実際の使用可能量より少ないCPUリソースしか使用できないと判断されて少なすぎるプロセスがスケジュールされる可能性があります。多すぎるプロセスがスケジュールされた場合、UTILIZATION_LIMITディレクティブを超えてしまい、CPUディレクティブが正しく規定されない可能性があります。少なすぎるプロセスがスケジュールされた場合、Oracleインスタンスによってサーバーのリソースが十分に使用されない可能性があります。

  • プロセスの優先度管理が使用禁止になっている必要があります。

  • 個々のデータベース・プロセスを異なる優先度レベルで管理する機能(例: UNIXプラットフォームでのniceコマンドの使用)は、サポートされていません。インスタンスがクラッシュするなど、重大な結果になる可能性があります。オペレーティング・システムのリソース制御を使用して、Oracle Databaseインスタンスが固定されているメモリーを管理できる場合も、同様に望ましくない結果になることが予想されます。

親トピック: オペレーティング・システムのリソース制御との相互作用

27.13 Oracle Database Resource Managerの参照情報

リソース・マネージャには、事前定義済のリソース・プラン、コンシューマ・グループおよびコンシューマ・グループ・マッピング・ルールが含まれます。リソース・マネージャ構成に関する情報をデータ・ディクショナリ・ビューに問い合せることができます。

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

27.13.1 事前定義のリソース・プランおよびコンシューマ・グループ

Oracle Databaseには、事前定義のリソース・プランが含まれます。

各Oracle Databaseに事前定義されているリソース・プランを表27-5にリストし、リソース・コンシューマ・グループを表27-6にリストします。ビューDBA_RSRC_PLANSおよびDBA_RSRC_CONSUMER_GROUPSを問い合せることによって、これらの内容を確認できます。

次の問合せにより、プラン例DSS_PLANでのCPU割当てが表示されます。 

SELECT group_or_subplan, mgmt_p1, mgmt_p2, mgmt_p3, mgmt_p4 
   FROM dba_rsrc_plan_directives WHERE plan = 'DSS_PLAN';
 
GROUP_OR_SUBPLAN                  MGMT_P1    MGMT_P2    MGMT_P3    MGMT_P4
------------------------------ ---------- ---------- ---------- ----------
SYS_GROUP                              75          0          0          0
DSS_CRITICAL_GROUP                     18          0          0          0
DSS_GROUP                               3          0          0          0
ETL_GROUP                               1          0          0          0
BATCH_GROUP                             1          0          0          0
ORA$AUTOTASK                            1          0          0          0
OTHER_GROUPS                            1          0          0          0

表27-5 事前定義のリソース・プラン

リソース・プラン 説明

DEFAULT_MAINTENANCE_PLAN

メンテナンス・ウィンドウのデフォルト・プラン。このプランの詳細は、「自動化メンテナンス・タスクに対するリソース割当てについて」を参照してください。メンテナンス・ウィンドウはOracle Schedulerの通常のウィンドウであるため、必要に応じて、それらに関連付けられているリソース・プランを変更できます。メンテナンス・ウィンドウのリソース・プランを変更する場合は、サブプランORA$AUTOTASKが新しいプランに含まれていることを確認してください。

DEFAULT_PLAN

SYS_GROUP操作の優先度を設定し、自動化メンテナンス操作と診断操作に最小限のリソースを割り当てる基本のデフォルト・プラン。

DSS_PLAN

重要ではないDSS問合せやETL操作よりも重要なDSS問合せを優先させるデータ・ウェアハウス・プランの例。

ETL_CRITICAL_PLAN

DSS問合せよりもETL操作を優先させるデータ・ウェアハウス・プランの例。

INTERNAL_PLAN

リソース・マネージャの無効化用。内部使用のみに対応しています。

INTERNAL_QUIESCE

データベースの静止用。このプランは直接アクティブ化できません。アクティブ化するにはQUIESCEコマンドを使用します。

MIXED_WORKLOAD_PLAN

バッチ操作よりも対話型操作を優先させる複合ワークロード・プランの例。詳細は、「オラクル社が提供する複合ワークロード・プラン」を参照してください。

表27-6 事前定義のリソース・コンシューマ・グループ

リソース・コンシューマ・グループ 説明

BATCH_GROUP

バッチ操作用のコンシューマ・グループ。プラン例MIXED_WORKLOAD_PLANによって参照されます。

DSS_CRITICAL_GROUP

重要なDSS問合せ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

DSS_GROUP

重要ではないDSS問合せ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

ETL_GROUP

ETLジョブ用のコンシューマ・グループ。プラン例DSS_PLANおよびETL_CRITICAL_PLANによって参照されます。

INTERACTIVE_GROUP

対話型OLTP操作用のコンシューマ・グループ。プラン例MIXED_WORKLOAD_PLANによって参照されます。

LOW_GROUP

優先度が低いセッション用のコンシューマ・グループ。

ORA$AUTOTASK

メンテナンス・タスク用のコンシューマ・グループ。

OTHER_GROUPS

明示的な初期コンシューマ・グループを持たないすべてのセッションのデフォルトのコンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールによってコンシューマ・グループにマップされないか、現在アクティブなリソース・プラン内にないコンシューマ・グループにマップされます。

OTHER_GROUPSは、すべてのプランで指定されているリソース・プラン・ディレクティブを保持する必要があります。これをマッピング・ルールによって明示的にセッションに割り当てることはできません。

SYS_GROUP

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

親トピック: Oracle Database Resource Managerの参照情報

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

Oracle Databaseには、事前定義済のコンシューマ・グループ・マッピング・ルールが含まれます。

表27-7に、Oracle Databaseで事前定義されているコンシューマ・グループ・マッピング・ルールの要約を示します。ビューDBA_RSRC_GROUP_MAPPINGSを問い合せることで、これらのルールを確認できます。DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらのマッピング・ルールを変更または削除できます。

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

属性 値 マップされるコンシューマ・グループ 注意

ORACLE_USER

SYS

SYS_GROUP

ORACLE_USER

SYSTEM

SYS_GROUP

ORACLE_FUNCTION

BACKUP

BATCH_GROUP

セッションでは、RMANによるバックアップ操作が実行されます。操作が開始すると、セッションは自動的にBATCH_GROUPに切り替えられます。

ORACLE_FUNCTION

COPY

BATCH_GROUP

セッションでは、RMANによるコピー操作が実行されます。操作が開始すると、セッションは自動的にBATCH_GROUPに切り替えられます。

ORACLE_FUNCTION

DATALOAD

ETL_GROUP

セッションでは、データ・ポンプによるデータ・ロード操作が実行されます。操作が開始すると、セッションは自動的にETL_GROUPに切り替えられます。

関連項目:

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

親トピック: Oracle Database Resource Managerの参照情報

27.13.3 リソース・マネージャのデータ・ディクショナリ・ビュー

データ・ディクショナリ・ビューのセットに対してデータベース・リソース管理に関する情報を問い合せることができます。

表27-8に、リソース・マネージャに関連付けられているビューをリストします。

表27-8 リソース・マネージャのデータ・ディクショナリ・ビュー

ビュー 説明

DBA_RSRC_CONSUMER_GROUP_PRIVS

USER_RSRC_CONSUMER_GROUP_PRIVS

DBAビューには、すべてのリソース・コンシューマ・グループと、それが付与されているユーザーおよびロールがリストされます。USERビューには、ユーザーに付与されたすべてのリソース・コンシューマ・グループがリストされます。

DBA_RSRC_CONSUMER_GROUPS

データベースに存在するすべてのリソース・コンシューマ・グループがリストされます。

DBA_RSRC_MANAGER_SYSTEM_PRIVS

USER_RSRC_MANAGER_SYSTEM_PRIVS

DBAビューには、リソース・マネージャのシステム権限が付与されているユーザーとロールがすべてリストされます。USERビューには、DBMS_RESOURCE_MANAGERパッケージのシステム権限が付与されているユーザーがすべてリストされます。

DBA_RSRC_PLAN_DIRECTIVES

データベースに存在するすべてのリソース・プラン・ディレクティブがリストされます。

DBA_RSRC_PLANS

データベースに存在するすべてのリソース・プランがリストされます。

DBA_RSRC_GROUP_MAPPINGS

すべてのセッション属性に対する様々なマッピングのペアがすべてリストされます。

DBA_RSRC_MAPPING_PRIORITY

各属性の現在のマッピング優先度がリストされます。

DBA_HIST_RSRC_PLAN

リソース・プランのアクティブ化に関する履歴情報が表示されます。このビューには、V$RSRC_PLAN_HISTORYのAWRスナップショットが含まれています。

DBA_HIST_RSRC_CONSUMER_GROUP

コンシューマ・グループに関する履歴統計情報が表示されます。このビューには、V$RSRC_CONS_GROUP_HISTORYのAWRスナップショットが含まれています。

DBA_USERS

USER_USERS

DBAビューには、データベースのすべてのユーザーに関する情報が含まれます。これには、各ユーザーの初期リソース・コンシューマ・グループが含まれます。USERビューには、現行ユーザーに関する情報が含まれます。これには、現行ユーザーの初期リソース・コンシューマ・グループが含まれます。

V$RSRC_CONS_GROUP_HISTORY

V$RSRC_PLAN_HISTORYビューの各エントリについて、プランの各コンシューマ・グループに対応するエントリが含まれており、コンシューマ・グループの累積統計が表示されます。

V$RSRC_CONSUMER_GROUP

アクティブなリソース・コンシューマ・グループに関する情報が表示されます。このビューは、チューニングに使用できます。

V$RSRCMGRMETRIC

過去1分間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに表示されます。

V$RSRCMGRMETRIC_HISTORY

過去1時間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに分単位で表示されます。新しいリソース・プランが有効な場合、履歴はクリアされます。

V$RSRC_PLAN

現在のアクティブ・リソース・プランの名前がすべて表示されます。

V$RSRC_PLAN_HISTORY

そのインスタンスでリソース・マネージャのプランがいつ有効または無効になったかが表示されます。時間の経過とともに、どのようにリソースがコンシューマ・グループ間で共有されていたかを理解するのに役立ちます。

V$RSRC_SESSION_INFO

各セッションについてリソース・マネージャの統計が表示されます。リソース・マネージャによるセッションへの影響が表示されます。チューニングに使用できます。

V$SESSION

現行セッションごとにセッション情報が表示されます。その中には、各現行セッションのリソース・コンシューマ・グループの名前が含まれます。

親トピック: Oracle Database Resource Managerの参照情報