DRM : Database Resource Manager

Cet article est une introduction sommaire à Oracle DRM (Database Resource Manager). DRM est un outil qui permet aux DBAs d’organiser leur production en fonction des priorités demandées par les utilisateurs. Dans notre exemple de configuration de DRM, nous nous intéresserons à limiter la consommation des ressources par un batch afin de laisser un maximum de puissance à un serveur d’application.
Dans la vraie vie, on demandera souvent au DBA de s’assurer que son site web de production répond de façon convenable alors que les services commerciaux peuvent également lui demander de lancer des travaux de batch divers (consolidation statistique, purges, etc). Dans ce cas, les travaux de type Batch ne devront évidement jamais gêner la production : DRM doit alors entrer en scène.

1) Introduction

Dans le cadre de la priorisation des exécutions de processus Oracle, DRM va nous donner la possibilité de définir des Plans d’exécution de Resources (”Resource Plan” ou “RP”).  Un RP est un élément logique permettant de définir un périmètre en matière de priorisation des taches en cours au sein d’une instance. Les limites et la nature de ce périmètre (CPU, nombre de sessions max, …) seront définis dans un second temps.

Un RP est donc une manière de répartir la consommation des ressources d’une instance Oracle selon les exigences de la production. Il conviendra, en fonction des fenêtres de votre activité, de construire plusieurs RP de production, par exemple, si un serveur d’application a une activité très faible la nuit, on donnera une importance assez grande aux batchs, alors qu’en plein jour, on la minimisera pour que les requêtes OLTP aient une puissance maximale.

2) Création d’un plan de ressources et des groupes de consommateurs :

2.1 - Création du Plan de Resource (”RP”):

Il faut détenir le grant SYSDBA pour pouvoir créer un RP, et l’instruction est la suivante:

SQL > dbms_resource_manager.create_plan(
      plan => 'PROD_JOUR'
      ,comment => 'Ceci est un plan de test');

Cette instruction a pour effet de créer un plan de ressource nommé ‘PROD_JOUR’, nous verrons en effet plus loin qu’il sera utile de définir, comme indiqué dans l’introduction, divers RP pour les différentes heures de la journée et correspondant aux exigences de votre Direction commerciale.

2.2 - Création des Groupes de consommateurs (”Consumer Group” ou “CG”):

Maintenant que le RP est créé, nous allons créer des groupes de consommateurs qui seront notamment associés à des notions de priorisations (valeurs limites, poids, …) qui définieront notre périmètre de consommation de ressources.

Un GP se crée avec l’instruction SYSDBA suivante:

dbms_resource_manager.create_consumer_group(
     consumer_group => 'OLTP'
     ,comment        => 'Comptes de prod pour
                         le serveur d'applis'
     ,cpu_mth => 'ROUND-ROBIN'
);

Dans cet exemple, nous créons un groupe de consommateurs nommé “OLTP’ dont les priorisations de ses utilisateurs seront fonction de la puissance CPU et dont la méthode de répartition de charge choisie sera du RoundRobbin.

Typiquement, le(s) user(s) utilisés par le serveur d’applications seront ensuite affectés à ce groupe.

Nous créons ensuite le deuxième CG pour les users de type batch :

dbms_resource_manager.create_consumer_group(
     consumer_group => 'BATCH'
     ,comment        => 'Comptes de prod pour
                         les batchs'
     ,cpu_mth => 'ROUND-ROBIN'
);

En dehors de la priorisation de la CPU, DRM permet de définir d’autres points de mesure (nombre de sessions max, etc), mais cela ne fait pas l’objet de ce billet, cf doc Oracle pour cela.

2.3 - Affectation des users Oracle aux groupes de consommateurs :

Une fois ces groupes définis, nous allons indiquer à l’instance quels sont les users qui les composent. Dans notre exemple, nous utiliseront deux users Oracle, le premier qui sert à notre serveur d’application à accèder à la database par l’intermédiaire d’un pilote JDBC, c’est le user “SERVEUR_APPLI”. Le deuxième, un user qui déclenchera les scripts SQL ou les blocs PLSQL de purge ou de traitement quelconque, c’est le user “TRAITEMENTS”.

dbms_resource_manager_privs.grant_switch_consumer_group(
    grantee_name=>'SERVEUR_APPLI'
    ,consumer_group=>'OLTP'
    ,grant_option=>false);
dbms_resource_manager_privs.grant_switch_consumer_group(
    grantee_name=>'TRAITEMENTS'    
    ,consumer_group=>'BATCH'
    ,grant_option=>false);

dbms_resource_manager.set_initial_consumer_group(
    user=>'SERVEUR_APPLI'
    ,consumer_group=>'OLTP');
dbms_resource_manager.set_initial_consumer_group(
   user=>'TRAITEMENTS'    
   , consumer_group=>'BATCH');

La fonction grant_switch_consumer_group du package dbms_resource_manager_privs permet de définir l’appartenance d’un user Oracle à un CG alors que la fonction set_initial_consumer_group du package dbms_resource_manager permet de définir le groupe de “départ” de chaque user.

