テナント内のリソース分離の設定

本記事では、Oracleモードにおけるリソース分離の設定方法について説明します。

CPUやIOPSなどのリソースのリソース分離の設定

前提条件

• リソース分離の設定を開始する前に、リソースグループ、リソース管理計画、リソース管理計画の内容などの基本的な概念について理解しておくことを推奨します。また、リソース分離に関連する基本概念と適用シナリオについては、リソース分離の概要を参照してください。

• CPUのリソース分離はcgroupに依存しているため、CPUのリソース分離を制御する必要がある場合は、リソース分離の設定を開始する前に、cgroupディレクトリを設定し、cgroup機能を有効にする必要があります。cgroupディレクトリの設定とcgroup機能の有効化に関する操作手順については、cgroupの設定を参照してください。

  ユーザーレベルのリソース分離とファンクションレベルのリソース分離を設定する際、CPUのリソース分離を制御する必要がない場合（IOPSリソース分離のみが必要な場合）、cgroupの設定は不要です。SQLレベルのリソース分離を設定する際は、CPUのリソース分離を制御する必要が有無にかかわらず、cgroupの設定が必要です。

• IOPSリソース分離を行う前に、ディスク性能のキャリブレーションを行う必要があります。ディスク性能キャリブレーションに関する操作手順については、ディスク性能キャリブレーションを参照してください。

  CPUのリソース分離のみを制御する必要がある場合は、ディスク性能のキャリブレーションは不要です。

• リソース分離を行うユーザーがすでに作成されていることを確認してください。ユーザーの作成に関する詳細な操作手順については、ユーザーの作成を参照してください。

• SQLレベルのリソース分離を設定する必要がある場合は、リソース分離を行うデータベース、テーブル、および列がすでに作成されていることを確認してください。

背景

リソース分離には、Userレベルのリソース分離、SQLレベルのリソース分離、Functionレベルのリソース分離の3種類があります。3つのリソース分離についてのより詳細な説明については、リソース分離の概要を参照してください。

注意事項

DBMS_RESOURCE_MANAGERシステムパッケージを使用してテナント内のFunctionレベルのリソース分離を設定する場合、グローバルCPUリソースのフロントエンド/バックエンド分離機能が有効になっている場合、テナント内の各バックグラウンドタスクのCPU使用上限は、テナント内のすべてのバックグラウンドタスクが利用できる総CPU使用上限に基づいて計算されます。つまり、テナント内の各バックグラウンドタスクのCPU使用上限は実際にはmin(global_background_cpu_quota, テナントのMAX_CPU) * リソースグループ内のUTILIZATION_LIMITとなります。

ステップ１（オプション）：テナントのMAX_IOPSとMIN_IOPSを有効な値に設定する

ディスクカリブレーションが完了した後、リソース分離スケジュールを設定する前に、テナントのリソース仕様における MAX_IOPS と MIN_IOPS の値が有効な値であることを確認する必要があります。ここでいう有効な値とは、16KB読み取り対応のIOPS値をテナントのIOPS設定の参考値として使用することを指します。

1. root ユーザーを使用してクラスタの sys テナントにログインします。

2. 以下のコマンドを実行して、リソース分離を行うテナントのリソース仕様を確認します。

   obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_UNIT_CONFIGS;
   

   クエリ結果の例は次のとおりです：

   +----------------+-----------------+----------------------------+----------------------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   | UNIT_CONFIG_ID | NAME            | CREATE_TIME                | MODIFY_TIME                | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS            | MIN_IOPS            | IOPS_WEIGHT |
   +----------------+-----------------+----------------------------+----------------------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   |              1 | sys_unit_config | 2023-12-19 13:55:04.463295 | 2023-12-19 13:56:08.969718 |       3 |       3 |  2147483648 |    3221225472 | 9223372036854775807 | 9223372036854775807 |           3 |
   |           1001 | small_unit      | 2023-12-19 13:56:09.851665 | 2023-12-19 13:56:09.851665 |       1 |       1 |  2147483648 |    6442450944 | 9223372036854775807 | 9223372036854775807 |           1 |
   |           1002 | medium_unit     | 2023-12-19 13:56:10.030914 | 2023-12-19 13:56:10.030914 |       8 |       4 |  8589934592 |   25769803776 | 9223372036854775807 | 9223372036854775807 |           4 |
   |           1003 | large_unit      | 2023-12-19 13:56:10.112115 | 2023-12-19 13:56:10.112115 |      16 |       8 | 21474836480 |   64424509440 | 9223372036854775807 | 9223372036854775807 |           8 |
   +----------------+-----------------+----------------------------+----------------------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   4 rows in set
   

   クエリ結果に基づいて、テナントの MAX_IOPS と MIN_IOPS がデフォルト値 INT64_MAX (9223372036854775807) である場合、テナントが使用できるIOPSリソースを再計画する必要があります。

