Configure resource isolation within a tenant

This topic describes how to configure resource isolation in Oracle-compatible mode.

Configure resource isolation for CPU, IOPS, and other resources

Prerequisites

• Before you configure resource isolation, it is recommended that you understand basic concepts such as resource groups, resource management plans, and their contents. For more information about basic concepts and application scenarios of resource isolation, see Resource isolation overview.

• CPU resource isolation depends on cgroup. If you need to control CPU resource isolation, you must configure the cgroup directory and enable the cgroup feature before you configure resource isolation. For more information about how to configure the cgroup directory and enable the cgroup feature, see Configure cgroup.

  When configuring user-level or function-level resource isolation, if you do not need to control CPU resource isolation (only IOPS resource isolation), you do not need to configure cgroup. When configuring SQL-level resource isolation, you must configure cgroup regardless of whether you need to control CPU resource isolation.

• Before performing IOPS resource isolation, you can perform disk performance calibration. For more information about how to perform disk performance calibration, see Disk performance calibration.

  Note

  In the current version, IOPS resource isolation is no longer heavily dependent on disk performance calibration.

• Make sure that you have created the user for whom you want to configure resource isolation. For more information about how to create a user, see Create a user.

• If you need to configure SQL-level resource isolation, make sure that you have created the database, table, and column for which you want to configure resource isolation.

Background information

Resource isolation is divided into three types: user-level resource isolation, SQL-level resource isolation, and function-level resource isolation. For more information about these three types of resource isolation, see Resource isolation overview.

Step 1 (Optional): Configure the tenant's MAX_IOPS and MIN_IOPS to valid values

After disk calibration, before configuring a resource isolation plan, you must ensure that the MAX_IOPS and MIN_IOPS values in the tenant's unit specification are valid. Valid values refer to the IOPS values corresponding to 16 KB reads, which serve as reference values for the tenant's IOPS configuration.

1. Log in to the sys tenant of the cluster as the root user.

2. Run the following command to view the unit specification of the tenant for which you want to configure resource isolation.

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

   An example of the query result is as follows:

   +----------------+-----------------+----------------------------+----------------------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   | 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
   

   Based on the query result, if the tenant's MAX_IOPS and MIN_IOPS are both the default value INT64_MAX (9223372036854775807), you need to re-plan the IOPS resources available to the tenant.

3. Run the following command to confirm on which OBServer nodes the tenant is deployed.

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

   An example of the query result is as follows:

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

4. Run the following command to obtain the disk calibration values on the OBServer node where the tenant to be isolated resides. Use the disk calibration value for 16 KB reads as the upper limit for setting the IOPS for that node.

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

   An example of the query result is as follows:

   +----------------+----------+--------------+------+-------+-------+------+---------+
   | 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
   

   Based on the query results, use the obtained disk calibration values for each node as the upper limits to plan the IOPS available to tenants. Since multiple tenants may be deployed on the same OBServer node within a cluster, you can allocate these IOPS according to your actual business needs.

   Suppose there are two tenants in a cluster, both deployed on the same OBServer node. The disk IOPS baseline for 16 KB reads on each OBServer node is the same, at 20,000 IOPS. Also, assume the load for both tenants is roughly equal. Then, you can divide the 20,000 IOPS equally between the two tenants (you can adjust the IOPS allocated to each tenant based on your actual business situation). That is, configure both tenants' MAX_IOPS and MIN_IOPS to 10,000. Alternatively, based on your business considerations, you can set MIN_IOPS to a value less than MAX_IOPS.

5. Run the following command to modify the tenant's MAX_IOPS and MIN_IOPS values.

   It is recommended to modify MIN_IOPS first, then MAX_IOPS.

   ALTER RESOURCE UNIT unit_name MIN_IOPS = xxx;
   

   ALTER RESOURCE UNIT unit_name MAX_IOPS = xxx;
   

Step 2: Configure a resource isolation plan

Assume there are already two users, tp_user and ap_user, in the current tenant.

You can follow these steps to configure a resource isolation plan to control different users or background tasks from using different CPU or IOPS resources.

1. Log in to the Oracle-compatible tenant of the cluster as a tenant administrator.

