Gestion des ressources de charge globale avec Database Resource Manager dans Autonomous Database

Les sous-programmes cs_resource_manager vous permettent d'associer des stratégies et des directives d'utilisation des ressources spécifiques à chaque groupe de consommateurs de ressources, et d'implémenter, de surveiller et de réviser vos stratégies à mesure que vos besoins changent.

Avec les sous-programmes cs_resource_manager, vous pouvez :

• Créez votre propre plan Database Resource Manager (DBRM).
• Créez et supprimez des groupes de consommateurs personnalisés.
• Définissez les mappings de groupes de consommateurs de ressources, c'est-à-dire les règles et les priorités relatives à l'affectation des sessions à ces groupes.
• Définir les priorités du mapping de groupes de consommateurs de ressources.
• Définissez des directives de plan pour affecter les contrôles de ressources suivants à chaque groupe de consommateurs de ressources personnalisé :
  • Part de l'allocation des ressources pour le groupe de consommateurs. Les partages déterminent la quantité de ressources d'UC et d'E/S qu'un groupe de consommateurs obtient par rapport aux autres groupes de consommateurs. Par exemple, un groupe de consommateurs de ressources avec une part de 2 obtiendra deux fois plus de ressources d'UC et d'E/S qu'un groupe de consommateurs de ressources avec une part de 1. La valeur par défaut est 1.
  • Limites de ressources qui déterminent le nombre maximal de ressources d'E/S et de CPU qu'un groupe de consommateurs de ressources peut obtenir.
  • Durée d'exécution d'une session sur l'UC (en secondes) avant l'exécution de l'action déterminée par le paramètre switch_action. La valeur par défaut est NULL, ce qui signifie illimité.
  • Quantité d'E/S (en Mo) qu'une session peut émettre avant que l'action déterminée par le paramètre switch_action ne soit effectuée. La valeur par défaut est NULL, ce qui signifie illimité.
  • Nombre de demandes d'E/S qu'une session peut émettre avant l'exécution de l'action déterminée par le paramètre switch_action. La valeur par défaut est NULL, ce qui signifie illimité.
  • Nombre d'E/S logiques qui déclencheront l'action indiquée par switch_action.
  • Temps écoulé (en secondes) qui déclenche l'action indiquée par switch_action.
  • Nombre de secondes pendant lesquelles une session peut être inactive avant la fin de la session. La valeur par défaut est NULL, ce qui signifie illimité.
  • Durée maximale (en secondes) pendant laquelle une session peut être inactive avant la fin de la session, si la session contient un verrou ou une ressource nécessaire à d'autres sessions.
  • Nombre maximal de sessions pouvant simultanément avoir un appel actif.
  • Délai (en secondes) après lequel un appel dans la file d'attente de session inactive (en attente d'exécution) expire. La valeur par défaut est NULL, ce qui signifie illimité.
  • Limite du degré de parallélisme (DOP) pour toute opération. La valeur par défaut est NULL, ce qui signifie illimité. Utiliser la valeur 1 pour qu'une opération soit en série
  • Niveau de simultanéité pour les instructions parallèles. Etant donné que le niveau de simultanéité détermine indirectement le degré de parallélisme, la définition des deux valeurs crée un conflit. Il est recommandé de définir uniquement la simultanéité ou le degré de parallélisme pour un groupe de consommateurs de ressources, et non les deux.
  • Quantité maximale de mémoire PGA non réglable (en Mo) qu'une session de ce groupe de consommateurs de ressources peut allouer avant d'être arrêtée. NULL (valeur par défaut) n'indique aucune limite. Les opérations SQL qui allouent la mémoire PGA réglable (opérations pouvant choisir d'utiliser l'espace temporaire) ne sont pas contrôlées par cette limite.
  • Temps (en secondes) pendant lequel une instruction parallèle peut rester dans la file d'attente des instructions parallèles de son groupe de consommateurs de ressources. Vous devez l'associer à l'action à effectuer lorsqu'une instruction parallèle est supprimée de la file d'attente en raison d'un dépassement de délai. Les options permettent d'annuler ou d'exécuter l'instruction.
  • Mesures à prendre pour atteindre l'une des limites spécifiées dans les directives. Les valeurs valides sont cancel_sql, kill_session ou un nom de groupe de consommateurs de ressources vers lequel basculer.
• Activez votre plan DBRM personnalisé et rétablissez la valeur par défaut, si nécessaire.