3. 以下のコマンドを実行して、テナントがデプロイされているOBServerノードを確認します。

   obclient [oceanbase]> SELECT DISTINCT SVR_IP, SVR_PORT FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE tenant_id = xxxx;
   

   クエリ結果の例は次のとおりです：

   +----------------+----------+
   | SVR_IP         | SVR_PORT |
   +----------------+----------+
   | xx.xxx.xxx.xx1 |    xxxx1 |
   | xx.xxx.xxx.xx1 |    xxxx2 |
   | xx.xxx.xxx.xx1 |    xxxx3 |
   +----------------+----------+
   3 rows in set
   

4. 以下のコマンドを実行して、リソース分離を行うテナントが配置されているOBServerノードのディスクカリブレーション値を確認します。16KB読み取りのディスクカリブレーション値をそのノードのIOPS設定の上限値として使用します。

   obclient [oceanbase]> SELECT * FROM oceanbase.GV$OB_IO_BENCHMARK WHERE MODE='READ' AND SIZE=16384;
   

   クエリ結果の例は次のとおりです：

   +----------------+----------+--------------+------+-------+-------+------+---------+
   | SVR_IP         | SVR_PORT | STORAGE_NAME | MODE | SIZE  | IOPS  | MBPS | LATENCY |
   +----------------+----------+--------------+------+-------+-------+------+---------+
   | xx.xxx.xxx.xx1 |    xxxx1 | DATA         | READ | 16384 | 48162 |  752 |     331 |
   | xx.xxx.xxx.xx1 |    xxxx2 | DATA         | READ | 16384 | 47485 |  741 |     336 |
   | xx.xxx.xxx.xx1 |    xxxx3 | DATA         | READ | 16384 | 48235 |  753 |     331 |
   +----------------+----------+--------------+------+-------+-------+------+---------+
   3 rows in set
   

   クエリ結果に基づいて、取得した各ノードのディスクカリブレーション値を上限値として、テナントが使用可能なIOPSを計画します。クラスタ内には同じOBServerノードに複数のテナントがデプロイされている可能性があるため、ビジネス上の状況に応じてこれらのIOPSを割り当てることが必要です。

   例えば、あるクラスタには2つのテナントがあり、両方のテナントが同じOBServerノードにデプロイされており、各OBServerノードの16KB読み取りのディスクIOPS基準値が同じ20000 IOPSであり、両テナントの負荷がほぼ同じと予想される場合、20000 IOPSを2つのテナントに均等に割り当てることができます（具体的には、ビジネス上の状況に応じてテナントごとに使用可能なIOPSを割り当てる）。つまり、各テナントの MAX_IOPS と MIN_IOPS をどちらも10000に設定することができます。また、ビジネス上の要件により、MIN_IOPS を MAX_IOPS よりも小さい値に設定することも可能です。

5. 以下のコマンドを実行して、テナントの MAX_IOPS と MIN_IOPS の値を変更します。

   MIN_IOPS を変更した後に MAX_IOPS を変更することを推奨します。

   ALTER RESOURCE UNIT unit_name MIN_IOPS = xxx;
   

   ALTER RESOURCE UNIT unit_name MAX_IOPS = xxx;
   

ステップ2：リソース分離計画を設定する

現在のテナントにはすでに tp_user および ap_user のような2つのユーザーが存在していると仮定します。

異なるユーザーまたはバックグラウンドタスクが異なるCPUまたはIOPSリソースを使用するように制御するために、以下の手順に従ってリソース分離計画を設定できます。

1. テナント管理者は、クラスタのOracleテナントにログインします。

