Oracle Cloud Infrastructureドキュメント

Autonomous AI Databaseのデータベース・リソース・マネージャを使用したワークロード・リソースの管理

Autonomous AI Databaseで様々なユーザー、アプリケーションまたはワークロード・タイプのリソース割当てをカスタマイズするには、cs_resource_managerサブプログラムを使用して、独自のデータベース・リソース・マネージャ(DBRM)計画およびコンシューマ・グループを作成および管理できます。

Autonomous AI Databaseでは、各サービスに割り当てられるリソースを制御するデフォルトのリソース管理計画が使用されます。ただし、カスタマイズされたリソース・マネージャ・プランでデータベース内の様々なユーザー、アプリケーションおよびワークロードのリソースを制御する場合は、cs_resource_managerサブプログラムを使用して、独自のデータベース・リソース・マネージャ(DBRM)プランを定義および管理し、カスタム・コンシューマ・グループを定義し、Autonomous AI Databaseでリソース使用率ポリシーを調整して、ワークロードの優先順位付けおよびシステム・リソース割当てを制御できます。

トピック:

cs_resource_managerパッケージについて

cs_resource_managerサブプログラムを使用すると、特定のリソース使用ポリシーおよびディレクティブを各コンシューマ・グループに関連付け、要件の変更に応じてポリシーを実装、監視および改訂できます。

cs_resource_managerサブプログラムを使用すると、次のことができます。

  • 独自のデータベース・リソース・マネージャ(DBRM)計画を作成します。

  • カスタム・コンシューマ・グループを作成および削除します。

  • コンシューマ・グループ・マッピング、つまり、これらのコンシューマ・グループにセッションを割り当てる方法のルールと優先度を設定します。

  • コンシューマ・グループのマッピング優先度を設定します。

  • プラン・ディレクティブを定義して、各カスタム・コンシューマ・グループに次のリソース制御を割り当てます。

    • コンシューマ・グループのリソース割当ての共有。共有は、コンシューマ・グループが他のコンシューマ・グループに対して取得するCPUおよびIOリソースの量を決定します。たとえば、2のシェアを持つコンシューマ・グループは、1のシェアを持つコンシューマ・グループよりも2倍のCPUおよびIOリソースを取得します。デフォルト値は1です。

    • コンシューマ・グループが取得できる最大CPUおよびI/Oリソースを決定するリソース制限。

    • switch_actionパラメータによって決定されたアクションが実行されるまでにセッションを実行できるCPUの時間(秒)。デフォルトのNULLは、無制限を意味します。

    • switch_actionパラメータによって決定されたアクションの実行前に、セッションで発行できるI/Oの容量(MB)。デフォルトのNULLは、無制限を意味します。

    • switch_actionパラメータによって決定されたアクションが実行される前にセッションが発行できるI/Oリクエストの数。デフォルトのNULLは、無制限を意味します。

    • switch_actionで指定されたアクションをトリガーする論理I/Oの数。

    • switch_actionで指定されたアクションをトリガーする経過時間(秒単位)。

    • セッションが終了するまでにセッションをアイドル状態にできる秒数。デフォルトのNULLは、無制限を意味します。

    • セッションがロックまたはほかのセッションに必要なリソースを保持している場合に、セッションが終了するまでにセッションをアイドル状態にできる最大時間(秒)。

    • アクティブ・コールを同時に持つことができるセッションの最大数。

    • 非アクティブ・セッション・キューにあるコール(実行待ち状態)がタイムアウトする時間(秒)を指定します。デフォルトのNULLは、無制限を意味します。

    • 任意の操作に対する並列度(DOP)の制限。デフォルトのNULLは、無制限を意味します。工程をシリアルにするには値1を使用します

    • パラレル文の同時実行性レベル。同時実行性レベルによってDOPが間接的に決定されるため、両方の値を設定すると競合が発生します。コンシューマ・グループの同時実行性または並列度のみを設定することをお薦めします。両方は設定しないでください。

    • このコンシューマ・グループのセッションが終了する前に割当て可能な、チューニングできないPGAの最大量(MB)。NULL (デフォルト)は、制限がないことを示します。チューニング可能なPGAを割り当てるSQL操作(一時領域の使用を選択できる操作)は、この制限によって制御されません。

    • パラレル・ステートメントがコンシューマ・グループ内のパラレル・ステートメント・キュー内に残存する時間(秒)。タイムアウトのためにパラレル・ステートメントがキューから削除されたときに実行するアクションと組み合せる必要があります。オプションは、文を取り消すか実行するかのいずれかです。

    • ディレクティブで指定された制限に達したときに実行されるアクション。有効な値は、cancel_sql、kill_sessionまたは切り替えるコンシューマ・グループ名です。

  • カスタムDBRMプランをアクティブ化し、必要に応じてデフォルトに戻します。

