Pour maîtriser la consommations des ressources CPU(s), Oracle nous offre en standard deux solutions qui peuvent se compléter :

• Instance Caging
• Database Resource Manager

1. Instance Caging

Instance Caging’ est une réponse simple et efficace pour les DBAs qui désirent consolider leurs serveurs simplement en initialisant le paramètre CPU_COUNT. En effet cette option permet de prévenir et brider l’utilisation des ressources processeurs d’une base de données vis-à-vis des autres bases de données en limitant son activité au nombre de processeurs défini sur la globalité des ressources disponibles du serveur. Du fait que ‘Instance Caging’ soit simple à configurer et ne requière aucun composant supplémentaire en option, cette solution est une excellente alternative à d’autres outils de consolidation tel que la virtualisation ou l’utilisation de gestionnaire de ressources ‘système’.

Prenons pour exemple un serveur qui dispose de 16 coeurs et qui héberge 4 bases de données, la répartition des ressources CPU pourrait être calculée en fonction des priorités que l’on donne à chacune des bases de données sans dépasser la limite du nombre total de CPUs physique du serveur ou alors définir un quota indépendamment du nombre total de CPU(s) du fait de l’utilisation sporadique de certaines bases de données (OverProvisioning)

OverProvisioning pour l’option 2 : en raison de l’utilisation ponctuelle de la base d’intégration

2. Database Resource Manager

L’autre solution pour maitriser les ressources est ‘Oracle resource manager’ qui permet de contôler l’allocation des ressources d’une base de données au niveau :

1. Utilisateurs
2. Applications
3. Services

Le gestionnaire de ressources s’assure que les ressources disponibles pour la base de données soit partagées et distribuées pour les utisateurs, applications, services. Le gestionnaire de ressources peut s’exécuter sur un ou plusieurs noeuds dans une configuration RAC ce qui permet de supporter plusieurs applications et une charge de travail globale avec une efficacité optimale. Ainsi le ‘Database Resource Manager’ fournit la capacité de prioriser un travail aussi bien au sein d’une base de données que d’un environnement RAC.

Les ressources sont allouées à l’utilisateur en fonction du plan de ressources qui est spécifié par l’administrateur de la base de données. Les notions suivantes sont utilisées pour caractériser un plan de ressources.

• Un plan de ressource définit comment les ressources doivent être distribuées parmi les différents utilisateurs (resource consumer groups) : EASY_PLAN
• Un groupe de consommation des ressources ‘Resource consumer group’ permet d’associer un ensemble de sessions ‘utilisateur’ à des besoins de ressources : CALCUL_GROUP, GESTION_GROUP
• Les méthodes d’allocation des ressources sont définies au niveau du plan de ressource pour chacun des groupes de consommation
  • CALCUL_GROUP : 80% des ressources CPU
  • GESTION_GROUP: 75% des ressources CPU
  • Le sous plan que le DBA peut créer à l’intérieur d’un plan de ressource permet la sous division de ressources pour différents utilisateurs d’une application.
  • Huit niveaux d’allocation des ressources peuvent être spécifiés. Ces niveaux offre un mécanisme pour préciser la distribution des ressources non utilisées pour d’autres utilisateurs.

‘Database Resource Manager’ autorise d’associer un groupe de consommateurs de ressources à un service, aussi les utilisateurs qui se connectent à ce service seront régis par les règles d’allocation qui ont été fixées pour le groupe de consommateurs.

A tout moment lorsqu’un seul groupe de consommation est actif celui-ci peut aller au delà du seuil qui lui a été fixé pour éventuellement obtenir 100% des ressources.

Mise en oeuvre Database Resource Manager

 Step 1 : Création de la zone de modification ‘Pending Area’

Les changements effectuées dans cette zone ne sont pas visibles jusqu’à la confirmation des modifications.

 SQL> exec dbms_resource_manager.create_pending_area();

A tout moment, vous pouvez abandonner les modifications dans cette zone par la commande suivante :

SQL> exec dbms_resource_manager.clear_pending_area();

 Step 2: Création des groupes de consommateurs

SQL> exec dbms_resource_manager.create_consumer_group ('CALCUL_GROUP','Calcul Application');
SQL> exec dbms_resource_manager.create_consumer_group ('GESTION_GROUP','Gestion Application');

 Step 3: Associer les utilisateurs ou services à un groupe de consommation

 SQL> exec dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.service_name, value => 'CALCUL',consumer_group => 'CALCUL_GROUP');

SQL> exec dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.service_name, value => 'GESTION',consumer_group => 'GESTION_GROUP');

 Step 4: Créer un plan de ressources

 SQL> exec dbms_resource_manager.create_plan(‘EASY_PLAN','Plan ORM EASY');

 Step 5: Définir les règles d’allocation du plan de ressources

SQL> exec dbms_resource_manager.create_plan_directive( ‘EASY_PLAN', ‘CALCUL_GROUP', 'Percentage of CPU for CALCUL', mgmt_p1 => 25, max_utilization_limit => 90);
SQL> exec dbms_resource_manager.create_plan_directive( ‘EASY_PLAN', ‘GESTION_GROUP', 'Percentage of CPU for GESTION', mgmt_p1 => 75);

Step 6: Enregistrement des modifications effectuées dans la zone

SQL> exec dbms_resource_manager.submit_pending_area();

Step 7a: Activation du plan de ressources au niveau de l’instance

SQL> alter system set resource_manager_plan = ‘EASY_PLAN' sid='*‘ scope=both;

Step 7b: Activation du plan de ressources via l’ordonnanceur Oracle

SQL> exec dbms_scheduler.set_attribute('MONDAY_WINDOW', 'RESOURCE_PLAN',‘EASY_PLAN');

Voilà…. en espérant que ce petit article succinct vous aidera dans vos futures implémentations Oracle