2. DBMS_RESOURCE_MANAGER システムパッケージ内の CREATE_CONSUMER_GROUP サブルーチンを呼び出して、リソース分離に必要な2つのリソースグループを作成します。

   ステートメントは次のとおりです：

   BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
   consumer_group => 'group_name' ,
   COMMENT => 'coments'
   );
   END;
   

   関連パラメータの説明は以下のとおりです：

   • CONSUMER_GROUP：リソースグループ名を定義します。

   • COMMENT：リソースグループのコメント情報を入力します。

   例えば、以下の2つのリソースグループを作成します。それぞれ big_group と small_group です。

   obclient [SYS]> delimiter //
   

   obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
   consumer_group => 'big_group' ,
   COMMENT => 'TP'
   );
   END; //
   

   obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
   consumer_group => 'small_group' ,
   COMMENT => 'AP'
   );
   END; //
   

   作成が成功した後、DBA_RSRC_CONSUMER_GROUPS ビューを照会して確認できます。DBA_RSRC_CONSUMER_GROUPS ビューの詳細については、DBA_RSRC_CONSUMER_GROUPSを参照してください。

3. DBMS_RESOURCE_MANAGER システムパッケージ内の CREATE_PLAN サブルーチンを呼び出して、リソース管理計画を作成します。

   ステートメントは次のとおりです：

   BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN => 'plan_name',
   COMMENT =>'coments'
   );
   END;
   

   関連パラメータの説明は以下のとおりです：

   • PLAN：リソース管理計画名を定義します。

   • COMMENT：リソース管理計画のコメント情報を入力します。

   例えば、plan_a という名前のリソース管理計画を作成します。

   obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN => 'plan_a');
   END; //
   

   作成が成功した後、DBA_RSRC_PLANS ビューを照会して確認できます。DBA_RSRC_PLANS ビューの詳細については、DBA_RSRC_PLANSを参照してください。

4. DBMS_RESOURCE_MANAGER システムパッケージ内の CREATE_PLAN_DIRECTIVE サブルーチンを呼び出して、リソース管理計画に対応するリソース管理計画の内容を作成します。これにより、リソース管理計画を有効にする際に、リソースグループが使用できるCPUリソースとIOPSリソースを制限します。

   ステートメントは次のとおりです：

   BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
   PLAN => 'plan_name',
   GROUP_OR_SUBPLAN => 'group_name',
   COMMENT  => 'comments',
   MGMT_P1 => int_value,
   UTILIZATION_LIMIT => int_value,
   MIN_IOPS => int_value,
   MAX_IOPS => int_value,
   WEIGHT_IOPS => int_value);
   END;
   

   関連パラメータの説明は以下のとおりです：

   • PLAN：このリソース管理計画内容に関連付けられたリソース管理計画名を指定します。

   • GROUP_OR_SUBPLAN：リソースグループを指定します。

   • COMMENT：リソース管理計画内容のコメント情報を入力します。デフォルト値は NULL です。

   • MGMT_P1：システムが満杯な場合、利用可能な最大CPU割合を指定します。デフォルト値は 100 です。

   • UTILIZATION_LIMIT：リソースグループが使用できるCPUリソースの上限を指定します。このパラメータのデフォルト値は 100 で、範囲は (0, 100] です。100 は、テナントが使用できる最大CPUリソースを表します。値が 40 の場合、テナントが使用できる最大CPUリソースは40%となります。

   • MIN_IOPS：I/O競合発生時にリソースグループが確保するIOPSリソース。合計は100を超えることはできません。デフォルト値は 0 です。

   • MAX_IOPS：リソースグループが使用できる最大IOPSリソースを指定します。合計は100を超えることができます。デフォルト値は 100 です。

   • WEIGHT_IOPS：IOPSの重み値を指定します。合計は100を超えることができます。デフォルト値は 0 です。

   例：

   • リソースプランを plan_a と指定し、リソースグループ big_group にバインドし、使用可能なCPUリソースの上限をテナントのCPU総リソースの60%と指定します。同時に、I/O競合が発生した場合、使用可能な最小IOPSリソースを20%、使用可能なIOPSリソースの上限をIOPS総リソースの100%、IOPSリソースの重みを20と指定します。

     obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
     PLAN => 'plan_a',
     GROUP_OR_SUBPLAN => 'big_group',
     COMMENT  => 'TP優先',
     UTILIZATION_LIMIT =>60,
     MIN_IOPS => 20,
     MAX_IOPS => 100,
     WEIGHT_IOPS => 20);
     END; //
     

   • リソースプランを plan_a と指定し、リソースグループ small_group にバインドし、使用可能なCPUリソースの上限をテナントのCPU総リソースの40%と指定します。同時に、I/O競合が発生した場合、使用可能な最小IOPSリソースを10%、使用可能なIOPSリソースの上限をIOPS総リソースの90%、IOPSリソースの重みを30と指定します。

     obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
     PLAN => 'plan_a',
     GROUP_OR_SUBPLAN => 'small_group' ,
     COMMENT  => 'AP優先',
     UTILIZATION_LIMIT =>40,
     MIN_IOPS => 10,
     MAX_IOPS => 90,
     WEIGHT_IOPS => 30);
     END; //
     

   作成が成功した後、DBA_RSRC_PLAN_DIRECTIVES ビューと DBA_OB_RSRC_IO_DIRECTIVES ビューを照会して確認できます。

   DBA_RSRC_PLAN_DIRECTIVES ビューの詳細については、DBA_RSRC_PLAN_DIRECTIVESを参照してください。

   DBA_OB_RSRC_IO_DIRECTIVES ビューの詳細については、DBA_OB_RSRC_IO_DIRECTIVESを参照してください。