Les rubriques suivantes décrivent le workflow détaillé de définition de groupes de consommateurs de ressources, de plans et de mappages de sessions personnalisés dans un exemple de cas d'utilisation pratique. Ce flux de travail et les exemples de code associés peuvent être modifiés et implémentés en fonction de vos besoins.

Prenons l'exemple d'une organisation qui a décidé d'utiliser une instance Autonomous Database pour un environnement de charge globale mixte disposant à la fois d'applications OLTP et de Lakehouse. En fonction des besoins en ressources et des caractéristiques de charge globale des applications, l'administrateur de base de données a décidé qu'il serait préférable de définir et d'utiliser des plans DBRM personnalisés plutôt que les groupes de consommateurs de ressources et les plans prédéfinis fournis avec Autonomous Database.

Ils ont mis la dernière main aux exigences suivantes :

1. Créez trois (3) groupes de consommateurs de ressources :
   • OLTP_HIGH pour gérer les sessions de traitement des transactions à priorité élevée.
   • OLTP_LOW pour gérer les sessions de traitement des transactions en arrière-plan ou à faible priorité.
   • LH_BATCH pour les charges globales de traitement par lots ou de reporting.
2. Créez un plan nommé OLTP_LH_PLAN pour répartir les ressources entre le traitement des transactions et les charges globales de lakehouse.
3. Créez quatre (4) directives de plan pour les scénarios suivants :
   • Les sessions de traitement des transactions de haute priorité obtiennent 8 partages de CPU et d'E/S et aucun parallélisme.
   • Les sessions de traitement des transactions de priorité inférieure obtiennent 4 partages de CPU et d'E/S et aucun parallélisme.
   • Les transactions Lakehouse et batch obtiennent 4 partages d'UC et d'E/S et le degré de parallélisme est plafonné à 4.
   • Toutes les autres sessions qui ne sont pas mappées avec un groupe de consommateurs de ressources obtiennent 1 partage d'UC/E/S et aucun parallélisme.
4. Créez les mappages utilisateur/groupe de consommateurs de ressources suivants :
   • APP_USER à OLTP_HIGH
   • LH_USER à LH_BATCH
5. Activez le plan.

Pour utiliser les sous-programmes cs_resource_manager, connectez-vous à Autonomous Database en tant qu'utilisateur ADMIN. En tant qu'utilisateur ADMIN, vous pouvez également accorder des privilèges sur ce package à d'autres utilisateurs, si nécessaire.

Vous pouvez créer des groupes de destinataires personnalisés à l'aide de la procédure cs_resource_manager.create_consumer_group.

Une connexion (session) peut être placée dans le nouveau groupe de consommateurs de ressources en indiquant le groupe de consommateurs de ressources dans la chaîne de connexion ou en configurant des règles de mise en correspondance de groupes de consommateurs de ressources à l'aide des sous-programmes set_consumer_group_mapping et set_consumer_group_mapping_pri.

• Démarrez une zone d'attente pour exécuter toutes les instructions LDD de Resource Manager.

  BEGIN
    CS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
  END;
  /

• Créez trois (3) groupes de consommateurs de ressources :
  • OLTP_HIGH pour gérer les sessions de traitement des transactions à priorité élevée.
  • OLTP_LOW pour gérer les sessions de traitement des transactions en arrière-plan ou à faible priorité.
  • LH_BATCH pour les charges globales de traitement par lots ou de reporting.

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

  Remarque
  
  OTHER_GROUPS est un groupe implicite disponible par défaut pour toutes les sessions non mises en correspondance.

Pour plus d'informations sur la syntaxe, reportez-vous à Procédure CREATE_PENDING_AREA et à Procédure CREATE_CONSUMER_GROUP.

Créez un plan nommé OLTP_LH_PLAN pour répartir les ressources entre les types de charge globale de traitement des transactions et de lakehouse.

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

Reportez-vous à Procédure CREATE_PLAN pour plus d'informations sur la syntaxe.

Vous pouvez affecter et ajuster des directives de plan, telles que le partage de CPU, les limites d'E/S, la simultanéité et le parallélisme, pour vos groupes de consommateurs de ressources personnalisés. Pour obtenir la liste complète des directives, reportez-vous à A propos du package cs_resource_manager.

Créez quatre (4) directives de plan pour les scénarios suivants :

