27 Oracle Database Resource Managerを使用したリソースの管理
Oracle Database Resource Manager(リソース・マネージャ)を使用して、データベースのリソース割当てを管理できます。
ノート:
この章では、PL/SQLパッケージ・プロシージャを使用してリソース・マネージャを管理する方法について説明します。リソース・マネージャをより簡単に管理するには、Oracle Enterprise Manager Cloud Control (Cloud Control)のグラフィカル・ユーザー・インタフェースを使用します。Cloud Controlを使用したリソース・マネージャの管理の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
Cloud Controlでリソース・マネージャを使用するには:
-
データベース・ホームページにアクセスします。
-
「管理」メニューから、「リソース・マネージャ」を選択します。
- 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 (リソース・マネージャ)を使用すると、システム・リソースやデータベース・リソースを求めて競合するデータベース内の複数のワークロードを管理できます。
- リソース・マネージャが提供するワークロード管理のソリューション
リソース・マネージャでは、データベースがハードウェア・リソースの割当て方法をより詳細に制御できます。 - リソース・マネージャの要素
リソース・マネージャには、管理できる複数の要素が含まれます。 - リソース・マネージャの管理権限について
リソース・マネージャを管理するために必要な権限を持っている必要があります。
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の割合に制限があるコンシューマ・グループに切り替えます。システム・リソースの過剰な消費により終了したSQL文は隔離されます。つまり、後続の実行中にコンパイル・エラーが発生することにより、それらの再実行は許可されません。
論理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の概要」を参照してください。
27.1.2 リソース・マネージャの要素
リソース・マネージャには、管理できる複数の要素が含まれます。
- リソース・マネージャの要素について
リソース・マネージャの要素には、リソース・コンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブが含まれます。 - リソース・コンシューマ・グループについて
リソース・コンシューマ・グループ(コンシューマ・グループ)とは、処理要件に基づいてグループ化されたユーザー・セッションの集合です。 - リソース・プラン・ディレクティブについて
リソース・マネージャは、現在アクティブなリソース・プランに属するリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースをコンシューマ・グループに割り当てます。 - リソース・プランについて
リソース・プランは、リソース・コンシューマ・グループへのリソースの割当て方法を指定するディレクティブのコンテナです。 - 例: 単純なリソース・プラン
単純なリソース・プランの例を示します。 - サブプランについて
リソース・プラン・ディレクティブ(ディレクティブ)は、コンシューマ・グループを参照するかわりに、別のリソース・プランを参照できます。この場合、そのプランはサブプランと呼ばれます。 - 例: サブプランを含むリソース・プラン
サブプランを含むリソース・プランの例を示します。
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%を使用できます。
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の比率を、プラン、サブプランおよびコンシューマ・グループ間を結ぶ線に沿って表示しています。
この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パッケージを使用します。次の表に、関連するパッケージ・プロシージャの一覧を示します。
プロシージャ | 説明 |
---|---|
|
ユーザーまたはロールに、 |
|
ユーザーまたはロールから、 |
次のPL/SQLブロックは、ユーザーHR
に管理権限を付与しますが、HR
にADMIN
オプションは付与しません。そのため、HR
はDBMS_RESOURCE_MANAGER
パッケージのすべてのプロシージャを実行できますが、HR
はGRANT_SYSTEM_PRIVILEGE
プロシージャを使用して他のユーザーに管理権限を付与することはできません。
BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( GRANTEE_NAME => 'HR', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER', ADMIN_OPTION => FALSE); END; /
この権限は、REVOKE_SYSTEM_PRIVILEGE
プロシージャを使用して取り消すことができます。
ノート:
ADMINISTER_RESOURCE_MANAGER
システム権限の付与または取消しは、DBMS_RESOURCE_MANAGER_PRIVS
パッケージを使用する場合のみ行うことができます。SQLのGRANT
文またはREVOKE
文によって、付与したり取り消すことはできません。
関連項目:
-
DBMS_RESOURCE_MANAGER
パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 -
DBMS_RESOURCE_MANAGER_PRIVS
パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 -
ADMIN
オプションの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください
27.2 リソース・コンシューマ・グループへのセッションの割当て
データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法があります。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager(リソース・マネージャ)では、そのセッションに対するリソース割当てが管理の対象となります。
ノート:
コンシューマ・グループに割り当てられていないセッションは、コンシューマ・グループOTHER_GROUPS
に配置されます。
- リソース・コンシューマ・グループへのセッション割当ての概要
リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。 - 初期リソース・コンシューマ・グループの割当て
セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。 - コンシューマ・グループへのセッションのマッピング・ルールの指定
コンシューマ・グループへのセッションのマッピング・ルールを作成し、優先順位を付けることができます。 - リソース・コンシューマ・グループの切替え
セッションのリソース・コンシューマ・グループを切り替えることができます。 - コンシューマ・グループの自動切替えの指定
特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。 - スイッチ特権の付与と取消し
ユーザーまたはアプリケーションがセッションを指定されたリソース・コンシューマ・グループに切り替えるには、スイッチ特権が必要です。
27.2.1 リソース・コンシューマ・グループへのセッション割当ての概要
リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。
これを行うために、マッピング・ルールを作成すると、セッションの起動時に、セッション属性に基づいてリソース・マネージャによって自動的に各セッションがコンシューマ・グループに割り当てられるようにすることができます。セッションがその初期コンシューマ・グループに割り当てられ実行された後は、プロシージャをコールして、セッションを別のコンシューマ・グループに手動で切り替えることができます。この操作は、リソースを過剰に使用しているセッションを、よりリソース割当ての制限されたコンシューマ・グループに移動する必要がある場合などに実行します。また、ユーザーおよびアプリケーションにスイッチ特権を付与して、ユーザーおよびアプリケーションが、あるコンシューマ・グループから別のコンシューマ・グループに自分のセッションを切り替えることができるようにすることができます。
セッション属性に変更がある場合やセッションが指定のリソース使用制限を超える場合は、あるコンシューマ・グループから別の(通常は優先度の低い)コンシューマ・グループにセッションを自動的に切り替えることもできます。
親トピック: リソース・コンシューマ・グループへのセッションの割当て
27.2.2 初期リソース・コンシューマ・グループの割当て
セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。
マッピング・ルールの構成方法は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。
親トピック: リソース・コンシューマ・グループへのセッションの割当て
27.2.3 コンシューマ・グループへのセッションのマッピング・ルールの指定
コンシューマ・グループへのセッションのマッピング・ルールを作成し、優先順位を付けることができます。
- コンシューマ・グループへのセッションのマッピング・ルールについて
セッションの初期コンシューマ・グループを指定し、セッション属性が変更された場合に別のコンシューマ・グループにセッションを動的に切り替えることができます。 - コンシューマ・グループのマッピング・ルールの作成
セッション属性と値のペアをコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPING
プロシージャを使用します。 - コンシューマ・グループのマッピング・ルールの変更と削除
コンシューマ・グループ・マッピング・ルールを変更するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPING
プロシージャを実行し、新しいコンシューマ・グループを指定します。 - マッピング・ルールの優先度の作成
競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。
親トピック: リソース・コンシューマ・グループへのセッションの割当て
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
には、次のいずれかを指定できます。
属性 | タイプ | 説明 |
---|---|---|
|
ログイン |
Oracle Databaseユーザー名。 |
|
ログイン |
クライアントが接続の確立に使用したデータベース・サービス名。 |
|
ログイン |
ログインしているクライアントのオペレーティング・システム・ユーザー名。 |
|
ログイン |
サーバーへのログインに使用されたクライアント・プログラム名。 |
|
ログイン |
クライアントが接続に使用しているコンピュータ名。 |
|
ログイン |
セッションのクライアント識別子 クライアント識別子のセッション属性は、 |
|
ランタイム |
|
|
ランタイム |
次のプロシージャのいずれかによる設定、またはそれに相当するOCI属性の設定に従って実行されている現行モジュールと処理の組合せ。
この属性にはモジュール名を指定し、その後ろにピリオド(.)および処理名を順に続けます( |
|
ランタイム |
|
|
ランタイム |
|
|
ランタイム |
RMANまたはデータ・ポンプ操作。有効な値は |
たとえば、次の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
を問い合せます。
関連項目:
-
DBMS_APPLICATION_INFO.SET_MODULE
プロシージャによるモジュール名の設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
27.2.4 リソース・コンシューマ・グループの切替え
セッションのリソース・コンシューマ・グループを切り替えることができます。
- 手動によるリソース・コンシューマ・グループの切替え
実行中のセッションのリソース・コンシューマ・グループを変更できます。 - ユーザーまたはアプリケーションに対する手動によるコンシューマ・グループの切替えの有効化
管理者は、ユーザーがDBMS_SESSION
パッケージのSWITCH_CURRENT_CONSUMER_GROUP
プロシージャを使用して、現在のコンシューマ・グループを切り替えられるように、スイッチ特権をユーザーに付与できます。
親トピック: リソース・コンシューマ・グループへのセッションの割当て
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
プロシージャは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。このプロシージャを使用すると、セッションの優先度を実質的に変更できます。
SWITCH_CONSUMER_GROUP_FOR_SESS
プロシージャは、Oracle Real Application Clusters (Oracle RAC)インスタンス固有です。切り替えるセッションが実行されているのと同じOracle RACインスタンスのプラガブル・データベースに接続してから、このプロシージャを実行する必要があります。
次の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
プロシージャを使用して、スイッチ特権があるコンシューマ・グループにのみ切り替えることができます。他のプロシージャからこのプロシージャがコールされた場合、ユーザーはコール側のプロシージャの所有者がスイッチ特権を持っているコンシューマ・グループに切り替えることができます。
このプロシージャのパラメータは、次のとおりです。
パラメータ | 説明 |
---|---|
|
切替え先のコンシューマ・グループ。 |
|
切替え元のコンシューマ・グループの名前が戻ります。このパラメータは、後で元のコンシューマ・グループに再び切り替えるときに使用できます。 |
|
切替えエラー発生時の動作を制御します。
|
次のSQL*Plusセッションは、新しいコンシューマ・グループへの切替え方法を示しています。出力パラメータold_group
の値が出力されているため、変更前のコンシューマ・グループ名がどのように保存されているかがわかります。
SET serveroutput on DECLARE old_group varchar2(30); BEGIN DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('BATCH_GROUP', old_group, FALSE); DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group); END; /
次の行が出力されます。
OLD GROUP = OLTP_GROUP
リソース・マネージャでは、セッションをすでに配置されているコンシューマ・グループに切り替えるためにSWITCH_CURRENT_CONSUMER_GROUP
プロシージャがコールされている場合でも、切替えが発生したとみなされます。
ノート:
リソース・マネージャは、一般的なデータベース・ユーザー名を使用してアプリケーションにログインしている環境でも機能します。DBMS_SESSION
パッケージは、セッションの開始時、または特定のモジュールがコールされたときにセッションのコンシューマ・グループ割当てを切り替えるために使用できます。
関連項目:
-
DBMS_SESSION
パッケージのその他の例と詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: リソース・コンシューマ・グループの切替え
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; /
関連項目:
-
論理I/Oの詳細は、「リソース・マネージャが提供するワークロード管理のソリューション」を参照してください
親トピック: コンシューマ・グループの自動切替えの指定
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
にスイッチ特権を付与したり取り消すことができます。スイッチ特権を使用すると、ユーザーまたはアプリケーションが、指定されているリソース・コンシューマ・グループにセッションを切り替えることができるようになります。
このパッケージでは、スイッチ特権を取り消すこともできます。次の表に、関連するパッケージ・プロシージャの一覧を示します。
プロシージャ | 説明 |
---|---|
|
ユーザー、ロールまたは |
|
ユーザー、ロールまたは |
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合計量を制御します。 - アイドル時間制限
セッションがアイドル状態のままでいられる時間(セッションが終了されるまでの時間)を指定できます。
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_P
n
(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割当て |
---|---|---|---|
|
80% |
||
|
50% |
||
|
50% |
||
|
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割当て | 使用率制限 |
---|---|---|---|---|
|
80% |
|||
|
50% |
75% |
||
|
50% |
50% |
||
|
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
属性が単一のインスタンスではなくクラスタ全体に適用されます。
- パラレル・サーバー制限を使用したパラレル・ステートメント・キューイングの管理
PARALLEL_SERVER_LIMIT
属性を使用すると、いつコンシューマ・グループからパラレル・ステートメントをキューできるかを指定できます。Oracle Databaseには、コンシューマ・グループごとにパラレル・ステートメント・キューが保持されます。
関連項目:
-
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
親トピック: パラレル実行サーバー
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
ノート:
すべてのセッションでパラレル実行サーバーの使用状況が監視されますが、設定したパラレル実行サーバー・ディレクティブ属性は、パラレル・ステートメント・キューイングが有効になっている(PARALLEL_DEGREE_POLICY
がAUTO
に設定されている)セッションにのみ影響を与えます。セッションのPARALLEL_DEGREE_POLICY
がMANUAL
に設定されている場合、このセッションからのパラレル・ステートメントはキューされません。ただし、このようなセッションで使用されているパラレル実行サーバーは、PARALLEL_SERVER_LIMIT
の制限の決定に使用されるカウントに数えられます。この制限を超えても、このセッションからのパラレル・ステートメントはキューされません。
関連項目:
親トピック: パラレル・サーバー制限
27.3.3.3 パラレル・キューのタイムアウト
PARALLEL_QUEUE_TIMEOUT
ディレクティブ属性を使用すると、パラレル・ステートメントがパラレル・ステートメント・キュー内でタイムアウトになるまで待機する最大時間を秒単位で指定できます。
パラレル・ステートメント・キューイングを使用すると、データベースにパラレル・ステートメントを実行するほどのリソースがない場合、そのステートメントは必要なリソースが使用可能になるまでキューで待機します。ただし、パラレル・ステートメントが意図した時間よりも長くパラレル・ステートメント・キューで待機する場合があります。このような状況を回避するには、パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を指定します。
PARALLEL_QUEUE_TIMEOUT
属性は、コンシューマ・グループごとに設定できます。この属性は、リソース・プランの他の管理属性(MGMT_P1
、MGMT_P2
など)を指定していなくても適用できます。
関連項目:
パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
ノート:
パラレル・ステートメント・キューはクラスタ全体で機能するため、パラレル・ステートメント・キューに関連するすべてのディレクティブもクラスタ全体で機能します。
タイムアウトになったパラレル文の処理方法は、コンシューマ・グループごとにPQ_TIMEOUT_ACTION
属性を設定することで制御できます。この属性は、次の値に設定できます。
-
CANCEL
- 文の実行はエラーORA-07454
で終了します。これは、タイムアウトになったパラレル文のデフォルトの動作です。 -
RUN
- 文は即時実行されます。文を即時実行するためのパラレル・サーバーが不足している場合は、並列度を下げて実行するように文がダウングレードされます。
関連項目:
すべてのパラレル実行サーバー・ディレクティブ属性を組み合せて使用する方法の詳細は、「ディレクティブ属性を使用したパラレル・ステートメントの管理の例」を参照してください
親トピック: パラレル実行サーバー
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値 |
---|---|
|
20 |
|
10 |
|
Null (制限なし) |
|
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)以降では、リソース・マネージャは特定のコンシューマ・グループ内の各セッションに割り当てることのできるPGAメモリーの量を制限できます。
- コンシューマ・グループの自動切替え
指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。 - SQLの取消しとセッションの終了
リソース・マネージャを使用すると、CPUとI/Oなどのシステム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了することができます。 - 実行時間制限
ある操作に許可される最大の実行時間を指定できます。
関連項目:
プログラム・グローバル領域(PGA)親トピック: リソース・マネージャによって管理されるリソースのタイプ
27.3.5.1 コンシューマ・グループの自動切替え
指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。
通常、この方法は、グループ内の典型的なセッションに対するリソース使用予測を上回ったセッションを、優先度の高いコンシューマ・グループ(システム・リソースを高い比率で使用するグループ)から優先度の低いコンシューマ・グループに切り替えるために使用します。
詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。
親トピック: リソース集中型の問合せ
27.3.5.2 SQLの取消しとセッションの終了
リソース・マネージャを使用すると、CPUとI/Oなどのシステム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了することができます。
リソース・マネージャによって取り消されたSQL問合せは、DBMS_SQLQ
パッケージのサブプログラムを使用することで、それらの問合せを再実行できないように隔離を構成できます。
関連項目:
-
システム・リソースの消費に基づいてSQL問合せの取消しまたはセッションの終了を行うためのリソース・マネージャの構成方法の詳細は、リソース制限の設定による自動切替えの指定を参照してください。
-
DBMS_SQLQ
パッケージのサブプログラムを使用して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
プロシージャには、次の引数を指定します。
パラメータ | 説明 |
---|---|
|
計画の名前。 |
|
1番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
2番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
3番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
4番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
5番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
6番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
7番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
|
8番目のグループのコンシューマ・グループ名 |
|
このグループに割り当てるCPUリソース |
このプロシージャでは、最大8個のコンシューマ・グループを指定できます。サポート対象のリソース割当て方法は、CPUによる方法のみです。プランでは、EMPHASIS
CPU割当てポリシー(デフォルト)が使用され、各コンシューマ・グループでは、ROUND_ROBIN
スケジューリング・ポリシー(これもデフォルト)が使用されます。
例: 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;
/
SELECT plan, group_or_subplan, mgmt_p1
FROM dba_rsrc_plan_directives
WHERE plan = 'SIMPLE_PLAN1';
非マルチテナント環境で作成されたプランは次のとおりです:PLAN GROUP_OR_SUBPLAN MGMT_P1
-------------------- -------------------- ----------
SIMPLE_PLAN1 MYGROUP1 80
SIMPLE_PLAN1 MYGROUP2 20
SIMPLE_PLAN1 SYS_GROUP 50
SIMPLE_PLAN1 OTHER_GROUPS 5
PLAN GROUP_OR_SUBPLAN MGMT_P1
-------------------- -------------------- ----------
SIMPLE_PLAN1 MYGROUP1 80
SIMPLE_PLAN1 MYGROUP2 20
SIMPLE_PLAN1 OTHER_GROUPS 5
関連項目:
-
EMPHASIS
CPU割当てポリシーの詳細は、「リソース・プランの作成」を参照してください -
ROUND_ROBIN
スケジューリング・ポリシーの詳細は、「リソース・コンシューマ・グループの作成」を参照してください
27.5 複雑なリソース・プランの作成
複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。
複雑なリソース・プランの作成に必要なステップの概要は、次のとおりです。
ノート:
複雑なリソース・プランとは、DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN
プロシージャでは作成できないリソース・プランを指します。
ステップ1: ペンディング・エリアを作成します。
ステップ2: コンシューマ・グループを作成、変更または削除します。
ステップ3: コンシューマ・グループにセッションをマップします。
ステップ4: リソース・プランを作成します。
ステップ5: リソース・プラン・ディレクティブを作成します。
ステップ6: ペンディング・エリアの妥当性をチェックします。
ステップ7: ペンディング・エリアを発行します。
これらのステップは、DBMS_RESOURCE_MANAGER
PL/SQLパッケージのプロシージャを使用して完了します。
- ペンディング・エリアについて
ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。 - ペンディング・エリアの作成
ペンディング・エリアはCREATE_PENDING_AREA
プロシージャを使用して作成します。 - リソース・コンシューマ・グループの作成
リソース・コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUP
プロシージャを使用します。 - コンシューマ・グループへのセッションのマッピング
SET_CONSUMER_GROUP_MAPPING
プロシージャを使用して、コンシューマ・グループにセッションをマップできます。 - リソース・プランの作成
リソース・プランを作成するには、CREATE_PLAN
プロシージャを使用します。 - リソース・プラン・ディレクティブの作成
リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVE
プロシージャを使用します。各ディレクティブはプランまたはサブプランに属しており、リソースをコンシューマ・グループまたはサブプランに割り当てます。 - ペンディング・エリアの妥当性チェック
ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREA
をコールして、そのペンディング・エリアの妥当性を確認できます。 - ペンディング・エリアの発行
変更の妥当性チェックを完了した後は、SUBMIT_PENDING_AREA
プロシージャをコールして変更内容をアクティブにします。 - ペンディング・エリアのクリア
CLEAR_PENDING_AREA
プロシージャを使用して、ペンディング・エリアをいつでもクリアできます。
関連項目:
-
DBMS_RESOURCE_MANAGER
PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
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
プロシージャを使用します。
次のパラメータを指定できます。
パラメータ | 説明 |
---|---|
|
コンシューマ・グループに割り当てる名前。 |
|
任意のコメント。 |
|
非推奨。 |
|
コンシューマ・グループのセッション間でCPUを分配するためのリソース割当て方法。デフォルトは |
例: リソース・コンシューマ・グループの作成
次のスクリプトは、グループ内のセッションにリソースを割り当てるデフォルトの方法(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
プロシージャを使用して、コンシューマ・グループにセッションをマップできます。
次のパラメータを指定できます。
パラメータ | 説明 |
---|---|
|
パッケージ定数として指定されているセッション属性タイプ。 |
|
属性の値 |
|
コンシューマ・グループの名前。 |
例: コンシューマ・グループへのセッションのマップ
次のスクリプトは、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つのパラメータは必須です。他のパラメータはオプションです。
パラメータ | 説明 |
---|---|
|
グループに割り当てる名前。 |
|
任意の内容を表現するコメント。 |
|
非推奨。 |
|
アクティブ・セッション・プールのリソース割当て方法。デフォルトの |
|
デフォルトは |
|
キューイングのリソース割当て方法。キュー内の非アクティブ・セッションをキューから削除し、アクティブ・セッション・プールに追加する順序を制御します。デフォルトは |
|
各コンシューマ・グループまたは各サブプランが取得するCPUの量を指定するためのリソース割当て方法。デフォルトの方法 |
|
|
例: リソース・プランの作成
次のスクリプトは、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回のみ、特定のコンシューマ・グループを指定することをお薦めします。
次のパラメータを指定できます。
パラメータ | 説明 |
---|---|
|
ディレクティブが属しているリソース・プランの名前。 |
|
リソースを割り当てるコンシューマ・グループまたはサブプランの名前。 |
|
任意のコメント。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
非推奨。 |
|
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を指定します。他のセッションは、非アクティブ・セッション・キューで実行を待機します。デフォルトは |
|
非アクティブ・セッション・キュー内で実行を待機しているセッションがタイムアウトしてコールが終了されるまでの時間を秒数で指定します。デフォルトは |
|
任意の操作の並列度を制限します。デフォルトは |
|
切替え基準が満たされた場合に、セッションの切替え先になるコンシューマ・グループを指定します。 グループ名が グループ名が グループ名が
ノート: |
|
処理が実行されるまでにコールが実行可能な時間をCPU秒数で指定します。デフォルトは |
|
実行時間の見積りはオプティマイザから取得されます。見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。一般的に、統計には±10分未満の誤差があると考えてください。 |
|
コールに許可される最大の実行時間をCPU秒数で指定します。あるコールに対するオプティマイザの見積り実行時間が 見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。 |
|
コンシューマ・グループで生成される、コミットされていないトランザクションのUNDO合計量の最大値をKBで設定します。デフォルトは |
|
セッションの最大アイドル時間を秒数で示します。デフォルトは |
|
ブロックしているセッションの最大アイドル時間を秒数で示します。デフォルトは |
|
非推奨。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
処理が実行される前に、セッションで移動(読取りおよび書込み)できる物理I/Oのサイズ(MB)を指定します。デフォルトは |
|
処理が実行される前にセッションが実行できる物理I/O要求の数を指定します。デフォルトは |
|
|
|
パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を秒単位で指定します。この時間を超えると、タイムアウトします。 |
|
特定のコンシューマ・グループが使用できるパラレル実行サーバー・プールの最大割合を指定します。特定のコンシューマ・グループで使用されているパラレル実行サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル実行サーバーの合計となります。 |
|
コンシューマ・グループに許可する最大CPU使用率を指定します。この値は、すべてのレベルのCPU割当て( |
|
|
|
処理をトリガーする経過時間(秒単位)は、 |
|
マルチテナント・コンテナ・データベース(CDB)内のプラガブル・データベース(PDB)間にリソースを割り当てます。また、PDB内のコンシューマ・グループ間でリソースを割り当てます。 |
|
コンシューマ・グループのパラレル・ステートメントが重要かどうかを指定します。
|
|
特定のコンシューマ・グループ内の各セッションに割り当てることのできる最大PGAメモリーの量をMB単位で指定します。セッションが制限を超えた場合、プロセスは |
例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
初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。
デフォルトでは、次の状況を除き、リソース・マネージャは有効になっていません。
-
この項の後半で説明されている、事前定義済メンテナンス・ウィンドウの間。
-
INMEMORY_SIZE
初期化パラメータを0より大きい値に設定することでOracle Database In-Memoryが有効になっているとき。
テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランがmydb_plan
として設定されます。
RESOURCE_MANAGER_PLAN = mydb_plan
DBMS_RESOURCE_MANAGER.SWITCH_PLAN
パッケージ・プロシージャまたはALTER SYSTEM
文を使用して、リソース・マネージャをアクティブ化(または解除)したり、現行のトップレベル・プランを変更することもできます。
次のSQL文は、トップレベルのプランをmydb_plan
に設定し、リソース・マネージャをアクティブ化します(アクティブ化されていない場合)。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';
指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。
Oracle Schedulerのウィンドウでのリソース・マネージャの自動有効化
リソース・プランを指定するOracle Schedulerのウィンドウがオープン状態の場合、リソース・マネージャは自動的にアクティブ化されます。スケジューラのウィンドウがクローズ状態の場合、そのウィンドウに関連付けられているリソース・プランは無効で、スケジューラのウィンドウがオープンする前に実行されていたリソース・プランが再度有効になります。(ウィンドウのオープン前に有効なリソース・プランがなかった場合、リソース・マネージャは無効になります。)したがって、ウィンドウのリソース・プランはあらゆるインスタンスで有効になります。
デフォルトでは、MAINTENANCE_WINDOW_GROUP
ウィンドウ・グループのメンバーである事前定義済のスケジューラ・ウィンドウであり、DEFAULT_MAINTENANCE_PLAN
リソース・プランを指定するメンテナンス・ウィンドウの間に一連の自動化されたメンテナンス・タスクが実行されることに注意してください。そのため、リソース・マネージャは、メンテナンス・ウィンドウ中にデフォルトでアクティブ化されます。必要な場合は、これらのメンテナンス・ウィンドウを変更して、別のリソース・プランを使用できます。
ノート:
メンテナンス・ウィンドウに関連付けられたプランを変更する場合は、サブプランORA$AUTOTASK
が新しいプランに含まれていることを確認してください。
Oracle Schedulerのウィンドウでのプラン切替えの無効化
場合によっては、スケジューラのウィンドウ境界でのリソース・マネージャ・プランの自動変更は、望ましくない可能性があります。たとえば、終了する必要のある重要なタスクがあり、リソース・マネージャ・プランにタスクの優先度を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、スケジューラのウィンドウはプランの設定後にアクティブになるため、タスクの実行中にリソース・マネージャ・プランが変更される可能性があります。
この状況を回避するには、次のSQL文に示すように、RESOURCE_MANAGER_PLAN
初期化パラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:
」を付加します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';
接頭辞FORCE
を使用することで、現行のリソース・プランの変更は、データベース管理者がRESOURCE_MANAGER_PLAN
初期化パラメータの値を変更した場合のみ可能であることを示します。この制限を解除するには、プラン名の前に「FORCE:
」を付加せずに、そのコマンドを再実行します。
DBMS_RESOURCE_MANAGER.SWITCH_PLAN
パッケージ・プロシージャには同様の機能があります。
関連項目:
DBMS_RESOURCE_MANAGER.SWITCH_PLAN
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
リソース・マネージャの無効化
リソース・マネージャを無効にするには、次のステップを完了します。
27.7 各種の方法を組み合せたOracle Database Resource Managerの例
リソース・マネージャでリソースを割り当てる方法を例で示します。
- 複数レベルのプランの例
複数レベルのプランの例を示します。 - 使用率制限の属性を使用した例
UTILIZATION_LIMIT
ディレクティブ属性を使用すると、アプリケーションのCPU使用率を制限できます。この属性の一般的な使用例として、データベース統合をあげることができます。 - 各種のリソース割当て方法を使用した例
各種のリソース割当て方法を使用した例を示します。 - ディレクティブ属性を使用したパラレル・ステートメントの管理の例
ディレクティブ属性を使用したパラレル・ステートメントの管理の例を示します。 - オラクル社が提供する複合ワークロード・プラン
Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN
(バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。
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
のコールはオプションです。
このプラン・スキーマでは、次のように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
に割り当てられます。
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
コンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは(プランの一部であっても)省略されています。
次の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%になります。
27.7.3 各種のリソース割当て方法を使用した例
各種のリソース割当て方法を使用した例を示します。
ここで示す例は、パッケージ化されたEnterprise Resource Planning(ERP)またはCustomer Relationship Management(CRM)アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理(OLTP)の適切な応答時間を得ることにあります。
次の表にプランがまとめられています。
グループ | CPUリソース割当て% | パラレル文のキューイング | コンシューマ・グループの自動切替え | 最大見積り実行時間 | UNDOプール | 各セッションのPGA制限 |
---|---|---|---|---|---|---|
|
60% |
-- |
切替え先グループ: 切替え時間: 3秒 |
-- |
200K |
20M |
|
30% |
パラレル・サーバー制限: 8 パラレル・キューのタイムアウト: 600秒 |
-- |
3600秒 |
-- |
-- |
|
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; /
27.7.4 ディレクティブ属性を使用したパラレル・ステートメントの管理の例
ディレクティブ属性を使用したパラレル・ステートメントの管理の例を示します。
一般的に、データ・ウェアハウス環境は、リソース要件が様々に異なる多様なユーザーで構成されています。処理要件が共通するユーザーは、コンシューマ・グループにグループ化されます。コンシューマ・グループURGENT_GROUP
は、経営陣に重要な情報を提供するためのレポートを実行するユーザーで構成されています。このグループは、多数のパラレル問合せを生成します。コンシューマ・グループETL_GROUP
に属するユーザーは、ソース・システムからデータをインポートし、抽出、変換、ロード(ETL)の各操作を実行します。グループOTHER_GROUPS
には、非定型問合せを実行するユーザーが含まれています。パフォーマンスを最適に保つと同時に、このような多様なユーザー・グループの要件を管理する必要があります。
次のディレクティブ属性を使用すると、パラレル・ステートメントの実行を管理および最適化できます。
-
MGMT_P
n -
PARALLEL_SERVER_LIMIT
-
PARALLEL_STMT_CRITICAL
-
PARALLEL_QUEUE_TIMEOUT
-
PQ_TIMEOUT_ACTION
-
PARALLEL_DEGREE_LIMIT_P1
-
SHARES
ノート:
-
MGMT_P
n管理属性とSHARES
属性では、パラレル文キューから実行するパラレル文を選択する方法を制御します。あるコンシューマ・グループのパラレル・ステートメントを別のグループよりも優先させるには、そのグループの管理属性の値を大きくします。 -
マルチテナント環境では、詳細なワークロードごとの管理が必要な場合、
SHARES
属性を使用して、パラレル文のキューイング・リソースを含むプラガブル・データベース(PDB)のリソース割当ての共有を指定できます。また、前述した別のディレクティブ属性を使用することもできます。
表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 |
---|---|---|---|---|---|---|
|
100% |
12 |
||||
|
100% |
8 |
50% |
|||
|
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
が返されます。
27.7.5 オラクル社が提供する複合ワークロード・プラン
Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN
(バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。
MIXED_WORKLOAD_PLAN
は、次のように定義されています。
グループまたはサブプラン | CPUリソース割当て | ||||
---|---|---|---|---|---|
レベル1 | レベル2 | レベル3 | コンシューマ・グループの自動切替え | 最大並列度 | |
|
100% |
||||
|
85% |
切替え先グループ: 切替え時間: 60秒 コールに対する切替え: |
1 |
||
|
5% |
||||
|
5% |
||||
|
100% |
このプランのINTERACTIVE_GROUP
は短いトランザクションを対象にしているため、60秒を超えるCPU時間を使用するコールは、長いバッチ操作を対象にしたBATCH_GROUP
に自動的に切り替わります。
使用環境に適する場合は、この事前定義済のプランを使用できます。(このプランは変更したり、使用しない場合に削除できます。)BATCH_GROUP
およびINTERACTIVE_GROUP
の名前に特別な意味はありません。この名前はグループの用途を反映しているだけで、ユーザーは任意に、これらのグループにアプリケーション・セッションをマップし、それに応じてCPUリソースの割当て使用率を調整して、使用する対話型アプリケーションおよびバッチ・アプリケーションにあわせた適切なリソース管理を実現できます。たとえば、対話型アプリケーションをINTERACTIVE_GROUP
コンシューマ・グループの下で実行するには、ユーザー名、サービス名、プログラム名、モジュール名または処理に基づいて、このコンシューマ・グループに対話型アプリケーションのユーザー・セッションをマップする必要があります(「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照)。同じように、BATCH_GROUP
にバッチ・アプリケーションをマップする必要があります。最後に、このプランを有効にする必要があります(「Oracle Database Resource Managerの有効化とプランの切替え」を参照)。
27.8 単一サーバーにおける複数のデータベース・インスタンスの管理
Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。
- インスタンス・ケージングについて
各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。 - インスタンス・ケージングの有効化
CPUディレクティブでリソース・プランを作成し、CPU_COUNT
初期化パラメータを設定することで、インスタンス・ケージングの使用を有効にできます。
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つのインスタンスへの負荷が別のインスタンスに影響を及ぼすことがなくなり、各インスタンスは想定したとおりに実行されます。
使用率制限が適用されたインスタンス・ケージングの使用
27.9 コンシューマ・グループ、プランおよびディレクティブのメンテナンス
Oracle Database Resource Manager (リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスできます。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER
PL/SQLパッケージを使用して実行します。
- コンシューマ・グループの更新
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUP
プロシージャを使用します。 - コンシューマ・グループの削除
DELETE_CONSUMER_GROUP
プロシージャは、指定されたコンシューマ・グループを削除します。 - プランの更新
プラン情報を更新するには、UPDATE_PLAN
プロシージャを使用します。 - プランの削除
DELETE_PLAN
プロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。 - リソース・プラン・ディレクティブの更新
プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVE
プロシージャを使用します。 - リソース・プラン・ディレクティブの削除
リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVE
プロシージャを使用します。
関連項目:
-
DBMS_RESOURCE_MANAGER
PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
27.9.1 コンシューマ・グループの更新
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUP
プロシージャを使用します。
コンシューマ・グループを更新するには:
-
ペンディング・エリアを作成します。
-
UPDATE_CONSUMER_GROUP
プロシージャを実行します。引数を指定せずに
UPDATE_CONSUMER_GROUP
プロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。 -
ペンディング・エリアを発行します。
関連トピック
27.9.2 コンシューマ・グループの削除
DELETE_CONSUMER_GROUP
プロシージャは、指定されたコンシューマ・グループを削除します。
コンシューマ・グループを削除するには:
-
ペンディング・エリアを作成します。
-
DELETE_CONSUMER_GROUP
プロシージャを実行します。 -
ペンディング・エリアを発行します。
コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてOTHER_GROUPS
が割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはOTHER_GROUPS
に切り替わります。
リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。
関連トピック
27.9.3 プランの更新
プラン情報を更新するには、UPDATE_PLAN
プロシージャを使用します。
プランを更新するには:
-
ペンディング・エリアを作成します。
-
UPDATE_PLAN
プロシージャを実行します。たとえば、次のスクリプトは、COMMENT
パラメータを更新するPL/SQLブロックです。BEGIN DBMS_RESOURCE_MANAGER.UPDATE_PLAN( PLAN => 'DAYTIME', NEW_COMMENT => '50% more resources for OLTP applications'); END; /
引数を指定せずに
UPDATE_PLAN
プロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。 -
ペンディング・エリアを発行します。
関連トピック
27.9.4 プランの削除
DELETE_PLAN
プロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。
計画を削除するには:
-
ペンディング・エリアを作成します。
-
DELETE_PLAN_CASCADE
プロシージャを実行します。たとえば、次のスクリプトは、great_bread
プランとそのディレクティブを削除するPL/SQLブロックです。BEGIN DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'great_bread'); END; /
引数を指定せずに
UPDATE_PLAN
プロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。削除したディレクティブが参照していたリソース・コンシューマ・グループは削除されませんが、
great_bread
プランとの関連は解除されます。DELETE_PLAN_CASCADE
プロシージャは、指定のプランとその子孫すべて(プラン・ディレクティブ、および必須のマークが付けられていないサブプランとリソース・コンシューマ・グループ)を削除します。エラーが発生したDELETE_PLAN_CASCADE
はロールバックされ、プランは変更されません。現在アクティブなプランは削除できません。
-
ペンディング・エリアを発行します。
関連トピック
27.9.5 リソース・プラン・ディレクティブの更新
プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVE
プロシージャを使用します。
リソース・プラン・ディレクティブを更新するには:
-
ペンディング・エリアを作成します。
-
UPDATE_PLAN_DIRECTIVE
プロシージャを実行します。次の例ではディレクティブにコメントを追加します。
BEGIN DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE( PLAN => 'SIMPLE_PLAN1', GROUP_OR_SUBPLAN => 'MYGROUP1', NEW_COMMENT => 'Higher priority' ); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; /
コメントをクリアする(NULLにする)には、NULL文字列(
''
)を渡します。数値のディレクティブ・パラメータをクリアする(0またはNULLにする)には、新しい値を-1に設定します。BEGIN DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE( PLAN => 'SIMPLE_PLAN1', GROUP_OR_SUBPLAN => 'MYGROUP1', NEW_MAX_EST_EXEC_TIME => -1 ); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; /
UPDATE_PLAN_DIRECTIVE
プロシージャの引数を指定しない場合、ディレクティブ内の対応パラメータは変更されません。 -
ペンディング・エリアを発行します。
関連トピック
27.10 データベース・リソース・マネージャの構成とステータスの表示
Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。
- ユーザーまたはロールに権限付与されたコンシューマ・グループの表示
DBA_RSRC_CONSUMER_GROUP_PRIVS
ビューには、ユーザーまたはロールに付与されているコンシューマ・グループが表示されます。 - プラン情報の表示
DBA_RSRC_PLANS
ビューを使用して、データベースに定義されているすべてのリソース・プランを表示する例を示します。 - セッションの現行コンシューマ・グループの表示
V$SESSION
ビューを使用すれば、セッションに現在割り当てられているコンシューマ・グループを表示できます。 - 現在アクティブなプランの表示
V$RSRC_PLAN
ビューには現在アクティブなプランが表示されます。
関連項目:
すべての静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
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
列に、パラレル・ステートメント・キューイングが有効であるかどうかが表示されます。
関連項目:
V$RSRC_CONSUMER_GROUP
V$RSRC_CONSUMER_GROUP
ビューは、CPU、I/O、パラレル実行サーバーなど、使用されているリソースを監視する場合に使用します。また、CPUリソースの管理、リソース集中型の問合せの管理、パラレル・ステートメント・キューイングなどに関連する統計を監視する場合にも使用できます。すべての統計は、プランがアクティブ化された時点からの累積です。
SELECT name, active_sessions, queue_length, consumed_cpu_time, cpu_waits, cpu_wait_time FROM v$rsrc_consumer_group; NAME ACTIVE_SESSIONS QUEUE_LENGTH CONSUMED_CPU_TIME CPU_WAITS CPU_WAIT_TIME ------------------ --------------- ------------ ----------------- ---------- ------------- OLTP_ORDER_ENTRY 1 0 29690 467 6709 OTHER_GROUPS 0 0 5982366 4089 60425 SYS_GROUP 1 0 2420704 914 19540 DSS_QUERIES 4 2 4594660 3004 55700
前述の問合せ結果では、DSS_QUERIES
コンシューマ・グループには、アクティブ・セッション・プールに4つのセッションがあり、2つのセッションがキューでアクティブ化を待機しています。
このビューの主な測定値はCPU_WAIT_TIME
です。この測定値は、リソース管理のために、コンシューマ・グループのセッションがCPUの割当てを待機していた合計時間を示します。この測定値には、ラッチまたはエンキューの競合、I/O待機などに起因する待機は含まれません。
ノート:
STATISTICS_LEVEL
初期化パラメータがALL
またはTYPICAL
に設定されている場合、V$RSRC_CONSUMER_GROUP
ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。
関連項目:
V$RSRC_SESSION_INFO
このビューを使用して、1つ以上のセッションのステータスを監視します。このビューには、リソース・マネージャによるセッションへの影響が表示されます。次の情報が提供されます。
-
セッションが現在属しているコンシューマ・グループ。
-
セッションが当初属していたコンシューマ・グループ。
-
コンシューマ・グループへのセッションのマップに使用されたセッション属性。
-
セッションの状態(
RUNNING
、WAIT_FOR_CPU
、QUEUED
など)。 -
メトリックに関する現在の統計と累積の統計(CPU使用、待機時間、待ち行列時間、使用されるアクティブなパラレル・サーバーの数など)。現在の統計には、セッションが現在のコンシューマ・グループに所属してからの統計が反映されています。累積の統計には、セッションが作成された以降に所属したすべてのコンシューマ・グループでの統計が反映されています。
SELECT se.sid sess_id, co.name consumer_group, se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time FROM v$rsrc_session_info se, v$rsrc_consumer_group co WHERE se.current_consumer_group_id = co.id; SESS_ID CONSUMER_GROUP STATE CPU_TIME CPU_WAIT_TIME QUEUED_TIME ------- ------------------ -------- --------- ------------- ----------- 113 OLTP_ORDER_ENTRY WAITING 137947 28846 0 135 OTHER_GROUPS IDLE 785669 11126 0 124 OTHER_GROUPS WAITING 50401 14326 0 114 SYS_GROUP RUNNING 495 0 0 102 SYS_GROUP IDLE 88054 80 0 147 DSS_QUERIES WAITING 460910 512154 0
このビューのCPU_WAIT_TIME
には、V$RSRC_CONSUMER_GROUP
ビューと同様の意味がありますが、個々のセッションに適用されます。
このビューとV$SESSION
ビューを結合して、さらに詳細なセッションに関する情報を表示できます。
V$RSRC_PLAN_HISTORY
このビューには、インスタンスでリソース・プランがいつ有効または無効になったかが表示されます。各リソース・プランのアクティブ化または解除には連番が割り当てられます。このビューの各エントリについては、プランの各コンシューマ・グループに対応するエントリがV$RSRC_CONS_GROUP_HISTORY
ビューにあり、コンシューマ・グループの累積統計が表示されます。この2つのビューは、それぞれのSEQUENCE#
列で結合しています。
SELECT sequence# seq, name plan_name, to_char(start_time, 'DD-MON-YY HH24:MM') start_time, to_char(end_time, 'DD-MON-YY HH24:MM') end_time, window_name FROM v$rsrc_plan_history; SEQ PLAN_NAME START_TIME END_TIME WINDOW_NAME ---- -------------------------- --------------- --------------- ---------------- 1 29-MAY-07 23:05 29-MAY-07 23:05 2 DEFAULT_MAINTENANCE_PLAN 29-MAY-07 23:05 30-MAY-07 02:05 TUESDAY_WINDOW 3 30-MAY-07 02:05 30-MAY-07 22:05 4 DEFAULT_MAINTENANCE_PLAN 30-MAY-07 22:05 31-MAY-07 02:05 WEDNESDAY_WINDOW 5 31-MAY-07 02:05 31-MAY-07 22:05 6 DEFAULT_MAINTENANCE_PLAN 31-MAY-07 22:05 THURSDAY_WINDOW
PLAN_NAME
の下のNULL値は、プランがアクティブにならなかったことを示します。
このビューのAWRスナップショットはDBA_HIST_RSRC_PLAN
ビューに格納されます。
関連項目:
V$RSRC_CONS_GROUP_HISTORY
このビューは、時間の経過とともに、リソースがコンシューマ・グループ間でどのように共有されていたかを理解するのに役立ちます。sequence#
列は、V$RSRC_PLAN_HISTORY
ビューの同名の列に対応しています。そのため、コンシューマ・グループ統計の各行について、アクティブであったプランを判別できます。
SELECT sequence# seq, name, cpu_wait_time, cpu_waits, consumed_cpu_time FROM v$rsrc_cons_group_history; SEQ NAME CPU_WAIT_TIME CPU_WAITS CONSUMED_CPU_TIME ---- ------------------------- ------------- ---------- ----------------- 2 SYS_GROUP 18133 691 33364431 2 OTHER_GROUPS 51252 825 181058333 2 ORA$AUTOTASK_MEDIUM_GROUP 21 5 4019709 2 ORA$AUTOTASK_URGENT_GROUP 35 1 198760 2 ORA$AUTOTASK_STATS_GROUP 0 0 0 2 ORA$AUTOTASK_SPACE_GROUP 0 0 0 2 ORA$AUTOTASK_SQL_GROUP 0 0 0 2 ORA$AUTOTASK_HEALTH_GROUP 0 0 0 4 SYS_GROUP 40344 85 42519265 4 OTHER_GROUPS 123295 1040 371481422 4 ORA$AUTOTASK_MEDIUM_GROUP 1 4 7433002 4 ORA$AUTOTASK_URGENT_GROUP 22959 158 19964703 4 ORA$AUTOTASK_STATS_GROUP 0 0 0 . .
このビューのAWRスナップショットはDBA_HIST_RSRC_CONSUMER_GROUP
ビューに格納されます。コンシューマ・グループ統計の各履歴セットについて、アクティブであったプランを判別するには、DBA_HIST_RSRC_CONSUMER_GROUP
とDBA_HIST_RSRC_PLAN
を併用します。
ノート:
STATISTICS_LEVEL
初期化パラメータがALL
またはTYPICAL
に設定されている場合、V$RSRC_CONS_GROUP_HISTORY
ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。
関連項目:
-
AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
V$RSRCMGRMETRIC
このビューを使用すると、セッション数の観点または過去1分間の使用状況の観点から、CPUメトリックをミリ秒単位で追跡できます。各コンシューマ・グループのリアルタイムなメトリックが提供されるため、ワークロードの実行中に、CPUリソースの使用状況を継続的に監視する場合に非常に便利です。
このビューを使用すると、コンシューマ・グループの最大CPU使用率と平均CPU使用率を、使用したCPU時間、CPU待ち時間、CPUを消費しているセッションの平均数、CPU割当てを待機しているセッションの数など他のコンシューマ・グループ設定と比較できます。たとえば、コンシューマ・グループが使用したCPUリソースの量およびコンシューマ・グループがリソース割当てを待機した期間を表示できます。または、各コンシューマ・グループから実行されているセッションの数とアクティブなセッションの総数とを対比できます。
CPU使用率でCPUの消費量を追跡するには、CPU_UTILIZATION_LIMIT
列およびAVG_CPU_UTILIZATION
列を使用します。AVG_CPU_UTILIZATION列
には、コンシューマ・グループによるサーバーのCPUの平均使用率が表示されます。CPU_UTILIZATION_LIMIT
列は、コンシューマ・グループが使用できるサーバーのCPUの最大割合を表します。この制限は、UTILIZATION_LIMIT
ディレクティブ属性を使用して設定されます。
SELECT consumer_group_name, cpu_utilization_limit, avg_cpu_utilization FROM v$rsrcmgrmetric;
CPUの消費量および制限量をミリ秒単位で追跡するには、CPU_CONSUMED_TIME
列およびCPU_TIME_WAIT
列を使用します。NUM_CPUS
列は、リソース・マネージャが管理しているCPUの数を表します。
SELECT consumer_group_name, cpu_consumed_time, cpu_wait_time, num_cpus FROM v$rsrcmgrmetric;
CPUの消費量および制限量をセッションの数で追跡するには、RUNNING_SESSIONS_LIMIT
、AVG_RUNNING_SESSIONS
、AVG_WAITING_SESSIONS
の各列を使用します。RUNNING_SESSIONS_LIMIT
列には、特定のコンシューマ・グループからいつでも実行できるセッションの最大数が表示されます。この制限は、コンシューマ・グループまたはコンシューマ・グループが含まれているサブプランに設定するUTILIZATION_LIMIT
ディレクティブ属性で定義されます。コンシューマ・グループごとに、AVG_RUNNING_SESSIONS
列にはCPUを消費しているセッションの平均数が表示され、AVG_WAITING_SESSIONS
列にはCPUを待機しているセッションの平均数が表示されます。
SELECT sequence#, consumer_group_name, running_sessions_limit, avg_running_sessions, avg_waiting_sessions FROM v$rsrcmgrmetric;
パラレル・ステートメントおよびコンシューマ・グループのパラレル・サーバーの使用を追跡するには、AVG_ACTIVE_PARALLEL_STMTS
、AVG_QUEUED_PARALLEL_STMTS
、AVG_ACTIVE_PARALLEL_SERVERS
、AVG_QUEUED_PARALLEL_SERVERS
およびPARALLEL_SERVERS_LIMIT
列を使用します。AVG_ACTIVE_PARALLEL_STMTS
とAVG_ACTIVE_PARALLEL_SERVERS
には、実行されているパラレル・ステートメントの平均数、およびパラレル・ステートメントによって使用されるパラレル・サーバーの平均数が表示されます。AVG_QUEUED_PARALLEL_STMTS
とAVG_QUEUED_PARALLEL_SERVERS
には、キュー内のパラレル・ステートメントの平均数、およびキュー内のパラレル・ステートメントによって要求されたパラレル・サーバーの平均数が表示されます。PARALLEL_SERVERS_LIMIT
には、コンシューマ・グループで使用できるパラレル・サーバーの数が表示されます。
SELECT avg_active_parallel_stmts, avg_queued_parallel_stmts, avg_active_parallel_servers, avg_queued_parallel_servers, parallel_servers_limit FROM v$rsrcmgrmetric;
ノート:
STATISTICS_LEVEL
初期化パラメータがALL
またはTYPICAL
に設定されている場合、V$RSRCMGRMETRIC
ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。
関連項目:
V$RSRCMGRMETRIC_HISTORY
V$RSRCMGRMETRIC_HISTORY
の各列は、V$RSRCMGRMETRICと同じビューです。これらのビューの唯一の違いは、V$RSRCMGRMETRICには過去1分間のみのメトリックが含まれているのに対して、V$RSRCMGRMETRIC_HISTORY
には過去60分間のメトリックが含まれていることです。
ノート:
STATISTICS_LEVEL
初期化パラメータがALL
またはTYPICAL
に設定されている場合、V$RSRCMGRMETRIC_HISTORY
ビューでは、リソース・マネージャによって現在管理されていないリソースの統計が記録されます。
27.12 オペレーティング・システムのリソース制御との相互作用
多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。たとえば、HP社のProcess Resource Managerや、Solaris Containers、ZonesおよびResource Poolsなどがあります。
- オペレーティング・システムのリソース制御を使用するためのガイドライン
オペレーティング・システムのリソース制御を使用する場合は、ガイドラインに従います。
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には、事前定義のリソース・プランが含まれます。 - 事前定義のコンシューマ・グループ・マッピング・ルール
Oracle Databaseには、事前定義済のコンシューマ・グループ・マッピング・ルールが含まれます。 - リソース・マネージャのデータ・ディクショナリ・ビュー
データ・ディクショナリ・ビューのセットに対してデータベース・リソース管理に関する情報を問い合せることができます。
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 事前定義のリソース・プラン
リソース・プラン | 説明 |
---|---|
|
メンテナンス・ウィンドウのデフォルト・プラン。このプランの詳細は、「自動化メンテナンス・タスクに対するリソース割当てについて」を参照してください。メンテナンス・ウィンドウはOracle Schedulerの通常のウィンドウであるため、必要に応じて、それらに関連付けられているリソース・プランを変更できます。メンテナンス・ウィンドウのリソース・プランを変更する場合は、サブプラン |
|
|
|
重要ではないDSS問合せやETL操作よりも重要なDSS問合せを優先させるデータ・ウェアハウス・プランの例。 |
|
DSS問合せよりもETL操作を優先させるデータ・ウェアハウス・プランの例。 |
|
リソース・マネージャの無効化用。内部使用のみに対応しています。 |
|
データベースの静止用。このプランは直接アクティブ化できません。アクティブ化するには |
|
バッチ操作よりも対話型操作を優先させる複合ワークロード・プランの例。詳細は、「オラクル社が提供する複合ワークロード・プラン」を参照してください。 |
表27-6 事前定義のリソース・コンシューマ・グループ
リソース・コンシューマ・グループ | 説明 |
---|---|
|
バッチ操作用のコンシューマ・グループ。プラン例 |
|
重要なDSS問合せ用のコンシューマ・グループ。プラン例 |
|
重要ではないDSS問合せ用のコンシューマ・グループ。プラン例 |
|
ETLジョブ用のコンシューマ・グループ。プラン例 |
|
対話型OLTP操作用のコンシューマ・グループ。プラン例 |
|
優先度が低いセッション用のコンシューマ・グループ。 |
|
メンテナンス・タスク用のコンシューマ・グループ。 |
|
明示的な初期コンシューマ・グループを持たないすべてのセッションのデフォルトのコンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールによってコンシューマ・グループにマップされないか、現在アクティブなリソース・プラン内にないコンシューマ・グループにマップされます。
|
|
システム管理者用のコンシューマ・グループ。これは、ユーザー・アカウント |
27.13.2 事前定義のコンシューマ・グループ・マッピング・ルール
Oracle Databaseには、事前定義済のコンシューマ・グループ・マッピング・ルールが含まれます。
表27-7に、Oracle Databaseで事前定義されているコンシューマ・グループ・マッピング・ルールの要約を示します。ビューDBA_RSRC_GROUP_MAPPINGS
を問い合せることで、これらのルールを確認できます。DBMS_RESOURCE_MANAGER
.SET_CONSUMER_GROUP_MAPPING
プロシージャを使用して、これらのマッピング・ルールを変更または削除できます。
表27-7 事前定義のコンシューマ・グループ・マッピング・ルール
属性 | 値 | マップされるコンシューマ・グループ | ノート |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
セッションでは、RMANによるバックアップ操作が実行されます。操作が開始すると、セッションは自動的に |
|
|
|
セッションでは、RMANによるコピー操作が実行されます。操作が開始すると、セッションは自動的に |
|
|
|
セッションでは、データ・ポンプによるデータ・ロード操作が実行されます。操作が開始すると、セッションは自動的に |
27.13.3 リソース・マネージャのデータ・ディクショナリ・ビュー
データ・ディクショナリ・ビューのセットに対してデータベース・リソース管理に関する情報を問い合せることができます。
表27-8に、リソース・マネージャに関連付けられているビューをリストします。
表27-8 リソース・マネージャのデータ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
|
|
データベースに存在するすべてのリソース・コンシューマ・グループがリストされます。 |
|
|
|
データベースに存在するすべてのリソース・プラン・ディレクティブがリストされます。 |
|
データベースに存在するすべてのリソース・プランがリストされます。 |
|
すべてのセッション属性に対する様々なマッピングのペアがすべてリストされます。 |
|
各属性の現在のマッピング優先度がリストされます。 |
|
リソース・プランのアクティブ化に関する履歴情報が表示されます。このビューには、 |
|
コンシューマ・グループに関する履歴統計情報が表示されます。このビューには、 |
|
|
|
|
|
アクティブなリソース・コンシューマ・グループに関する情報が表示されます。このビューは、チューニングに使用できます。 |
|
過去1分間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに表示されます。 |
|
過去1時間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに分単位で表示されます。新しいリソース・プランが有効な場合、履歴はクリアされます。 |
|
現在のアクティブ・リソース・プランの名前がすべて表示されます。 |
|
そのインスタンスでリソース・マネージャのプランがいつ有効または無効になったかが表示されます。時間の経過とともに、どのようにリソースがコンシューマ・グループ間で共有されていたかを理解するのに役立ちます。 |
|
各セッションについてリソース・マネージャの統計が表示されます。リソース・マネージャによるセッションへの影響が表示されます。チューニングに使用できます。 |
|
現行セッションごとにセッション情報が表示されます。その中には、各現行セッションのリソース・コンシューマ・グループの名前が含まれます。 |