5. DBMS_RESOURCE_MANAGER システムパッケージ内の SET_CONSUMER_GROUP_MAPPING サブルーチンを呼び出して、実際の使用シナリオに基づいてリソース分離マッチングルールを作成します。

   ステートメントは次のとおりです：

   BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
      ATTRIBUTE => 'column | user | function',
      VALUE => 'values',
      CONSUMER_GROUP => 'group_name');
      END;
   

   関連パラメータの説明は以下のとおりです：

   • ATTRIBUTE：プロパティタイプを指定します。プロパティ名は大文字と小文字を区別しません。

     • column はSQLレベルのリソース分離を表します。

     • user はUserレベルのリソース分離を表します。

     • function はFunctionレベルのリソース分離を表します。

   • VALUE：プロパティ値を指定します。

     • プロパティタイプが column の場合、ここではデータベース名、テーブル名、列名、定数値、およびユーザー名などの情報が必要です。

       其中：

       • データベース名とユーザー名はオプションです。デフォルトのデータベース名は現在のデータベース名（ユーザー名と同じ）であり、ユーザー名が指定されていない場合、現在のテナントで後から作成されるすべてのユーザーにも適用されます。

       • テーブル名、列名、定数値は必須項目であり、各項目には1つの値のみを指定できます。定数値を指定する場合、数値または文字列のみを指定できます。

       • テーブル名、列名、ユーザー名を指定する場合、指定されたテーブル、列、ユーザーは存在する必要があります。

       OceanBaseデータベースのOracleモードにおいて、ステートメントが実行されると、データベース名、テーブル名、列名、ユーザー名はすべて大文字に自動的に変換されます。小文字を維持したい場合は、ダブルクォートを追加することで大文字に変換されることを防ぐことができます。例：

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE        =>  'column',
       VALUE            => '"test"."t1"."c3" = 3 for "user_big"',
       CONSUMER_GROUP   => 'big_group');
       END; //
       

     • プロパティタイプが user の場合、ここではユーザー名を指定します。現在は1つのユーザーのみを指定できます。

     • プロパティタイプが function の場合、ここではDAGスレッドに対応するバックグラウンドタスクであるcompaction_high、ha_high、compaction_mid、ha_mid、compaction_low、ha_low、ddl、ddl_high、clog_highおよびopt_statsのいずれかを指定します。1つのタスクのみを指定できます。各タスクの詳細については、リソース分離の概要を参照してください。

   • CONSUMER_GROUP：バインドする必要があるリソースグループを指定します。これは、SQLが VALUE で設定されたマッチングルールにヒットすると、どのリソースグループにバインドしてそのステートメントを実行するかを示します。現在は1つのリソースグループのみをバインドできます。

     バインドする必要があるリソースグループが指定されていない場合、デフォルトでシステムが組み込みの OTHER_GROUPS にバインドされます。システムが組み込みの OTHER_GROUPS に対応するリソースは以下のとおりです：

     • MIN_IOPS = 100 - SUM(テナント内の他のリソースグループの合計)

     • MAX_IOPS = 100

     • WEIGHT_IOPS = 100

   例：

   • SQLレベルのリソース分離マッチングルールを作成します。

     • ユーザー tp_user が実行するSQL文の WHERE 条件に sys.t.c3 = 3 が含まれる場合、そのSQL文は big_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       注意

       SQL文を実行する際には、文に必ず sys.t. が含まれる必要はありません。ただ c3 が最終的に sys.t.c3 として解釈されるだけで、そのSQL文は `big_group` という名前のリソースグループにバインドされます。例：SELECT * FROM sys.t WHERE c3 = 1;。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'column',
       VALUE => 'sys.t.c3=3 for tp_user',
       CONSUMER_GROUP => 'big_group');
       END; //
       

     • 実行するSQL文の WHERE 条件に t.c3=5 が含まれる場合、そのSQL文は small_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'column',
       VALUE => 't.c3=5',
       CONSUMER_GROUP => 'small_group');
       END; //
       

   • Userレベルのリソース分離マッチングルールを作成します。

     • tp_user ユーザーが実行するSQL文は big_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'user',
       VALUE => 'tp_user',
       CONSUMER_GROUP => 'big_group');
       END; //
       

     • ap_user ユーザーが実行するSQL文は small_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'user',
       VALUE => 'ap_user',
       CONSUMER_GROUP => 'small_group');
       END; //
       

   • Functionレベルのリソース分離マッチングルールを作成します。

     • ha_high タスクを実行する場合、システムは big_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'function',
       VALUE => 'ha_high',
       CONSUMER_GROUP => 'big_group');
       END; //
       

     • ddl_high タスクを実行する場合、システムは small_group という名前のリソースグループにバインドされ、そのリソースグループで制限されたCPUリソースとIOPSリソースを使用して実行されます。

       obclient [SYS]> BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
       ATTRIBUTE => 'function',
       VALUE => 'ddl_high',
       CONSUMER_GROUP => 'small_group');
       END; //
       

   作成が成功した後、DBA_RSRC_GROUP_MAPPINGS ビューを照会して確認できます。DBA_RSRC_GROUP_MAPPINGS ビューの詳細については、DBA_RSRC_GROUP_MAPPINGSを参照してください。