En effet, nous verrons plus loin que nous pouvons définir des “politiques de glissement” d’un CG à un autre CG en fonction de différents êvènements, il faut donc bien préciser quel est le groupe de “départ” et l’autorisation d’un groupe à glisser (switch) dans un autre CG que son CG de départ.

Par exemple, si un package met trop de temps à s’exécuter, on peut le switcher automatique vers un CG qui a une priorisation CPU moins importante, etc.

3) Créations des directives de consommation

Une fois le RP créé, que les CG ont été définis, il faut définir, pour tous les groupes nommés dans les GC, des directives comportementales. Dans notre exemple basé sur la priorisation de la CPU, nous parlerons alors de directives en terme de droit à consommer de la CPU (80% pour le groupe OLTP, 10% pour le batch, …)  et de poids (Les transactions OLTP doivent prendre toute la CPU si elles le réclament, dans la négative les batchs peuvent consommer de la CPU , les users passent en troisème, etc ..)

3.1 - Introduction aux poids de consommation :

Le poid dans DRM est une notion de “priorité” en matière de répartition des ressources. Dans le cadre de la consommation CPU, nous allons définir plusieurs poids, sachant que les groupes bénéficiant des poids les plus faibles seront servis les premiers en matière de puissance CPU.

On peu définir, pour chaque poids, une politique de consommation maximale de la CPU (en %) répartie sur l’ensemble des groupes de consommateurs créés en 2.2.

Exemple:

             OLTP           BATCH          OTHER_GROUPS
poids 1      100%           0%             0%
poids 2      0%             80%            20%
poids 3      0%             0%             100%

Dans cet exemple, seul le groupe OLTP peut prendre toute la CPU s’il en a besoin, car il est le seul à bénéficier du poids 1 (le plus faible).

Si les users du CG OLTP n’ont pas besoin de la totalité de la CPU, alors Oracle va donner de la puissance aux users présents dans les groupes définis dans le poids 2, à savoir 80% de la puissance restante pour le batch (purges, stats, …) et 20% pour les autres utilisateurs qui ne sont définis dans aucun CG.

Si aucunne activité OLTP n’est requise et que aucun batch ne tourne, alors les autres utilisateurs peuvent exploiter la totalité de la CPU.

Remarque 1: Notez l’apparition dans notre exemple du groupe “OTHER_GROUPS”, vous n’avez pas à le définir, il est implicite et contient tous les users Oracle que vous n’aurez pas affecté à des CG.

Remarque 2: Un deuxième groupe implicite existe et fait par défaut partie du poids 1 : “SYSTEM_GROUP”, ce sont les SYSDBA, en effet, quoi qu’il se passe, il faut qu’un SYSDBA puisse à tout instant se connecter à une instance pour des opérations de maintenance.

3.2 - Définition des directives de poids :

Il s’agit simplement d’utiliser  dbms_resource_manager.create_plan_directive pour traduire le tableau précédent tel que:

dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'OLTP'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / OLTP'
          ,cpu_p1           => 100
          ,cpu_p2           => 0
          ,cpu_p3           => 0
);
dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'BATCH'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / BATCH'
          ,cpu_p1           => 0
          ,cpu_p2           => 80
          ,cpu_p3           => 0
);
dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'OTHER_GROUPS'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / OTHERS'
          ,cpu_p1           => 0
          ,cpu_p2           => 20
          ,cpu_p3           => 100

);

Notez que la totalité des puissances CPU, pour chaque poids, doit faire exactement 100%.

4) La “Pending Area” :

Il serait très délicat de modifier le périmètre d’un Plan d’exécution alors que celui-ci est pris en compte par votre instance à un instant t. Pour cela, nous disposons de la “Pending Area”, qui est une aire de temporaire et intermédiaire de stockage des définitions concernant les objets des RP qui ne sera pris en compte au final que après validation et dont on peut effacer le contenu à tout instant.

Toutes les blocs d’instructions précédentes doivent être précédés de ces odres :

    dbms_resource_manager.clear_pending_area;
    dbms_resource_manager.create_pending_area;

    ... <opérations sur les RP> ...

    dbms_resource_manager.validate_pending_area;
    dbms_resource_manager.submit_pending_area;

Ceci assure la stabilité de votre instance pendant la modification des RP.

5) Prise en compte d’un plan d’exécution:

Une fois le RP créé et son périmètre défini, il faut indiquer à votre instance qu’elle doit le prendre en compte, vous utiliserez alors l’instruction suivante :

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='PRODUCTION_PLAN';

Pour annuler toute prise en compte de plan d’exécution en cas de problème, il suffit de passer l’ordre

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='';

N’hésitez pas à consuler le plan en cours d’exécution avec

SHOW PARAMETER RESOURCE_MANAGER_PLAN;

6) monitoring :

La vue v$rsrc_consumer_group vous permet de consulter, en quasi temps réel, la répartition des différents utilisateurs des différents CG en fonction de vos directives de consommations.

select name
,active_sessions
,execution_waiters
,requests
,cpu_wait_time
,cpu_waits
,consumed_cpu_time
,yields
,queue_length
,current_undo_consumption
from v$rsrc_consumer_group;