Gestión de recursos de carga de trabajo con el gestor de recursos de base de datos en Autonomous AI Database

Los subprogramas cs_resource_manager permiten asociar directivas y políticas de uso de recursos específicas a cada grupo de consumidores e implantar, supervisar y revisar las políticas a medida que cambian los requisitos.

Con los subprogramas cs_resource_manager, puede:

• Cree su propio plan de gestor de recursos de base de datos (DBRM).
• Crear y suprimir grupos de consumidores personalizados.
• Definir asignaciones de grupos de consumidores, es decir, reglas y prioridades para cómo se asignan las sesiones a estos grupos de consumidores.
• Definir prioridades para asignación de grupos de consumidores.
• Defina directivas de plan para asignar los siguientes controles de recursos para cada grupo de consumidores personalizado:
  • Porcentaje de asignación de recursos para el grupo de consumidores. Los recursos compartidos determinan la cantidad de recursos de CPU y E/S que obtiene un grupo de consumidores en relación con otros grupos de consumidores. Por ejemplo, un grupo de consumidores con una cuota de 2 obtendrá el doble de recursos de CPU y E/S que un grupo de consumidores con una cuota de 1. El valor por defecto es 1.
  • Límites de recursos que determinan el máximo de recursos de CPU y E/S que puede obtener un grupo de consumidores.
  • Tiempo en la CPU (en segundos) que se puede ejecutar una sesión antes de realizar la acción determinada por el parámetro switch_action. El valor por defecto es NULL, lo que significa ilimitado.
  • Cantidad de E/S (en MB) que puede emitir una sesión antes de que se realice la acción determinada por el parámetro switch_action. El valor por defecto es NULL, lo que significa ilimitado.
  • Número de solicitudes de E/S que una sesión puede emitir antes de que se realice la acción determinada por el parámetro switch_action. El valor por defecto es NULL, lo que significa ilimitado.
  • Número de E/S lógicas que dispararán la acción especificada por switch_action.
  • Tiempo transcurrido (en segundos) que disparará la acción especificada por switch_action.
  • Número de segundos que una sesión puede estar inactiva antes de que finalice la sesión. El valor por defecto es NULL, lo que significa ilimitado.
  • Cantidad máxima de tiempo en segundos que una sesión puede estar inactiva antes de que finalice la sesión, si la sesión mantiene un bloqueo o un recurso que necesitan otras sesiones.
  • Número máximo de sesiones que pueden tener simultáneamente una llamada activa.
  • Tiempo (en segundos) tras el cual se agota el tiempo de espera de una llamada en la cola de sesiones inactiva (en espera de ejecución). El valor por defecto es NULL, lo que significa ilimitado.
  • Límite en el Grado de Paralelismo (DOP) para cualquier operación. El valor por defecto es NULL, lo que significa ilimitado. Utilice el valor 1 para que una operación sea en serie
  • Nivel de simultaneidad para sentencias paralelas. Puesto que el nivel de simultaneidad determina indirectamente el nivel de DOP, la definición de ambos valores creará un conflicto. Se recomienda definir solo la simultaneidad o el grado de paralelismo para un grupo de consumidores, no ambos.
  • Cantidad máxima de PGA no ajustable (en MB) que una sesión de este grupo de consumidores puede asignar antes de terminar. NULL (valor por defecto) indica que no hay límite. Las operaciones SQL que asignan PGA ajustable (operaciones que pueden optar por utilizar espacio temporal) no están controladas por este límite.
  • Tiempo (en segundos) que una sentencia paralela puede permanecer en la cola de sentencias paralelas de su grupo de consumidores. Debe emparejarlo con la acción que se va a realizar cuando se elimine una sentencia paralela de la cola debido al timeout. Las opciones son cancelar o ejecutar la sentencia.
  • Medidas que deben adoptarse al alcanzar cualquiera de los límites especificados en las directivas. Los valores válidos son cancel_sql, kill_session o un nombre de grupo de consumidores al que cambiar.
• Active su plan de DBRM personalizado y vuelva al valor por defecto, si es necesario.

