Multitenant Activity
Trucs et Astuces
✓ d.side temps réel
Objectif de la fonctionnalité Multitenant Activity
Connexion au niveau du container
Lorsque la connexion est établie à un container possédant plusieurs pluggable databases (PDBs), le Multitenant Activity permet de voir en un instant comment les différentes PDBs se répartissent l’activité. Y a-t-il une PDB plus chargée que les autres, les ressources sont-elles utilisées de manière équilibrée entre chaque PDB, les transactions sont-elles réparties uniformément entre chacune, ou une PDB reçoit-elle moins de requêtes à traiter ?
Chaque ligne correspond à une statistique de l’activité : CPU, logical reads, IOs, nombre de transactions, d’exécutions…
Et chacune représente un total de 100% pour l’ensemble du container.
Par exemple, dans un container composé de deux PDBs :
Chaque ligne correspond à une statistique de l’activité : CPU, logical reads, IOs, nombre de transactions, d’exécutions…
Et chacune représente un total de 100% pour l’ensemble du container.
Par exemple, dans un container composé de deux PDBs :
- si les deux PDBs exécutent chacune à peu près le même nombre de requêtes, la statistique “execute count” affichera deux valeurs à peu près équivalentes à 50% chacune :
- Si en revanche une PDB traite par exemple 3 fois plus de transactions que l’autre, alors le Multitenant Activity présentera pour la statistique “user commits” une barre représentant 75% des transactions alors que l’autre barre totalisera les 25% restants :
Connexion au niveau PDB
Lorsque la connexion est établie à une PDB ou sur un container ne possédant qu’une seule PDB, le Multitenant Activity ne montre alors que les statistiques pour cette seule PDB :
On voit ici que la PDB numéro 4 “PDBDSIDE2” ne réalise aucune transaction et ne génère pas d’écriture physique.
Mais dans cette configuration, le Multitenant Activity est alors beaucoup moins utile, montrant que 100% de ce qui peut se passer dans la base est imputable à cette seule PDB.
L’objectif du Multitenant Activity est de donner une vision rapide de l’équilibre entre les PDBs, on l’utilisera donc connecté au niveau du container.
Détails
Lorsque l’on survole le graphique avec la souris, le Multitenant Activity indique de quelle statistique et quelle PDB il s’agit, précisant la valeur que représente cette statistique sur le total.
Dans l’exemple suivant, on voit en survolant le secteur bleu de la deuxième ligne que la PDB numéro 3 “PDBDSIDE1” représente 31% de toutes les “DB Time” consommées au sein du container.
Exemples d’utilisation
Cas d’utilisation 1
Dans ce premier cas, le Multitenant Activity permet de confirmer que les 3 PDBs du container se répartissent de manière homogène la consommation de ressources et la charge (CPU, IOs, nombre de transactions…).
Cas d’utilisation 2
Dans cette situation, en revanche, le Multitenant Activity permet de remarquer que la PDB numéro 3 “PDBDSIDE1” totalise plus de transactions (nombre de COMMITs) que les deux autres PDBs, tout en consommant bien moins de ressources (CPU, IOs).
Les deux autres PDBs se partagent de manière plutôt homogène les ressources consommées ou les statistiques de charge. On observe juste un peu plus de “logical reads” pour la PDB numéro 4 “PDBDSIDE2”.
Comment ouvrir le Multitenant Activity
La fenêtre “Multitenant Activity” est directement accessible depuis le menu Analyzers de d.side :
User Oracle et privilèges requis
Pour avoir, depuis une connexion au container, une vue de l’ensemble des PDBs, il est nécessaire d’utiliser un user comme SYSTEM, par exemple, ou alors de créer un nouveau “common user”.
Exemple de création d’un common user :
CREATE USER c##myuser IDENTIFIED BY mypassword CONTAINER=ALL; GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO c##myuser CONTAINER=ALL; ALTER USER c##myuser SET CONTAINER_DATA=all CONTAINER=CURRENT;
Les clauses CONTAINER=ALL et CONTAINER_DATA=ALL permettent de créer le common user dans toutes les PDBs et d’avoir accès aux statistiques de chacune. Ceci est indispensable pour pouvoir exploiter le Multitenant Activity. Sans ces privilèges on risque de se retrouver avec des données qui manquent, des PDBs invisibles, voire une fenêtre complètement vide, ou encore de rencontrer des erreurs Oracle du type :
ORA-1435: user does not exist
Remarque : c’est un paramètre d’instance Oracle qui impose de préfixer le nom d’un common user avec par défaut la valeur C## :
common_user_prefix=C##
Conclusion :
Utilisé au niveau du container ROOT de la CDB, le Multitenant Activity offre une vue d’ensemble, globale, de la consommation et de la répartition des charges entre les différentes PDBs qui le composent.
On y détecte ainsi très rapidement si l’équilibre entre ces PDBs est respecté ou si certaines sollicitent davantage ou moins que les autres les ressources de l’ensemble.
Ensuite, on peut toujours se connecter avec d.side à chaque PDB indépendamment pour obtenir les détails concernant chacune (événements d’attente, requêtes SQL…), de manière habituelle.
On y détecte ainsi très rapidement si l’équilibre entre ces PDBs est respecté ou si certaines sollicitent davantage ou moins que les autres les ressources de l’ensemble.
Ensuite, on peut toujours se connecter avec d.side à chaque PDB indépendamment pour obtenir les détails concernant chacune (événements d’attente, requêtes SQL…), de manière habituelle.
Recent Posts