6. リソースグループに適切なリソース管理計画を有効にします。

   同じリソースグループが異なるリソース管理計画で異なるリソースに制限される可能性があるため、リソースグループに適切なリソース管理計画を有効にする必要があります。

   obclient [SYS]>delimiter ;
   

   obclient [SYS]> ALTER SYSTEM SET resource_manager_plan = 'plan_a';
   

   説明

   リソースの制限を不要な場合は、ALTER SYSTEM SET resource_manager_plan = ''; ステートメントを使用してすべてのリソース計画を無効にできます。

設定後の注意事項

• リソース分離マッチングルールを追加した後、ユーザーを削除して再作成しても、リソース分離マッチングルールは引き続き適用されます。

• リソース分離マッチングルールの追加は即時に反映されません。概ね10秒以内に反映されるものと予想されますが、実際の環境によって異なります。

• SQLレベルのリソース分離は、UserレベルおよびFunctionレベルのリソース分離よりも優先順位が高いです。

• リソース分離マッチングルールを追加した後、現在はSELECT、INSERT、UPDATE、DELETEなどのステートメントでのみ有効であり、DDLおよびDCLステートメントやPLには適用されません。prepareStatementでは有効になります。

設定後のパフォーマンスへの影響

• UserレベルおよびFunctionレベルのリソース分離は、SQLが解析される前からどのリソースグループのリソースを使用するかが確認できるため、パフォーマンスに影響しません。