2. Call the CREATE_CONSUMER_GROUP subprogram in the DBMS_RESOURCE_MANAGER system package to create the two resource groups required for resource isolation.

   The statement is as follows:

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

   The related parameters are described as follows:

   • CONSUMER_GROUP: Defines the name of the resource group.

   • COMMENT: Enters remarks for the resource group.

   For example, create the following two resource groups named big_group and 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; //
   

   After successful creation, you can query the DBA_RSRC_CONSUMER_GROUPS view to confirm. For detailed information about the DBA_RSRC_CONSUMER_GROUPS view, see DBA_RSRC_CONSUMER_GROUPS.

3. Call the CREATE_PLAN subprogram in the DBMS_RESOURCE_MANAGER system package to create a resource management plan.

   The statement is as follows:

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

   The related parameters are described as follows:

   • PLAN: Defines the name of the resource management plan.

   • COMMENT: Enters remarks for the resource management plan.

   For example, create a resource management plan named plan_a.

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

   After successful creation, you can query the DBA_RSRC_PLANS view to confirm. For detailed information about the DBA_RSRC_PLANS view, see DBA_RSRC_PLANS.

4. Call the CREATE_PLAN_DIRECTIVE subprogram in the DBMS_RESOURCE_MANAGER system package to create the content for the resource management plan corresponding to the resource management plan created in step 3. This content is used to limit the CPU and IOPS resources used by the resource groups when the resource management plan is enabled.

   The statement is as follows:

   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,
   MAX_NET_BANDWIDTH => int_value,
   NET_BANDWIDTH_WEIGHT => int_value);
   END;
   

   The related parameters are described as follows:

   • PLAN: Specifies the name of the resource management plan associated with the content of this resource management plan.

   • GROUP_OR_SUBPLAN: Specifies the resource group.

   • COMMENT: Enters remarks for the resource management plan content. The default value is NULL.

   • MGMT_P1: Specifies the maximum relative CPU usage under full system load. The default value is 100.

   • UTILIZATION_LIMIT: Specifies the upper limit of CPU resources that a resource group can use. The default value of this parameter is 100, and its value range is (0, 100]. 100 indicates that the tenant can use all CPU resources. If the value is 40, it means the tenant can use up to 40% of the CPU resources.

   • MIN_IOPS: Reserves IOPS resources for the resource group in case of I/O contention, with a total not exceeding 100. The default value is 0.

   • MAX_IOPS: Specifies the maximum IOPS resources that a resource group can use, with a total exceeding 100. The default value is 100.

   • WEIGHT_IOPS: Specifies the weight value for IOPS, with a total exceeding 100. The default value is 0.

   • MAX_NET_BANDWIDTH: Specifies the maximum network bandwidth resources that can be used, with a total exceeding 100. The default value is 100.

   • NET_bandWIDTH_WEIGHT: Specifies the weight value for network bandwidth, with a total exceeding 100 and allocated proportionally. The default value is 0.

   Examples:

   • Specify the resource plan as plan_a, bind it to the resource group big_group, and set the upper limit of usable CPU resources to 60% of the tenant's total CPU resources. Also, specify the minimum available IOPS resources to 20% in case of I/O contention, the upper limit of usable IOPS resources to 100% of the total IOPS resources, the IOPS resource weight to 20, the usable network bandwidth resources to 50%, and the network bandwidth weight to 50.

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

   • Specify the resource plan as plan_a, bind it to the resource group small_group, and set the upper limit of usable CPU resources to 40% of the tenant's total CPU resources. Also, specify the minimum available IOPS resources to 10% in case of I/O contention, the upper limit of usable IOPS resources to 90% of the total IOPS resources, the IOPS resource weight to 30, the usable network bandwidth resources to 60%, and the network bandwidth weight to 60.

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

   After successful creation, you can query the DBA_RSRC_PLAN_DIRECTIVES view and the DBA_OB_RSRC_IO_DIRECTIVES view to confirm it.

   For more information about the DBA_RSRC_PLAN_DIRECTIVES view, see DBA_RSRC_PLAN_DIRECTIVES.

   For more information about the DBA_OB_RSRC_IO_DIRECTIVES view, see DBA_OB_RSRC_IO_DIRECTIVES.