次のトピックでは、実用的なユースケースの例として、カスタム・コンシューマ・グループ、プランおよびセッション・マッピングを定義するための詳細なワークフローの概要を示します。このワークフローおよび関連するコード例は、要件に応じて変更および実装できます。

ユースケース

OLTPアプリケーションとレイクハウス・アプリケーションの両方を備えた混合ワークロード環境に自律型AIデータベースを使用することを決定した組織について考えてみます。データベース管理者は、アプリケーションのリソース要件とワークロード特性に基づいて、Autonomous AI Databaseに付属する事前定義済のコンシューマ・グループやプランではなく、カスタムDBRMプランを定義して使用するのが最適であると判断しました。

次の要件について最終決定しました。

  1. 3つのコンシューマ・グループを作成します。

    • 優先度の高いトランザクション処理セッションを処理するOLTP_HIGH。

    • バックグラウンドまたは低優先度のトランザクション処理セッションを処理するOLTP_LOW。

    • バッチまたはレポート・ワークロードの場合はLH_BATCH。

  2. OLTP_LH_PLANというプランを作成して、トランザクション処理ワークロードとレイクハウス・ワークロード間でリソースを分割します。

  3. 次のシナリオについて、4つのプラン・ディレクティブを作成します。

    • 優先度の高いトランザクション処理セッションでは、8個のCPUおよびI/O共有が取得され、並列性は取得されません。

    • 優先度の低いトランザクション処理セッションでは、4つのCPUおよびI/O共有が取得され、並列性は取得されません。

    • レイクハウスおよびバッチ・トランザクションでは、4つのCPUおよびI/O共有を取得し、並列度は4に制限されます。

    • コンシューマ・グループにマップされていない他のすべてのセッションでは、1つのCPU/IO共有が取得され、並列性は取得されません。

  4. 次のユーザーからコンシューマ・グループへのマッピングを作成します。

    • APP_USERからOLTP_HIGH

    • LH_USERからLH_BATCH

  5. プランを使用可能にします。

前提条件

cs_resource_managerサブプログラムを使用するには、ADMINユーザーとしてAutonomous AI Databaseに接続します。ADMINユーザーとして、必要に応じて、このパッケージに対する権限を他のユーザーに付与することもできます。

ステップ1: コンシューマ・グループの作成

カスタム・コンシューマ・グループは、cs_resource_manager.create_consumer_groupプロシージャを使用して作成できます。

接続(セッション)は、接続文字列にコンシューマ・グループを指定するか、set_consumer_group_mappingおよびset_consumer_group_mapping_priサブプログラムを使用してコンシューマ・グループ・マッピング・ルールを構成することで、新しいコンシューマ・グループに配置できます。

  • ペンディング・エリアを起動して、すべてのリソース・マネージャDDL文を実行します。

    BEGIN
  CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
END;
/

  • 3つのコンシューマ・グループを作成します。

    • 優先度の高いトランザクション処理セッションを処理するOLTP_HIGH。

    • バックグラウンドまたは低優先度のトランザクション処理セッションを処理するOLTP_LOW。

    • バッチまたはレポート・ワークロードの場合はLH_BATCH。

    BEGIN
  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'OLTP_HIGH',
    comment        => 'Priority OLTP sessions');

  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'OLTP_LOW',
    comment        => 'Background/low-priority OLTP');

  CS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    consumer_group => 'LH_BATCH',
    comment        => 'Batch / reporting workloads');