• SQLレベルのリソース分離によるパフォーマンスへの影響は主にリトライから生じます。UserレベルおよびFunctionレベルのリソース分離とは異なり、SQLが解析される前からどのリソースグループのリソースを使用するかが決定されるのではなく、SQLの解析またはPlan Cacheヒット時にのみ決定されます。この時点で、使用すべきリソースグループが現在使用しているものと異なることが判明した場合、システムはリトライを実行し、マッチングルールに対応するリソースグループのリソースを使用してそのSQLを処理します。

  SQLレベルのリソース分離によるパフォーマンスへの影響は、主に以下の3つのケースに分類されます：

  1. あるSQLがどのルールにもマッチしない場合、パフォーマンスにほとんど影響はありません。

  2. あるSQLが1つのルールにマッチした場合、そのルールで指定されたリソースグループをbig_groupと仮定すると、そのSQLは最終的にbig_groupのリソースで実行され、次のSQLも最初はbig_groupのリソースで実行され、ルールにマッチして他のリソースグループに切り替えるまでリトライが行われません。連続的に一連のSQLを実行し、かつこれらのSQLがすべて同じリソースグループにバインドされているシナリオでは、この戦略により、一連のSQLのうち最初のSQLのみに対してリトライが必要であり、その後のSQLについてはリトライが不要になるため、リトライ回数を最小限に抑え、パフォーマンスへの影響は小さくなります。

  3. 各SQLが予想されるリソースグループが前のSQLと異なる場合、各SQLに対してリトライが必要となり、パフォーマンスへの影響が大きくなります。

（オプション）DDLワーカースレッドリソースのリソース分離を構成する

現在のバージョンでは、DDLリクエストとDMLリクエストが相互にフロントエンドワーカースレッドを競合し、短時間に大量のDDLリクエストが発生すると、ユーザーの通常リクエストに深刻な影響を与えます。パフォーマンスの安定性に影響を与えるスレッドリソースの競合をできるだけ減らすため、OceanBaseデータベースはDDLワーカースレッドリソースとDMLワーカースレッドリソースを分離し、ユーザーは実際のビジネス状況に応じて、DDLワーカースレッドのリソース分離を有効にするかどうかを選択できます。

OceanBaseデータベースは、テナントレベルの隠蔽構成パラメータ_enable_ddl_worker_isolationを使用して、DDLスレッドリソース分離のスイッチを制御します。この構成パラメータの値とその意味は以下のとおりです：

• False：DDLワーカースレッドのリソース分離が無効になっています。この場合、DDLリクエストとDMLリクエストなどは共通のワーカースレッドを使用し、相互に影響を与えます。

• True：DDLワーカースレッドのリソース分離が有効になっています。この場合、DDLリクエストは独立したワーカースレッドを使用し、同時にテナントで実行されるDDLリクエストの数を制限することで、DMLリクエストへの過度な影響を回避します。

DDLワーカースレッドのリソース分離を有効にする方法は以下のとおりです：

1. SYSユーザーを使用して、クラスタのOracleテナントにログインします。

   接続例：

   obclient -h172.30.xxx.xxx -P2883 -usys@oracletenant#obdemo -pxxxx -A
   

2. 現在の構成パラメータ_enable_ddl_worker_isolationの値を確認します。

   obclient [SYS]> SELECT * FROM SYS.GV$OB_PARAMETERS WHERE NAME LIKE '%_enable_ddl_worker_isolation%';
   

   クエリ結果の例：

   +----------------+----------+-------+--------+-----------+------------------------------+-----------+-------+------------------------------------------+--------------+-------------------+---------------+-----------+
   | SVR_IP         | SVR_PORT | ZONE  | SCOPE  | TENANT_ID | NAME                         | DATA_TYPE | VALUE | INFO                                     | SECTION      | EDIT_LEVEL        | DEFAULT_VALUE | ISDEFAULT |
   +----------------+----------+-------+--------+-----------+------------------------------+-----------+-------+------------------------------------------+--------------+-------------------+---------------+-----------+
   | 172.xx.xxx.xxx |     2882 | zone1 | TENANT |      1004 | _enable_ddl_worker_isolation | NULL      | False | a switch controling ddl thread isolation | ROOT_SERVICE | DYNAMIC_EFFECTIVE | False         | YES       |
   +----------------+----------+-------+--------+-----------+------------------------------+-----------+-------+------------------------------------------+--------------+-------------------+---------------+-----------+
   1 row in set
   

3. 構成パラメータ_enable_ddl_worker_isolationの値を変更します。

   obclient [SYS]> ALTER SYSTEM SET "_enable_ddl_worker_isolation" = True;
   

関連ドキュメント

• リソース分離の概要

• ディスク性能の調整

• 履歴セッションのパフォーマンス監視

• バックグラウンドタスクのリソース分離事例