5. Call the SET_CONSUMER_GROUP_MAPPING subprogram in the DBMS_RESOURCE_MANAGER system package to create resource isolation matching rules based on your actual usage scenario.

   The statement is as follows:

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

   The relevant parameters are described as follows:

   • ATTRIBUTE: Specifies the attribute type. The attribute name is case-insensitive.

     • column: Indicates SQL-level resource isolation.

     • user: Indicates user-level resource isolation.

     • function: Indicates function-level resource isolation.

   • VALUE: Specifies the attribute value.

     • If the attribute type is column, you need to specify information such as the database name, table name, column name, constant value, and username.

       Among these:

       • The database name and username are optional. The default database name is the current database name (with the same name as the username). If the username is not specified, it applies to all users, including those created subsequently in the current tenant.

       • The table name, column name, and constant value are required, and only one value can be specified for each. When specifying a constant value, only numeric or string values are supported.

       • When specifying a table name, column name, or username, the specified table, column, and user must exist.

       In OceanBase Database's Oracle-compatible mode, after the statement is executed successfully, the database name, table name, column name, and username will automatically be adjusted to uppercase. If you need to keep them lowercase, you can add double quotes to prevent this. Example:

       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; //
       

     • If the attribute type is user, you only need to specify the username here. Currently, only one user can be specified.

     • If the attribute type is function, specify one of the following background tasks corresponding to the DAG thread: compaction_high, ha_high, compaction_mid, ha_mid, compaction_low, ha_low, ddl, ddl_high, clog_high, and opt_stats. Only one task can be specified at a time. For detailed descriptions of each task, see Resource isolation overview.

   • CONSUMER_GROUP: Specifies the resource group to which the statement needs to be bound. This means that when an SQL statement matches the rule set in VALUE, it will be executed on the specified resource group. Currently, only binding to one resource group is supported.

     If no resource group is specified, the system's built-in OTHER_GROUPS will be used by default. The resources corresponding to the system's built-in OTHER_GROUPS are as follows:

     • MIN_IOPS = 100 - SUM(the total of other resource groups within the tenant)

     • MAX_IOPS = 100

     • WEIGHT_IOPS = 100

   Example:

   • Create an SQL-level resource isolation matching rule.

     • Specify that when a user tp_user executes an SQL statement containing the WHERE condition sys.t.c3 = 3, this SQL statement will be bound to a resource group named big_group for execution, and will use the CPU and IOPS resources constrained by that resource group.

       Note

       When executing an SQL statement, the statement itself does not necessarily need to contain sys.t.. As long as c3 is ultimately resolved to sys.t.c3, the SQL statement will be bound to the resource group named big_group for execution. For example: 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; //
       

     • Specifies that when executing an SQL statement containing the condition t.c3=5, it will be bound to the resource group named small_group and executed using the CPU and IOPS resources constrained by that resource group.

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

     In addition to binding resource groups by calling the SET_CONSUMER_GROUP_MAPPING subprogram, OceanBase Database also supports binding resource groups using hints. Users can flexibly submit SQL statements to a specified resource group by using hints. For example, if the SQL statement to be executed is SELECT * FROM T and you want this statement to use the resources constrained by the big_group resource group, an example of binding the corresponding resource group using hints is as follows:

     obclient [SYS]> SELECT /*+resource_group('big_group')*/ * FROM T;
     

     Note

     If the specified resource group does not exist when using hints, the statement will execute using the default resource group OTHER_GROUPS.

   • Creates a user-level resource isolation matching rule.

     • Specifies that SQL statements executed by the tp_user account are bound to the resource group named big_group and executed using the CPU and IOPS resources constrained by that resource group.

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

     • Specifies that SQL statements executed by the ap_user account are bound to the resource group named small_group and executed using the CPU and IOPS resources constrained by that resource group.

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

   • Creates a function-level resource isolation matching rule.

     • Specifies that when executing tasks of the ha_high priority, the system will bind to the resource group named big_group and execute using the CPU and IOPS resources constrained by that resource group.

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

     • Specifies that when executing tasks of the ddl_high priority, the system will bind to the resource group named small_group and execute using the CPU and IOPS resources constrained by that resource group.

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

   After successful creation, you can query the DBA_RSRC_GROUP_MAPPINGS view to confirm it. For detailed information about the DBA_RSRC_GROUP_MAPPINGS view, see DBA_RSRC_GROUP_MAPPINGS.