• Les sessions de traitement des transactions de haute priorité obtiennent 8 partages de CPU et d'E/S et aucun parallélisme.
• Les sessions de traitement des transactions de priorité inférieure obtiennent 4 partages de CPU et d'E/S et aucun parallélisme.
• Transactions Lakehouse et batch :
  • Obtenez 4 partages de CPU et d'E/S.
  • Le degré de parallélisme est plafonné à 4.
  • Définissez le délai d'expiration de la file d'attente parallèle sur 60 secondes et l'instruction SQL prendra fin après le délai d'expiration.
• Toutes les autres sessions qui ne sont pas mappées avec un groupe de consommateurs de ressources obtiennent 1 partage d'UC/E/S et aucun parallélisme.

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

Reportez-vous à Procédure CREATE_PLAN_DIRECTIVE pour plus d'informations sur la syntaxe.

Vous pouvez mettre en correspondance des sessions avec vos groupes de destinataires personnalisés, en fonction des attributs de connexion et d'exécution de la session. A l'aide des sous-programmes cs_resource_manager.set_consumer_group_mapping et cs_resource_manager.set_consumer_group_mapping_pri, vous pouvez définir des règles et des priorités pour l'affectation des sessions à ces groupes de destinataires et définir les priorités de mise en correspondance des groupes de destinataires. Vous pouvez avoir plusieurs mappages avec des attributs différents. Dans cet exemple, APP_USER est mis en correspondance avec OLTP_HIGH et LH_USER avec LH_BATCH. Ces mappings sont évalués dans l'ordre de priorité défini par SET_CONSUMER_GROUP_MAPPING_PRI.

Vous pouvez déterminer la façon dont les sessions sont placées dans les groupes de consommateurs de ressources via :

• Attribution de chaîne de connexion : indiquez CONSUMER_GROUP dans la chaîne de connexion à la base de données, comme indiqué ci-dessous. Cette approche est prioritaire sur le mapping et remplacera tous les mappings définis.

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

• Règles de mise en correspondance : utilisez les sous-programmes set_consumer_group_mapping et set_consumer_group_mapping_pri pour affecter des sessions ou des applications à des groupes de consommateurs de ressources en fonction d'attributs tels que le nom utilisateur ou le nom d'application.

Les sessions peuvent être mises en correspondance avec des groupes de destinataires par l'un des attributs répertoriés dans DBMS_RESOURCE_MANAGER Constantes. Ces mappings sont évalués dans l'ordre de priorité défini par SET_CONSUMER_GROUP_MAPPING_PRI. Dans cet exemple, mappons les groupes de consommateurs de ressources avec les utilisateurs suivants :

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

Utilisez validate_pending_area pour vérifier vos modifications et submit_pending_area pour activer les directives de plan.

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

Reportez-vous aux sections Procédure SET_CONSUMER_GROUP_MAPPING, Procédure SET_CONSUMER_GROUP_MAPPING_PRI, Procédure VALIDATE_PENDING_AREA et Procédure SUBMIT_PENDING_AREA pour plus d'informations sur la syntaxe.

Enfin, vous pouvez activer le plan DBRM personnalisé en exécutant une instruction ALTER comme indiqué ci-dessous.

ALTER SYSTEM SET resource_manager_plan='OLTP_LH_PLAN';

Lorsque vous n'en avez plus besoin, vous pouvez désactiver le plan et supprimer les directives de plan, le plan et les groupes de consommateurs de ressources à l'aide des instructions suivantes :

• Pour rétablir le plan par défaut :

  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.

• Pour supprimer une directive de plan :

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

• Pour supprimer un plan, procédez comme suit :

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

• Pour supprimer un groupe de consommateurs de ressources :

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

Reportez-vous aux sections Procédure DELETE_CONSUMER_GROUP, Procédure DELETE_PLAN et Procédure DELETE_PLAN_DIRECTIVE pour plus d'informations sur la syntaxe.

Si vous utilisez un plan DBRM personnalisé et vous connectez à votre base de données à l'aide des services LOW, TP ou TPURGENT, ces sessions bénéficient d'un parallélisme manuel et vous pouvez limiter le degré de parallélisme de ces sessions à l'aide des directives de votre plan. Si vous connectez à l'aide des services HIGH et MEDIUM, ces sessions obtiendront automatiquement le parallélisme et vous pouvez limiter le degré de parallélisme de ces sessions à l'aide des directives de votre plan.