En los siguientes temas se describe el flujo de trabajo detallado para definir grupos de consumidores personalizados, planes y asignaciones de sesiones en un caso de uso práctico de ejemplo. Este flujo de trabajo y los ejemplos de código asociados se pueden modificar e implantar según sus necesidades.

Considere una organización que haya decidido utilizar una base de datos de IA autónoma para un entorno de carga de trabajo mixta que tenga aplicaciones OLTP y Lakehouse. En función de los requisitos de recursos y las características de carga de trabajo de las aplicaciones, el administrador de la base de datos decidió que sería óptimo definir y utilizar planes de DBRM personalizados en lugar de los grupos de consumidores y planes predefinidos que incluyen Autonomous AI Database.

Terminaron con los siguientes requisitos:

1. Cree tres (3) grupos de consumidores:
   • OLTP_HIGH para manejar sesiones de procesamiento de transacciones de alta prioridad.
   • OLTP_LOW para manejar sesiones de procesamiento de transacciones en segundo plano o de baja prioridad.
   • LH_BATCH para cargas de trabajo por lotes o de informes.
2. Cree un plan denominado OLTP_LH_PLAN para dividir los recursos entre el procesamiento de transacciones y las cargas de trabajo de lakehouse.
3. Cree cuatro (4) directivas de plan para los siguientes escenarios:
   • Las sesiones de procesamiento de transacciones de alta prioridad obtienen 8 recursos compartidos de CPU y E/S y sin paralelismo.
   • Las sesiones de procesamiento de transacciones de menor prioridad obtienen 4 recursos compartidos de CPU y E/S y sin paralelismo.
   • Las transacciones por lotes y de Lakehouse obtienen 4 recursos compartidos de CPU y E/S y el grado de paralelismo está limitado a 4.
   • Todas las demás sesiones que no están asignadas a un grupo de consumidores obtienen 1 recurso compartido de CPU/E/S y ningún paralelismo.
4. Cree las siguientes asignaciones de usuario a grupo de consumidores:
   • De APP_USER a OLTP_HIGH
   • De LH_USER a LH_BATCH
5. Active el plan.

Para utilizar los subprogramas cs_resource_manager, conéctese a la base de datos de IA autónoma como usuario ADMIN. Como usuario ADMIN, también puede otorgar privilegios en este paquete a otros usuarios, según sea necesario.

Puede crear grupos de consumidores personalizados mediante el procedimiento cs_resource_manager.create_consumer_group.

Una conexión (sesión) se puede colocar en el nuevo grupo de consumidores especificando el grupo de consumidores en la cadena de conexión o configurando reglas de asignación de grupos de consumidores mediante los subprogramas set_consumer_group_mapping y set_consumer_group_mapping_pri.

• Inicie un área pendiente para ejecutar todas las sentencias DDL del gestor de recursos.

  BEGIN
    CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
  END;
  /

• Cree tres (3) grupos de consumidores:
  • OLTP_HIGH para manejar sesiones de procesamiento de transacciones de alta prioridad.
  • OLTP_LOW para manejar sesiones de procesamiento de transacciones en segundo plano o de baja prioridad.
  • LH_BATCH para cargas de trabajo por lotes o de informes.

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

  Nota
  
  OTHER_GROUPS es un grupo implícito que está disponible por defecto para cualquier sesión sin asignar.

Consulte Procedimiento CREATE_PENDING_AREA y Procedimiento CREATE_CONSUMER_GROUP para obtener referencias de sintaxis.

Cree un plan denominado OLTP_LH_PLAN para dividir los recursos entre el procesamiento de transacciones y los tipos de carga de trabajo de lakehouse.

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

Consulte CREATE_PLAN Procedure para obtener referencias de sintaxis.

Puede asignar y ajustar directivas de plan, como el recurso compartido de CPU, los límites de E/S, la simultaneidad y el paralelismo, para los grupos de consumidores personalizados. Consulte Acerca del paquete cs_resource_manager para obtener la lista completa de directivas.

Cree cuatro (4) directivas de plan para los siguientes escenarios:

