Gérer les ressources de charge de travail avec le gestionnaire de ressources de base de données dans Autonomous AI Database

Les sous-programmes cs_resource_manager vous permettent d'associer des politiques et des directives d'utilisation de ressources spécifiques à chaque groupe de consommateurs de ressources et de mettre en oeuvre, surveiller et réviser vos politiques en fonction de l'évolution de vos besoins.

Avec les sous-programmes cs_resource_manager, vous pouvez :

• Créez votre propre plan Database Resource Manager (DBRM).
• Créer et supprimer des groupes de consommateurs de ressources personnalisés.
• Définissez des mappings de groupes de consommateurs de ressources, c'est-à-dire des règles et des priorités pour l'affectation des sessions à ces groupes de consommateurs de ressources.
• définition des priorités de mappage des 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'affectation des ressources pour le groupe de consommateurs. Les partages déterminent la quantité de CPU et d'E/S qu'un groupe de consommateurs obtient par rapport aux autres groupes de consommateurs. Par exemple, un groupe de consommateurs avec une part de 2 recevra deux fois plus de ressources d'UC et d'E/S qu'un groupe de consommateurs avec une part de 1. La valeur par défaut est 1.
  • Limites des ressources qui déterminent le nombre maximal de ressources d'UC et d'E/S qu'un groupe de consommateurs peut obtenir.
  • Temps sur l'UC (en secondes) pendant lequel une session peut s'exécuter 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é.
  • 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 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 d'E/S logiques qui déclencheront l'action spécifiée par switch_action.
  • Temps écoulé (en secondes) pour déclencher l'action spécifiée par switch_action.
  • Nombre de secondes pendant lesquelles une session peut être inactive avant son arrêt. La valeur par défaut est NULL, ce qui signifie illimité.
  • Durée maximale en secondes pendant laquelle une session peut être inactive avant son arrêt, si la session est verrouillée ou si une ressource est requise par d'autres sessions.
  • Nombre maximal de sessions pouvant avoir simultanément un appel actif.
  • Temps (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 une opération en série
  • Niveau d'accès simultané pour les instructions parallèles. Etant donné que le niveau d'accès simultané détermine indirectement DOP, 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 (par défaut) indique qu'il n'y a pas de limite. Les opérations SQL qui allouent une mémoire PGA ajustable (opérations qui peuvent choisir d'utiliser de l'espace temporaire) ne sont pas contrôlées par cette limite.
  • Durée (en secondes) pendant laquelle une instruction parallèle peut rester dans la file d'attente d'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'une temporisation. Les options sont d'annuler ou d'exécuter l'instruction.
  • Mesures à prendre en vue d'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 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 flux de travail détaillé pour définir des groupes de consommateurs de ressources personnalisés, des plans et des mappings de session 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 base de données autonome d'IA pour un environnement de charge de travail mixte avec des applications OLTP et d'entrepôt avec lac de données. En fonction des besoins en ressources des applications et des caractéristiques de charge de travail, l'administrateur de base de données a décidé qu'il serait optimal 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 AI 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 de travail par lots ou de production de rapports.
2. Créez un plan nommé OLTP_LH_PLAN pour fractionner les ressources entre le traitement des transactions et les charges de travail d'entrepôt avec lac de données.
3. Créez quatre (4) directives de plan pour les scénarios suivants :
   • Les sessions de traitement des transactions hautement prioritaires bénéficient de 8 partages CPU et E/S sans parallélisme.
   • Les sessions de traitement des transactions de moindre priorité bénéficient de 4 partages CPU et E/S sans parallélisme.
   • Les transactions d'entrepôt avec lac de données et de lot reçoivent 4 partages d'UC et d'E/S et le degré de parallélisme est limité à 4.
   • Toutes les autres sessions qui ne sont pas mappées à un groupe de consommateurs de ressources reçoivent 1 partage CPU/E/S et aucun parallélisme.
4. Créez les mappings utilisateur-groupe de consommateurs suivants :
   • APP_USER à OLTP_HIGH
   • LH_USER à LH_BATCH
5. Activer le plan.

Pour utiliser les sous-programmes cs_resource_manager, connectez-vous à la base de données d'intelligence artificielle autonome en tant qu'utilisateur ADMIN. En tant qu'utilisateur ADMIN, vous pouvez également accorder des privilèges sur cet ensemble à d'autres utilisateurs, si nécessaire.

Vous pouvez créer des groupes de consommateurs de ressources 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 en spécifiant le groupe de consommateurs dans la chaîne de connexion ou en configurant des règles de mappage de groupe de consommateurs à 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 du gestionnaire de ressources.

  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 de travail par lots ou de production de rapports.

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

  Note
  
  OTHER_GROUPS est un groupe implicite disponible par défaut pour toutes les sessions non mappées.

Pour plus d'informations sur la syntaxe, voir Procédure CREATE_PENDING_AREA et Procédure CREATE_CONSUMER_GROUP.

Créez un plan nommé OLTP_LH_PLAN pour fractionner les ressources entre le traitement des transactions et les types de charge de travail d'entrepôt avec lac de données.

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

Pour plus d'informations sur la syntaxe, voir Procédure CREATE_PLAN.

Vous pouvez affecter et ajuster des directives de plan, telles que le partage CPU, les limites d'E/S, la simultanéité et le parallélisme, pour vos groupes de consommateurs de ressources personnalisés. Voir À propos de l'ensemble cs_resource_manager pour la liste complète des directives.

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

• Les sessions de traitement des transactions hautement prioritaires bénéficient de 8 partages CPU et E/S sans parallélisme.
• Les sessions de traitement des transactions de moindre priorité bénéficient de 4 partages CPU et E/S sans parallélisme.
• Transactions d'entrepôt avec lac de données et par lots :
  • Obtenez 4 partages d'UC et d'E/S.
  • Avoir le degré de parallélisme plafonné à 4.
  • Réglez la temporisation de la file d'attente parallèle à 60 secondes et l'instruction SQL prendra fin après la temporisation.
• Toutes les autres sessions qui ne sont pas mappées à un groupe de consommateurs de ressources reçoivent 1 partage CPU/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;
/

Pour plus d'informations sur la syntaxe, voir Procédure CREATE_PLAN_DIRECTIVE.

Vous pouvez mapper des sessions avec vos groupes de consommateurs de ressources personnalisés, en fonction des attributs de connexion et d'exécution de la session. À 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 consommateurs de ressources et définir les priorités de mappage des groupes de consommateurs de ressources. Vous pouvez avoir plusieurs mappages avec des attributs différents. Dans cet exemple, APP_USER est mappé à OLTP_HIGH et LH_USER est mappé à LH_BATCH. Ces mappages sont évalués dans l'ordre de priorité défini par SET_CONSUMER_GROUP_MAPPING_PRI.

Vous pouvez déterminer comment les sessions sont placées dans des groupes de consommateurs de ressources :

• Affectation de chaîne de connexion : Spécifiez CONSUMER_GROUP dans la chaîne de connexion à la base de données, comme indiqué ci-dessous. Cette approche a priorité sur le mappage et remplacera tous les mappages 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 mappage : 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 d'utilisateur ou le nom d'application.

Les sessions peuvent être mappées à des groupes de consommateurs de ressources en fonction de l'un des attributs répertoriés dans Constantes DBMS_RESOURCE_MANAGER. Ces mappages 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 par 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;
/

Pour plus d'informations sur la syntaxe, voir Procédure SET_CONSUMER_GROUP_MAPPING, Procédure SET_CONSUMER_GROUP_MAPPING_PRI, Procédure VALIDATE_PENDING_AREA et Procédure SUBMIT_PENDING_AREA.

Enfin, vous pouvez activer le plan DBRM personnalisé en exécutant un énoncé 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, 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 :

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

Pour plus d'informations sur la syntaxe, voir Procédure DELETE_CONSUMER_GROUP, Procédure DELETE_PLAN et Procédure DELETE_PLAN_DIRECTIVE.

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 obtiendront un parallélisme manuel et vous pouvez limiter le degré de parallélisme pour ces sessions à l'aide des directives de votre plan. Si vous êtes connecté à l'aide des services HIGH et MEDIUM, ces sessions obtiendront automatiquement un parallélisme et vous pouvez limiter le degré de parallélisme de ces sessions à l'aide des directives de votre plan.