END;
/

    ノート

    ノート: OTHER_GROUPSは、マップされていないセッションに対してデフォルトで利用できる暗黙的なグループです。

構文リファレンスについては、CREATE_PENDING_AREAプロシージャおよびCREATE_CONSUMER_GROUPプロシージャを参照してください。

ステップ2: 計画の作成

OLTP_LH_PLANというプランを作成して、トランザクション処理とレイクハウス・ワークロード・タイプの間でリソースを分割します。

BEGIN
  CS_RESOURCE_MANAGER.CREATE_PLAN(
    plan    => 'OLTP_LH_PLAN',
    comment => 'Split resources between OLTP and Lakehouse workload types');
END;
/

構文リファレンスは、「CREATE_PLANプロシージャ」を参照してください。

ステップ3: 計画ディレクティブの作成

カスタム・コンシューマ・グループに対して、CPU共有、I/O制限、同時実行性および並列性などのプラン・ディレクティブを割り当てて調整できます。ディレクティブの完全なリストは、「cs_resource_managerパッケージについて」を参照してください。

次のシナリオについて、4つのプラン・ディレクティブを作成します。

  • 優先度の高いトランザクション処理セッションでは、8個のCPUおよびI/O共有が取得され、並列性は取得されません。

  • 優先度の低いトランザクション処理セッションでは、4つのCPUおよびI/O共有が取得され、並列性は取得されません。

  • レイクハウスおよびバッチ・トランザクション:

    • 4 CPUおよびI/O共有を取得します。

    • 並列度は4に制限されています。

    • パラレル・キューのタイムアウトを60秒に設定し、タイムアウト後にSQL文を終了します。

  • コンシューマ・グループにマップされていない他のすべてのセッションでは、1つのCPU/IO共有が取得され、並列性は取得されません。

BEGIN

  -- High-priority OLTP gets 8 CPU/IO shares and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OLTP_HIGH',
    comment               => 'OLTP high priority',
    shares                => 8,
    parallel_degree_limit => 1
  );

  -- Lower-priority OLTP gets 4 CPU/IO shares and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OLTP_LOW',
    comment               => 'OLTP low priority',
    shares                => 2,
    parallel_degree_limit => 1
  );

  -- Lakehouse / batch gets 4 shares and the degree of parallelism is capped to 4.
  -- If a parallel SQL statement waits in the queue for more than 60 seconds, it will be canceled.
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                          => 'OLTP_LH_PLAN',
    consumer_group                => 'LH_BATCH',
    comment                       => 'Lakehouse/reporting workloads',
    shares                        => 4,
    parallel_degree_limit         => 4,     -- cap DOP within this group (adjust as needed)
    parallel_queue_timeout        => 60,
    parallel_queue_timeout_action => 'CANCEL'
  );

  -- Catch-all for anything unmapped; sessions that are not mapped to a consumer group get 1 CPU/IO share and no parallelism
  CS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    plan                  => 'OLTP_LH_PLAN',
    consumer_group        => 'OTHER_GROUPS',
    comment               => 'Catch-all for unmapped sessions',
    shares                => 1,
    parallel_degree_limit => 1
  );
END;
/

構文リファレンスは、「CREATE_PLAN_DIRECTIVEプロシージャ」を参照してください。

ステップ4: コンシューマ・グループ・マッピングの作成

セッションのログイン属性およびランタイム属性に基づいて、セッションをカスタム・コンシューマ・グループにマップできます。cs_resource_manager.set_consumer_group_mappingおよびcs_resource_manager.set_consumer_group_mapping_priサブプログラムを使用すると、これらのコンシューマ・グループにセッションを割り当てるためのルールおよび優先度を定義し、コンシューマ・グループ・マッピングの優先度を定義できます。異なる属性を持つ複数のマッピングを持つことができます。この例では、APP_USERがOLTP_HIGHにマップされ、LH_USERがLH_BATCHにマップされます。これらのマッピングは、SET_CONSUMER_GROUP_MAPPING_PRIで設定された優先順位で評価されます。