• Las sesiones de procesamiento de transacciones de alta prioridad obtienen 8 recursos compartidos de CPU y E/S y sin paralelismo.
• Las sesiones de procesamiento de transacciones de menor prioridad obtienen 4 recursos compartidos de CPU y E/S y sin paralelismo.
• Lakehouse y transacciones por lotes:
  • Obtenga 4 recursos compartidos de CPU y E/S.
  • Tener el grado de paralelismo limitado a 4.
  • Haga que el timeout de cola paralela se defina en 60 segundos y la sentencia SQL terminará después del timeout.
• Todas las demás sesiones que no están asignadas a un grupo de consumidores obtienen 1 recurso compartido de CPU/E/S y ningún paralelismo.

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

Consulte CREATE_PLAN_DIRECTIVE Procedure para obtener referencias de sintaxis.

Puede asignar sesiones a sus grupos de consumidores personalizados en función de los atributos de conexión y tiempo de ejecución de la sesión. Mediante los subprogramas cs_resource_manager.set_consumer_group_mapping y cs_resource_manager.set_consumer_group_mapping_pri, puede definir reglas y prioridades para la asignación de sesiones a estos grupos de consumidores y definir prioridades de asignación de grupos de consumidores. Puede tener varias asignaciones con diferentes atributos. En este ejemplo, APP_USER se asigna a OLTP_HIGH y LH_USER se asigna a LH_BATCH. Estas asignaciones se evalúan en orden de prioridad definido por SET_CONSUMER_GROUP_MAPPING_PRI.

Puede determinar cómo se colocan las sesiones en grupos de consumidores mediante:

• Asignación de cadena de conexión: especifique CONSUMER_GROUP en la cadena de conexión de la base de datos, como se muestra a continuación. Este enfoque tiene prioridad sobre la asignación y sustituirá las asignaciones definidas.

  (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)))

• Reglas de asignación: utilice los subprogramas set_consumer_group_mapping y set_consumer_group_mapping_pri para asignar sesiones o aplicaciones a grupos de consumidores en función de atributos como nombre de usuario o nombre de aplicación.

Las sesiones se pueden asignar a grupos de consumidores mediante cualquiera de los atributos que se muestran en DBMS_RESOURCE_MANAGER Constants. Estas asignaciones se evalúan en orden de prioridad definido por SET_CONSUMER_GROUP_MAPPING_PRI. En este ejemplo, asignemos los grupos de consumidores por los siguientes usuarios:

• De APP_USER a OLTP_HIGH
• De LH_USER a 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;
/

Utilice validate_pending_area para revisar los cambios y submit_pending_area para activar las directivas del plan.

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

Consulte Procedimiento SET_CONSUMER_GROUP_MAPPING, Procedimiento SET_CONSUMER_GROUP_MAPPING_PRI, Procedimiento VALIDATE_PENDING_AREA y Procedimiento SUBMIT_PENDING_AREA para obtener referencias de sintaxis.

Por último, puede activar el plan personalizado de DBRM ejecutando una sentencia ALTER como se muestra a continuación.

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

Cuando ya no sea necesario, puede desactivar el plan y suprimir las directivas, el plan y los grupos de consumidores del plan mediante las siguientes sentencias:

• Para revertir al plan por defecto:

  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.

• Para suprimir una directiva de plan:

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

• Para suprimir un plan:

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

• Para suprimir un grupo de consumidores:

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

Consulte el procedimiento DELETE_CONSUMER_GROUP, el procedimiento DELETE_PLAN y el procedimiento DELETE_PLAN_DIRECTIVE para obtener una referencia de sintaxis.

Si utiliza un plan DBRM personalizado y se conecta a la base de datos mediante los servicios LOW, TP o TPURGENT, esas sesiones obtendrán paralelismo manual y puede limitar el grado de paralelismo de esas sesiones mediante las directivas del plan. Si se conecta mediante los servicios HIGH y MEDIUM, esas sesiones obtendrán paralelismo automáticamente y puede limitar el grado de paralelismo para esas sesiones mediante las directivas de su plan.