11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
Oracle Database Resource Manager（リソース・マネージャ）を使用すると、多数のコンカレント・データベース・セッションにリソースを最適に割り当てられます。次の各項では、リソース・マネージャの概要を説明します。
データベース・リソースの割当てがオペレーティング・システムによって決定される場合は、次のような問題が生じることがあります。
過剰なオーバーヘッドは、サーバー・プロセスの数が多いときに、Oracle Databaseサーバー・プロセス間でオペレーティング・システムのコンテキストが切り替わることによって発生します。
オペレーティング・システムは、データベース・サーバーがラッチを保持している間にデータベース・サーバーのスケジュールを解除しますが、これは非効率的です。
オペレーティング・システムはタスク間の優先度付けができないため、すべてのアクティブなプロセスの間で均等にリソースを分配します。
リソース・マネージャは、ハードウェア・リソースの割当て方法をデータベースで厳密に制御することによって、これらの問題を克服します。複数のコンカレント・ユーザー・セッションがあり、各セッションでは異なる優先度のジョブが実行される環境では、すべてのセッションが同等に処理されるわけではありません。リソース・マネージャを使用すると、セッション属性に基づいてセッションを複数のグループに分類し、それらのグループに対して、アプリケーション環境のハードウェア利用が最適化されるようにリソースを配分できます。
リソース・マネージャを使用すると、次のことが可能になります。
次の表に、リソース・マネージャの要素を示します。
これらの要素の作成とメンテナンスには、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用します。要素は、データ・ディクショナリ内の表に格納されます。要素に関する情報は、データ・ディクショナリ・ビューを使用して表示できます。
リソース・コンシューマ・グループ（コンシューマ・グループ）とは、処理要件に基づいてグループ化されたユーザー・セッションの集合です。セッションが作成されると、そのセッションは、管理者が設定したマッピング・ルールに基づいてコンシューマ・グループに自動的にマップされます。データベース管理者（DBA）は、セッションを、異なるコンシューマ・グループに手動で切り替えることができます。同様に、アプリケーションでは、そのセッションを特定のコンシューマ・グループに切り替えるPL/SQLパッケージ・プロシージャを実行できます。
リソース・マネージャによるリソース（CPUなど）の割当て先は、コンシューマ・グループのみであるため、セッションがコンシューマ・グループのメンバーになると、そのリソース割当ては、コンシューマ・グループの割当てによって決定されます。デフォルトでは、コンシューマ・グループの各セッションは、そのグループに割り当てられているリソースをグループ内の他のセッションとラウンド・ロビン方式で共有します。
常にデータ・ディクショナリに存在する3種類の特別なコンシューマ・グループがあります。これらのグループは、変更したり削除することはできません。次に、この3種類のコンシューマ・グループを示します。
SYS_GROUPこれは、ユーザー・アカウントSYSまたはSYSTEMによって作成されたすべてのセッションの初期コンシューマ・グループです。この初期コンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールで上書きできます。
DEFAULT_CONSUMER_GROUP これは、SYSおよびSYSTEM以外のユーザー・アカウントによって開始されたすべてのセッションの初期コンシューマ・グループです。この初期コンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールで上書きできます。DEFAULT_CONSUMER_GROUPには、リソース・プラン・ディレクティブで名前を指定できません。
OTHER_GROUPS このグループは、DEFAULT_CONSUMER_GROUPに属しているセッションも含めて、現在はアクティブなプランの一部でないコンシューマ・グループに属しているすべてのセッションに適用されます。OTHER_GROUPSには、すべてのプランに指定されているリソース・プラン・ディレクティブを設定する必要があります。このグループは、マッピング・ルールを介してセッションに明示的に割り当てることはできません。
リソース・マネージャは、現在アクティブなリソース・プランに属している一連のリソース・プラン・ディレクティブ（ディレクティブ）に従って、リソースをコンシューマ・グループに割り当てます。リソース・プランとそのリソース・プラン・ディレクティブには親子の関係があります。各ディレクティブは1つのコンシューマ・グループを参照します。現在アクティブなプランの2つのディレクティブが同じコンシューマ・グループを参照することはできません。
ディレクティブには、コンシューマ・グループへのリソース割当てを制限できる多くの方法があります。たとえば、コンシューマ・グループが確保できるCPU全体の割合を制御したり、コンシューマ・グループ内でアクティブにできるセッションの総数を制限できます。詳細は、「リソース割当て方法の概要」を参照してください。
各Oracleデータベースに事前定義されているリソース・プランの他に、リソース・プランは必要な数だけ作成できます。ただし、1度にアクティブにできるリソース・プランは1つのみです。リソース・プランがアクティブな場合は、その子の各リソース・プラン・ディレクティブが異なるコンシューマ・グループへのリソース割当てを制御します。各プランには、OTHER_GROUPSというコンシューマ・グループにリソースを割り当てるディレクティブが必要です。OTHER_GROUPSは、現在アクティブなプランの一部でないコンシューマ・グループに属しているすべてのセッションに適用されます。
図25-1は、日中にオンライン・トランザクション処理（OLTP）アプリケーションとレポート・アプリケーションを同時に実行する組織の単純なリソース・プランを示しています。現在アクティブなプランDAYTIMEによって、3つのリソース・コンシューマ・グループにCPUリソースが割り当てられます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。
Oracle Databaseには、単純なリソース・プランを迅速に作成できるプロシージャ（CREATE_SIMPLE_PLAN）が用意されています。このプロシージャについては、「単純なリソース・プランの作成」を参照してください。
リソース・プラン・ディレクティブ（ディレクティブ）は、コンシューマ・グループを参照するかわりに、別のリソース・プランを参照できます。この場合、そのプランはサブプランと呼ばれます。サブプラン自体に、リソースをコンシューマ・グループと他のサブプランに割り当てるディレクティブがあります。この場合、リソースの割当ては次のように段階的な方式で機能します。最初に、トップレベルのリソース・プラン（現在アクティブなプラン）によって、リソースがコンシューマ・グループとサブプランに分割されます。次に、各サブプランによって、リソース割当て合計の一部がそのコンシューマ・グループとサブプランに割り当てられます。階層的なプランは、必要な数のサブプランを使用して作成できます。
リソース・サブプランは、リソース・プランを作成する方法と同じ方法で作成します。プランとサブプランの作成方法は同じです。プランは、サブプランとして使用することのみでサブプランになります。
この例では、Great Bread Companyによって、CPUリソースが図25-2のように割り当てられています。この図は、トップレベルのプラン（GREAT_BREAD）とその子すべてを示しています。わかりやすくするために、OTHER_GROUPSコンシューマ・グループを指定する要件は無視し、リソース・プラン・ディレクティブは（プランの一部であっても）省略されています。かわりに、ディレクティブが割り当てるCPUの比率を、プラン、サブプランおよびコンシューマ・グループ間を結ぶ線に沿って表示しています。
このGREAT_BREADプランでは、次のようにリソースを割り当てます。
MARKETに割り当てます。
SALES_TEAMに割り当てます。このサブプランでは、リソースがWHOLESALEコンシューマ・グループとRETAILコンシューマ・グループ間で均等に分割されます。
DEVELOP_TEAMに割り当てます。このサブプランでは、リソースがBREADコンシューマ・グループとMUFFINコンシューマ・グループ間で均等に分割されます。
サブプランまたはコンシューマ・グループは、複数の親を持つ場合があります。たとえば、MARKETグループがSALES_TEAMサブプランに含まれていた場合です。ただし、プラン内でループすることはできません。たとえば、SALES_TEAMサブプランには、GREAT_BREADプランを参照するディレクティブを設定できません。
リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。次の各項では、これらのリソース割当て方法について簡単に説明します。
この方法では、コンシューマ・グループおよびサブプランの間でのCPUリソースの割当て方法を指定します。複数レベル（最大8レベル）のCPUリソース割当てによって、プラン内でCPU使用の優先度を設定できます。レベル2のコンシューマ・グループとサブプランは、レベル1に割り当てられなかったリソース、つまりレベル1のコンシューマ・グループまたはサブプランで使用されなかったリソースを取得します。同様に、レベル3のリソース・コンシューマには、レベル1と2の割当ての一部が残っている場合のみ、リソースが割り当てられます。同じ規則がレベル4から8にも適用されます。複数のレベルを使用すると、優先度を設定できるのみでなく、すべての主リソースと残りのリソースの使用方法を明示的に指定できます。
複数レベルのプラン・スキーマの例は、図25-3を参照してください。
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが定義されます。アクティブ・セッションとは、コール中のセッションです。セッションがブロックされている場合（I/Oリクエスト完了の待機中など）もアクティブとみなされます。アクティブ・セッション・プールがいっぱいの場合、コールを処理しようとしているセッションはキューに送られます。アクティブなセッションが終了すると、キュー内の最初のセッションがキューから削除され、実行に向けてスケジュールされます。実行キュー内のセッションがタイムアウトするまでの期間も指定できます。タイムアウトすると、エラーで終了します。
パラレル実行セッションは全体で1つのアクティブ・セッションとして数えられます。
この機能は、リソースについて競合する、コンシューマ・グループ内のセッション数を制限する場合に便利です。たとえば、コンシューマ・グループがレポートのための長時間実行のパラレル問合せ処理に使用されている場合、1つのレポートをできるだけ早く完了させるためにアクティブ・セッション数を1つに制限して、CPUまたはパラレル問合せスレーブを他のレポートと競合しないようにできます。
管理者は、1つのコンシューマ・グループ内での操作に対して最大並列度を制限できます。この制限は、1つのコンシューマ・グループ内の1つの操作に適用されます。コンシューマ・グループ内のすべての操作にわたる総合的な並列度が制限されるわけではありません。ただし、必要な制御を実現するために、並列度制限とアクティブ・セッション・プールの機能を組み合せることはできます。
この方法を使用すると、指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。通常、この方法は、グループ内の典型的なセッションに対するリソース使用予測を上回ったセッションを、優先度の高いコンシューマ・グループ（システム・リソースを高い比率で使用するグループ）から優先度の低いコンシューマ・グループに切り替えるために使用します。
詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。
ディレクティブを指定すると、システム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了できます。詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。
ある操作に許可される最大の実行時間を指定できます。ある操作についてデータベースが見積った実行時間が、指定された最大実行時間より長い場合、その操作はエラーを出力して終了します。このエラーはトラップ可能であり、操作は再スケジュールできます。
UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールは、コンシューマ・グループが生成できる、コミットされていないトランザクションに対するUNDO合計量を制御します。コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、そのUNDOを生成している現行のデータ操作言語（DML）文が終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たにデータ操作を実行できません。
セッションのアイドル時間を指定できます。指定した時間を経過するとセッションは終了します。厳しいアイドル時間制限を指定して、他のセッションをブロックしているアイドル状態のセッションに適用することもできます。
リソース・マネージャを管理するには、システム権限ADMINISTER_RESOURCE_MANAGERが必要です。この権限（ADMINオプション付き）は、DBAロールを介してデータベース管理者に付与されます。
リソース・マネージャの管理者は、DBMS_RESOURCE_MANAGER PL/SQLパッケージ内のすべてのプロシージャを実行できます。
ADMINオプションを持つ管理者は、必要に応じて管理権限を他のユーザーまたはロールに付与できます。そのためには、DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用します。次の表に、関連するパッケージ・プロシージャの一覧を示します。
| プロシージャ | 説明 |
|---|---|
|
|
ユーザーまたはロールに、 |
|
|
ユーザーまたはロールから、 |
次のスクリプトは、ユーザーSCOTTにADMINオプションなしで管理権限を付与するPL/SQLブロックです。したがって、SCOTTはDBMS_RESOURCE_MANAGERパッケージ内のすべてのプロシージャを実行できますが、管理権限を他のユーザーに付与するためのGRANT_SYSTEM_PRIVILEGEプロシージャは使用できません。
BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( GRANTEE_NAME => 'SCOTT', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER', ADMIN_OPTION => FALSE); END;
この権限は、REVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消すことができます。
CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。このプロシージャでは、1回のプロシージャ・コールの実行で、コンシューマ・グループを作成し、そのグループにリソースを割り当てることができます。このプロシージャを使用する際は、ペンディング・エリアの作成、各コンシューマ・グループの個別作成、リソース・プラン・ディレクティブの指定のために、後述のプロシージャをコールする必要はありません。
CREATE_SIMPLE_PLANプロシージャには、次の引数を指定します。
このプロシージャでは、最大8個のコンシューマ・グループを指定できます。サポート対象のリソース割当て方法は、CPUによる方法のみです。プランでは、EMPHASIS CPU割当てポリシー（デフォルト）が使用され、各コンシューマ・グループでは、ROUND_ROBINスケジューリング・ポリシー（これもデフォルト）が使用されます。プラン内の指定された各コンシューマ・グループには、レベル2のCPUパーセンテージが割り当てられます。このプランには、SYS_GROUP（ユーザーSYSおよびSYSTEM用にシステムによって定義された初期コンシューマ・グループ）とOTHER_GROUPSも暗黙的に含まれています。SYS_GROUPコンシューマ・グループには、レベル1でCPUの100%が割り当てられ、OTHER_GROUPSには、レベル3でCPUの100%が割り当てられます。
次のスクリプトは、ユーザー指定の2つのコンシューマ・グループを備えた単純なリソース・プランを作成するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'SIMPLE_PLAN1', CONSUMER_GROUP1 => 'MYGROUP1', GROUP1_PERCENT => 80, CONSUMER_GROUP2 => 'MYGROUP2', GROUP2_PERCENT => 20); END;
この文を実行すると、次のプランが作成されます。
| コンシューマ・グループ | レベル1 | レベル2 | レベル3 |
|---|---|---|---|
|
|
100% |
- |
- |
|
|
- |
80% |
- |
|
|
- |
20% |
- |
|
|
- |
- |
100% |
|
関連項目:
|
複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。
複雑なリソース・プランの作成に必要な手順の概要は、次のとおりです。
手順1: ペンディング・エリアを作成します。
手順2: コンシューマ・グループを作成、変更または削除します。
手順3: リソース・プランを作成します。
手順4: リソース・プラン・ディレクティブを作成します。
手順5: ペンディング・エリアの妥当性をチェックします。
手順6: ペンディング・エリアを発行します。
これらの手順は、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して完了します。次の各項では、詳細について説明します。
関連項目:
DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えずに、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。ペンディング・エリアを作成すると、そのペンディング・エリアはデータベースによって初期化されて既存のプランがコピーされます。これによって、既存のプランが更新可能となります。
|
ヒント:
ペンディング・エリアを作成した後、 |
変更を追加した後のペンディング・エリアは、発行する前に妥当性をチェックします。発行すると、保留中の変更内容がすべてデータ・ディクショナリに適用され、ペンディング・エリアはクリアされ、解除されます。
最初にペンディング・エリアを作成せずにプランを作成、更新または削除しようとすると（つまり、コンシューマ・グループまたはリソース・プラン・ディレクティブを作成、更新または削除しようとすると）、エラー・メッセージが表示されます。
ペンディング・エリアの発行によって、作成した新しいプランがアクティブ化されることはありません。単に、プランに関する新規または更新情報がデータ・ディクショナリに格納されるのみです。ただし、現在アクティブなプランを変更した場合、そのプランは新しいプラン定義で再度アクティブ化されます。 リソース・プランのアクティブ化の詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。
ペンディング・エリアを作成した後は、そのペンディング・エリアを発行またはクリアするか、ログアウトするまで、他のユーザーはペンディング・エリアを作成できません。
ペンディング・エリアはCREATE_PENDING_AREAプロシージャを使用して作成します。
次のスクリプトは、ペンディング・エリアを作成して初期化するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); END;
リソース・コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUPプロシージャを使用します。次のパラメータを指定できます。
次のスクリプトは、グループ内のセッションにリソースを割り当てるデフォルトの方法（ROUND-ROBIN）を使用して、OLTPというコンシューマ・グループを作成するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP ( CONSUMER_GROUP => 'OLTP', COMMENT => 'OLTP applications'); END;
リソース・プランを作成するには、CREATE_PLANプロシージャを使用します。次の表のパラメータを指定できます。最初の2つのパラメータは必須です。他のパラメータはオプションです。
次のスクリプトは、DAYTIMEというリソース・プランを作成するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN( PLAN => 'DAYTIME', COMMENT => 'More resources for OLTP applications'); END;
RATIO方法は、単一レベルのCPU割当てのみを使用する単純なプランを対象にした、代替のCPU割当て方法です。パーセンテージのかわりに、各コンシューマ・グループに与えるCPUの割合に対応する数を指定します。RATIO方法を使用するには、CREATE_PLANプロシージャのMGMT_MTH引数に'RATIO'を設定します。 この方法を使用するプランの例は、「リソース・プラン・ディレクティブの作成」を参照してください。
リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVEプロシージャを使用します。次のパラメータを指定できます。
次のスクリプトは、プラン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コンシューマ・グループに割り当てます。
図25-1にあるプランを完了するには、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); 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に設定されています。
この例では、CPUの割当てにRATIO方法を使用します。この方法は、パーセンテージのかわりに割合を使用します。アプリケーション・パッケージでは、クライアントに対してGold、SilverおよびBronzeの3種類のサービス・レベルが提供されていると仮定します。GOLD_CG、SILVER_CGおよびBRONZE_CGという3つのコンシューマ・グループを作成し、次のリソース・プランを作成します。
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になります。
トップレベルのプランと複数のサブプランから同じコンシューマ・グループを参照する場合があります。この場合は、同じコンシューマ・グループを参照する複数のリソース・プラン・ディレクティブがあるため、次の規則が適用されます。
SWITCH_TIME、SWITCH_IO_MEGABYTESまたはSWITCH_IO_REQSがある場合は、Oracle Database Resource Manager（リソース・マネージャ）によって、すべての入力値の中で最も制限が大きい値が選択されます。具体的には、次のようになります。
TRUEの場合、SWITCH_FOR_CALLはTRUEです。
MAX_EST_EXEC_TIME = min（入力されるすべてのMAX_EST_EXEC_TIME値）
ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREAをコールして、そのペンディング・エリアの妥当性を確認できます。
従う必要がある規則は、次のとおりです。これらの規則が妥当性チェック・プロシージャによってチェックされます。
OTHER_GROUPSのプラン・ディレクティブが存在する必要があります。これによって、現在のアクティブ・プラン内に含まれるコンシューマ・グループのいずれにも属していないセッションに、OTHER_GROUPSのディレクティブで指定したリソースが割り当てられます。
これらの規則のいずれかに違反すると、VALIDATE_PENDING_AREAからエラー・メッセージが返されます。その場合は、変更を加えて問題を修正し、プロシージャを再度コールできます。
プラン・ディレクティブによって参照されない孤立したコンシューマ・グループを作成できます。これによって、当面は使用しないものの、将来的に実装するプランの一部となる、コンシューマ・グループを作成できます。
次のスクリプトは、ペンディング・エリアの妥当性をチェックするPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); END;
変更の妥当性チェックを完了した後は、SUBMIT_PENDING_AREAプロシージャをコールして変更内容をアクティブにします。
SUBMITプロシージャでは妥当性チェックも実行されるため、妥当性チェック・プロシージャを別個にコールする必要はありません。ただし、プランを大幅に変更している場合は、通常、変更の妥当性チェックを段階的に実施するほうが問題のデバッグ作業が容易になります。ペンディング・エリア内のすべての変更について妥当性チェックが成功するまで、変更は発行されません（つまり、アクティブになりません）。
SUBMIT_PENDING_AREAプロシージャは、変更の妥当性チェックとコミットに成功すると、ペンディング・エリアをクリア（解除）します。
次のスクリプトは、ペンディング・エリアを発行するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END;
ペンディング・エリアを随時クリアするためのプロシージャも用意されています。次のスクリプトは、変更のすべてをペンディング・エリアからクリアし、ペンディング・エリアを解除するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); END;
CLEAR_PENDING_AREAをコールした後、再び変更を実施するには、その前にCREATE_PENDING_AREAプロシージャをコールする必要があります。
ここでは、データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法について説明します。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager（リソース・マネージャ）では、そのセッションに対するリソース割当てが管理の対象となります。
この項の内容は、次のとおりです。
リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。これには、マッピング・ルールを作成します。このルールにより、リソース・マネージャは、セッションの起動時にセッション属性に基づいて各セッションをコンシューマ・グループに自動的に割り当てることができます。セッションがその初期コンシューマ・グループに割り当てられ実行された後は、プロシージャをコールして、セッションを別のコンシューマ・グループに手動で切り替えることができます。この操作は、リソースを過剰に使用しているセッションを、よりリソース割当ての制限されたコンシューマ・グループに移動する必要がある場合などに実行します。あるコンシューマ・グループから別のコンシューマ・グループにそれぞれのセッションを切り替えることができるように、ユーザーやアプリケーションにスイッチ特権を付与することもできます。
セッション属性に変更がある場合やセッションが指定のリソース使用制限を超える場合は、あるコンシューマ・グループから別の（通常は優先度の低い）コンシューマ・グループにセッションを自動的に切り替えることもできます。
セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。 マッピング・ルールの構成方法は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。新しいセッションに適用するマッピング・ルールがない場合、セッションのデフォルトのコンシューマ・グループは、そのセッションを起動したユーザーのINITIAL_RSRC_CONSUMER_GROUP属性を使用して指定されます。この属性の値は、*_USERビューのINITIAL_RSRC_CONSUMER_GROUP列を表示することで確認できます。
DBMS_RESOURCE_MANAGER PL/SQLパッケージには、管理者が実行中のセッションのリソース・コンシューマ・グループを変更できるように、2つのプロシージャが用意されています。この2つのプロシージャでは、コーディネータのセッションに対応付けられたパラレル実行サーバー・セッションのコンシューマ・グループも変更できます。これらのプロシージャで行った変更は永続的ではなく、現行セッションのみに影響します。ユーザーの初期コンシューマ・グループも変更されません。
あるユーザーがCPUを過剰に使用している場合は、そのユーザーのセッションを停止（終了）するかわりに、ユーザーのコンシューマ・グループをリソースの割当てが低いグループに変更できます。
SWITCH_CONSUMER_GROUP_FOR_SESSプロシージャは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。このプロシージャを使用すると、セッションの優先度を実質的に変更できます。
次のスクリプトは、特定のセッションを新しいコンシューマ・グループに切り替えるPL/SQLブロックです。セッション識別子（SID）が17、セッション・シリアル番号（SERIAL#）が12345のセッションを移動します。新しいコンシューマ・グループはHIGH_PRIORITYコンシューマ・グループです。
BEGIN DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345', 'HIGH_PRIORITY'); END;
SID、セッション・シリアル番号、およびセッションの現行リソース・コンシューマ・グループは、V$SESSIONビューを使用して確認できます。
SWITCH_CONSUMER_GROUP_FOR_USERプロシージャは、指定したユーザー名に関連するすべてのセッションのリソース・コンシューマ・グループを変更します。次のスクリプトは、ユーザーSCOTTに属しているすべてのセッションをLOW_GROUPコンシューマ・グループに切り替えるPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('SCOTT', 'LOW_GROUP'); END;
特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。自動切替えは、次の場合に実行されます。
次の各項では、詳細について説明します。
セッションの実行中にセッション属性が変更されると、コンシューマ・グループへのセッションのマッピング・ルールが再評価されます。新しいルールが有効な場合、そのセッションは別のコンシューマ・グループに移動する可能性があります。 詳細は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。
コンシューマ・グループに対してリソース・プラン・ディレクティブを作成する場合は、そのグループのセッションに対してCPUおよびI/Oリソースの使用制限を指定できます。そのためには、セッション内の単一のコールが制限のいずれかを超過した場合に実行する処理を指定します。次のような処理が考えられます。
通常、ターゲット・コンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。セッションのユーザーには、新しいコンシューマ・グループに対するスイッチ特権が必要です。スイッチ特権がない場合は切り替えることができません。 詳細は、「スイッチ特権の付与と取消し」を参照してください。
このタイプのセッション自動切替えに関連するリソース・プラン・ディレクティブの属性は、次のとおりです。
これらの属性の詳細は、「リソース・プラン・ディレクティブの作成」を参照してください。
切替えは、実行中のセッションがリソースを使用している場合に発生します。ユーザー入力の待機時やCPUサイクルの待機中には発生しません。切替え後のグループのアクティブ・セッション・プールがいっぱいの場合も、切り替えたセッションは引き続き実行することを許可されます。このような状況では、コンシューマ・グループは、アクティブ・セッション・プールで指定された数より多いセッションを実行できます。
SWITCH_FOR_CALLは、中間層のサーバーがセッション・プーリングを使用している3層アプリケーションの場合に有効です。PL/SQLの最上位コールは、1つのコールとして処理されるPL/SQLブロック全体です。SQLの最上位コールは個々のSQL文です。
次に、リソース制限に基づいた自動切替えの例を示します。
次のスクリプトは、OLTPグループのリソース・プラン・ディレクティブを作成するPL/SQLブロックです。このディレクティブによって、セッション内のコールが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;
次のスクリプトは、OLTPグループのリソース・プラン・ディレクティブを作成するPL/SQLブロックです。このディレクティブによって、セッションが10,000回のI/Oリクエストまたは2,500MBのデータ転送を超過した場合は、そのグループ内のすべてのセッションが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;
次のスクリプトは、OLTPグループのリソース・プラン・ディレクティブを作成するPL/SQLブロックです。このディレクティブによって、60秒のCPU時間を超過したセッションは停止（終了）します。この例は、リソース集中型の問合せに起因するリソースの過剰使用を防止します。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN => 'DAYTIME', GROUP_OR_SUBPLAN => 'OLTP', COMMENT => 'OLTP group', MGMT_P1 => 75, SWITCH_GROUP => 'KILL_SESSION', SWITCH_TIME => 60); END;
ここでは、コンシューマ・グループへのセッションのマッピング・ルールに関するバックグラウンド情報を提供し、ルールの作成方法と優先度の設定方法について説明します。この項の内容は、次のとおりです。
コンシューマ・グループへのセッションのマッピング・ルールを作成すると、次のことができます。
このマッピング・ルールは、セッション属性（ユーザー名、セッションがデータベースへの接続に使用したサービス、クライアント・プログラムの名前など）に基づいています。
マッピング・ルール間の競合を解決するために、リソース・マネージャでは、各ルールが優先度別に順序付けされます。たとえば、ユーザーSCOTTがSALESサービスを使用してデータベースに接続すると仮定します。あるマッピング・ルールには、ユーザーSCOTTがMED_PRIORITYコンシューマ・グループで起動することが記載され、別のルールには、SALESサービスに接続するセッションはSALESコンシューマ・グループで起動することが記載されている場合、この競合は、マッピング・ルールの優先度によって解決されます。
マッピング・ルールの基本となるセッション属性には、ログイン属性とランタイム属性の2つのタイプがあります。ログイン属性が有効なのは、セッションのログイン時、つまり、リソース・マネージャによってセッションの初期コンシューマ・グループが決定されるときのみです。一方、すでにログインしているセッションは、ランタイム属性の変更に基づいて、その後、別のコンシューマ・グループに再割当てできます。
コンシューマ・グループへのセッションの自動割当てを構成するには、SET_CONSUMER_GROUP_MAPPINGおよびSET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。これらのプロシージャに対してはペンディング・エリアを使用する必要があります。（ペンディング・エリアを作成してプロシージャを実行し、必要に応じてペンディング・エリアの妥当性をチェックしてから、そのペンディング・エリアを発行する必要があります。 ペンディング・エリアの使用例は、「複雑なリソース・プランの作成」を参照してください。）
セッションは、マッピング・ルールを介して様々な時点で特定のコンシューマ・グループに自動的に切り替えられます。
これらのルールについては、次の2つの点に注意してください。
ACTIVE_TIME_IN_GROUP値があります。 セッションのマッピング・ルールは、一連の属性とコンシューマ・グループのペアで構成され、このペアによって、セッションとコンシューマ・グループとの組合せ方法が決定します。1つのセッション属性をコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。このプロシージャのパラメータは、次のとおりです。
| パラメータ | 説明 |
|---|---|
|
|
ログインまたはランタイムのセッション属性タイプ。パッケージ定数として指定されています。 |
|
|
マッピングされる属性の値。 |
|
|
マッピング先のコンシューマ・グループ。 |
ATTRIBUTEには、次のいずれかを指定できます。
たとえば、次の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プロシージャを実行する前にペンディング・エリアを作成する必要があります。
競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。各属性に、1（最も高い重要度）〜10（最も低い重要度）の一意の整数を設定するには、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); END;
この例では、データベース・ユーザー名の優先度は7（重要度が低い）に設定され、モジュール名の優先度は5（重要度が高い）に設定されています。
マッピング・ルールの優先度がどのように機能するかを示すために、DEV_GROUPコンシューマ・グループへのユーザーSCOTTのマッピングの他に、次のようなモジュール名のマッピング・ルールがあると仮定します。
BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.MODULE_NAME, 'BACKUP', 'LOW_PRIORITY'); END;
ユーザーSCOTTのセッションによって、モジュール名がBACKUPに設定された場合、そのセッションはLOW_PRIORITYコンシューマ・グループに再割当てされます。これは、モジュール名マッピングのほうが、データベース・ユーザー・マッピングより優先度が高いためです。
セッション属性の現在の優先度を確認するには、ビューDBA_RSRC_MAPPING_PRIORITYを問い合せます。
認可されていないクライアントがそのセッション属性を設定して優先度の高いコンシューマ・グループにクライアント自身をマッピングしないように、コンシューマ・グループに対してユーザー・スイッチ特権が適用されます。したがって、特定のセッションの属性がマッピング・ペアと一致した場合でも、指定したコンシューマ・グループに対するスイッチ特権がそのセッションに付与されていない場合は、そのマッピング・ルールは無視されます。
管理者は、ユーザーが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('OLTP', old_group, FALSE); DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group); END; /
次の行が出力されます。
OLD GROUP = DEFAULT_CONSUMER_GROUP
リソース・マネージャでは、セッションをすでに配置されているコンシューマ・グループに切り替えるためにSWITCH_CURRENT_CONSUMER_GROUPプロシージャがコールされている場合でも、切替えが発生したとみなされます。
DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり、取り消すことができます。ユーザーまたはアプリケーションは、スイッチ特権を使用してセッションを指定のリソース・コンシューマ・グループに切り替えることができます。コンシューマ・グループへのセッションのマッピング・ルールに指定されているコンシューマ・グループ、またはリソース・プラン・ディレクティブのSWITCH_GROUPパラメータに指定されているコンシューマ・グループに、セッションを自動的に切り替えることもできます。このパッケージでは、スイッチ特権を取り消すこともできます。次の表に、関連するパッケージ・プロシージャの一覧を示します。
| プロシージャ | 説明 |
|---|---|
|
|
ユーザー、ロールまたは |
|
|
ユーザー、ロールまたは |
DEFAULT_CONSUMER_GROUPでは、スイッチ特権がPUBLICに付与されています。したがって、すべてのユーザーに、このコンシューマ・グループに対するスイッチ特権が自動的に付与されます。
次の例では、コンシューマ・グループ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の場合、コンシューマ・グループのスイッチ特権が付与されたユーザーは、そのコンシューマ・グループのスイッチ特権を他のユーザーに付与することもできます。
次の例では、コンシューマ・グループOLTPに切り替えるユーザーSCOTTの権限を取り消しています。
BEGIN DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP ( REVOKEE_NAME => 'SCOTT', CONSUMER_GROUP => 'OLTP'); END;
特定のコンシューマ・グループに対するユーザーのスイッチ特権を取り消すと、そのユーザーがそのコンシューマ・グループに切り替えようとすると失敗します。ユーザーから初期コンシューマ・グループのスイッチ特権を取り消すと、そのユーザーはログイン時に自動的にDEFAULT_CONSUMER_GROUPに割り当てられます。
コンシューマ・グループに対するスイッチ特権をロールから取り消すと、そのロールを介してのみコンシューマ・グループのスイッチ特権を与えられているユーザーは、そのコンシューマ・グループに切り替えることができなくなります。
コンシューマ・グループに対するスイッチ特権をPUBLICから取り消すと、直接またはロールを介してスイッチ特権を明示的に割り当てられているユーザー以外は、そのコンシューマ・グループに切り替えることができなくなります。
Oracle Database Resource Manager（リソース・マネージャ）を有効にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャはアクティブになりません。
デフォルトでは、リソース・マネージャは有効化されていません。
テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランがmydb_planとして設定されます。
RESOURCE_MANAGER_PLAN = mydb_plan
DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャまたはALTER SYSTEM文を使用して、リソース・マネージャをアクティブ化（または解除）したり、現行のトップレベル・プランを変更することもできます。
次のSQL文は、トップレベルのプランをmydb_planに設定し、リソース・マネージャをアクティブ化します（アクティブ化されていない場合）。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';
指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。
リソース・プランを指定するOracle Schedulerのウィンドウがオープン状態の場合、リソース・マネージャは自動的にアクティブ化されます。スケジューラのウィンドウがクローズ状態の場合、そのウィンドウに関連付けられているリソース・プランは無効で、スケジューラのウィンドウがオープンする前に実行されていたリソース・プランが再度有効になります（ウィンドウのオープン前に有効なリソース・プランがなかった場合、リソース・マネージャはウィンドウのクローズ時に再度無効になります）。Oracle Real Application Clusters環境では、スケジューラのウィンドウはすべてのインスタンスに適用されます。したがって、ウィンドウのリソース・プランはあらゆるインスタンスで有効になります。
デフォルトでは、一連の自動化メンテナンス・タスクはメンテナンス・ウィンドウ内で実行されます。このメンテナンス・ウィンドウは、事前定義のスケジューラのウィンドウで、MAINTENANCE_WINDOW_GROUPウィンドウ・グループのメンバーであり、DEFAULT_MAINTENANCE_PLANリソース・プランを指定するウィンドウです。したがって、デフォルトでは、リソース・マネージャはメンテナンス・ウィンドウの期間中にアクティブ化されます。
場合によっては、スケジューラのウィンドウ境界でのリソース・マネージャ・プランの自動変更は、望ましくない可能性があります。たとえば、終了する必要のある重要なタスクがあり、リソース・マネージャ・プランにタスクの優先度を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、スケジューラのウィンドウはプランの設定後にアクティブになるため、タスクの実行中にリソース・マネージャ・プランが変更される可能性があります。
この状況を回避するには、次のSQL文に示すように、RESOURCE_MANAGER_PLAN初期化パラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:」を付加します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';
接頭辞FORCEを使用することで、現行のリソース・プランの変更は、データベース管理者がRESOURCE_MANAGER_PLAN初期化パラメータの値を変更した場合のみ可能であることを示します。この制限を解除するには、プラン名の前に「FORCE:」を付加せずに、そのコマンドを再実行します。
DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャには同様の機能があります。
リソース・マネージャを無効にするには、次の手順を完了します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
そのためには、resource_plan属性のリソース・プランを参照するすべてのスケジューラのウィンドウについて、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、resource_planを空の文字列（''）に設定します。SYSユーザーでログインしていない場合は、SYSスキーマ名を使用してウィンドウ名を修飾します。スケジューラのウィンドウは、DBA_SCHEDULER_WINDOWSデータ・ディクショナリ・ビューで表示できます。 詳細は、「ウィンドウの変更」および『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
|
注意:
デフォルトでは、すべてのメンテナンス・ウィンドウが |
ここでは、リソース・プランの例をいくつか示します。ここで取り上げる例は、次のとおりです。
次のスクリプトは、図25-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ではレベル1、2および3で割当てを定義し、bugdb_planではレベル1および2で割当てを定義します。これらのサブプランの各レベルは、その親プラン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%の一部）も使用できます。
Users_groupまたはMail_Maint_groupが使用していないCPUリソースはOTHER_GROUPSに割り当てられます。これは、複数レベルのプランの場合、使用されていないリソースは、同じレベルの兄弟ではなく、次の下位レベルのコンシューマ・グループまたはサブプランに再配分されるためです。したがって、Users_groupが80%ではなく70%のみを使用している場合は、残りの10%をMail_Maint_groupで使用することはできません。この10%を使用できるのは、レベル3のOTHER_GROUPSのみです。
ここで示す例は、パッケージ化されたEnterprise Resource Planning（ERP）またはCustomer Relationship Management（CRM）アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理（OLTP）の適切な応答時間を得ることにあります。
次の表にプランがまとめられています。
| グループ | CPUリソース割当て% | アクティブ・セッション・プール・パラメータ | コンシューマ・グループの自動切替え | 最大見積り実行時間 | UNDOプール |
|---|---|---|---|---|---|
|
|
レベル1: 80% |
|
切替え時間: 3秒 |
|
200K |
|
|
レベル2: 100% |
タイムアウト: 600秒 |
-- |
3600秒 |
-- |
|
|
レベル3: 100% |
-- |
-- |
|
-- |
レベル1のoltpにCPUの80%のみを割り当てることで、batchには最低20%が保証され、さらに、oltpが使用しないCPUリソースを使用できます。ただし、OTHER_GROUPSに対するCPUリソースの保証はありません。OTHER_GROUPSがCPUリソースを取得するのは、batchがその割当てを使用できない場合のみです。類似するプランでは、レベル1のoltpに80%、batchに20%が付与され、レベル2のOTHER_GROUPSには100%が付与されます。このプランでは、oltpが使用していないCPU割当てが、batchではなく、OTHER_GROUPSに付与されます。
次の文は、この表のプランを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 => 80, SWITCH_GROUP => 'batch', SWITCH_TIME => 3, UNDO_POOL => 200); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan', GROUP_OR_SUBPLAN => 'batch', COMMENT => 'BATCH sessions', MGMT_P2 => 100, ACTIVE_SESS_POOL_P1 => 5, QUEUEING_P1 => 600, MAX_EST_EXEC_TIME => 3600); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan', GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'mandatory', MGMT_P3 => 100); DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END;
Oracle Databaseには、事前定義のリソース・プランMIXED_WORKLOAD_PLANが用意されています。このプランでは、バッチ操作よりも対話型操作が優先されます。必要なサブプランと推奨するコンシューマ・グループも含まれています。MIXED_WORKLOAD_PLANは、次のように定義されています。
| グループまたはサブプラン | CPUリソース割当て | ||||
|---|---|---|---|---|---|
| レベル1 | レベル2 | レベル3 | コンシューマ・グループの自動切替え | 最大並列度 | |
|
|
|
|
100% |
|
|
|
|
|
85% |
|
コールに対する切替え: |
1 |
|
|
|
5% |
|
|
|
|
|
|
5% |
|
|
|
|
|
|
5% |
|
|
|
|
|
100% |
|
|
|
|
このプランのINTERACTIVE_GROUPは短いトランザクションを対象にしているため、60秒を超えるコールは、長いバッチ操作を対象にしたBATCH_GROUPに自動的に切り替わります。
この事前定義のプランは、自社の環境に対して適切な場合に使用できます。（このプランは変更可能です。使用する予定がない場合は削除できます。）BATCH_GROUPおよびINTERACTIVE_GROUPという名前に特別な意味はありません。これら名前には各グループに関する意図した目的のみが反映されています。対話型アプリケーションとバッチ・アプリケーションで適切なリソース管理を遂行できるように、アプリケーション・セッションをこれらのグループにマップして、CPUリソース割当て率を適切に調整する作業は管理者に任されます。 たとえば、INTERACTIVE_GROUPコンシューマ・グループで対話型アプリケーションを確実に実行するには、「コンシューマ・グループへのセッションのマッピング・ルールの指定」の説明に従って、ユーザー名、サービス名、プログラム名、モジュール名または処理に基づいて、その対話型アプリケーションのユーザー・セッションをこのコンシューマ・グループにマップする必要があります。同様の方法で、バッチ・アプリケーションをBATCH_GROUPにマップすることも必要です。 最後に、「Oracle Database Resource Managerの有効化とプランの切替え」の説明に従って、このプランを有効にしてください。
このプランの他のリソース・コンシューマ・グループとサブプランについては、表25-1および表25-2を参照してください。
ここでは、Oracle Database Resource Manager（リソース・マネージャ）のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスする方法について説明します。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。この項の内容は、次のとおりです。
関連項目:
DBMS_RESOURCE_MANAGER PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを更新する必要があります。引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。
DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを削除する必要があります。コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてDEFAULT_CONSUMER_GROUPが割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはDEFAULT_CONSUMER_GROUPに切り替わります。
リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。
プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、プランを更新する必要があります。引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。次のスクリプトは、COMMENTパラメータを更新するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.UPDATE_PLAN( PLAN => 'DAYTIME', NEW_COMMENT => '50% more resources for OLTP applications'); END;
DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。最初にペンディング・エリアを作成し、発行する前に、プランを削除する必要があります。
次のスクリプトは、great_breadプランとそのディレクティブを削除するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'great_bread'); END;
削除したディレクティブが参照していたリソース・コンシューマ・グループは削除されませんが、great_breadプランとの関連は解除されます。
DELETE_PLAN_CASCADEプロシージャは、指定のプランとその子孫すべて（プラン・ディレクティブ、および必須のマークが付けられていないサブプランとリソース・コンシューマ・グループ）を削除します。エラーが発生したDELETE_PLAN_CASCADEはロールバックされ、プランは変更されません。
現在アクティブなプランは削除できません。
プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、リソース・プラン・ディレクティブを更新する必要があります。引数を指定せずにUPDATE_PLAN_DIRECTIVEプロシージャを実行すると、データ・ディクショナリ内のプラン・ディレクティブは変更されません。
リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、リソース・プラン・ディレクティブを削除する必要があります。
Oracle Database Resource Manager（リソース・マネージャ）の現在の構成とステータスを表示するには、様々な静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。ここでは、次の例を示します。
DBA_RSRC_CONSUMER_GROUP_PRIVSビューには、ユーザーまたはロールに付与されたコンシューマ・グループが表示されます。具体的には、ユーザーまたはロールが属しているグループや、切替え先のグループが表示されます。たとえば、次に示すビューでは、ユーザーSCOTTは常にSALESコンシューマ・グループで開始し、特定の付与を介してMARKETINGグループに切り替えることができます。さらに、DEFAULT_CONSUMER_GROUPグループとLOW_GROUPグループにも切り替えることができます。これは、これらのグループにPUBLICが付与されているためです。また、SCOTTには、他のユーザーにSALESグループを付与する機能がありますが、MARKETINGグループを付与する機能はありません。
SQL> 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パッケージを使用してこれらのグループに切り替える機能がすでに付与されています。
この例では、DBA_RSRC_PLANSビューを使用して、データベース内に定義されているすべてのリソース・プランを表示しています。プランはすべてNULLステータスです。これは、ペンディング・エリア内のプランでないことを意味します。
SQL> SELECT PLAN,COMMENTS,STATUS FROM DBA_RSRC_PLANS; PLAN COMMENTS STATUS -------------------------- ------------------------------------------- ------ MIXED_WORKLOAD_PLAN Example plan for a mixed workload that prio ORA$AUTOTASK_SUB_PLAN Default sub-plan for automated maintenance ORA$AUTOTASK_HIGH_SUB_PLAN Default sub-plan for high-priority, automat ERP_PLAN Resource plan/method for ERP Database DEFAULT_PLAN Default, basic, pre-defined plan that prior INTERNAL_QUIESCE Plan for quiescing the database. This plan INTERNAL_PLAN Internally-used plan for disabling the reso DEFAULT_MAINTENANCE_PLAN Default plan for maintenance windows that p
V$SESSIONビューを使用すれば、セッションに現在割り当てられているコンシューマ・グループを表示できます。
SQL> 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
この例では、mydb_plan（「複数レベルのプランの例」の例で作成したプラン）をトップレベルのプランとして設定しています。次に、V$RSRC_PLANビューを問い合せて、現在アクティブなプランを表示します。このビューには、現行のトップレベルのプランとその子孫のサブプランすべてが表示されます。
SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = mydb_plan; System altered. SQL> SELECT NAME, IS_TOP_PLAN FROM V$RSRC_PLAN; NAME IS_TOP_PLAN ---------------------------- MYDB_PLAN TRUE MAILDB_PLAN FALSE BUGDB_PLAN FALSE
次の動的パフォーマンス・ビューは、Oracle Database Resource Managerの設定結果の監視に役立ちます。
これらのビューには、次の情報が表示されます。
さらに、履歴統計は、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の使用量が、コンシューマ・グループごとに分単位で表示されます。Enterprise Managerでは、これらのメトリックを「リソース・マネージャ統計」ページでグラフィカルに表示できます。
このビューには、現在アクティブなリソース・プランとそのサブプランが表示されます。
SELECT name, is_top_plan FROM v$rsrc_plan; NAME IS_TOP_PLAN -------------------------------- ----------- DEFAULT_PLAN TRUE ORA$AUTOTASK_SUB_PLAN FALSE ORA$AUTOTASK_HIGH_SUB_PLAN FALSE
IS_TOP_PLANがTRUEのプランは、現在アクティブな（トップレベルの）プランです。他のプランは、トップレベルのプランのサブプランか、リスト内の他のサブプランのサブプランです。
CPU使用とCPU待ちを監視するには、V$RSRC_CONSUMER_GROUPビューを使用します。このビューには、各コンシューマ・グループの全セッションについて、CPU使用累積時間、CPU待ち累積時間およびCPU待ち累積回数が表示されます。その他にも、チューニングに役立つ測定値が含まれています。
SQL> 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待機などに起因する待機は含まれません。
1つ以上のセッションを監視するには、このビューを使用します。このビューには、リソース・マネージャによるセッションへの影響が表示されます。次のような情報が表示されます。
RUNNING、WAIT_FOR_CPU、QUEUEDなど）。
SQL> 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$RSRC_CONS_GROUP_HISTORYビューにあり、コンシューマ・グループの累積統計が表示されます。この2つのビューは、それぞれのSEQUENCE#列で結合しています。
SQL> 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ビューに格納されます。
このビューは、時間の経過に従ってコンシューマ・グループ内でリソースがどのように共有されたかを理解するのに役立ちます。sequence#列は、V$RSRC_PLAN_HISTORYビューの同名の列に対応しています。これによって、コンシューマ・グループ統計の各行について、アクティブであったプランを判別できます。
SQL> 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 2 ORA$DIAGNOSTICS 0 0 1072678 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 . . 6 ORA$DIAGNOSTICS 0 0 0
このビューのAWRスナップショットはDBA_HIST_RSRC_CONSUMER_GROUPビューに格納されます。コンシューマ・グループ統計の各履歴セットについて、アクティブであったプランを判別するには、DBA_HIST_RSRC_CONSUMER_GROUPとDBA_HIST_RSRC_PLANを併用します。
多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。Oracle Databaseは、静的な構成を想定し、データベースの起動時に検出された使用可能なリソースから、ラッチなどの内部リソースを割り当てます。オペレーティング・システムのリソース構成を頻繁に変更すると、データベースが最適に実行されず、不安定になる場合があります。
オペレーティング・システムによるリソース制御をOracle Databaseと併用する場合は、次のガイドラインに従って慎重に使用する必要があります。
ここでは、Oracle Database Resource Manager（リソース・マネージャ）の参照情報を提供します。
各Oracleデータベースに事前定義されているリソース・プランを表25-1にリストし、リソース・コンシューマ・グループを表25-2にリストします。
| リソース・プラン | 説明 |
|---|---|
|
|
メンテナンス・ウィンドウのデフォルト・プラン。 このプランの詳細は、「自動化メンテナンス・タスクに対するリソース割当ての概要」を参照してください。 |
|
|
|
|
|
リソース・マネージャの無効化用。内部処理でのみ使用されます。 |
|
|
データベースの静止用。このプランは直接アクティブ化できません。アクティブ化するには |
|
|
バッチ操作よりも対話型操作を優先させる複合ワークロード・プランの例。 詳細は、「オラクル社が提供する複合ワークロード・プラン」を参照してください。 |
|
|
優先度の高い自動化メンテナンス・タスクのデフォルト・サブプラン。このサブプランは、 |
|
|
自動化メンテナンス・タスクのデフォルト・サブプラン。このサブプランに対するディレクティブは、自動化メンテナンス・タスクによって使用されるリソースを管理するために、すべてのトップレベルのプランに含まれている必要があります。このプランは、 |
表25-3に、DBMS_RESOURCE_MANAGERパッケージのプロシージャの要約を示します。これらのプロシージャを実行するには、ADMINISTER_RESOURCE_MANAGER権限が必要です。
表25-4に、リソース・マネージャに関連付けられているビューをリストします。
