| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
Oracle Database Resource Managerの参照情報
|
注意: この章では、PL/SQLパッケージ・プロシージャを使用してリソース・マネージャを管理する方法について説明します。リソース・マネージャを管理する簡単な方法は、Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用することです。Enterprise Managerを使用してリソース・マネージャを管理する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。 |
Oracle Database Resource Manager (リソース・マネージャ)を使用すると、システム・リソースやデータベース・リソースを求めて競合するデータベース内の複数のワークロードを管理できます。
次の各項では、リソース・マネージャの概要を説明します。
データベース・リソースの割当てがオペレーティング・システムによって決定される場合は、次のようなワークロードの管理に関する問題が生じることがあります。
過剰なオーバーヘッドの発生
過剰なオーバーヘッドは、サーバー・プロセスの数が多いときに、Oracle Databaseサーバー・プロセス間でオペレーティング・システムのコンテキストが切り替わることによって発生します。
非効率的なスケジューリング
オペレーティング・システムは、データベース・サーバーがラッチを保持している間にデータベース・サーバーのスケジュールを解除しますが、これは非効率的です。
不適当なリソースの割当て
オペレーティング・システムはタスク間の優先度付けができないため、すべてのアクティブなプロセスの間で均等にリソースを分配します。
パラレル実行サーバーやアクティブ・セッションなど、データベース固有のリソースを管理できない
リソース・マネージャは、ハードウェア・リソースの割当て方法をデータベースで厳密に制御することによって、これらの問題を克服します。複数のコンカレント・ユーザー・セッションがあり、各セッションでは異なる優先度のジョブが実行される環境では、すべてのセッションが同等に処理されるわけではありません。リソース・マネージャを使用すると、セッション属性に基づいてセッションを複数のグループに分類し、それらのグループに対して、アプリケーション環境のハードウェア利用が最適化されるようにリソースを配分できます。
リソース・マネージャを使用すると、次のことが可能になります。
システムにかかる負荷やユーザー数に関係なく、特定のセッションのCPUが最小量になることを保証します。
様々なユーザーおよびアプリケーションに、比率を指定してCPU時間を割り当てて、使用可能なCPUを分配します。データ・ウェアハウスの場合は、バッチ・ジョブよりもリレーショナル・オンライン分析処理(ROLAP)アプリケーションへの割当て率を高くできます。
ユーザー・グループのメンバーが実行する処理の並列度を制限します。
パラレル・ステートメント・キュー内のパラレル・ステートメントの順序を管理します。優先度の低いユーザー・グループからのパラレル・ステートメントよりも前に、重要なアプリケーションからのパラレル・ステートメントをエンキューできます。
ユーザー・グループが使用できるパラレル・サーバーの数を制限します。これにより、使用可能なすべてのパラレル・サーバーが1つのユーザー・グループにのみ割り当てられることを回避できます。
アクティブ・セッション・プールを作成します。アクティブ・セッション・プールは、ユーザー・グループ内で同時にアクティブにできる指定された最大数のユーザー・セッションで構成されています。最大数を超える追加セッションは実行待ちのキューに送られますが、キューで待機しているジョブが終了するまでのタイムアウト周期を指定できます。アクティブ・セッション・プールによって、リソースについて実際に競合するセッションの総数が制限されるため、アクティブなセッションの進行を早めることができます。
次の方法でリソース集中型のセッションまたはコールを管理します。
グループが使用できるCPUの割合に絶対的な制限を設けます。
セッションまたはコールによって使用されるCPUまたはI/Oが指定量を超過している状況を検出することによって、自動的に、セッションまたはコールを終了するか、またはCPUの割当てが少ないコンシューマ・グループに切り替えます。これにより、実質的にリソース集中型のセッションまたはコールの影響を軽減します。
ある操作に対するオプティマイザの見積り実行時間が指定された制限を超える場合は、その操作が実行されないようにします。
セッションのアイドル時間を制限します。この制限は、他のセッションをブロックしているセッションのみに限定することもできます。
ワークロード要件の変更に基づいて、データベースで様々なリソース・プランを使用できます。インスタンスを停止して再起動しなくても、たとえば、昼間のリソース・プランから夜間のリソース・プランに変更するなど、リソース・プランを動的に変更できます。リソース・プランの変更は、Oracle Schedulerを使用してスケジュールすることもできます。詳細は、第28章「Oracle Schedulerの概要」を参照してください。
次の表に、リソース・マネージャの要素を示します。
これらの要素の作成とメンテナンスには、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用します。要素は、データ・ディクショナリ内の表に格納されます。要素に関する情報は、データ・ディクショナリ・ビューを使用して表示できます。
リソース・コンシューマ・グループ(コンシューマ・グループ)とは、処理要件に基づいてグループ化されたユーザー・セッションの集合です。セッションが作成されると、そのセッションは、管理者が設定したマッピング・ルールに基づいてコンシューマ・グループに自動的にマップされます。データベース管理者(DBA)は、セッションを、異なるコンシューマ・グループに手動で切り替えることができます。同様に、アプリケーションでは、そのセッションを特定のコンシューマ・グループに切り替えるPL/SQLパッケージ・プロシージャを実行できます。
リソース・マネージャによるリソース(CPUなど)の割当て先は、コンシューマ・グループのみであるため、セッションがコンシューマ・グループのメンバーになると、そのリソース割当ては、コンシューマ・グループの割当てによって決定されます。
常にデータ・ディクショナリに存在する特別なコンシューマ・グループがあります。これらのグループは、変更したり削除することはできません。これらを次に示します。
リソース・マネージャは、現在アクティブなリソース・プランに属するリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースをコンシューマ・グループに割り当てます。リソース・プランとそのリソース・プラン・ディレクティブは親子関係にあります。各ディレクティブは1つのコンシューマ・グループを参照し、現在アクティブなプランの2つのディレクティブで同じコンシューマ・グループを参照することはできません。
ディレクティブには、コンシューマ・グループへのリソース割当てを制限できる複数の方法があります。たとえば、CPUにおいてコンシューマ・グループが確保できるCPU全体の割合を制御したり、コンシューマ・グループ内でアクティブにできるセッションの総数を制限できます。詳細は、「リソース・マネージャによって管理されるリソースのタイプ」を参照してください。
各Oracle Databaseに事前定義されているリソース・プランの他に、リソース・プランは必要な数だけ作成できます。ただし、1度にアクティブにできるリソース・プランは1つのみです。リソース・プランがアクティブな場合は、その子の各リソース・プラン・ディレクティブが異なるコンシューマ・グループへのリソース割当てを制御します。各プランには、OTHER_GROUPSというコンシューマ・グループにリソースを割り当てるディレクティブが必要です。OTHER_GROUPSは、現在アクティブなプランの一部でないコンシューマ・グループに属しているすべてのセッションに適用されます。
|
注意: 「リソース・プラン」(または単に「プラン」)という用語はリソース・マネージャの1つの要素を示しますが、この章では、完全なリソース・プラン・スキーマ(リソース・プランの要素そのもの、そのリソース・プラン・ディレクティブ、ディレクティブによって参照されるコンシューマ・グループなど)を指す場合にも使用します。たとえば、この章でDAYTIMEリソース・プランに触れたときは、DAYTIMEというリソース・プラン要素を意味する場合も、DAYTIMEリソース・プランとそのディレクティブが定義する特定のリソース割当てスキーマを意味する場合もあります。したがって、簡潔に言えば、「DAYTIMEプランは、バッチ・アプリケーションよりも対話型アプリケーションに近い」といえます。 |
図27-1は、日中にオンライン・トランザクション処理(OLTP)アプリケーションとレポート・アプリケーションを同時に実行する組織の単純なリソース・プランを示しています。現在アクティブなプランDAYTIMEによって、3つのリソース・コンシューマ・グループにCPUリソースが割り当てられます。具体的には、CPUタイムの75%がOLTPに、15%がREPORTSに、残りの10%がOTHER_GROUPSに割り当てられています。
Oracle Databaseには、単純なリソース・プランを迅速に作成できるプロシージャ(CREATE_SIMPLE_PLAN)が用意されています。このプロシージャについては、「単純なリソース・プランの作成」を参照してください。
|
注意: 現在アクティブなリソース・プランは、CPU使用率が100%になるまで割当てを規定しません。CPU使用率が100%未満の場合、データベースはCPUによる制限を受けないため、すべてのセッションが必要なリソース割当てを獲得できるように割当てを規定する必要はありません。さらに、割当てが規定されている場合は、あるコンシューマ・グループが使用していない割当てを、他のコンシューマ・グループが使用できます。前述の例では、 |
リソース・プラン・ディレクティブ(ディレクティブ)は、コンシューマ・グループを参照するかわりに、別のリソース・プランを参照できます。この場合、そのプランはサブプランと呼ばれます。サブプラン自体に、リソースをコンシューマ・グループと他のサブプランに割り当てるディレクティブがあります。その場合、リソースの割当て方式は次のように機能します。トップレベルのリソース・プラン(現在アクティブなプラン)によって、リソースがコンシューマ・グループおよびサブプランに分割されます。次に、各サブプランによって、リソース割当て合計の一部がそのコンシューマ・グループとサブプランに割り当てられます。階層的なプランは、必要な数のサブプランを使用して作成できます。
リソース・サブプランは、リソース・プランを作成する方法と同じ方法で作成します。サブプランとしてのみ使用されるプランを作成するには、パッケージ・プロシージャDBMS_RESOURCE_MANAGER.CREATE_PLANでSUB_PLAN引数を使用します。
トップレベルのプランでは、サブプランを1回のみ参照できます。サブプランは、OTHER_GROUPSへのディレクティブを必要とせず、リソース・プランとして設定できません。
この例では、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プランを参照するディレクティブを設定できません。
リソース・マネージャを管理するには、システム権限ADMINISTER_RESOURCE_MANAGERが必要です。この権限(ADMINオプション付き)は、DBAロールを介してデータベース管理者に付与されます。
リソース・マネージャの管理者は、DBMS_RESOURCE_MANAGER PL/SQLパッケージ内のすべてのプロシージャを実行できます。
ADMINオプションを持つ管理者は、必要に応じて管理権限を他のユーザーまたはロールに付与できます。そうするには、DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用します。次の表に、関連するパッケージ・プロシージャの一覧を示します。
| プロシージャ | 説明 |
|---|---|
GRANT_SYSTEM_PRIVILEGE |
ユーザーまたはロールに、ADMINISTER_RESOURCE_MANAGERシステム権限を付与します。 |
REVOKE_SYSTEM_PRIVILEGE |
ユーザーまたはロールから、ADMINISTER_RESOURCE_MANAGERシステム権限を取り消します。 |
次のPL/SQLブロックは、ユーザーHRに管理権限を付与しますが、HRにADMINオプションは付与しません。そのため、HRはDBMS_RESOURCE_MANAGERパッケージのすべてのプロシージャを実行できますが、HRはGRANT_SYSTEM_PRIVILEGEプロシージャを使用して他のユーザーに管理権限を付与することはできません。
BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( GRANTEE_NAME => 'HR', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER', ADMIN_OPTION => FALSE); END; /
この権限は、REVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消すことができます。
|
関連項目: リソース・マネージャのパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
『Oracle Databaseセキュリティ・ガイド』では、 |
ここでは、データベース管理者、ユーザーおよびアプリケーションがセッションをリソース・コンシューマ・グループに割り当てる際に使用できる自動および手動の方法について説明します。セッションがリソース・コンシューマ・グループに割り当てられると、Oracle Database Resource Manager(リソース・マネージャ)では、そのセッションに対するリソース割当てが管理の対象となります。
|
注意: コンシューマ・グループに割り当てられていないセッションは、コンシューマ・グループOTHER_GROUPSに配置されます。 |
この項の内容は次のとおりです。
リソース・マネージャを有効にする前に、ユーザー・セッションをリソース・コンシューマ・グループに割り当てる方法を指定する必要があります。これを行うために、マッピング・ルールを作成すると、セッションの起動時に、セッション属性に基づいてリソース・マネージャによって自動的に各セッションがコンシューマ・グループに割り当てられるようにすることができます。セッションがその初期コンシューマ・グループに割り当てられ実行された後は、プロシージャをコールして、セッションを別のコンシューマ・グループに手動で切り替えることができます。この操作は、リソースを過剰に使用しているセッションを、よりリソース割当ての制限されたコンシューマ・グループに移動する必要がある場合などに実行します。また、ユーザーおよびアプリケーションにスイッチ特権を付与して、ユーザーおよびアプリケーションが、あるコンシューマ・グループから別のコンシューマ・グループに自分のセッションを切り替えることができるようにすることができます。
セッション属性に変更がある場合やセッションが指定のリソース使用制限を超える場合は、あるコンシューマ・グループから別の(通常は優先度の低い)コンシューマ・グループにセッションを自動的に切り替えることもできます。
セッションの初期コンシューマ・グループは、管理者が構成するマッピング・ルールによって決まります。マッピング・ルールの構成方法は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。
ここでは、コンシューマ・グループへのセッションのマッピング・ルールに関するバックグラウンド情報を提供し、ルールの作成方法と優先度の設定方法について説明します。この章では、次の項目について説明します。
コンシューマ・グループへのセッションのマッピング・ルールを作成すると、次のことができます。
セッションの初期コンシューマ・グループをセッション属性に基づいて指定できます。
リソース・マネージャを使用して、実行中のセッションをセッション属性の変更に基づいて別のコンシューマ・グループに動的に切り替えることができます。
このマッピング・ルールは、セッション属性(ユーザー名、セッションがデータベースへの接続に使用したサービス、クライアント・プログラムの名前など)に基づいています。
マッピング・ルール間の競合を解決するために、リソース・マネージャでは、各ルールが優先度別に順序付けされます。たとえば、ユーザー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-6で指定されている事前定義のコンシューマ・グループに自動的にマップされます。
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらの事前定義のマッピング・ルールを変更または削除できます。
セッション属性と値のペアをコンシューマ・グループにマップするには、SET_CONSUMER_GROUP_MAPPINGプロシージャを使用します。このプロシージャのパラメータは、次のとおりです。
| パラメータ | 説明 |
|---|---|
ATTRIBUTE |
セッション属性タイプ。パッケージ定数として指定されています。 |
VALUE |
属性の値。 |
CONSUMER_GROUP |
この属性と値のペアのマッピング先のコンシューマ・グループ。 |
ATTRIBUTEには、次のいずれかを指定できます。
| 属性 | タイプ | 説明 |
|---|---|---|
ORACLE_USER |
ログイン | Oracle Databaseユーザー名。 |
SERVICE_NAME |
ログイン | クライアントが接続の確立に使用したデータベース・サービス名。 |
CLIENT_OS_USER |
ログイン | ログインしているクライアントのオペレーティング・システム・ユーザー名。 |
CLIENT_PROGRAM |
ログイン | サーバーへのログインに使用されたクライアント・プログラム名。 |
CLIENT_MACHINE |
ログイン | クライアントが接続に使用しているコンピュータ名。 |
CLIENT_ID |
ログイン | セッションのクライアント識別子
クライアント識別子のセッション属性は、 |
MODULE_NAME |
ランタイム | DBMS_APPLICATION_INFO.SET_MODULEプロシージャによる設定、またはそれに相当するOCI属性の設定に従って現在実行されているアプリケーション内のモジュール名。 |
MODULE_NAME_ACTION |
ランタイム | 次のプロシージャのいずれかによる設定、またはそれに相当するOCI属性の設定に従って実行されている現行モジュールと処理の組合せ。
この属性にはモジュール名を指定し、その後ろにピリオド(.)および処理名を順に続けます( |
SERVICE_MODULE |
ランタイム | service_name.module_nameの書式によるサービス名およびモジュール名の組合せ。 |
SERVICE_MODULE_ACTION |
ランタイム | service_name.module_name.action_nameの書式によるサービス名、モジュール名および処理名の組合せ。 |
ORACLE_FUNCTION |
ランタイム | RMANまたはデータ・ポンプ操作。有効な値はDATALOAD、BACKUPおよびCOPYです。これらの値それぞれに事前定義のマッピングがあります。セッションでこれらの機能のいずれかを実行している場合、事前定義のコンシューマ・グループに自動的にマップされます。詳細は、表27-6を参照してください。 |
たとえば、次の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
コンシューマ・グループ・マッピング・ルールを変更するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、新しいコンシューマ・グループを指定します。ルールを削除するには、必要な属性と値のペアに対してSET_CONSUMER_GROUP_MAPPINGプロシージャを実行し、NULLのコンシューマ・グループを指定します。
競合するマッピング・ルールを解決するために、最も高い重要度のセッション属性から最も低いセッション属性まで優先度を設定できます。各属性に、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パッケージおよびタイプ・リファレンス』で詳細に説明されている次のパッケージ・プロシージャを使用して、コンシューマ・グループを明示的に切り替えます。
|
マッピング・ルールの優先度がどのように機能するかを示すために、引き続き前の例を使用して、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_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ビューを使用して確認できます。
|
関連項目: V$SESSIONビューの詳細は、『Oracle Databaseリファレンス』 |
管理者は、ユーザーがDBMS_SESSIONパッケージのSWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、現在のコンシューマ・グループを切り替えられるように、スイッチ特権をユーザーに付与できます。ユーザーが対話型セッション(SQL*Plusなど)でこのプロシージャを実行するか、アプリケーションでこのプロシージャをコールすることで、セッションを切り替え、実質的にその優先度を動的に変更できます。
ユーザーは、SWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、スイッチ特権があるコンシューマ・グループにのみ切り替えることができます。他のプロシージャからこのプロシージャがコールされた場合、ユーザーはコール側のプロシージャの所有者がスイッチ特権を持っているコンシューマ・グループに切り替えることができます。
| パラメータ | 説明 |
|---|---|
NEW_CONSUMER_GROUP |
切替え先のコンシューマ・グループ。 |
OLD_CONSUMER_GROUP |
切替え元のコンシューマ・グループの名前が戻ります。このパラメータは、後で元のコンシューマ・グループに再び切り替えるときに使用できます。 |
INITIAL_GROUP_ON_ERROR |
切替えエラー発生時の動作を制御します。
|
次の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パッケージおよびタイプ・リファレンス』 |
特定の条件を満たしたときに、セッションを別のコンシューマ・グループに自動的に切り替えるように、リソース・マネージャを構成できます。自動切替えは、次の場合に実行されます。
セッション属性が変更され、新しいマッピング・ルールが有効になった場合。
セッションが、そのコンシューマ・グループに設定されているCPUまたはI/Oリソースの使用制限を超えた場合。
この項の内容は、次のとおりです。
セッションの実行中にセッション属性が変更されると、コンシューマ・グループへのセッションのマッピング・ルールが再評価されます。新しいルールが有効になると、セッションが別のコンシューマ・グループに移動されることがあります。詳細は、「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照してください。
ここでは、指定された制限を超えるCPUリソースまたはI/Oリソースを使用する、リソース集中型のセッションまたはコールの管理について説明します。リソース集中型のセッションはSQL問合せ、リソース集中型のコールはPL/SQLコールです。
コンシューマ・グループに対してリソース・プラン・ディレクティブを作成する場合は、そのグループのセッションに対してCPUおよびI/Oリソースの使用制限を指定できます。その後、セッション内の単一のコールが制限のいずれかを超過した場合に実行する処理を指定できます。次のような処理が考えられます。
セッションを指定のコンシューマ・グループに動的に切り替えます。
通常、ターゲット・コンシューマ・グループは、より低いリソース割当てのコンシューマ・グループです。セッションのユーザーは、新しいコンシューマ・グループに対するスイッチ特権を持っている必要があり、持っていない場合は切替えを行えません。詳細は、「スイッチ特権の付与と取消し」を参照してください。
セッションを停止(終了)します。
セッションの現行のSQL文を中止します。
このタイプのセッション自動切替えに関連するリソース・プラン・ディレクティブの属性は、次のとおりです。
SWITCH_GROUP
SWITCH_TIME
SWITCH_ESTIMATE
SWITCH_IO_MEGABYTES
SWITCH_IO_REQS
SWITCH_FOR_CALL
これらの属性の詳細は、「リソース・プラン・ディレクティブの作成」を参照してください。
切替えは、実行中でリソースを使用しているセッション(ユーザー入力またはCPUサイクルを待機中でないセッション)に対して行われます。セッションが切り替えられた後は、アイドル状態になるまでターゲット・コンシューマ・グループで継続され、アイドル状態になると、元のコンシューマ・グループに切替えが戻されます。ただし、SWITCH_FOR_CALLがTRUEに設定されている場合、リソース・マネージャは、セッションがアイドル状態になるまで待機して元のリソース・コンシューマ・グループにセッションを戻す処理を行いません。かわりに、現在のトップレベルのコールが完了すると、セッションは戻されます。PL/SQLの場合、トップレベルのコールは、1つのコールとして処理されるPL/SQLブロック全体です。SQLの場合、トップレベルのコールは、個々のSQL文です。
リソース・マネージャは、コールの間隔が一定の時間を超えたセッションをアイドル状態とみなします。この時間間隔は設定できません。
SWITCH_FOR_CALLは、中間層のサーバーがセッション・プーリングを使用している3層アプリケーションの場合に有効です。
新しいグループのアクティブ・セッション・プールが一杯の場合も、切り替えたセッションは引き続き実行できます。このような状況では、コンシューマ・グループは、アクティブ・セッション・プールで指定された数より多いセッションを実行できます。
次に、リソース制限に基づいた自動切替えの例を示します。
例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; /
DBMS_RESOURCE_MANAGER_PRIVS PL/SQLパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり取り消すことができます。スイッチ特権を使用すると、ユーザーまたはアプリケーションが、指定されているリソース・コンシューマ・グループにセッションを切り替えることができるようになります。また、データベースによって自動的に、コンシューマ・グループへのセッションのマッピング・ルール、またはリソース・プラン・ディレクティブのSWITCH_GROUPパラメータで指定されているコンシューマ・グループにセッションが切り替えられるようにすることもできます。このパッケージでは、スイッチ特権を取り消すこともできます。次の表に、関連するパッケージ・プロシージャの一覧を示します。
| プロシージャ | 説明 |
|---|---|
GRANT_SWITCH_CONSUMER_GROUP |
ユーザー、ロールまたはPUBLICに、指定したリソース・コンシューマ・グループに切り替える許可を付与します。 |
REVOKE_SWITCH_CONSUMER_GROUP |
ユーザー、ロールまたはPUBLICから、指定したリソース・コンシューマ・グループに切り替える許可を取り消します。 |
OTHER_GROUPSでは、スイッチ特権が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; /
特定のコンシューマ・グループに対するユーザーのスイッチ特権を取り消すと、そのユーザーがそのコンシューマ・グループに切り替えようとすると(手動での切替え、またはコンシューマ・グループのマッピング・ルールを使用した自動での切替えのいずれも)、失敗します。このユーザーのセッションは、自動的にOTHER_GROUPSに割り当てられます。
コンシューマ・グループに対するスイッチ特権をロールから取り消すと、そのロールを介してのみコンシューマ・グループのスイッチ特権を与えられているユーザーは、そのコンシューマ・グループに切り替えることができなくなります。
コンシューマ・グループに対するスイッチ特権をPUBLICから取り消すと、直接またはロールを介してスイッチ特権を明示的に割り当てられているユーザー以外は、そのコンシューマ・グループに切り替えることができなくなります。
リソース・プラン・ディレクティブは、リソース・コンシューマ・グループまたはサブプランへのリソースの割当て方法を指定します。各ディレクティブでは、リソースをそのコンシューマ・グループまたはサブプランに割り当てるための複数の異なる方法を指定できます。次の各項では、これらのリソース割当て方法について簡単に説明します。
CPUリソースを管理するために、リソース・マネージャはリソースをコンシューマ・グループに割り当て、割り当てられたものの使用されなかったCPUリソースを再配分します。特定のコンシューマ・グループに割り当てることができるCPUリソースの量に制限を設定することもできます。
リソース・マネージャでは、次のリソース・プラン・ディレクティブ属性を使用して、CPUリソース割当てを制御できます。
管理属性
管理属性では、コンシューマ・グループおよびサブプランの間でのCPUリソースの割当て方法を指定します。複数レベル(最大8レベル)のCPUリソース割当てによって、プラン内でCPU使用の優先度を設定できます。レベル2のコンシューマ・グループとサブプランは、レベル1に割り当てられなかったリソース、またはレベル1に割り当てられたがレベル1のコンシューマ・グループまたはサブプランで完全には使用されなかったリソースを取得します。同様に、レベル3のリソース・コンシューマには、レベル1と2の割当ての一部が残っている場合のみ、リソースが割り当てられます。リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、割合およびレベルで構成されます。複数のレベルを使用すると、優先度を設定できるのみでなく、すべての主リソースと残りのリソースの使用方法を明示的に指定できます。
管理属性MGMT_Pn(nは1から8の整数)は、複数レベルのCPUリソース割当てを指定する場合に使用します。たとえば、MGMT_P1ディレクティブ属性を使用してレベル1でCPUリソース割当てを指定し、MGMT_P2ディレクティブ属性を使用してレベル2でリソース割当てを指定します。
パラレル・ステートメント・キューイングを制御するには、管理属性とともに、並列度制限やパラレル・ターゲット率などのパラレル・ステートメント・ディレクティブ属性を使用します。パラレル・ステートメント・キューイングが使用されている場合、管理属性はどのコンシューマ・グループが次のパラレル・ステートメントを発行できるかを決定するために使用されます。たとえば、コンシューマ・グループのMGMT_P1ディレクティブ属性を80に設定した場合、そのグループが次のパラレル・ステートメントを発行する確率は80%になります。
|
関連項目: パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
また、管理属性を使用すると、Exadata I/OのCPUリソース割当てを指定できます。
|
関連項目: Exadataの入出力に関する管理属性の使用の詳細は、Exadataのドキュメントを参照してください。 |
表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%はプランの他のすべてのコンシューマ・グループおよびサブプランに比例で再配分できます。
前の使用例で、他の部分が非アクティブであるために、LOW_GROUPがCPUの90%を取得したとします。重要ではないセッションにCPUを大量に使用させないために、LOW_GROUPがサーバーの90%を使用できないようにするとします。リソース・プラン・ディレクティブのMAX_UTILIZATION_LIMIT属性を使用して、この状況を防ぐことができます。
MAX_UTILIZATION_LIMIT属性は、リソース・コンシューマ・グループのCPU使用率に絶対上限を設定する場合に使用します。この絶対的な制限により、プラン内でのCPUの再配布は無視されます。
MAX_UTILIZATION_LIMIT属性の設定はオプションです。コンシューマ・グループに対するこの属性を省略した場合は、コンシューマ・グループが使用できるCPUの量に制限はありません。このため、他のすべてのアプリケーションがアイドル状態である場合、MAX_UTILIZATION_LIMITが設定されていないコンシューマ・グループに100%のCPUリソースを割り当てることができます。
レベルの制限を使用しないで、コンシューマ・グループのCPU使用率を制限する唯一の手段としてMAX_UTILIZATION_LIMIT属性を使用することもできます。
表27-2に、前のプランを変更したプランを示します。このプランでは、MAX_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ではMAX_UTILIZATION_LIMITを50%に設定します。このため、より多くのCPUリソースが使用可能である場合も、サブプランMAINT_SUBPLANに属するコンシューマ・グループには50%を超えたCPUを割り当てることができません。
サブプランとそのサブプランに含まれているコンシューマ・グループの両方にMAX_UTILIZATION_LIMITを設定できます。このような場合、コンシューマ・グループの制限はサブプランとそのコンシューマ・グループに指定されている制限を使用して算出されます。たとえば、MAINT_SUBPLANには、コンシューマ・グループMAINT_GROUP1とMAINT_GROUP2が含まれています。MAINT_GROUP1のMAX_UTILIZATION_LIMITは40%に設定されています。ただし、MAINT_SUBPLANの制限は50%に設定されています。このため、コンシューマ・グループMAINT_GROUP1の制限は50%の40%、つまり20%になります。コンシューマ・グループとそのグループが属するサブプランの両方に制限が指定されている場合に、コンシューマ・グループのMAX_UTILIZATION_LIMITを計算する方法の例については、「例4 - コンシューマ・グループおよびサブプランに最大使用率の制限を指定する」を参照してください。
管理者は、1つのコンシューマ・グループ内での操作に対して最大並列度を制限できます。並列度は、単一の処理に対応付けられるパラレル実行サーバーの数で表されます。PARALLEL_DEGREE_LIMIT_P1ディレクティブ属性は、コンシューマ・グループの並列度を指定する場合に使用します。
|
関連項目: プロデューサ/コンシューマ操作での並列度の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
並列度制限は、コンシューマ・グループ内の1つの操作に対して適用されます(コンシューマ・グループ内のすべての操作の合計並列度は制限されません)。ただし、PARALLEL_DEGREE_LIMIT_P1とPARALLEL_TARGET_PERCENTAGEの両方のディレクティブ属性を組み合せて、任意の制御を行うことは可能です。PARALLEL_TARGET_PERCENTAGE属性の詳細は、「パラレル・ターゲット率」を参照してください。
単一のコンシューマ・グループが数多くのパラレル・ステートメントを起動することによって、使用可能なすべてのパラレル・サーバーが使用されることがあります。この場合、別のコンシューマ・グループから優先度の高いパラレル・ステートメントが実行されても、このグループにパラレル・サーバーを割り当てることができません。このような状況を回避するには、特定のコンシューマ・グループが使用できるパラレル・サーバーの数を制限します。
|
注意: この機能は、Oracle Database 11gリリース2(11.2.0.2)以上で使用できます。 |
PARALLEL_TARGET_PERCENTAGEディレクティブ属性は、特定のコンシューマ・グループが使用できるパラレル・サーバー・プールの最大割合を指定する場合に使用します。特定のコンシューマ・グループで使用されているパラレル・サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル・サーバーの合計となります。
|
関連項目: パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
たとえば、PARALLEL_SERVERS_TARGET初期化パラメータによってパラレル・サーバーの総数が32に設定され、コンシューマ・グループMY_GROUPのPARALLEL_TARGET_PERCENTAGEディレクティブ属性が50%に設定されているとします。このコンシューマ・グループは、最大で32の50%、つまり16台のパラレル・サーバーを使用できます。
リソース・プランで管理属性(MGMT_P1、MGMT_P2など)が設定された場合は、管理属性ごとに別々のパラレル・ステートメント・キューが先入れ先出し(FIFO)キューとして管理されます。
リソース・プランで管理属性が設定されない場合は、1つのパラレル・ステートメント・キューがFIFOキューとして管理されます。
Oracle Real Application Clusters(Oracle RAC)環境の場合、パラレル・サーバーのターゲット数はすべてのOracle RACインスタンスでの(PARALLEL_TARGET_PERCENTAGE * PARALLEL_SERVERS_TARGET /100)の合計となります。あるコンシューマ・グループが上記で算出した数以上のパラレル・サーバーを使用している場合、そのコンシューマ・グループは制限値を超えているため、そのコンシューマ・グループのパラレル・ステートメントはキューされます。
コンシューマ・グループにOracle RACデータベース内で実行されているパラレル・ステートメントがない場合、最初のパラレル・ステートメントはPARALLEL_TARGET_PERCENTAGEで指定された制限を超えることができます。
|
注意: Oracle Real Application Clusters(Oracle RAC)環境では、PARALLEL_TARGET_PERCENTAGE属性が単一のインスタンスではなくクラスタ全体に適用されます。 |
PARALLEL_TARGET_PERCENTAGE属性を使用すると、いつコンシューマ・グループからパラレル・ステートメントをキューできるかを指定できます。Oracle Databaseには、コンシューマ・グループごとにパラレル・ステートメント・キューが保持されます。
コンシューマ・グループからのパラレル・ステートメントは実行されず、そのかわり、次の条件が満たされた場合に、そのコンシューマ・グループのパラレル・ステートメント・キューに追加されます。
PARALLEL_DEGREE_POLICYがAUTOに設定されています。
このパラメータをAUTOに設定すると、自動並列度(Auto DOP)、パラレル・ステートメント・キューイングおよびメモリー内パラレル実行が有効になります。
PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されているパラレル・ステートメントはただちに実行され、パラレル・ステートメント・キューに追加されません。
すべてのコンシューマ・グループのアクティブなパラレル・サーバー数が、PARALLEL_SERVERS_TARGET初期化パラメータの設定を超えています。この条件は、PARALLEL_TARGET_PERCENTAGEを指定しているかどうかに関係なく適用されます。PARALLEL_TARGET_PERCENTAGEが指定されていない場合は、100%にデフォルト設定されます。
コンシューマ・グループのアクティブなパラレル・サーバーの総数およびパラレル・ステートメントの並列度がアクティブなパラレル・サーバーのターゲット数を超えています。
アクティブなパラレル・サーバーのターゲット数は、次のように計算されます。
PARALLEL_TARGET_PERCENTAGE/100 * PARALLEL_SERVERS_TARGET
パラレル・ステートメント・キューイングを使用すると、データベースにパラレル・ステートメントを実行するほどのリソースがない場合、そのステートメントは必要なリソースが使用可能になるまでキューで待機します。ただし、パラレル・ステートメントが意図した時間よりも長くパラレル・ステートメント・キューで待機する場合があります。このような状況を回避するには、パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を指定します。
|
注意: この機能は、Oracle Database 11gリリース2(11.2.0.2)以降で使用可能です。 |
PARALLEL_QUEUE_TIMEOUTディレクティブ属性を使用すると、パラレル・ステートメントがパラレル・ステートメント・キュー内でタイムアウトになるまで待機する最大時間を秒単位で指定できます。PARALLEL_QUEUE_TIMEOUT属性は、コンシューマ・グループごとに設定できます。この属性は、リソース・プランの他の管理属性(MGMT_P1、MGMT_P2など)を指定していなくても適用できます。
|
関連項目: パラレル・ステートメント・キューイングの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
|
注意: パラレル・ステートメント・キューはクラスタ全体で機能するため、パラレル・ステートメント・キューに関連するすべてのディレクティブもクラスタ全体で機能します。 |
パラレル・ステートメントがタイムアウトすると、ステートメントの実行は次のエラー・メッセージで終了します。
ORA-07454: queue timeout, n second(s), exceeded
ワークロード単位で細かく管理する場合は、次のディレクティブ属性を使用する必要があります。
MGMT_Pn
管理属性は、パラレル・ステートメント・キューから実行するパラレル・ステートメントをどのように選択するかを制御します。あるコンシューマ・グループのパラレル・ステートメントを別のグループよりも優先させるには、そのグループの管理属性の値を大きくします。
PARALLEL_TARGET_PERCENTAGE
PARALLEL_QUEUE_TIMEOUT
PARALLEL_DEGREE_LIMIT_P1
すべてのセッションでパラレル・サーバーの使用状況が監視されますが、設定したパラレル・サーバー・ディレクティブ属性はパラレル・ステートメント・キューイングが有効になっている(PARALLEL_DEGREE_POLICYがAUTOに設定されている)セッションにのみに影響を与えます。セッションのPARALLEL_DEGREE_POLICYがMANUALに設定されている場合、このセッションからのパラレル・ステートメントはキューされません。ただし、このようなセッションで使用されているパラレル・サーバーは、PARALLEL_TARGET_PERCENTAGEの制限の決定に使用されるカウントに数えられます。この制限を超えても、このセッションからのパラレル・ステートメントはキューされません。
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが定義されます。アクティブ・セッションとは、現在、トランザクションまたはSQL文を処理しているセッションです。具体的には、アクティブ・セッションは、ユーザー・エンキューを保持した状態でトランザクション内にあるか、またはオープン・カーソルを持ちつつ5秒を超える長さにわたりアイドル状態になっていないかのいずれかです。アクティブ・セッションは、セッションがブロックされている場合であっても(たとえば、I/O要求の完了の待機中など)、アクティブであるとみなされます。アクティブ・セッション・プールが一杯になると、コールの処理を試行しているセッションはキューに送られます。アクティブ・セッションが完了すると、キュー内の最初のセッションがキューから削除されて実行がスケジュールされます。また、実行キュー内のセッションがタイムアウトして、そのコールがエラーで終了されるまでの時間も指定できます。
OLTPワークロードにはアクティブ・セッションの制限を使用しないでください。また、接続プーリングまたはパラレル・ステートメント・キューイングを実装する目的でアクティブ・セッションの制限を使用しないでください。
パラレル・ステートメントを管理するには、PARALLEL_TARGET_PERCENTAGE属性および管理属性(MGMT_P1、MGMT_P2など)とともに、パラレル・ステートメント・キューイングを使用する必要があります。
この方法を使用すると、指定のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソース割当てを制御できます。通常、この方法は、グループ内の典型的なセッションに対するリソース使用予測を上回ったセッションを、優先度の高いコンシューマ・グループ(システム・リソースを高い比率で使用するグループ)から優先度の低いコンシューマ・グループに切り替えるために使用します。
詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。
ディレクティブを指定すると、システム・リソースの使用量に基づいて、長時間実行SQL問合せを取り消したり、長時間実行セッションを終了できます。詳細は、「リソース制限の設定による自動切替えの指定」を参照してください。
ある操作に許可される最大の実行時間を指定できます。ある操作についてデータベースが見積った実行時間が、指定された最大実行時間より長い場合、その操作はエラーを出力して終了します。このエラーはトラップ可能であり、操作は再スケジュールできます。
UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールは、コンシューマ・グループが生成できる、コミットされていないトランザクションに対するUNDO合計量を制御します。コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、そのUNDOを生成している現行のデータ操作言語(DML)文が終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たにデータ操作を実行できません。
セッションがアイドル状態のままでいられる時間(セッションが終了されるまでの時間)を指定できます。また、アイドル状態で他のセッションをブロックしているセッションに適用される、さらに厳密なアイドル時間制限も指定できます。
CREATE_SIMPLE_PLANプロシージャを使用すると、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。このプロシージャでは、1回のプロシージャ・コールの実行で、コンシューマ・グループを作成し、そのグループにリソースを割り当てることができます。このプロシージャを使用する際は、ペンディング・エリアの作成、各コンシューマ・グループの個別作成、リソース・プラン・ディレクティブの指定のために、後述のプロシージャをコールする必要はありません。
CREATE_SIMPLE_PLANプロシージャには、次の引数を指定します。
| パラメータ | 説明 |
|---|---|
SIMPLE_PLAN |
計画の名前。 |
CONSUMER_GROUP1 |
1番目のグループのコンシューマ・グループ名 |
GROUP1_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP2 |
2番目のグループのコンシューマ・グループ名 |
GROUP2_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP3 |
3番目のグループのコンシューマ・グループ名 |
GROUP3_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP4 |
4番目のグループのコンシューマ・グループ名 |
GROUP4_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP5 |
5番目のグループのコンシューマ・グループ名 |
GROUP5_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP6 |
6番目のグループのコンシューマ・グループ名 |
GROUP6_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP7 |
7番目のグループのコンシューマ・グループ名 |
GROUP7_PERCENT |
このグループに割り当てるCPUリソース |
CONSUMER_GROUP8 |
8番目のグループのコンシューマ・グループ名 |
GROUP8_PERCENT |
このグループに割り当てるCPUリソース |
このプロシージャでは、最大8個のコンシューマ・グループを指定できます。サポート対象のリソース割当て方法は、CPUによる方法のみです。プランでは、EMPHASIS CPU割当てポリシー(デフォルト)が使用され、各コンシューマ・グループでは、ROUND_ROBINスケジューリング・ポリシー(これもデフォルト)が使用されます。プラン内の指定された各コンシューマ・グループには、レベル2のCPUパーセンテージが割り当てられます。このプランには、SYS_GROUP(ユーザーSYSおよびSYSTEM用にシステムによって定義された初期コンシューマ・グループ)とOTHER_GROUPSも暗黙的に含まれています。SYS_GROUPコンシューマ・グループには、レベル1でCPUの100%が割り当てられ、OTHER_GROUPSには、レベル3でCPUの100%が割り当てられます。
例: CREATE_SIMPLE_PLANプロシージャを使用した単純なプランの作成
次のスクリプトは、ユーザー指定の2つのコンシューマ・グループを備えた単純なリソース・プランを作成するPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'SIMPLE_PLAN1', CONSUMER_GROUP1 => 'MYGROUP1', GROUP1_PERCENT => 80, CONSUMER_GROUP2 => 'MYGROUP2', GROUP2_PERCENT => 20); END; /
この文を実行すると、次のプランが作成されます。
| コンシューマ・グループ | レベル1 | レベル2 | レベル3 |
|---|---|---|---|
SYS_GROUP |
100% | - | - |
MYGROUP1 |
- | 80% | - |
MYGROUP2 |
- | 20% | - |
OTHER_GROUPS |
- | - | 100% |
|
関連項目:
|
複雑なリソース・プランが必要な場合は、ペンディング・エリアと呼ばれるステージング領域で、プランとそのディレクティブやコンシューマ・グループを作成し、そのプランの妥当性をチェックしてから、データ・ディクショナリに保存する必要があります。
複雑なリソース・プランの作成に必要な手順の概要は、次のとおりです。
|
注意: 複雑なリソース・プランとは、DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLANプロシージャでは作成できないリソース・プランを指します。 |
手順1: ペンディング・エリアを作成します。
手順2: コンシューマ・グループを作成、変更または削除します。
手順3: リソース・プランを作成します。
手順4: リソース・プラン・ディレクティブを作成します。
手順5: ペンディング・エリアの妥当性をチェックします。
手順6: ペンディング・エリアを発行します。
これらの手順は、DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを使用して完了します。この項の内容は、次のとおりです。
|
関連項目:
|
ペンディング・エリアとは、現在実行中のアプリケーションに影響を与えることなく、新規リソース・プランの作成、既存のプランの更新、またはプランの削除を実行できるステージング領域です。ペンディング・エリアを作成すると、データベースによってペンディング・エリアが初期化され、既存のプランがペンディング・エリアにコピーされて、既存のプランを更新できるようになります。
|
ヒント: ペンディング・エリアを作成した後、DBA_RSRC_PLANSデータ・ディクショナリ・ビューを問い合せてすべてのプランをリストすると、各プランについて2つのコピー(PENDINGステータスが付いているコピーと付いていないコピー)が表示されます。PENDINGステータスのプランには、ペンディング・エリアの作成後に実行した変更内容が反映されています。保留中の変更は、コンシューマ・グループの場合はDBA_RSRC_CONSUMER_GROUPSを使用して、リソース・プラン・ディレクティブの場合はDBA_RSRC_PLAN_DIRECTIVESを使用して表示できます。詳細は、「リソース・マネージャのデータ・ディクショナリ・ビュー」を参照してください。 |
変更を追加した後のペンディング・エリアは、発行する前に妥当性をチェックします。発行すると、保留中の変更内容がすべてデータ・ディクショナリに適用され、ペンディング・エリアはクリアされ、解除されます。
最初にペンディング・エリアを作成せずにプランを作成、更新または削除しようとすると(つまり、コンシューマ・グループまたはリソース・プラン・ディレクティブを作成、更新または削除しようとすると)、エラー・メッセージが表示されます。
ペンディング・エリアを発行しても、新しく作成したプランはアクティブ化されません(新しいプランまたは更新後のプランの情報がデータ・ディクショナリに格納されるだけです)。ただし、現在アクティブなプランを変更した場合、そのプランは新しいプラン定義で再アクティブ化されます。リソース・プランをアクティブ化する方法の詳細は、「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プロシージャを使用します。各ディレクティブはプランまたはサブプランに属しており、リソースをコンシューマ・グループまたはサブプランに割り当てます。
|
注意: リソース・プランとそのサブプランに属するディレクティブ全体で1回のみ、特定のサブプランを指定できます。特定のコンシューマ・グループに対するディレクティブは、トップレベルのプランとそのサブプランで指定できます。ただし、リソース・プランとそのサブプランに対するディレクティブ全体で1回のみ、特定のコンシューマ・グループを指定することをお薦めします。 |
次のパラメータを指定できます。
| パラメータ | 説明 |
|---|---|
PLAN |
ディレクティブが属しているリソース・プランの名前。 |
GROUP_OR_SUBPLAN |
リソースを割り当てるコンシューマ・グループまたはサブプランの名前。 |
COMMENT |
任意のコメント。 |
CPU_P1 |
非推奨。MGMT_P1を使用してください。 |
CPU_P2 |
非推奨。MGMT_P2を使用してください。 |
CPU_P3 |
非推奨。MGMT_P3を使用してください。 |
CPU_P4 |
非推奨。MGMT_P4を使用してください。 |
CPU_P5 |
非推奨。MGMT_P5を使用してください。 |
CPU_P6 |
非推奨。MGMT_P6を使用してください。 |
CPU_P7 |
非推奨。MGMT_P7を使用してください。 |
CPU_P8 |
非推奨。MGMT_P8を使用してください。 |
ACTIVE_SESS_POOL_P1 |
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を指定します。他のセッションは、非アクティブ・セッション・キューで実行を待機します。デフォルトはUNLIMITEDです。 |
QUEUEING_P1 |
非アクティブ・セッション・キュー内で実行を待機しているセッションがタイムアウトしてコールが中止されるまでの時間を秒数で指定します。デフォルトはUNLIMITEDです。 |
PARALLEL_DEGREE_LIMIT_P1 |
任意の操作の並列度を制限します。デフォルトはUNLIMITEDです。 |
SWITCH_GROUP |
切替え基準が満たされた場合に、セッションの切替え先となるコンシューマ・グループを指定します。グループ名が'CANCEL_SQL'の場合は、切替え基準が満たされると、現在のコールは取り消されます。グループ名が'KILL_SESSION'の場合は、切替え基準が満たされると、そのセッションは強制終了します。デフォルトはNULLです。
グループ名が' |
SWITCH_TIME |
処理が実行されるまでにコールが実行可能な時間をCPU秒数で指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。 |
SWITCH_ESTIMATE |
TRUEの場合は、各コールの実行時間が見積られ、実行時間の見積りがSWITCH_TIMEを超える場合は、コールを開始する前にセッションをSWITCH_GROUPに切り替えます。デフォルトはFALSEです。
実行時間の見積りはオプティマイザから取得されます。見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。一般的に、統計には±10分未満の誤差があると考えてください。 |
MAX_EST_EXEC_TIME |
コールに許可される最大の実行時間をCPU秒数で指定します。あるコールに対するオプティマイザの見積り実行時間がMAX_EST_EXEC_TIMEを超える場合、そのコールは実行されず、ORA-07455が発行されます。オプティマイザが判断しない場合は、このディレクティブの効果はありません。デフォルトはUNLIMITEDです。
見積りの正確さは、様々な要因(特にオプティマイザ統計の品質)によって異なります。 |
UNDO_POOL |
コンシューマ・グループで生成される、コミットされていないトランザクションのUNDO合計量の最大値をKBで設定します。デフォルトはUNLIMITEDです。 |
MAX_IDLE_TIME |
セッションの最大アイドル時間を秒数で示します。デフォルトはNULLで、無制限を意味します。 |
MAX_IDLE_BLOCKER_TIME |
ブロックしているセッションの最大アイドル時間を秒数で示します。デフォルトはNULLで、無制限を意味します。 |
SWITCH_TIME_IN_CALL |
非推奨。SWITCH_FOR_CALLを使用してください。 |
MGMT_P1 |
MGMT_MTHパラメータがEMPHASISに設定されているプランの場合は、レベル1のCPUパーセンテージを指定します。MGMT_MTHパラメータがRATIOに設定されている場合は、CPU使用の比重を指定します。MGMT_PパラメータのデフォルトはすべてNULLです。 |
MGMT_P2 |
EMPHASISの場合は、レベル2のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P3 |
EMPHASISの場合は、レベル3のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P4 |
EMPHASISの場合は、レベル4のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P5 |
EMPHASISの場合は、レベル5のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P6 |
EMPHASISの場合は、レベル6のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P7 |
EMPHASISの場合は、レベル7のCPUパーセンテージを指定します。RATIOには適用しません。 |
MGMT_P8 |
EMPHASISの場合は、レベル8のCPUパーセンテージを指定します。RATIOには適用しません。 |
SWITCH_IO_MEGABYTES |
処理が実行される前に、セッションで移動(読取りおよび書込み)できるI/Oのサイズ(MB)を指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。 |
SWITCH_IO_REQS |
処理が実行されるまでにセッションが実行可能なI/Oのリクエスト件数を指定します。デフォルトはUNLIMITEDです。処理はSWITCH_GROUPで指定されます。 |
SWITCH_FOR_CALL |
TRUEの場合は、SWITCH_TIME、SWITCH_IO_MEGABYTESまたはSWITCH_IO_REQSに基づいて別のコンシューマ・グループに自動的に切り替えたセッションが、トップレベルのコールが完了した時に当初のコンシューマ・グループに戻されます。デフォルトはNULLです。 |
MAX_UTILIZATION_LIMIT |
コンシューマ・グループに許可する絶対最大CPU使用率。この値は、すべてのレベルのCPU割当て(MGMT_P1からMGMT_P8)よりも優先され、未使用の割当てが再配分されるときの合計CPU使用率の制限にも適用されます。この属性を指定して、MGMT_P1からMGMT_P8をNULLにしておくことができます。 |
PARALLEL_TARGET_PERCENTAGE |
特定のコンシューマ・グループが使用できるパラレル・サーバー・プールの最大割合を指定します。特定のコンシューマ・グループで使用されているパラレル・サーバーの数は、そのコンシューマ・グループのすべてのセッションで使用されているパラレル・サーバーの合計となります。 |
PARALLEL_QUEUE_TIMEOUT |
パラレル・ステートメントがパラレル・ステートメント・キューで待機できる最大時間を秒単位で指定します。この時間を超えると、タイムアウトします。 |
例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コンシューマ・グループに割り当てます。
図27-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に設定されています。
例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になります。
トップレベルのプランと複数のサブプランから同じコンシューマ・グループを参照する場合があります。このような場合は、複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されます。このことは許可されますが、トップレベルのプランおよびそのいずれのサブプランからも同じコンシューマ・グループが参照されないようにすることをお薦めします。
複数のリソース・プラン・ディレクティブによって同じコンシューマ・グループが参照されている場合、次のルールが適用されます。
コンシューマ・グループの並列度制限は、すべての入力値の最小になります。
コンシューマ・グループのアクティブ・セッション・プールは、すべての入力値の合計になり、キューのタイムアウトは、すべての入力タイムアウト値の最小になります。
コンシューマ・グループのUNDOプールは、すべての入力値の合計になります。
複数のSWITCH_TIME、SWITCH_IO_MEGABYTESまたはSWITCH_IO_REQSが存在する場合、Oracle Database Resource Manager (リソース・マネージャ)では、すべての入力値のうち最も制限が厳しいものが選択されます。具体的には、次のようになります。
SWITCH_TIME = min(入力されるすべてのSWITCH_TIME値)
SWITCH_IO_MEGABYTES = min(入力されるすべてのSWITCH_IO_MEGABYTES値)
SWITCH_IO_REQS = min(入力されるすべてのSWITCH_IO_REQS値)
SWITCH_ESTIMATE = FALSEよりもSWITCH_ESTIMATE = TRUEが優先する
|
注意: 両方のプラン・ディレクティブの切替え時間が同じで、切替えグループが異なる場合、切替え先のグループは、リソース・マネージャによって任意に決められた一方に固定されます。 |
いずれかの入力値がTRUEの場合、SWITCH_FOR_CALLはTRUEです。
最大推定実行時間は、すべての入力値のうち最も制限が厳しいものになります。具体的には、次のようになります。
MAX_EST_EXEC_TIME = min(入力されるすべてのMAX_EST_EXEC_TIME値)
最大アイドル時間は、すべての入力値の最小になります。
最大アイドル・ブロッカ時間は、すべての入力値の最小になります。
ペンディング・エリアで変更を追加しているときは、いつでもVALIDATE_PENDING_AREAをコールして、そのペンディング・エリアの妥当性を確認できます。
従う必要がある規則は、次のとおりです。これらの規則が妥当性チェック・プロシージャによってチェックされます。
プランにループを含めることはできません。ループが発生するのは、サブプランに、プラン階層ではそのサブプランの上位となるプランを参照するディレクティブが含まれている場合です。たとえば、サブプランはトップレベルのプランを参照できません。
すべてのプランに、プランまたはリソース・コンシューマ・グループを指すプラン・ディレクティブが必要です。
特定のレベルの全パーセンテージの合計は、100以下であることが必要です。
次のパラメータは、リソース・コンシューマ・グループを参照するプラン・ディレクティブでのみ使用できます。他のリソース・プランを参照するプラン・ディレクティブでは使用できません。
PARALLEL_DEGREE_LIMIT_P1
ACTIVE_SESS_POOL_P1
QUEUEING_P1
SWITCH_GROUP
SWITCH_TIME
SWITCH_ESTIMATE
SWITCH_IO_REQS
SWITCH_IO_MEGABYTES
MAX_EST_EXEC_TIME
UNDO_POOL
MAX_IDLE_TIME
MAX_IDLE_BLOCKER_TIME
SWITCH_FOR_CALL
MAX_UTILIZATION_LIMIT
アクティブなプランに含まれるリソース・コンシューマ・グループ数は、28以内にする必要があります。また、プランは最大28の子を持つことができます。
プランとリソース・コンシューマ・グループには、異なる名前を使用する必要があります。
アクティブなプラン内のどこかに、OTHER_GROUPSのプラン・ディレクティブが存在する必要があります。これによって、現在のアクティブ・プラン内に含まれるコンシューマ・グループのいずれにも属していないセッションに、OTHER_GROUPSのディレクティブで指定したリソースが割り当てられます。
これらの規則のいずれかに違反すると、VALIDATE_PENDING_AREAからエラー・メッセージが返されます。その場合は、変更を加えて問題を修正し、プロシージャを再度コールできます。
プラン・ディレクティブによって参照されない孤立したコンシューマ・グループを作成できます。これによって、当面は使用しないものの、将来的に実装するプランの一部となる、コンシューマ・グループを作成できます。
例: ペンディング・エリアの妥当性チェック
次のスクリプトは、ペンディング・エリアの妥当性をチェックするPL/SQLブロックです。
BEGIN DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); END; /
変更の妥当性チェックを完了した後は、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; /
Oracle Database Resource Manager(リソース・マネージャ)を有効にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータは、トップレベルのプランを指定し、現行のインスタンスで使用するプランを識別します。このパラメータでプランを指定しない場合、リソース・マネージャは有効になりません。
デフォルトでは、後で説明するように、事前に構成されているメンテナンス・ウィンドウの期間中を除き、リソース・マネージャは有効ではありません。
テキスト形式の初期化パラメータ・ファイルに次のように記述すると、データベースの起動時にリソース・マネージャがアクティブ化され、トップレベルのプランがmydb_planとして設定されます。
RESOURCE_MANAGER_PLAN = mydb_plan
DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャまたはALTER SYSTEM文を使用して、リソース・マネージャをアクティブ化(または解除)したり、現行のトップレベル・プランを変更することもできます。
次のSQL文は、トップレベルのプランをmydb_planに設定し、リソース・マネージャをアクティブ化します(アクティブ化されていない場合)。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';
指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。
Oracle Schedulerのウィンドウでのリソース・マネージャの自動有効化
リソース・プランを指定するOracle Schedulerのウィンドウがオープン状態の場合、リソース・マネージャは自動的にアクティブ化されます。スケジューラのウィンドウがクローズ状態の場合、そのウィンドウに関連付けられているリソース・プランは無効で、スケジューラのウィンドウがオープンする前に実行されていたリソース・プランが再度有効になります。(ウィンドウのオープン前に有効なリソース・プランがなかった場合、リソース・マネージャは無効になります。)したがって、ウィンドウのリソース・プランはあらゆるインスタンスで有効になります。
デフォルトでは、MAINTENANCE_WINDOW_GROUPウィンドウ・グループのメンバーである事前定義済のスケジューラ・ウィンドウであり、DEFAULT_MAINTENANCE_PLANリソース・プランを指定するメンテナンス・ウィンドウの間に一連の自動化されたメンテナンス・タスクが実行されることに注意してください。そのため、リソース・マネージャは、メンテナンス・ウィンドウ中にデフォルトでアクティブ化されます。必要な場合は、これらのメンテナンス・ウィンドウを変更して、別のリソース・プランを使用できます。
|
注意: メンテナンス・ウィンドウに関連付けられたプランを変更する場合は、サブプランORA$AUTOTASK_SUB_PLANおよびコンシューマ・グループORA$DIAGNOSTICSが新しいプランに含まれていることを確認してください。 |
Oracle Schedulerのウィンドウでのプラン切替えの無効化
場合によっては、スケジューラのウィンドウ境界でのリソース・マネージャ・プランの自動変更は、望ましくない可能性があります。たとえば、終了する必要のある重要なタスクがあり、リソース・マネージャ・プランにタスクの優先度を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、スケジューラのウィンドウはプランの設定後にアクティブになるため、タスクの実行中にリソース・マネージャ・プランが変更される可能性があります。
この状況を回避するには、次のSQL文に示すように、RESOURCE_MANAGER_PLAN初期化パラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:」を付加します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';
接頭辞FORCEを使用することで、現行のリソース・プランの変更は、データベース管理者がRESOURCE_MANAGER_PLAN初期化パラメータの値を変更した場合のみ可能であることを示します。この制限を解除するには、プラン名の前に「FORCE:」を付加せずに、そのコマンドを再実行します。
DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャには同様の機能があります。
|
関連項目: DBMS_RESOURCE_MANAGER.SWITCH_PLANの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
リソース・マネージャの無効化
リソース・マネージャを無効にするには、次の手順を完了します。
次のSQL文を発行します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
すべてのOracle Schedulerのウィンドウからリソース・マネージャの関連を削除します。
そのためには、resource_plan属性のリソース・プランを参照するすべてのスケジューラのウィンドウについて、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、resource_planを空の文字列('')に設定します。SYSユーザーでログインしていない場合は、SYSスキーマ名を使用してウィンドウ名を修飾します。スケジューラのウィンドウは、DBA_SCHEDULER_WINDOWSデータ・ディクショナリ・ビューで表示できます。詳細は、「ウィンドウの変更」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
|
注意: デフォルトでは、すべてのメンテナンス・ウィンドウがDEFAULT_MAINTENANCE_PLANリソース・プランを参照します。リソース・マネージャを完全に無効にするには、すべてのメンテナンス・ウィンドウを変更してこのプランを削除する必要があります。ただし、自動化メンテナンス・タスクによるリソース使用が規制されなくなるため、他のセッションのパフォーマンスに悪影響を与える可能性があることに注意してください。メンテナンス・ウィンドウの詳細は、第26章「自動データベース・メンテナンス・タスクの管理」を参照してください。 |
ここでは、リソース・プランの例をいくつか示します。ここで取り上げる例は、次のとおりです。
次のスクリプトは、図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に割り当てられます。
MAX_UTILIZATION_LIMITディレクティブ属性を使用すると、アプリケーションのCPU使用率を制限できます。この属性の一般的な使用例として、データベース統合をあげることができます。
データベースの統合では、次の処理が必要になる場合があります。
あるアプリケーションが別のアプリケーションのパフォーマンスに及ぼす影響を管理します。
このパフォーマンスの影響を管理する方法として、アプリケーションごとにコンシューマ・グループを作成し、各コンシューマ・グループにリソースを割り当てる方法をあげることができます。
各アプリケーションの使用率を制限します。
一般的に、CPUリソースの特定の使用率を各コンシューマ・グループに割り当てること以外に、グループごとに最大CPU使用率を制限することが必要になる場合があります。この制限によって、他のすべてのコンシューマ・グループがアイドル状態のときに、あるコンシューマ・グループがすべてのCPUリソースを使用することを回避できます。
場合によっては、他のアプリケーションからのワークロードに関係なく、すべてのアプリケーション・ユーザーに一貫性のあるパフォーマンスを提供することが必要になる場合があります。そのためには、リソース・プランのコンシューマ・グループごとに最大使用率の制限を指定します。
次の例は、MAX_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',
MAX_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,
MAX_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%に制限されます。MAX_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',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'apps_plan',
GROUP_OR_SUBPLAN => 'APP2_GROUP',
COMMENT => 'Apps group 2',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'apps_plan',
GROUP_OR_SUBPLAN => 'APP3_GROUP',
COMMENT => 'Apps group 3',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'apps_plan',
GROUP_OR_SUBPLAN => 'APP4_GROUP',
COMMENT => 'Apps group 4',
MAX_UTILIZATION_LIMIT => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'apps_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT => 'Mandatory',
MAX_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に示すように、サブプランおよびそのサブプラン内のコンシューマ・グループに対してMAX_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%',
MAX_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%',
MAX_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',
MAX_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',
MAX_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',
MAX_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%になります。
ここで示す例は、パッケージ化されたEnterprise Resource Planning(ERP)またはCustomer Relationship Management(CRM)アプリケーションをサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理(OLTP)の適切な応答時間を得ることにあります。
次の表にプランがまとめられています。
| グループ | CPUリソース割当て% | アクティブ・セッション・プール・パラメータ | コンシューマ・グループの自動切替え | 最大見積り実行時間 | UNDOプール |
|---|---|---|---|---|---|
oltp |
レベル1: 80% | 切替え先グループ: batch
切替え時間: 3秒 |
200K | ||
batch |
レベル2: 100% | プール・サイズ: 5
タイムアウト: 600秒 |
-- | 3600秒 | -- |
OTHER_GROUPS |
レベル3: 100% | -- | -- | -- |
レベル1のoltpにCPUの80%のみを割り当てることで、batchには最低20%が保証され、さらに、oltpが使用しないCPUリソースを使用できます。ただし、OTHER_GROUPSに対するCPUリソースの保証はありません。それは、batchがその割当てのすべてを使用していない場合にのみ、CPUリソースを取得します。類似するプランでは、レベル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; /
一般的に、データ・ウェアハウス環境は、リソース要件が様々に異なる多様なユーザーで構成されています。処理要件が共通するユーザーは、コンシューマ・グループにグループ化されます。コンシューマ・グループURGENT_GROUPは、経営陣に重要な情報を提供するためのレポートを実行するユーザーで構成されています。このグループは、多数のパラレル問合せを生成します。コンシューマ・グループETL_GROUPに属するユーザーは、ソース・システムからデータをインポートし、抽出、変換、ロード(ETL)の各操作を実行します。グループOTHER_GROUPSには、非定型問合せを実行するユーザーが含まれています。パフォーマンスを最適に保つと同時に、このような多様なユーザー・グループの要件を管理する必要があります。
次のディレクティブ属性を使用すると、パラレル・ステートメントの実行を管理および最適化できます。
MGMT_Pn
PARALLEL_TARGET_PERCENTAGE
PARALLEL_QUEUE_TIMEOUT
PARALLEL_DEGREE_LIMIT_P1
表27-3に、データ・ウェアハウス・ユーザーのニーズを管理するために使用可能なプランDW_PLANのリソース割当てを示します。このプランには、コンシューマ・グループURGENT_GROUP、ETL_GROUPおよびOTHER_GROUPSが含まれています。この例は、1つのアプリケーションまたはコンシューマ・グループですべての使用可能なパラレル・サーバーを使用しないことが確実である場合のディレクティブ属性の使用例を示しています。
表27-3 パラレル・ステートメント・ディレクティブが設定されたリソース・プラン
| コンシューマ・グループ | レベル1のCPU割当て | レベル2のCPU割当て | レベル3のCPU割当て | PARALLEL_DEGREE_LIMIT_P1 | PARALLEL_TARGET_PERCENTAGE | 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_TARGET_PERCENTAGE属性は50%で、これらのグループが使用できるパラレル・サーバーの最大数は64の50%、つまり各グループとも32台のパラレル・サーバーを使用できます。
コンシューマ・グループからのパラレル・ステートメントがキューされるのは、PARALLEL_DEGREE_POLICYパラメータがAUTOに設定され、コンシューマ・グループのアクティブなサーバーの総数がPARALLEL_SERVERS_TARGETよりも高くなっている場合のみです。PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されている場合、パラレル・ステートメントは、十分な数のパラレル・サーバーが使用できるときにのみ、実行されます。このようなパラレル・ステートメントで使用されるパラレル・サーバーは、コンシューマ・グループで使用されるパラレル・サーバーの総数にカウントされます。ただし、パラレル・ステートメントはパラレル・ステートメント・キューに追加されません。
|
ヒント: 優先度が低いアプリケーションの場合、PARALLEL_DEGREE_LIMIT_P1およびPARALLEL_TARGET_PERCENTAGEに小さい値を設定するのが一般的です。 |
URGENT_GROUPSにはレベル1で100%が割り当てられているため、そのパラレル・ステートメントはパラレル・ステートメント・キューの他のコンシューマ・グループよりも前に常にキューされます。URGENT_GROUPSにはPARALLEL_TARGET_PERCENTAGEディレクティブ属性がありませんが、このグループのセッションによって発行されたステートメントは、そのステートメントを実行できるだけのパラレル・サーバーが使用可能でない場合にはキューされます。
PARALLEL_DEGREE_LIMIT_P1で表される並列度は、URGENT_GROUPの場合12に設定されます。このため、URGENT_GROUPからの各パラレル・ステートメントでは、最大12台のパラレル・サーバーを使用できます。同じく、ETL_GROUPからの各パラレル・ステートメントでは最大8台のパラレル・サーバーを使用でき、OTHER_GROUPSからの各パラレル・ステートメントでは2台のパラレル・サーバーを使用できます。
たとえば、ある時間にパラレル・ステートメントがETL_GROUPからのみ実行され、このパラレル・ステートメントによって、このグループで使用可能な32パラレル・サーバーのうち26が使用されているとします。このコンシューマ・グループからのセッションのPARALLEL_DEGREE_POLICYは、AUTOに設定されています。別のパラレル・ステートメントがPARALLEL_DEGREE_LIMIT_P1属性が8の設定でETL_GROUPから起動されても、ETL_GROUPで使用可能なパラレル・サーバーは、32-26=6パラレル・サーバーであるので、この問合せはすぐには実行されません。この新しいパラレル・ステートメントは、必要なパラレル・サーバー数がETL_GROUPで使用可能になるまでキューで待機します。
ETL_GROUPのパラレル・ステートメントの実行中、OTHER_GROUPSからパラレル・ステートメントが開始されたとします。このグループでは32台のパラレル・サーバーを使用できるので、パラレル・ステートメントは実行されます。
OTHER_GROUPSのPARALLEL_QUEUE_TIMEOUT属性は、360に設定されています。このため、このグループからのパラレル・ステートメントは、360秒間のみパラレル・サーバーのキューに残ることができます。この時間が経過すると、パラレル・ステートメントはキューから削除され、エラーORA-07454が返されます。
Oracle Databaseには、事前定義済のリソース・プランMIXED_WORKLOAD_PLAN (バッチ操作よりも対話型の操作を優先するプラン)と、Oracleが推奨する必須のサブプランとコンシューマ・グループが用意されています。MIXED_WORKLOAD_PLANは、次のように定義されています。
このプランのINTERACTIVE_GROUPは短いトランザクションを対象にしているため、60秒を超えるCPU時間を使用するコールは、長いバッチ操作を対象にしたBATCH_GROUPに自動的に切り替わります。
使用環境に適する場合は、この事前定義済のプランを使用できます。(このプランは変更したり、使用しない場合に削除できます。)BATCH_GROUPおよびINTERACTIVE_GROUPの名前に特別な意味はありません。この名前はグループの用途を反映しているだけで、ユーザーは任意に、これらのグループにアプリケーション・セッションをマップし、それに応じてCPUリソースの割当て使用率を調整して、使用する対話型アプリケーションおよびバッチ・アプリケーションにあわせた適切なリソース管理を実現できます。たとえば、対話型アプリケーションをINTERACTIVE_GROUPコンシューマ・グループの下で実行するには、ユーザー名、サービス名、プログラム名、モジュール名または処理に基づいて、このコンシューマ・グループに対話型アプリケーションのユーザー・セッションをマップする必要があります(「コンシューマ・グループへのセッションのマッピング・ルールの指定」を参照)。同じように、BATCH_GROUPにバッチ・アプリケーションをマップする必要があります。最後に、このプランを有効にする必要があります(「Oracle Database Resource Managerの有効化とプランの切替え」を参照)。
Oracle Databaseには、複数のデータベース・インスタンスを実行する複数CPUサーバーでCPU割当てを管理する方法が用意されています。この方法はインスタンス・ケージングと呼ばれます。インスタンス・ケージングとOracle Database Resource Manager(リソース・マネージャ)が連携して、複数インスタンス間で必要なサービス・レベルをサポートします。
この項の内容は次のとおりです。
1台のマルチCPU搭載サーバーで複数のOracle Databaseインスタンスを実行するように決定することがあります。その代表的な理由は、サーバーの統合、つまり使用できるハードウェア・リソースをより効率的に使用するためです。1台のサーバーで複数のインスタンスが実行されている場合、インスタンスはCPUリソースを競い合います。1つのリソース集中型のデータベース・インスタンスが、他のインスタンスのパフォーマンスを大きく低下させる場合があります。たとえば、16個のCPUのシステムで4つのデータベース・インスタンスが存在する場合に、ある1つのデータベース・インスタンスに大きな負荷がかかっている間、オペレーティング・システムによって、このインスタンスの実行にCPUの大半が使用される可能性があります。これにより、他の3つのインスタンスのパフォーマンスが低下することがあります。このようなCPU割当ては、オペレーティング・システムのみによって決定され、通常はユーザーが制御することはできません。
各データベース・インスタンスのCPU使用率を制限する簡単な方法は、インスタンス・ケージングを使用することです。インスタンス・ケージングは、初期化パラメータを使用して、インスタンスが同時に使用できるCPU数を制限する方法です。前の例で、インスタンス・ケージングを使用して4つのインスタンスそれぞれのCPU数を4に制限すると、1つのインスタンスによって他のインスタンスが妨害される可能性が低くなります。4つのCPUに制約されると、インスタンスはCPUにバインドされます。このとき、リソース・マネージャによって、インスタンスに対して設定したリソース・プランに基づき、様々なデータベース・セッション間でのCPUの割当てが開始されます。このように、インスタンス・ケージングとリソース・マネージャによって、単一サーバーで複数のインスタンスを管理する簡単で効果的な方法が提供されます。
サーバーのインスタンス・ケージングには、次の2つの一般的なアプローチがあります。
オーバープロビジョニング: このアプローチは、開発システムやテスト・システムなどの重要度の低いデータベースや、負荷が少なく、かつ重要度の低い本番システムに対して使用します。このアプローチでは、各インスタンスのCPU制限の合計がシステム上の実際のCPU数を超過します。たとえば、4つのデータベース・インスタンスがある4 CPUシステムで、各インスタンスを3つのCPUに制限します。この方法でサーバーがオーバープロビジョンされると、インスタンスが相互にパフォーマンスに影響を及ぼします。ただし、インスタンス・ケージングによってその影響は制限され、パフォーマンスはある程度予測可能になります。ただし、インスタンスの1つに高負荷の期間がある場合、CPUでそれを処理できます。1つ以上のインスタンスが頻繁にアイドルまたは低負荷になる可能性があるため、このアプローチは重要度の低いシステムに適切です。
パーティション化: このアプローチは、インスタンスが相互に妨害しないようにする必要がある、重要な本番システムに適しています。すべての割当ての合計がサーバー上のCPU数と等しくなるようにCPUを割り当てます。たとえば、16 CPUサーバー・システムで、最初のインスタンスに8つのCPU、2番目のインスタンスに4つのCPU、残りの2つのインスタンスに2つずつのCPUを割り当てます。CPUリソースを各データベース・インスタンス専用にすることによって、1つのインスタンスへの負荷が別のインスタンスに影響を及ぼすことがなくなり、各インスタンスは想定したとおりに実行されます。
最大使用率の制限が適用されたインスタンス・ケージングの使用
リソース・プランでインスタンス・ケージングを有効にし、最大使用率の制限を設定した場合、絶対上限は割り当てられたCPUリソースの割合として計算されます。
たとえば、インスタンス・ケージングを有効にし、CPU_COUNTを4に設定し、コンシューマ・グループの最大使用率の制限が50%である場合、コンシューマ・グループは4つのCPUの最大50%、つまり2つのCPUを使用できます。
インスタンス・ケージングを有効化するには、サーバー上の各インスタンスに対して次の処理を実行します。
リソース・プランを割り当てることでリソース・マネージャを有効化し、MGMT_P1からMGMT_P8のパラメータを使用してリソース・プランにCPUディレクティブがあるようにします。
手順については、「Oracle Database Resource Managerの有効化とプランの切替え」を参照してください。
cpu_count初期化パラメータを設定します。
これは動的パラメータであり、次の文を使用して設定できます。
ALTER SYSTEM SET CPU_COUNT = 4;
ここでは、Oracle Database Resource Manager(リソース・マネージャ)のコンシューマ・グループ、リソース・プランおよびリソース・プラン・ディレクティブをメンテナンスする方法について説明します。メンテナンス・タスクは、DBMS_RESOURCE_MANAGER PL/SQLパッケージを使用して実行します。この章では、次の項目について説明します。
|
関連項目:
|
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを更新する必要があります。引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。
DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。最初にペンディング・エリアを作成し、発行する前に、コンシューマ・グループを削除する必要があります。コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして割り当てられているすべてのユーザーには、初期コンシューマ・グループとしてOTHER_GROUPSが割り当てられます。削除したコンシューマ・グループに属している現在実行中のセッションはすべて、コンシューマ・グループ・マッピング・ルールに基づいて新しいコンシューマ・グループに割り当てられます。マッピングでセッションのコンシューマ・グループが見つからなかった場合、そのセッションはOTHER_GROUPSに切り替わります。
リソース・プラン・ディレクティブが参照しているコンシューマ・グループは削除できません。
プラン情報を更新するには、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プロシージャの引数を指定しない場合、ディレクティブ内の対応パラメータは変更されません。
次の例ではディレクティブにコメントを追加します。
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;
/
Oracle Database Resource Manager (リソース・マネージャ)の現在の構成とステータスを表示するには、いくつかの静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを使用できます。この項では、次の例を示します。
|
関連項目: すべての静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
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パッケージを使用してこれらのグループに切り替える機能がすでに付与されています。
この例では、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... ORA$AUTOTASK_SUB_PLAN Default sub-plan for automated maintenan... 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... ORA$AUTOTASK_HIGH_SUB_PLAN Default sub-plan for high-priority, auto...
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 ...
この例では、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
次の動的パフォーマンス・ビューは、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の使用量が、コンシューマ・グループごとに分単位で表示されます。Enterprise Managerでは、これらのメトリックを「リソース・マネージャ統計」ページでグラフィカルに表示できます。
V$RSRC_PLAN このビューには、現在アクティブなリソース・プランとそのサブプランが表示されます。
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のプランは、現在アクティブな(トップレベルの)プランです。他のプランは、トップレベルのプランのサブプランか、リスト内の他のサブプランのサブプランです。
このビューには、その他に次の情報なども含まれます。
INSTANCE_CAGING列に、インスタンス・ケージングが有効であるかどうかが表示されます。
CPU_MANAGED列に、CPUが管理されているかどうかが表示されます。
PARALLEL_EXECUTION_MANAGED列に、パラレル・ステートメント・キューイングが有効であるかどうかが表示されます。
|
関連項目: 『Oracle Databaseリファレンス』 |
V$RSRC_CONSUMER_GROUP V$RSRC_CONSUMER_GROUPビューは、CPU、I/O、パラレル・サーバーなど、使用されているリソースを監視する場合に使用します。また、CPUリソースの管理、リソース集中型の問合せの管理、パラレル・ステートメント・キューイングなどに関連する統計を監視する場合にも使用できます。すべての統計は、プランがアクティブ化された時点からの累積です。
SELECT name, active_sessions, queue_length, consumed_cpu_time, cpu_waits, cpu_wait_time FROM v$rsrc_consumer_group; NAME ACTIVE_SESSIONS QUEUE_LENGTH CONSUMED_CPU_TIME CPU_WAITS CPU_WAIT_TIME ------------------ --------------- ------------ ----------------- ---------- ------------- OLTP_ORDER_ENTRY 1 0 29690 467 6709 OTHER_GROUPS 0 0 5982366 4089 60425 SYS_GROUP 1 0 2420704 914 19540 DSS_QUERIES 4 2 4594660 3004 55700
前述の問合せ結果では、DSS_QUERIESコンシューマ・グループには、アクティブ・セッション・プールに4つのセッションがあり、2つのセッションがキューでアクティブ化を待機しています。
このビューの主な測定値はCPU_WAIT_TIMEです。この測定値は、リソース管理のために、コンシューマ・グループのセッションがCPUの割当てを待機していた合計時間を示します。この測定値には、ラッチまたはエンキューの競合、I/O待機などに起因する待機は含まれません。
|
関連項目: 『Oracle Databaseリファレンス』 |
V$RSRC_SESSION_INFO このビューは、1つ以上のセッションのステータスを監視する場合に使用します。このビューには、リソース・マネージャによるセッションへの影響が表示されます。次の情報が提供されます。
セッションが現在属しているコンシューマ・グループ。
セッションが当初属していたコンシューマ・グループ。
コンシューマ・グループへのセッションのマップに使用されたセッション属性。
セッションの状態(RUNNING、WAIT_FOR_CPU、QUEUEDなど)。
メトリックに関する現在の統計と累積の統計(CPU使用、待機時間、待ち行列時間など)。現在の統計には、セッションが現在のコンシューマ・グループに所属してからの統計が反映されています。累積の統計には、セッションが作成された以降に所属したすべてのコンシューマ・グループでの統計が反映されています。
SELECT se.sid sess_id, co.name consumer_group,
se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time
FROM v$rsrc_session_info se, v$rsrc_consumer_group co
WHERE se.current_consumer_group_id = co.id;
SESS_ID CONSUMER_GROUP STATE CPU_TIME CPU_WAIT_TIME QUEUED_TIME
------- ------------------ -------- --------- ------------- -----------
113 OLTP_ORDER_ENTRY WAITING 137947 28846 0
135 OTHER_GROUPS IDLE 785669 11126 0
124 OTHER_GROUPS WAITING 50401 14326 0
114 SYS_GROUP RUNNING 495 0 0
102 SYS_GROUP IDLE 88054 80 0
147 DSS_QUERIES WAITING 460910 512154 0
このビューのCPU_WAIT_TIMEには、V$RSRC_CONSUMER_GROUPビューと同様の意味がありますが、個々のセッションに適用されます。
このビューとV$SESSIONビューを結合して、さらに詳細なセッションに関する情報を表示できます。
|
関連項目: 『Oracle Databaseリファレンス』 |
V$RSRC_PLAN_HISTORY このビューには、インスタンスでリソース・プランが有効または無効になった日時が表示されます。各リソース・プランのアクティブ化または解除には連番が割り当てられます。このビューの各エントリについては、プランの各コンシューマ・グループに対応するエントリがV$RSRC_CONS_GROUP_HISTORYビューにあり、コンシューマ・グループの累積統計が表示されます。この2つのビューは、それぞれのSEQUENCE#列で結合しています。
SELECT sequence# seq, name plan_name, to_char(start_time, 'DD-MON-YY HH24:MM') start_time, to_char(end_time, 'DD-MON-YY HH24:MM') end_time, window_name FROM v$rsrc_plan_history; SEQ PLAN_NAME START_TIME END_TIME WINDOW_NAME ---- -------------------------- --------------- --------------- ---------------- 1 29-MAY-07 23:05 29-MAY-07 23:05 2 DEFAULT_MAINTENANCE_PLAN 29-MAY-07 23:05 30-MAY-07 02:05 TUESDAY_WINDOW 3 30-MAY-07 02:05 30-MAY-07 22:05 4 DEFAULT_MAINTENANCE_PLAN 30-MAY-07 22:05 31-MAY-07 02:05 WEDNESDAY_WINDOW 5 31-MAY-07 02:05 31-MAY-07 22:05 6 DEFAULT_MAINTENANCE_PLAN 31-MAY-07 22:05 THURSDAY_WINDOW
PLAN_NAMEの下のNULL値は、プランがアクティブにならなかったことを示します。
このビューのAWRスナップショットはDBA_HIST_RSRC_PLANビューに格納されます。
|
関連項目: 『Oracle Databaseリファレンス』 |
V$RSRC_CONS_GROUP_HISTORY このビューは、時間の経過に従ってコンシューマ・グループ内でリソースがどのように共有されたかを理解するのに役立ちます。sequence#列は、V$RSRC_PLAN_HISTORYビューの同名の列に対応しています。そのため、コンシューマ・グループ統計の各行について、アクティブであったプランを判別できます。
SELECT sequence# seq, name, cpu_wait_time, cpu_waits,
consumed_cpu_time FROM v$rsrc_cons_group_history;
SEQ NAME CPU_WAIT_TIME CPU_WAITS CONSUMED_CPU_TIME
---- ------------------------- ------------- ---------- -----------------
2 SYS_GROUP 18133 691 33364431
2 OTHER_GROUPS 51252 825 181058333
2 ORA$AUTOTASK_MEDIUM_GROUP 21 5 4019709
2 ORA$AUTOTASK_URGENT_GROUP 35 1 198760
2 ORA$AUTOTASK_STATS_GROUP 0 0 0
2 ORA$AUTOTASK_SPACE_GROUP 0 0 0
2 ORA$AUTOTASK_SQL_GROUP 0 0 0
2 ORA$AUTOTASK_HEALTH_GROUP 0 0 0
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を併用します。
|
関連項目:
|
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の最大割合を表します。この制限は、MAX_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列には、特定のコンシューマ・グループからいつでも実行できるセッションの最大数が表示されます。この制限は、コンシューマ・グループまたはコンシューマ・グループが含まれているサブプランに設定するMAX_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;
|
関連項目: 『Oracle Databaseリファレンス』 |
V$RSRCMGRMETRIC_HISTORY
V$RSRCMGRMETRIC_HISTORYの各列は、V$RSRCMGRMETRICと同じビューです。これらのビューの唯一の違いは、V$RSRCMGRMETRICには過去1分間のみのメトリックが含まれているのに対して、V$RSRCMGRMETRIC_HISTORYには過去60分間のメトリックが含まれていることです。
|
関連項目: 『Oracle Databaseリファレンス』 |
多くのオペレーティング・システムではリソース管理ツールを提供しています。これらのツールの名前には、「workload manager」や「resource manager」などの語句が含まれており、管理者が定義したポリシーを使用して、単一のサーバー・リソースを複数のアプリケーションで共有できることを意図しています。たとえば、HP社のProcess Resource Managerや、Solaris Containers、ZonesおよびResource Poolsなどがあります。
オペレーティング・システムによるリソース制御を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リソースしか使用できないと判断されて少なすぎるプロセスがスケジュールされる可能性があります。多すぎるプロセスがスケジュールされた場合、MAX_UTILIZATION_LIMITディレクティブを超えてしまい、CPUディレクティブが正しく規定されない可能性があります。少なすぎるプロセスがスケジュールされた場合、Oracleインスタンスによってサーバーのリソースが十分に使用されない可能性があります。
プロセスの優先度管理が使用禁止になっている必要があります。
個々のデータベース・プロセスを異なる優先度レベルで管理する機能(例: UNIXプラットフォームでのniceコマンドの使用)は、サポートされていません。インスタンスがクラッシュするなど、重大な結果になる可能性があります。オペレーティング・システムのリソース制御を使用して、Oracle Databaseインスタンスが固定されているメモリーを管理できる場合も、同様に望ましくない結果となることが予想されます。
ここでは、Oracle Database Resource Manager(リソース・マネージャ)の参照情報を提供します。
各Oracle Databaseに事前定義されているリソース・プランを表27-4にリストし、リソース・コンシューマ・グループを表27-5にリストします。ビュー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 0 75 0 0 DSS_GROUP 0 0 75 0 ETL_GROUP 0 0 0 45 BATCH_GROUP 0 0 0 45 ORA$DIAGNOSTICS 0 5 0 0 ORA$AUTOTASK_SUB_PLAN 0 5 0 0 OTHER_GROUPS 0 0 0 10
表27-4 事前定義のリソース・プラン
| リソース・プラン | 説明 |
|---|---|
|
|
メンテナンス・ウィンドウのデフォルト・プラン。このプランの詳細は、「自動化メンテナンス・タスクに対するリソース割当ての概要」を参照してください。メンテナンス・ウィンドウはOracle Schedulerの通常のウィンドウであるため、必要に応じて、それらに関連付けられているリソース・プランを変更できます。メンテナンス・ウィンドウのリソース・プランを変更する場合は、サブプラン |
|
|
|
|
|
重要ではないDSS問合せやETL操作よりも重要なDSS問合せを優先させるデータ・ウェアハウス・プランの例。 |
|
|
DSS問合せよりもETL操作を優先させるデータ・ウェアハウス・プランの例。 |
|
|
リソース・マネージャの無効化用。内部使用専用。 |
|
|
データベースの静止用。このプランは直接アクティブ化できません。アクティブ化するには |
|
|
バッチ操作よりも対話型操作を優先させる複合ワークロード・プランの例。詳細は、「オラクル社が提供する複合ワークロード・プラン」を参照してください。 |
表27-5 事前定義のリソース・コンシューマ・グループ
| リソース・コンシューマ・グループ | 説明 |
|---|---|
|
|
バッチ操作用のコンシューマ・グループ。プラン例 |
|
|
重要なDSS問合せ用のコンシューマ・グループ。プラン例 |
|
|
重要ではないDSS問合せ用のコンシューマ・グループ。プラン例 |
|
|
ETLジョブ用のコンシューマ・グループ。プラン例 |
|
|
対話型OLTP操作用のコンシューマ・グループ。プラン例 |
|
|
優先度が低いセッション用のコンシューマ・グループ。 |
|
|
クリティカル・エラーの発生時に診断ダンプを作成するデータベース・プロセスによって使用されるコンシューマ・グループ。 |
|
|
将来使用するために予約されています。 |
|
|
優先度が中程度のメンテナンス・タスク用のコンシューマ・グループ。 |
|
|
自動セグメント・アドバイザのメンテナンス・タスク用のコンシューマ・グループ。 |
|
|
自動SQLチューニング・アドバイザのメンテナンス・タスク用のコンシューマ・グループ。 |
|
|
オプティマイザ統計収集のメンテナンス・タスク用のコンシューマ・グループ。 |
|
|
緊急のメンテナンス・タスク用のコンシューマ・グループ。 |
|
|
明示的な初期コンシューマ・グループを持たないすべてのセッションのデフォルトのコンシューマ・グループは、コンシューマ・グループへのセッションのマッピング・ルールによってコンシューマ・グループにマップされないか、現在アクティブなリソース・プラン内にないコンシューマ・グループにマップされます。
|
|
|
システム管理者用のコンシューマ・グループ。これは、ユーザー・アカウント |
表27-6に、Oracle Databaseで事前定義されているコンシューマ・グループ・マッピング・ルールの要約を示します。ビューDBA_RSRC_GROUP_MAPPINGSを問い合せることで、これらのルールを確認できます。DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、これらのマッピング・ルールを変更または削除できます。
表27-6 事前定義のコンシューマ・グループ・マッピング・ルール
| 属性 | 値 | マップされるコンシューマ・グループ | 注意 |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
セッションでは、RMANによるバックアップ操作が実行されます。操作が開始すると、セッションは自動的に |
|
|
|
|
セッションでは、RMANによるコピー操作が実行されます。操作が開始すると、セッションは自動的に |
|
|
|
|
セッションでは、データ・ポンプによるデータ・ロード操作が実行されます。操作が開始すると、セッションは自動的に |
表27-7に、リソース・マネージャに関連付けられているビューをリストします。
表27-7 リソース・マネージャのデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
|
|
|
|
データベースに存在するすべてのリソース・コンシューマ・グループがリストされます。 |
|
|
|
|
|
データベースに存在するすべてのリソース・プラン・ディレクティブがリストされます。 |
|
|
データベースに存在するすべてのリソース・プランがリストされます。 |
|
|
すべてのセッション属性に対する様々なマッピングのペアがすべてリストされます。 |
|
|
各属性の現在のマッピング優先度がリストされます。 |
|
|
リソース・プランのアクティブ化に関する履歴情報が表示されます。このビューには、 |
|
|
コンシューマ・グループに関する履歴統計情報が表示されます。このビューには、 |
|
|
|
|
|
|
|
|
アクティブなリソース・コンシューマ・グループに関する情報が表示されます。このビューは、チューニングに使用できます。 |
|
|
過去1分間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに表示されます。 |
|
|
過去1時間のリソース使用履歴と累積CPU待ち時間(リソース管理に起因するもの)がコンシューマ・グループごとに分単位で表示されます。新しいリソース・プランが有効な場合、履歴はクリアされます。 |
|
|
現在のアクティブ・リソース・プランの名前がすべて表示されます。 |
|
|
そのインスタンスでリソース・マネージャのプランがいつ有効または無効になったかが表示されます。時間の経過とともに、どのようにリソースがコンシューマ・グループ間で共有されていたかを理解するのに役立ちます。 |
|
|
各セッションについてリソース・マネージャの統計が表示されます。リソース・マネージャによるセッションへの影響が表示されます。チューニングに使用できます。 |
|
|
現行セッションごとにセッション情報が表示されます。その中には、各現行セッションのリソース・コンシューマ・グループの名前が含まれます。 |
|
関連項目: これらの各ビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。 |