6. Enable an appropriate resource management plan for the resource group.

   Since different resource management plans may impose different constraints on the same resource group, you need to enable an appropriate resource management plan for the resource group.

   obclient [SYS]>delimiter ;
   

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

   Note

   If resource constraints are not required, you can disable all resource plans using the statement ALTER SYSTEM SET resource_manager_plan = '';.

Considerations after configuration

• After adding a resource isolation matching rule, if a user is deleted and then recreated, the resource isolation matching rule still applies.

• Resource isolation matching rules do not take effect immediately after being added. They are expected to start taking effect within 10 seconds, subject to the actual environment.

• In the same tenant, if isolation policies of multiple levels are configured simultaneously, their priorities are as follows:

  SQL-level resource isolation > User-level resource isolation > Function-level resource isolation

• After adding a resource isolation matching rule, it currently only takes effect on statements such as SELECT, INSERT, UPDATE, and DELETE. It does not take effect on DDL and DCL statements, nor on PL statements. However, it takes effect in prepared statements.

Performance impact after configuration

• User-level resource isolation and function-level resource isolation can determine which resource group's resources to use before SQL parsing is complete, so they have no impact on performance.

• The performance impact of SQL-level resource isolation mainly comes from retries. Unlike user-level and function-level resource isolation, which determine which resource group's resources to use before an SQL statement is parsed, SQL-level resource isolation determines which resource group's resources to use during SQL parsing or when the plan cache is hit. If it is found that the resource group to be used is different from the one currently in use, the system will perform a retry and use the resource group corresponding to the matching rule to process the SQL.

  The performance impact of SQL-level resource isolation is mainly divided into the following three scenarios:

  1. When an SQL statement does not match any rule, there is almost no impact on performance.

  2. When an SQL statement matches a rule, assume the resource group specified by that rule is big_group. Not only will this SQL statement ultimately be executed using the resources of big_group, but the next SQL statement will also first use the resources of big_group until a rule is matched that indicates a switch to another resource group, at which point the system will retry. For scenarios where a batch of SQL statements are executed consecutively and all are bound to the same resource group, using this strategy ensures that only the first SQL statement in the batch needs to be retried, while subsequent SQL statements do not need to be retried. This minimizes retries and has a minor impact on performance.

  3. When the expected resource group for each SQL statement is different from the previous one, each SQL statement needs to be retried once, which has a significant impact on performance.

(Optional) Configure resource isolation for DDL worker threads

In the current version, DDL and DML requests compete for front-end worker threads. When a large number of DDL requests arrive in a short period, it can severely impact normal user requests. To minimize performance and stability issues caused by thread resource contention, OceanBase Database has separated DDL worker thread resources from DML worker thread resources. You can choose whether to enable resource isolation for DDL worker threads based on your actual business situation.

OceanBase Database uses the tenant-level hidden parameter _enable_ddl_worker_isolation to control the switch for DDL thread resource isolation. The possible values and meanings of this parameter are as follows:

• False: Indicates that resource isolation for DDL worker threads is disabled. In this scenario, DDL and DML requests share worker threads and can affect each other.

• True: Indicates that resource isolation for DDL worker threads is enabled. In this scenario, DDL requests use dedicated worker threads, and the number of concurrent DDL requests allowed per tenant is also limited to avoid excessive impact on DML requests.

To enable resource isolation for DDL worker threads, perform the following steps:

1. Log in to the Oracle-compatible tenant of the cluster as the SYS user.

   A sample connection string is as follows:

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

2. Check the value of the current parameter _enable_ddl_worker_isolation.

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

   A sample query result is as follows:

   +----------------+----------+-------+--------+-----------+------------------------------+-----------+-------+------------------------------------------+--------------+-------------------+---------------+-----------+
   | 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. Modify the value of the parameter _enable_ddl_worker_isolation.

   obclient(SYS@oracle001)[SYS]> ALTER SYSTEM SET "_enable_ddl_worker_isolation" = True;
   

References

• Resource isolation overview

• Calibrate disk performance

• Resource isolation case of background tasks