10gリリース2（10.2）
B19224-02
 目次 |
 索引 |
| Oracle Database 管理者ガイド 10gリリース2（10.2） B19224-02 |
|
Oracle Databaseでは、データベース・リソース・マネージャによるデータベース・リソースの管理機能が提供されます。この章では、その使用方法について説明します。この章の内容は、次のとおりです。
データベース・リソース・マネージャの主な目的は、Oracle Databaseサーバーがリソース管理の決定を厳密に制御することによって、非効率的なオペレーティング・システム管理から生じる問題を回避することです。
データベース・リソースの割当てがオペレーティング・システムによって決定される場合は、次のような問題が生じることがあります。
過剰なオーバーヘッドは、サーバー・プロセスの数が多いときに、Oracle Databaseサーバー・プロセス間でオペレーティング・システムのコンテキストが切り替わることによって発生します。
オペレーティング・システムは、データベース・サーバーがラッチを保持している間にデータベース・サーバーのスケジュールを解除しますが、これは非効率的です。
オペレーティング・システムはタスク間の優先順位付けができないため、すべてのアクティブなプロセスの間で均等にリソースを分配します。
Oracle Database Resource Managerは、マシン・リソースの割当て方法をデータベースで厳密に制御することによって、これらの問題を克服します。
データベース・リソース・マネージャを使用すると、次のことが可能になります。
次に、データベース・リソース管理の要素を示します。各要素は、データベース・リソース・マネージャパッケージを通じて定義します。
これらの要素の作成方法および使用方法については、後述します。
ここでは、リソース・プランの概要について簡単に説明します。単純なリソース・プランの例を図示します。 複雑なプランについては、データベース・リソース・マネージャの要素の作成およびメンテナンス方法を説明した後（「各種の方法を組み合せたデータベース・リソース・マネージャの例」）に示します。
リソース・プランでは、そのプランに属するリソース・コンシューマ・グループを指定し、これらのグループ間でのリソース割当て方法を示すディレクティブを含めます。 プランにはサブプランを含めることも可能で、リソース・コンシューマ・グループとサブプランの両方の間でリソースを割り当てるように指定できます。 次にサブプランでは、割当てをサブプラン内のコンシューマ・グループとサブプランに割り当てます。 リソース・プランはいくつでも定義できますが、特定のOracle Databaseインスタンスで一度にアクティブにできるのは1つのみです。
DBMS_RESOURCE_MANAGERパッケージを使用して、データベース・リソース・マネージャの要素（リソース・プラン、リソース・コンシューマ・グループおよびリソース・プラン・ディレクティブ）を作成およびメンテナンスします。プラン情報は、データ・ディクショナリ内の表に格納されます。プラン・データの表示には、複数のビューを使用できます。
図24-1は、単純なプランを示しています。このプランでは、複数のリソース・コンシューマ・グループ間でのみリソースを割り当てています。Great Bread Companyは、3つのリソース・コンシューマ・グループ間でCPUリソースを割り当てるプランGREAT_BREADを持っています。具体的には、SALESにCPUタイムの60%、MARKETに20%、DEVELOPに残りの20%が割り当てられています。
Oracle Databaseには、単純なリソース・プランを迅速に作成できるプロシージャ（CREATE_SIMPLE_PLAN）が用意されています。 このプロシージャについては、「単純なリソース・プランの作成」を参照してください。
プランにはリソース・コンシューマ・グループ以外に、サブプランも含めることができます。 サブプランは、プラン階層内で、リソース・コンシューマ・グループと同じ位置を占めます。 たとえば、Great Bread Companyでは、CPUリソースを図24-2のように分割することもできます。この図は、トップレベルのプラン（GREAT_BREAD）とそのすべての子を含むプラン・スキーマを示しています。
このケースでは、GREAT_BREADプランは、前述の例と同様に、コンシューマ・グループMARKETにCPUリソースの20%を割り当てています。ただし、ここではサブプランSALES_TEAMにCPUリソースを割り当て（60%）、このサブプランの割当てをWHOLESALEグループとRETAILグループ間で均等に分割しています。同様に、DEVELOP_TEAMにCPUリソースを割り当て（20%）、このサブプランの割当てをBREADグループとMUFFINグループ間で均等に分割しています。
サブプランまたはコンシューマ・グループが複数の親（所有するプラン）を持つことはできますが、プラン・スキーマ内でループすることはできません。たとえば、Great Bread Companyに夜間のプランと日中のプランがある場合、サブプランは複数の親を持つことになります。 夜間のプランと日中のプランにはどちらもSALES_TEAMサブプランがメンバーとして含まれますが、各インスタンスのCPUリソース割当ては異なります。
リソース・コンシューマ・グループとは、処理要件に基づいてグループ化されたユーザー（セッション）のグループです。次に説明するリソース・プラン・ディレクティブによって、プラン・スキーマ内のコンシューマ・グループおよびサブプラン間でのリソースの割当て方法を指定します。
リソース・コンシューマ・グループへのリソースの割当て方法は、リソース割当てディレクティブで指定します。データベース・リソース・マネージャには、いくつかのリソース割当て方法が用意されています。
この方法では、コンシューマ・グループまたはサブプラン間でのCPUリソースの割当て方法を指定します。 複数レベル（最大8レベル）のCPUリソース割当てにより、プラン・スキーマ内でCPU使用の優先順位を設定できます。 レベル2のコンシューマ・グループおよびサブプランは、レベル1に割り当てられなかったリソース、またはレベル1のコンシューマ・グループやサブプランによって使用されなかったリソースを使用できます。同じ規則が、レベル3、4、以下同様に適用されます。複数レベルを使用すると、優先順位を設定できるだけでなく、すべての主リソースと残りのリソースの使用方法を明示的に指定できます。
複数レベルのプラン・スキーマの例は、図24-3を参照してください。
コンシューマ・グループ内で同時にアクティブにできるセッションの最大数を制御できます。この最大数によって、アクティブ・セッション・プールが構成されます。プールがいっぱいのためにセッションを初期化できない場合は、セッションがキューに送られます。アクティブなセッションが終了すると、キュー内の最初のセッションが実行のためにスケジュールされます。実行キュー内で実行されるのを待機しているジョブがタイムアウトするまでのタイムアウト周期も指定できます。ジョブがタイムアウトすると、エラーが発生して終了します。
パラレル実行セッションは全体で1つのアクティブ・セッションとして数えられます。
並列度制限を指定すると、コンシューマ・グループ内の任意の操作における最大の並列度を制御できます。
この方法では、他のコンシューマ・グループにセッションを自動的に切り替えるための基準を指定して、リソースを制御できます。コンシューマ・グループの切替えに使用できる基準は、次のとおりです。
データベース・リソース・マネージャは、セッションがアクティブである時間が切替え時間で設定されている秒数を超えたときに、実行中のセッションを切替えグループに切り替えます。ここでのアクティブは、セッションが実行中でリソースを消費していることを意味します。ユーザー入力待ちのためにアイドルしているときや、CPUサイクル待ちは含まれません。切替え後のグループのアクティブ・セッション・プールがいっぱいの場合でも、セッションは引き続き実行することを許可されます。このような状況では、コンシューマ・グループは、アクティブ・セッション・プールで指定された数より多くのセッションを実行できます。セッションの処理が終了し、アイドルになると、元のグループに切り替えられます。
見積りの使用をTRUEに設定した場合、データベース・リソース・マネージャは、操作が完了するまでの時間の予測値を使用します。データベースの見積りが切替え時間で指定された値よりも長い場合は、実行を開始する前に、セッションが切り替えられます。このパラメータを設定しない場合は、通常どおり操作が始まり、他の切替え基準が満たされた場合のみ、グループが切り替わります。
コールでの切替え時間は、3層アプリケーションでその中間層のサーバーがセッション・プーリングを使用している場合に有効です。各最上位コールの終了時に、セッションは元のコンシューマ・グループ（セッションがログインした時点で属していたグループ）にスイッチ・バックされます。PL/SQLの最上位コールは、1つのコールとして処理されるPL/SQLブロック全体です。SQLの最上位コールは、1つのコールとして処理され、クライアントから別々に発行される個々のSQL文です。
コールでの切替え時間と、切替え時間の両方を指定することはできません。
ディレクティブの指定によって、長時間実行SQL問合せの取消し、または長時間実行セッションの終了ができます。これを指定するには、CANCEL_SQLまたはKILL_SESSIONを切替えグループとして設定します。
ある操作に許可される最大の実行時間を指定できます。ある操作についてデータベースが見積った実行時間が、指定された最大実行時間より長い場合、その操作はエラーを出力して終了します。このエラーはトラップ可能であり、操作は再スケジュールできます。
UNDOプールは、コンシューマ・グループごとに指定できます。UNDOプールによって、コンシューマ・グループが生成できるUNDOの合計量が制御されます。コンシューマ・グループが生成するUNDOの合計量がそのUNDO制限を超えると、REDOを生成している現行のデータ操作言語（DML）文が終了します。コンシューマ・グループの他のメンバーは、UNDO領域がプールから解放されるまで、新たにデータ操作を実行できません。
セッションのアイドル時間を指定できます。指定した時間をすぎるとセッションは終了します。このような終了方法を、他のセッションをブロックしているセッションのみに限定することもできます。
データベース・リソース・マネージャを管理するには、システム権限ADMINISTER_RESOURCE_MANAGERが必要です。通常、データベース管理者（DBA）は、DBAロール（またはそれと等価のロール）の一部として、ADMINオプション付きでこの権限を持っています。
データベース・リソース・マネージャの管理者は、DBMS_RESOURCE_MANAGERパッケージ内のすべてのプロシージャを実行できます。次の表に、これらのプロシージャを示します。各プロシージャの使用方法については後述します。
ADMINオプションを持つ管理者は、必要に応じて管理権限を他のユーザーまたはロールに付与できます。そのためには、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用します。このパッケージには、次の表に示すプロシージャが含まれています。
次の例では、ユーザーscottにADMINオプションなしで管理権限を付与しています。したがって、scottはDBMS_RESOURCE_MANAGERパッケージ内のすべてのプロシージャを実行できますが、管理権限を他のユーザーに付与するGRANT_SYSTEM_PRIVILEGEプロシージャは使用できません。
EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE - (GRANTEE_NAME => 'scott', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER', - ADMIN_OPTION => FALSE);
この権限は、REVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消すことができます。
DBMS_RESOURCE_MANAGER_PRIVSパッケージの他のプロシージャについては、「スイッチ特権の管理」を参照してください。
CREATE_SIMPLE_PLANプロシージャを使用すれば、多くの状況に対応できる単純なリソース・プランを迅速に作成できます。このプロシージャでは、文を1回実行するだけで、コンシューマ・グループを作成し、それらにリソースを割り当てることができます。このプロシージャを使用する際は、ペンディング・エリアの作成、各コンシューマ・グループの個別作成およびリソース・プラン・ディレクティブの指定を行うために、後述のプロシージャをコールする必要はありません。
CREATE_SIMPLE_PLANプロシージャには、次のパラメータを指定できます。
このプロシージャでは、最大8個のコンシューマ・グループを指定できます。また、指定できるプラン・ディレクティブは、CPUに関するもののみです。 プランでは、EMPHASIS CPU割当てポリシーが使用され、各コンシューマ・グループでは、ROUND_ROBINスケジューリング・ポリシーが使用されます。 プラン内に指定された各コンシューマ・グループには、レベル2のCPUパーセンテージが割り当てられます。また、プランには、SYS_GROUP（ユーザーSYSとSYSTEMのためにシステムによって定義された初期コンシューマ・グループ）とOTHER_GROUPSも暗黙的に含まれます。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'simple_plan1', CONSUMER_GROUP1 => 'mygroup1', GROUP1_CPU => 80, CONSUMER_GROUP2 => 'mygroup2', GROUP2_CPU => 20); END;
この文を実行すると、次のプランが作成されます。
| コンシューマ・グループ | レベル1 | レベル2 | レベル3 |
|---|---|---|---|
|
|
100% |
- |
- |
|
|
- |
80% |
- |
|
|
- |
20% |
- |
|
|
- |
- |
100% |
ここでは、より複雑なリソース・プランが必要な状況で使用できるアクションとDBMS_RESOURCE_MANAGERプロシージャについて説明します。この部の構成は、次のとおりです。
プラン・スキーマを作成または変更する場合は、最初にペンディング・エリアを作成する必要があります。これは、段階的な変更を加え、アクティブにする前に妥当性をチェックできるスクラッチ領域です。
ペンディング・エリアを作成するには、次の文を使用します。
EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
実際には、プランの更新や新規プランの追加ができるように、ペンディング・エリアがアクティブになり、既存のプラン・スキーマ（アクティブなプラン・スキーマ）がすべてペンディング・エリアにロードされます。アクティブなプラン・スキーマとは、データベース・リソース・マネージャで使用できるように、すでにデータ・ディクショナリに格納されているスキーマです。先にペンディング・エリアをアクティブにしないで（つまり、作成せずに）、プランを更新または新規に追加しようとすると、ペンディング・エリアがアクティブでないことを示すエラー・メッセージが返されます。
ビューを使用すると、アクティブなすべてのリソース・プラン・スキーマと保留中のプラン・スキーマを表示できます。 これらのビューについては、「データベース・リソース・マネージャ情報の表示」を参照してください。
ペンディング・エリアで変更を加えているときは、次の文によって、いつでも妥当性チェック・プロシージャをコールできます。
EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;
このプロシージャは、加えられた変更が有効かどうかをチェックします。従う必要がある規則は、次のとおりです。これらの規則が妥当性チェック・プロシージャによってチェックされます。
OTHER_GROUPSのプラン・ディレクティブが存在する必要があります。これにより、現在のアクティブ・プラン内に含まれるコンシューマ・グループのいずれにも属していないセッションに、OTHER_GROUPSディレクティブで指定したリソースが割り当てられることが保証されます。
これらの規則のいずれかに違反すると、エラー・メッセージが返されます。その場合は、変更を加えて問題を修正し、妥当性チェック・プロシージャを再度コールできます。
プラン・ディレクティブによって参照されない孤立したコンシューマ・グループを作成できます。これにより、当面は使用しないものの、将来的に実装するプランの一部として、コンシューマ・グループを作成できます。
変更の妥当性チェックを完了した後に、SUBMITプロシージャをコールして変更をアクティブにします。
EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;
SUBMITプロシージャでは妥当性チェックも実行されるため、妥当性チェック・プロシージャを別個にコールする必要はありません。ただし、プラン・スキーマを大幅に変更している場合、通常は、変更の妥当性チェックを段階的に行う方が問題のデバッグ作業が容易になります。ペンディング・エリア内のすべての変更について妥当性チェックが成功するまで、変更は発行されません（つまり、アクティブになりません）。
SUBMIT_PENDING_AREAプロシージャは、変更の妥当性チェックとコミットに成功すると、ペンディング・エリアを消去（解除）します。
ペンディング・エリアを随時消去するためのプロシージャも用意されています。次の文は、すべての変更内容をペンディング・エリアから消去します。
EXEC DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA;
再び変更を行うには、まずCREATE_PENDING_AREAプロシージャをコールする必要があります。
リソース・プランを作成するときは、次の表に示すパラメータを指定できます。最初のパラメータは必須で、残りのパラメータはオプションです。
Oracle Databaseには、単純な構造を含むリソース・プランSYSTEM_PLANが用意されています。環境によっては、このリソース・プランで十分です。 このプランについては、「オラクル社が提供するプラン」を参照してください。
プランを作成するには、CREATE_PLANプロシージャを使用します。次の文は、great_breadプランを作成します。ここでは、デフォルトのリソース割当て方法を使用しています。
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'great_bread', - COMMENT => 'great plan');
プラン情報を更新するには、UPDATE_PLANプロシージャを使用します。引数を指定せずにUPDATE_PLANプロシージャを実行すると、データ・ディクショナリ内のプラン情報は変更されません。次の文は、COMMENTパラメータを更新します。
EXEC DBMS_RESOURCE_MANAGER.UPDATE_PLAN(PLAN => 'great_bread', - NEW_COMMENT => 'great plan for great bread');
DELETE_PLANプロシージャは、指定したプランと、それに対応付けられているすべてのプラン・ディレクティブを削除します。次の文は、great_breadプランとそのディレクティブを削除します。
EXEC DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'great_bread');
リソース・コンシューマ・グループ自体が削除されるのではなく、great_breadプランとの対応付けが解除されます。
DELETE_PLAN_CASCADEプロシージャは、指定したプランと、そのすべての子孫（プラン・ディレクティブ、サブプラン、リソース・コンシューマ・グループ）を削除します。DELETE_PLAN_CASCADEでエラーが発生するとロールバックされ、プラン・スキーマは変更されません。
RATIOポリシーは、単一レベルのCPU割当て方法です。パーセンテージのかわりに、コンシューマ・グループに与えるCPUの割合に対応する数を指定します。たとえば、3つのコンシューマ・グループGOLD_CG、SILVER_CGおよびBRONZE_CGに、次のプラン・ディレクティブを指定するとします。
DBMS_RESOURCE_MANAGER.CREATE_PLAN (PLAN => 'service_level_plan', CPU_MTH -> 'RATIO', COMMENT => 'service level plan'); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'service_level_plan', GROUP_OR_SUBPLAN => 'GOLD_CG', COMMENT => 'Gold service level customers', CPU_P1 => 10); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'service_level_plan', GROUP_OR_SUBPLAN => 'SILVER_CG', COMMENT => 'Silver service level customers', CPU_P1 => 5); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'service_level_plan', GROUP_OR_SUBPLAN => 'BRONZE_CG', COMMENT => 'Bonze service level customers', CPU_P1 => 2); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'service_level_plan', GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'Lowest priority sessions', CPU_P1 => 1);
CPU割当ての割合は、GOLD_CG、SILVER_CG、BRONZE_CGおよびOTHER_GROUPSコンシューマ・グループに対して、それぞれ10:5:2:1です。
GOLD_CGおよびSILVER_CGコンシューマ・グループにのみセッションが存在する場合、CPU割当ての割合は、この2つのグループ間で10:5になります。
リソース・コンシューマ・グループを作成するときは、次のパラメータを指定できます。
常にデータ・ディクショナリ内に存在する2つの特別なコンシューマ・グループがあり、このグループは変更または削除できません。次の方法があります。
DEFAULT_CONSUMER_GROUP これは、初期コンシューマ・グループが明示的に割り当てられていないすべてのユーザー/セッションの初期コンシューマ・グループです。 DEFAULT_CONSUMER_GROUPには、PUBLICに付与されたスイッチ特権があるため、すべてのユーザーにこのコンシューマ・グループのスイッチ特権が自動的に付与されます（「スイッチ特権の管理」を参照）。
OTHER_GROUPS このコンシューマ・グループは、明示的にユーザーに割り当てることはできません。OTHER_GROUPSは、任意のアクティブ・プランのスキーマ内に指定されたリソース・ディレクティブを必ず持っています。このグループは、DEFAULT_CONSUMER_GROUPを含め、現在アクティブなプラン・スキーマの一部でないコンシューマ・グループに属するすべてのセッションに選択的に適用されます。
また、他の2つのグループSYS_GROUPおよびLOW_GROUPも、オラクル社が提供するSYSTEM_PLANの一部として提供されます。「オラクル社が提供するプラン」を参照してください。
コンシューマ・グループを作成するには、CREATE_CONSUMER_GROUPプロシージャを使用します。次の文は、コンシューマ・グループsalesを作成します。この文を正常に実行するには、ペンディング・エリアをアクティブにする必要があります。
EXEC DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (CONSUMER_GROUP => 'sales', - COMMENT => 'retail and wholesale sales');
コンシューマ・グループ情報を更新するには、UPDATE_CONSUMER_GROUPプロシージャを使用します。引数を指定せずにUPDATE_CONSUMER_GROUPプロシージャを実行すると、データ・ディクショナリ内のコンシューマ・グループ情報は変更されません。
DELETE_CONSUMER_GROUPプロシージャは、指定されたコンシューマ・グループを削除します。コンシューマ・グループを削除すると、そのグループを初期コンシューマ・グループとして持っているすべてのユーザーには、初期コンシューマ・グループとしてDEFAULT_CONSUMER_GROUPが割り当てられます。現在実行中のセッションのうち、削除されたコンシューマ・グループに属しているものはすべて、DEFAULT_CONSUMER_GROUPに切り替えられます。
リソース・プラン・ディレクティブは、リソース・プランにコンシューマ・グループを割り当てて、各リソース割当て方法のパラメータを指定します。リソース・プラン・ディレクティブを作成するときは、次のパラメータを指定できます。
リソース・プラン・ディレクティブを作成するには、CREATE_PLAN_DIRECTIVEを使用します。次の文は、プランgreat_breadのリソース・プラン・ディレクティブを作成します。
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'great_bread', - GROUP_OR_SUBPLAN => 'sales', COMMENT => 'sales group', - CPU_P1 => 60, PARALLEL_DEGREE_LIMIT_P1 => 4);
図24-1のようなプランを作成するには、次の文を実行します。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'great_bread', GROUP_OR_SUBPLAN => 'market', COMMENT => 'marketing group', CPU_P1 => 20); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'great_bread', GROUP_OR_SUBPLAN => 'develop', COMMENT => 'development group', CPU_P1 => 20); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'great_bread', GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'this one is required', CPU_P1 => 0, CPU_P2 => 100); END;
このプランでは、コンシューマ・グループsalesに対して操作の最大並列度が4に設定されていますが、他のコンシューマ・グループの並列度に制限はありません。また、レベル1のCPUリソースが残っている場合は、OTHER_GROUPSに（100%）割り当てられます。
プラン・ディレクティブを更新するには、UPDATE_PLAN_DIRECTIVEプロシージャを使用します。この例では、リソース・コンシューマ・グループdevelopのCPU割当てを変更しています。
EXEC DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE (PLAN => 'great_bread', - GROUP_OR_SUBPLAN => 'develop', NEW_CPU_P1 => 15);
引数を指定せずにUPDATE_PLAN_DIRECTIVEプロシージャを実行すると、データ・ディクショナリ内のプラン・ディレクティブは変更されません。
リソース・プラン・ディレクティブを削除するには、DELETE_PLAN_DIRECTIVEプロシージャを使用します。
同じコンシューマ・グループを参照する複数のリソース・プラン・ディレクティブがある場合は、個々のケースに対して次の規則が適用されます。
MAX_EST_EXEC_TIME = min（入力されるすべてのMAX_EST_EXEC_TIME値）
データベース・リソース・マネージャを使用可能にする前に、ユーザーにリソース・コンシューマ・グループを割り当てる必要があります。手動で割り当てることもできますが、データベースによって、セッション属性に基づいてユーザー・セッションをコンシューマ・グループに自動的に割り当てるようなマッピングを指定することもできます。
DBMS_RESOURCE_MANAGERパッケージには、データベース・リソース・マネージャで使用される要素を作成、更新または削除するためのプロシージャのみでなく、ユーザーへのリソース・コンシューマ・グループの割当てに影響を与えるプロシージャも含まれています。また、ユーザー・セッションを一時的に別のコンシューマ・グループに切り替えるためのプロシージャも用意されています。
データベース・リソース・マネージャのシステム権限の付与に関連してすでに説明したように、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用して、別のユーザーにスイッチ特権を付与することもできます。この権限を付与されたユーザーは、自分のコンシューマ・グループを変更できます。
ここで説明しているプロシージャの中で、ペンディング・エリアが使用できるのはSET_CONSUMER_GROUP_MAPPINGおよびSET_CONSUMER_GROUP_MAPPING_PRIプロシージャのみです。これらのプロシージャは、コンシューマ・グループへのセッションの自動割当てに使用されます。
この項の内容は、次のとおりです。
セッションの初期コンシューマ・グループは、そのセッションの属性をコンシューマ・グループにマッピングすることによって決定されます。 マッピングの構成方法の詳細は、「リソース・コンシューマ・グループのセッションへの自動割当て」を参照してください。
DBMS_RESOURCE_MANAGERパッケージには、管理者が実行中のセッションのリソース・コンシューマ・グループを変更できるように、2つのプロシージャが含まれています。この2つのプロシージャでは、コーディネータのセッションに対応付けられたパラレル実行サーバー・セッションのコンシューマ・グループも変更できます。これらのプロシージャで行った変更は永続的ではなく、現行セッションのみに影響します。ユーザーの初期コンシューマ・グループも変更されません。
あるユーザーがCPUを過剰に使用している場合、管理者は、そのユーザーのセッションを停止するかわりに、ユーザーのコンシューマ・グループをCPUパーセンテージの低いグループに変更できます。この切替えは、コンシューマ・グループを自動的に切り替えるリソース・プラン・ディレクティブを使用して、自動的に実行できます。
SWITCH_CONSUMMER_GROUP_FOR_SESSは、指定したセッションを、指定したリソース・コンシューマ・グループに即時に移動します。この文を使用すれば、実質上、優先順位を変更できます。次の文は、特定セッションのリソース・コンシューマ・グループを、新しいコンシューマ・グループに変更します。セッション識別子（SID）が17、セッション・シリアル番号（SERIAL#）が12345のセッションが、high_priorityコンシューマ・グループに変更されます。
EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345', - 'high_priorty');
SID、セッション・シリアル番号、およびセッションの現行リソース・コンシューマ・グループは、V$SESSIONデータ・ディクショナリ・ビューを使用して確認できます。
SWITCH_CONSUMER_GROUP_FOR_USERプロシージャは、指定されたユーザー名を持つすべてのセッションのリソース・コンシューマ・グループを変更します。
EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('scott', - 'low_group');
スイッチ特権が付与されているユーザーは、DBMS_SESSIONパッケージのSWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、自分の現行コンシューマ・グループを切り替えることができます。
このプロシージャによって、ユーザーはスイッチ特権を持っているコンシューマ・グループに切り替えることができます。他のプロシージャからこのプロシージャがコールされた場合、ユーザーはコール側のプロシージャの所有者がスイッチ特権を持っているコンシューマ・グループに切り替えることができます。
このプロシージャのパラメータは、次のとおりです。
次の例は、新しいコンシューマ・グループへの切替え方法を示しています。出力パラメータold_groupの値が出力されているので、変更前のコンシューマ・グループ名がどのように保存されているかがわかります。
SET serveroutput on DECLARE old_group varchar2(30); BEGIN DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('sales', old_group, FALSE); DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group); END;
次の行が出力されます。
OLD GROUP = DEFAULT_CONSUMER_GROUP
DBMS_SESSIONパッケージは、PL/SQLアプリケーション内部から使用できます。これにより、アプリケーションからコンシューマ・グループを変更できるので、実質上、優先順位の動的な変更が可能になります。
データベース・リソース・マネージャでは、SWITCH_CURRENT_CONSUMER_GROUPプロシージャがコールされて、セッションがすでに属しているコンシューマ・グループに切り替えられた場合でも、切替えが発生したとみなされます。
DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用すると、ユーザー、ロールまたはPUBLICにスイッチ特権を付与したり、取り消したりできます。スイッチ特権は、ユーザーに対して自分の現行リソース・コンシューマ・グループを指定のリソース・コンシューマ・グループに切り替える権限を与えます。このパッケージでは、スイッチ特権を取り消すこともできます。
実際の切替えは、DBMS_SESSIONパッケージのプロシージャを実行することによって行われます。スイッチ特権が付与されているユーザー（またはそのユーザーが所有するプロシージャ）は、SWITCH_CURRENT_CONSUMER_GROUPプロシージャを使用して、別のリソース・コンシューマ・グループに切り替えることができます。切替え後のグループは、そのユーザーが明示的に切替えを許可されたグループである必要があります。
次の例では、コンシューマ・グループに切り替える権限を付与しています。ユーザーscottには、コンシューマ・グループbug_batch_groupに切り替える権限が付与されます。
EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP ('scott', - 'bug_batch_group', TRUE);
また、ユーザーscottには、bug_batch_groupのスイッチ特権を他のユーザーに付与する許可も付与されます。
特定のコンシューマ・グループに切り替えるユーザー許可を付与すると、そのユーザーは自分の現行コンシューマ・グループを新しいコンシューマ・グループに切り替えることができます。
特定のリソース・コンシューマ・グループに切り替えるロール許可を付与すると、そのロールが付与されており、使用可能になっているユーザーは、自分の現行コンシューマ・グループを新しいコンシューマ・グループに即時に切り替えることができます。
特定のコンシューマ・グループに切り替える許可をPUBLICに付与すると、だれでもそのグループに切り替えることができます。
GRANT_OPTION引数がTRUEの場合、コンシューマ・グループのスイッチ特権が付与されたユーザーは、そのコンシューマ・グループのスイッチ特権を他のユーザーに付与することもできます。
次の例では、ユーザーscottから、コンシューマ・グループbug_batch_groupに切り替える権限を取り消しています。
EXEC DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP ('scott', - 'bug_batch_group');
特定のコンシューマ・グループに対するユーザーのスイッチ特権を取り消した場合は、そのユーザーがそのコンシューマ・グループに切り替えようとすると失敗します。ユーザーの初期コンシューマ・グループを取り消すと、そのユーザーはログイン時に自動的にDEFAULT_CONSUMER_GROUPに割り当てられます。
コンシューマ・グループに対するスイッチ特権をロールから取り消すと、そのロールを介してのみコンシューマ・グループのスイッチ特権を与えられているユーザーは、そのコンシューマ・グループに切り替えることができなくなります。
コンシューマ・グループに対するスイッチ特権をPUBLICから取り消した場合は、直接またはPUBLICを介してスイッチ特権を明示的に割り当てられているユーザーを除き、そのコンシューマ・グループに切り替えることができなくなります。
データベース・リソース・マネージャは、セッション属性とコンシューマ・グループの間のマッピングを指定することによって、コンシューマ・グループをセッションに自動的に割り当てるように構成できます。さらに、競合が発生した場合に優先するマッピングを示すために、マッピングに優先順位を設定できます。
セッション属性には、ログイン属性とランタイム属性の2つのタイプがあります。ログイン属性が有効なのは、セッションのログイン時、つまりデータベース・リソース・マネージャによってセッションの初期コンシューマ・グループが決定されるときのみです。一方、すでにログインしているセッションは、そのランタイム属性に基づいて別のコンシューマ・グループに後で再割当できます。
コンシューマ・グループへのセッションの自動割当てを構成するには、SET_CONSUMER_GROUP_MAPPINGおよびSET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用します。これらのプロシージャに対してはペンディング・エリアを使用する必要があります。
セッションのマッピングは、セッションとコンシューマ・グループとの一致方法を決定する、属性とコンシューマ・グループとの組合せのセットで構成されます。SET_CONSUMER_GROUP_MAPPINGプロシージャを使用して、1つのセッション属性をコンシュ―マ・グループにマップします。このプロシージャのパラメータは、次のとおりです。
| パラメータ | 説明 |
|---|---|
|
|
ログインまたはランタイムのセッション属性タイプ。 |
|
|
マッピングされる属性の値。 |
|
|
マッピング先のコンシューマ・グループ。 |
次の属性があります。
たとえば、次の文では、ユーザーscottはログインするたびにdev_groupコンシューマ・グループにマッピングされます。
BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.ORACLE_USER, 'scott', 'dev_group'); END;
競合マッピング解決するために、重要度の最も高い属性から最も低い属性まで優先順位を設定できます。各属性の優先順位は、SET_CONSUMER_GROUP_MAPPING_PRIプロシージャを使用して、1（重要度が最も高い）〜10（重要度が最も低い）の一意の整数に設定します。次の例は、この優先順位の設定方法を示しています。
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のマッピングの他に、次のようなモジュール名マッピングがあると考えます。
EXEC DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING - (DBMS_RESOURCE_MANAGER.MODULE_NAME, 'backup', 'low_priority');
ここでセッションがそのモジュール名をbackupに設定すると、そのセッションはlow_priorityコンシューマ・グループに再割当てされます。これは、モジュール名マッピングのほうがデータベース・ユーザー・マッピングより優先順位が高いためです。
認可されていないクライアントがそのセッション属性を設定して優先順位の高いコンシューマ・グループにクライアント自身をマッピングしないように、コンシューマ・グループに対してユーザー・スイッチ特権が適用されます。つまり、指定されたセッション属性がマッピング・ペアと一致する場合でも、マッピングが有効であるとみなされるのは、セッションにその特定のコンシューマ・グループに対するスイッチ特権がある場合のみです。セッションは、スイッチ特権が付与されているコンシューマ・グループに対してのみ自動的に切り替えられます。
各セッションは、マッピングによって様々な時点で別のコンシューマ・グループに自動的に切り替えられます。
これらのルールについては、次の2つの点に注意してください。
ACTIVE_TIME_IN_GROUP値）。
データベース・リソース・マネージャを使用可能にするには、RESOURCE_MANAGER_PLAN初期化パラメータを設定します。このパラメータには、トップレベルのプランを指定します。これにより、このインスタンスで使用するプラン・スキーマが識別されます。このパラメータでプランを指定しない場合、データベース・リソース・マネージャはアクティブになりません。
次の例では、データベース・リソース・マネージャをアクティブにし、トップレベルのプランとしてmydb_planを指定しています。
RESOURCE_MANAGER_PLAN = mydb_plan
また、DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャまたはALTER SYSTEM文を使用して、データベース・リソース・マネージャのアクティブ化と非アクティブ化、または現行のトップレベル・プランの変更が可能です。この例では、トップレベルのプランとしてmydb_planを指定しています。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';
指定したプランがデータ・ディクショナリに存在しない場合は、エラー・メッセージが返されます。
データベース・リソース・マネージャを解除するには、次の文を発行します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
スケジューラによって、Resource Managerのプランがスケジューラ・ウィンドウ境界で自動的に変更されます。この変更は、容認できない場合があります。たとえば、終了する必要のある重要なタスクがあり、Resource Managerプランにタスクの優先順位を設定してある場合、設定を変更するまでは同じプランのままであることを想定しています。しかし、プランの設定後にスケジューラ・ウィンドウがアクティブになるため、タスクの実行中にResource Managerのプランが変更される可能性があります。
この状況を回避するには、RESOURCE_MANAGER_PLANパラメータをシステムに必要なプランの名前に設定し、その名前の前に「FORCE:」を付加します。接頭辞FORCEを付加すると、現行のResource Managerプランの変更が、データベース管理者によるRESOURCE_MANAGER_PLANパラメータ値の変更によってのみ可能となります。この制限を解除するには、プラン名の前に「FORCE:」を付加せずに、そのコマンドを再実行します。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';
DBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャには同様の機能があります。
ここでは、リソース・プラン・スキーマの例をいくつか示します。ここで取り上げる例は、次のとおりです。
次の文は、図24-3に図示されている複数レベルのスキーマを作成します。この例では、デフォルトのプランとリソース・コンシューマ・グループによる方法が使用されています。
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', CPU_P1 => 80, CPU_P2=> 0,
PARALLEL_DEGREE_LIMIT_P1 => 8);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'Batch_group',
COMMENT => 'batch bug users sessions at level 1', CPU_P1 => 20, CPU_P2 => 0,
PARALLEL_DEGREE_LIMIT_P1 => 2);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'Bug_Maint_group',
COMMENT => 'bug maintenance users sessions at level 2', CPU_P1 => 0, CPU_P2 => 100,
PARALLEL_DEGREE_LIMIT_P1 => 3);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'bugdb_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT => 'all other users sessions at level 3', CPU_P1 => 0, CPU_P2 => 0,
CPU_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Postman_group',
COMMENT => 'mail postman at level 1', CPU_P1 => 40, CPU_P2 => 0,
PARALLEL_DEGREE_LIMIT_P1 => 4);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Users_group',
COMMENT => 'mail users sessions at level 2', CPU_P1 => 0, CPU_P2 => 80,
PARALLEL_DEGREE_LIMIT_P1 => 4);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'Mail_Maint_group',
COMMENT => 'mail maintenance users sessions at level 2', CPU_P1 => 0, CPU_P2 => 20,
PARALLEL_DEGREE_LIMIT_P1 => 2);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'maildb_plan',
GROUP_OR_SUBPLAN => 'OTHER_GROUPS',
COMMENT => 'all other users sessions at level 3', CPU_P1 => 0, CPU_P2 => 0,
CPU_P3 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan',
GROUP_OR_SUBPLAN => 'maildb_plan',
COMMENT=> 'all mail users sessions at level 1', CPU_P1 => 30);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'mydb_plan',
GROUP_OR_SUBPLAN => 'bugdb_plan',
COMMENT => 'all bug users sessions at level 1', CPU_P1 => 70);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
妥当性チェックはSUBMIT_PENDING_AREAによって暗黙的に実行されるので、直前のVALIDATE_PENDING_AREAのコールはオプションです。
maildb_planでは、レベル1のPostman_groupに割り当てられているCPUは40%のみのため、レベル1には暗黙的に60%使用されていないリソースがあります。この60%は、レベル2のUsers_groupおよびMail_Maint_groupによって共有されます。
ここで示す例は、パッケージ化されたEnterprise Resource Planning（ERP）またはCustomer Relationship Management（CRM）をサポートするデータベース用のプランを表します。このような環境で必要な処理は多種多様です。大規模なパラレル問合せを含む長時間実行のバッチ・ジョブとともに、短いトランザクションや短い問合せが混在している場合があります。その目的は、バッチ・ジョブをパラレルに実行しながら、オンライン・トランザクション処理（OLTP）の適切な応答時間を得ることにあります。
次の表にプランがまとめられています。
| グループ | CPUリソース割当て% | アクティブ・セッション・プール・パラメータ | 自動切替えパラメータ | 最大見積り実行時間 | UNDOプール |
|---|---|---|---|---|---|
|
|
レベル1: 80% |
|
短い問合せ: |
-- |
サイズ: 200KB |
|
|
レベル2: 100% |
タイムアウト: 600 |
-- |
時間: 3600 |
-- |
|
|
レベル3: 100% |
-- |
-- |
-- |
-- |
次の文は、この表のプランを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', CPU_P1 => 80,
SWITCH_GROUP => 'batch', SWITCH_TIME => 3,SWITCH_ESTIMATE => TRUE,
UNDO_POOL => 200);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN => 'erp_plan',
GROUP_OR_SUBPLAN => 'batch', COMMENT => 'BATCH sessions', CPU_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', CPU_P3 => 100);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
Oracle Databaseには、システム・セッションの優先順位を設定するデフォルトのリソース・マネージャ・プラン、SYSTEM_PLANが用意されています。SYSTEM_PLANの定義は、次のとおりです。
| リソース・コンシューマ・グループ | CPUリソース割当て | ||
|---|---|---|---|
| レベル1 | レベル2 | レベル3 | |
|
|
100% |
0% |
0% |
|
|
0% |
100% |
0% |
|
|
0% |
0% |
100% |
このプランでデータベースは次のグループを用意しています。
SYS_GROUPは、ユーザーSYSおよびSYSTEMの初期コンシューマ・グループです。
OTHER_GROUPSは、現在アクティブなプラン・スキーマの一部でないコンシューマ・グループに属するすべてのセッションに適用されます。
LOW_GROUPは、このプランでSYS_GROUPおよびOTHER_GROUPSより優先順位の低いグループを表します。LOW_GROUPに含めるユーザー・セッションは、管理者が指定できます。このグループのスイッチ特権は、PUBLICに付与されています。
これらのグループの使用は選択可能で、変更または削除することもできます。
環境に適切な場合は、データベースにより提供されるこの単純なプランを使用できます。
データベース・リソース・マネージャを効果的に監視およびチューニングするには、代理環境を設計する必要があります。データベース・リソース・マネージャは、システム使用率が高い大規模な本番環境で最も効果的に機能します。システムの負荷が不十分な状態でテストを行うと、測定されたCPU割当てとアクティブ・リソース・プランに指定する割当てが大きく異なる場合があります。これは、コンシューマ・グループが必要なリソースを取得している間は、データベース・リソース・マネージャはCPU割当てのパーセンテージの制限を適用しないためです。
代理環境を作成するには、CPUリソースが不足するほど十分な負荷（CPUリソースの要求）が必要です。次の規則に従えば、テスト環境で生成される実際の（測定された）リソース割当てと、アクティブ・リソース・プランに指定するリソース割当てが一致します。
BEGIN DECLARE m NUMBER; BEGIN FOR i IN 1..100000 LOOP FOR j IN 1..100000 LOOP /* * The following query does a cartesian product without * a predicate and takes up significant CPU time. */ select count(*) into m from v$sysstat, v$system_event; END LOOP; END LOOP; END; END; /
すべてのグループが要求どおりのCPUリソースを確保できる場合、最初にデータベース・リソース・マネージャは、割り当てられたパーセンテージに従うのではなく、システム全体のスループットを最大限に高めようとします。たとえば、次のような条件を考えます。
この場合、各コンシューマ・グループで測定されるCPU割当ては、アクティブ・リソース・プランに指定された割当てとは関係なく25%になります。
前の項の1の計算に影響する別の要因があります。オペレーティング・システム・レベルでプロセッサ・アフィニティに従ってスケジューリングが実行された場合、負荷が十分でないシステムではCPU割当てにゆがみが生じることがあります。これについて、次の段落で説明します。
オペレーティング・システムの標準的なスケジューリング・アルゴリズムでは、同時実行プロセスの数が一定のレベルに達するまで、100%の使用は避けられます。データベース・リソース・マネージャは、実行プロセスの数を制限することによって、CPUの使用を制御します。また、どのプロセスにどれだけの時間実行を許可するかを決定することによって、CPUリソースの割当てを制御します。あるCPUのリソースが使用可能で、他のプロセッサがすべて100%使用されている場合、オペレーティング・システムはプロセスを使用率の低いプロセッサに移行しますが、即時にではありません。
プロセッサ・アフィニティによって、オペレーティング・システムは、CPU間でプロセスを強制的に移行する前に、他のプロセスが実行のためにディスパッチされることも想定して、プロセスの移行を（一時的に）待機します。この方式は、負荷が100%あり、多くのプロセスが待機しているシステムで有益です。大規模な本番環境では、現行のCPUキャッシュを無効化して新規のCPUキャッシュをロードすることは高コストであるため、プロセッサ・アフィニティによってパフォーマンスが大幅に向上します。ほとんどのプラットフォームで、プロセスはプロセッサ・アフィニティを持っているので、コンシューマ・グループごとにCPUの数より多くのプロセスを実行すべきです。そうでなければ、システムを100%使用することはできません。
これらのビューを使用して、Resource Manager設定の結果を監視します。
CPUの使用を監視するには、V$RSRC_CONSUMER_GROUPビューを使用します。このビューには、各コンシューマ・グループのすべてのセッションで消費されたCPUタイムの累積値が含まれています。その他にも、チューニングに役立つ測定値が含まれています。
SQL> SELECT NAME, CONSUMED_CPU_TIME FROM V$RSRC_CONSUMER_GROUP; NAME CONSUMED_CPU_TIME -------------------------------- ----------------- OTHER_GROUPS 14301 TEST_GROUP 8802 TEST_GROUP2 0 3 rows selected.
このビューを使用して、特定セッションのステータスを監視します。このビューは、Resource Managerによりセッションが受けている影響を示します。次のような情報が提供されます。
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 ------- --------------- -------- ---------- ------------- ----------- 145 SYS_GROUP RUNNING 572217 0 0 158 OTHER_GROUPS WAITING 220 0 0 142 OTHER_GROUPS WAITING 146453 0 0 141 OTHER_GROUPS WAITING 148228 0 0
このビューは、このインスタンスでResource Managerのプランが有効化あるいは無効化された場合に表示されます。 このビューは、コンシューマ・グループ間で一定期間にリソースがどのように共有されているかを理解する上で役立ちます。V$RSRC_CONS_GROUP_HISTORYビューのエントリごとに、プランの各コンシューマ・グループに対応するエントリが表示され、コンシューマ・グループごとの累積統計が示されます。
Oracle Databaseサーバーは、静的な構成を想定し、データベースの起動時に検出された使用可能なリソースから、ラッチなどの内部リソースを割り当てます。リソースの構成が頻繁に変更されると、データベースが最適に実行されず、不安定になる場合があります。
Oracle Databaseに関してオペレーティング・システムによるリソース制御を使用する場合は、次のガイドラインに従って慎重に使用する必要があります。
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='';
また、次回のデータベース起動時にデータベース・リソース・マネージャがアクティブ化されないように、初期化パラメータ・ファイルでこのパラメータをリセットすることも忘れないでください。
Sun社のプロセッサ・セットや動的システム・ドメインなどのツールは、Oracle Databaseとともに正常に動作します。CPUの数が変更された場合でも、インスタンスを再起動する必要はありません。
データベースでは、使用可能なCPUの数の変更が動的に検出され、内部リソースが再割当てされます。ほとんどのプラットフォームで、CPU_COUNT初期化パラメータの値が使用可能なCPUの数に自動的に調整されます。
データベース・リソース・マネージャに対応付けられているビューを次の表に示します。
これらのビューを使用して、権限やプラン・スキーマを表示できます。また、これらのビューを監視して、データベース・リソース・マネージャのチューニングに使用する情報を収集することもできます。次に、これらのビューの使用例をいくつか示します。
DBA_RSRC_CONSUMER_GROUP_PRIVSビューには、ユーザーまたはロールに付与されたコンシューマ・グループが表示されます。具体的には、ユーザーまたはロールが属しているグループや、切替え先のグループが表示されます。たとえば、次に示すビューでは、ユーザーscottはコンシューマ・グループmarketまたはsalesに所属でき、salesグループに他のユーザーを割り当てる（付与する）権限を持っています。しかし、marketグループに他のユーザーを割り当てる権限はありません。どちらのグループも、scottの初期コンシューマ・グループではありません。
SQL> SELECT * FROM DBA_RSRC_CONSUMER_GROUP_PRIVS; GRANTEE GRANTED_GROUP GRA INI ------------------------------ ------------------------------ --- --- PUBLIC DEFAULT_CONSUMER_GROUP YES YES PUBLIC LOW_GROUP NO NO SCOTT MARKET NO NO SCOTT SALES YES NO SYSTEM SYS_GROUP NO YES
scottは、DBMS_RESOURCE_MANAGER_PRIVSパッケージを使用してこれらのグループに切り替える権限をすでに付与されています。
この例では、DBA_RSRC_PLANSビューを使用して、データベース内に定義されているすべてのリソース・プランを表示する方法を示しています。表示されるプランはすべてアクティブです。つまり、ペンディング・エリアにステージングされていません。
SQL> SELECT PLAN,COMMENTS,STATUS FROM DBA_RSRC_PLANS; PLAN COMMENTS STATUS ----------- ------------------------------------------------------- ------ SYSTEM_PLAN Plan to give system sessions priority ACTIVE BUGDB_PLAN Resource plan/method for bug users sessions ACTIVE MAILDB_PLAN Resource plan/method for mail users sessions ACTIVE MYDB_PLAN Resource plan/method for bug and mail users sessions ACTIVE GREAT_BREAD Great plan for great bread ACTIVE ERP_PLAN Resource plan/method for ERP Database ACTIVE 6 rows selected.
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 10 rows selected.
この例では、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_TO ------------------------------------- MYDB_PLAN TRUE MAILDB_PLAN FALSE BUGDB_PLAN FALSE
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|