次の方法で、コンシューマ・グループにセッションを配置する方法を決定できます。

  • 接続文字列の割当て:次に示すように、データベース接続文字列にCONSUMER_GROUPを指定します。この方法はマッピングよりも優先され、定義されたマッピングはすべてオーバーライドされます。 
    (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=my_database_low.adb.oraclecloud.com)(CONSUMER_GROUP=OLTP_LOW))(security=(ssl_server_dn_match=yes)))

  • マッピング・ルール: set_consumer_group_mappingおよびset_consumer_group_mapping_priサブプログラムを使用して、ユーザー名やアプリケーション名などの属性に基づいて、セッションまたはアプリケーションをコンシューマ・グループに割り当てます。

    ノート

    ノート: set_consumer_group_mappingおよびset_consumer_group_mapping_priは、Autonomous AI Databaseに付属する事前定義済コンシューマ・グループ(TPURGENT、TP、HIGH、MEDIUMおよびLOW)では使用できません。

セッションは、DBMS_RESOURCE_MANAGER定数にリストされている属性のいずれかによってコンシューマ・グループにマップできます。これらのマッピングは、SET_CONSUMER_GROUP_MAPPING_PRIで設定された優先順位で評価されます。この例では、次のユーザーによってコンシューマ・グループをマップします。

  • APP_USERからOLTP_HIGH

  • LH_USERからLH_BATCH

BEGIN
  -- Map schema APP_USER to OLTP_HIGH
  CS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    attribute  => 'ORACLE_USER',
    value      => 'APP_USER',
    consumer_group => 'OLTP_HIGH');

  CS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    attribute  => 'ORACLE_USER',
    value      => 'LH_USER',
    consumer_group => 'LH_BATCH');
END;
/

validate_pending_areaを使用して変更を確認し、submit_pending_areaを使用してプラン・ディレクティブを有効にします。

BEGIN
  CS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;
  CS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;
END;
/

構文リファレンスについては、SET_CONSUMER_GROUP_MAPPINGプロシージャ、SET_CONSUMER_GROUP_MAPPING_PRIプロシージャ、VALIDATE_PENDING_AREAプロシージャおよびSUBMIT_PENDING_AREAプロシージャを参照してください。

ステップ5: 計画の有効化

最後に、次に示すようにALTER文を実行して、カスタマイズされたDBRM計画を有効にできます。

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

オプション・ステップ

不要になった場合は、次の文を使用して、プランを無効にし、プラン・ディレクティブ、プランおよびコンシューマ・グループを削除できます。

  • デフォルト・プランに戻すには: 
    ALTER SYSTEM SET resource_manager_plan= DWCS_PLAN; -- To revert to the default plan for the Autonomous AI Lakehouse workload type.
ALTER SYSTEM SET resource_manager_plan= OLTP_PLAN; -- To revert to the default plan for other Autonomous AI Database workload types.

  • プラン・ディレクティブを削除するには:

    CS_RESOURCE_MANAGER.DELETE_PLAN_DIRECTIVE (
   plan            => <plan_name>,
   consumer_group  => <consumer_group_name>);

  • 計画を削除するには:

    CS_RESOURCE_MANAGER.DELETE_PLAN (
  plan    ==> <plan_name>);

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

    CS_RESOURCE_MANAGER.DELETE_CONSUMER_GROUP (
   consumer_group ==> <consumer_group_name>);

ノート

ノート: Autonomous AI Databaseに付属する事前定義済コンシューマ・グループ(TPURGENT、TP、HIGH、MEDIUMおよびLOW)は削除できません。

構文参照については、DELETE_CONSUMER_GROUPプロシージャ、DELETE_PLANプロシージャおよびDELETE_PLAN_DIRECTIVEプロシージャを参照してください。

カスタム計画を使用したSQL並列動作

カスタムDBRMプランを使用し、LOW、TPまたはTPURGENTサービスを使用してデータベースに接続すると、それらのセッションは手動の並列度を取得し、プランのディレクティブを使用してそれらのセッションの並列度を制限できます。HIGHおよびMEDIUMサービスを使用して接続すると、それらのセッションは自動的に並列化され、計画内のディレクティブを使用してそれらのセッションの並列度を制限できます。