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

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アプリケーションとレイクハウス・アプリケーションの両方を備えた混合ワークロード環境にAutonomous Databaseを使用することを決定した組織を考えてみます。アプリケーションのリソース要件およびワークロードの特性に基づいて、データベース管理者は、Autonomous 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 Databaseに接続します。ADMINユーザーとして、このパッケージに対する権限を必要に応じて他のユーザーに付与することもできます。

カスタム・コンシューマ・グループは、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プロシージャを参照してください。

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プロシージャを参照してください。

カスタム・コンシューマ・グループに対して、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プロシージャを参照してください。

セッションのログイン属性およびランタイム属性に基づいて、セッションをカスタム・コンシューマ・グループにマップできます。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サブプログラムを使用して、ユーザー名やアプリケーション名などの属性に基づいてセッションまたはアプリケーションをコンシューマ・グループに割り当てます。

セッションは、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プロシージャを参照してください。

最後に、次に示すように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>);

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

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