Pour ceux qui ont déjà installé la version 12c du Grid Infrastructure, vous avez vu apparaitre une nouvelle base de données installée en même temps que le noyau, MGMTDB.
Cette nouvelle instance de base de données est utilisée pour stocker les données collectées pour le CHM (Cluster Health Monitor). Ce qui en soit n’est pas nouveau, en 11g ces données étaient stockées dans une base de données berkleydb .
Optionnel en 12.1.0.1, la base MGMTDB devient obligatoire en 12.1.0.2.
En 11g, les fichiers étaient stockés dans des fichiers de type .bdb dans le répertoire $GRID_HOME/CRF/db/Host_name. Suite à un bug en 11.2.0.2 ces fichiers pouvaient prendre beaucoup d’espace (> 100G).
En 12c, les fichiers de base de données sont stockés sur les disques sur lesquels sont stockés les fichiers OCR et VOTING, ce qui entraine une augmentation de la taille de ces derniers.De ce fait, Il est préconisé de les étendre jusqu’à 6G.
La première question que l’on peut se poser est :
Est il possible d’installer la base MGMTDB ailleurs que sur les disques OCR et VOTING ?
La réponse est Non.
Par contre il est possible de changer la localisation des fichiers en supprimant et recréant la base.
Attention, de ce fait on perd l’historique stocké dans la base.
La seconde est :
Doit on sauvegarder la base MGMTDB ?
A priori non. en cas de perte de la base, il suffit d’arrêt le service de collecte et de recréer la base avec le même mécanisme que celui utilisé pour le déplacement des dbf. Dans ce cas on perd bien entendu l’historique des traces.
Je vous propose de décliner cet article en 2 temps
Comment déplacer la base de données MGMTDB, puis quelques commandes utiles liées au CHM.
1. Comment déplacer la base de données MGMTDB
Voici la procédure à suivre, sous Unix/Linux en version 12.1.0.2 de Grid Infrastructure, pour déplacer la base MGMTDB.
- Sauvegarde des informations déjà collectées ( optionnel )
Si vous voulez conserver une trace des informations stockées dans la base, Il n’y a pas d’obligation, suivez la procédure suivante :
Positionnez l’environnement Grid Infrastructure à l’aide de la commande oraenv, puis dans le cas ou l’on veut garder les données générées entre le 18/01/2015 et le 19/01 15h10 , lancez :
rm mgmtdb.dump mknod mgmtdb.dump p cat mgmtdb.dump | gzip mgmtdb.dump.gz & oclumon dumpnodeview -allnodes -s "2015-01-18 00:00:00" -e "2015-01-19 15:10:00" >mgmtdb.dump
Si aucune date de début et de fin ne sont spécifiées, Il faudra faire un [CTRL]+[C] pour arrêter la génération du fichier.
Cet ensemble de commandes génère un fichier gz contenant des informations du type suivant sur l’ensemble des nœuds du cluster.
---------------------------------------- Node: monnoeud1 Clock: '15-01-19 12.28.15 Europe/Paris' SerialNo:221787 ---------------------------------------- SYSTEM: #pcpus: 2 #vcpus: 12 cpuht: N chipname: Intel(R) cpu: 1.48 cpuq: 0 physmemfree: 44481116 physmemtotal: 74232768 mcache: 26326964 swapfree: 16809976 swaptotal: 16809976 hugepagetotal: 0 hugepagefree: 0 hugepagesize: 2048 ior: 0 iow: 49 ios: 9 swpin: 0 swpout: 0 pgin: 0 pgout: 24 netr: 169.916 netw: 105.966 procs: 554 procsoncpu: 1 rtprocs: 45 rtprocsoncpu: N/A #fds: 14304 #sysfdlimit: 6815744 #disks: 28 #nics: 4 nicErrors: 0 TOP CONSUMERS: topcpu: 'gipcd.bin(5689) 1.60' topprivmem: 'java(2232) 405248' topshm: 'ora_mman_bddtst(30414) 20155688' topfd: 'polkit-gnome-au(16474) 1020' topthread: 'console-kit-dae(16316) 64' ---------------------------------------- Node: monnoeud2 Clock: '15-01-19 12.29.18 Europe/Paris' SerialNo:221976 ---------------------------------------- SYSTEM: #pcpus: 2 #vcpus: 12 cpuht: N chipname: Intel(R) cpu: 1.05 cpuq: 0 physmemfree: 29658212 physmemtotal: 49412052 mcache: 16704396 swapfree: 16809980 swaptotal: 16809980 hugepagetotal: 0 hugepagefree: 0 hugepagesize: 2048 ior: 0 iow: 86 ios: 16 swpin: 0 swpout: 0 pgin: 0 pgout: 43 netr: 137.464 netw: 58.943 procs: 470 procsoncpu: 1 rtprocs: 45 rtprocsoncpu: N/A #fds: 9120 #sysfdlimit: 6815744 #disks: 44 #nics: 4 nicErrors: 0 TOP CONSUMERS: topcpu: 'gipcd.bin(4127) 1.79' topprivmem: 'java(2642) 267668' topshm: 'ora_dbw0_bddtst(11807) 11689612' topfd: 'crsd.bin(4399) 227' topthread: 'java(6562) 44'
Cette opération peut prendre un temps certain .
- Etape suivante, on arrête et on désactive la ressource crf
Sur chaque nœud, une fois connecté root et après avoir positionné l’environnement Grid Infrastructure,lancez les commandes suivantes :
$GRID_HOME/bin/crsctl stop res ora.crf -init $GRID_HOME/bin/crsctl modify res ora.crf -attr ENABLED=0 -init
Attention, ne pas arrêter les ressources ora.mgmtlsnr et ora.mgmtdb. Dans le cas contraire, on aurait des messages du type
<<Oracle Grid Management database is running on node "". Run dbca on node "" to delete the database>>
lors de la suppression de la base .
- Suppression de la base existante
Utilisez la commande dbca sous le user grid pour supprimer la base existante.
Positionnez l’environnement Grid Infrafructure a l’aide de oraenv, puis :
vérifiez que la base est bien démarrée et son status .
srvctl status mgmtdb Database is disabled Instance -MGMTDB is running on node Monserveur01
Puis supprimez la base MGMTDB :
dbca -silent -deleteDatabase -sourceDB -MGMTDB Connecting to database 4% complete 9% complete 14% complete 19% complete 23% complete 28% complete 47% complete Updating network configuration files 48% complete 52% complete Deleting instance and datafiles 76% complete 100% complete Look at the log file "/u01/app/oracle/grid/cfgtoollogs/dbca/_mgmtdb.log" for further details.
- Recréation de la base MGMTDB
Dans notre cas, on est en version 12.1.0.2 du Grid Infrastructure avec un stockage en NFS pour compliquer un peut les choses.
On contrôlera donc la présence d’un fs partagé entre l’ensemble des noeuds du cluster.
On se connectera avec le user Grid infrastructure
On positionnera l’environnement Grid a l’aide de la commande oranev
Puis on lancera la commande suivante pour recréer la base:
dbca -silent -createDatabase -sid -MGMTDB -createAsContainerDatabase true \ -templateName MGMTSeed_Database.dbc -gdbName _mgmtdb \ -storageType FS -datafileDestination /nfs2/griddata \ -datafileJarLocation $ORACLE_HOME/assistants/dbca/templates \ -characterset AL32UTF8 -autoGeneratePasswords –skipUserTemplateCheck Registering database with Oracle Grid Infrastructure 5% complete Copying database files 7% complete 9% complete 16% complete 23% complete 41% complete Creating and starting Oracle instance 43% complete 48% complete 53% complete 57% complete 58% complete 59% complete 62% complete 64% complete Completing Database Creation 68% complete 69% complete 80% complete 90% complete 100% complete Look at the log file "/u01/app/oracle/grid/cfgtoollogs/dbca/_mgmtdb/_mgmtdb0.log" for further details.
La commande à utiliser pour un stockage des dbf sous ASM est un peut différente.
Après vous être assuré de l’existence du volume ASM sur l’ensemble des nœuds du cluster et du niveau de compatibilité ASM et RDBMS du volume (CREATE DISKGROUP … ATTRIBUTE ‘compatible.rdbms’ = ‘12.1’, ‘compatible.asm’ = ‘12.1’; ) , lancez la commande suivante :
dbca -silent -createDatabase -sid -MGMTDB -createAsContainerDatabase true \
-templateName MGMTSeed_Database.dbc -gdbName _mgmtdb \
-storageType ASM -diskGroupName +MON_DG \
-datafileJarLocation $ORACLE_HOME/assistants/dbca/templates \
-characterset AL32UTF8 –autoGeneratePasswords \
-skipUserTemplateCheck
On va maintenant créer la Pluggable Database qui va servir au stockage des données collectées dans le container MGMTDB.
Pour cela , sous le user grid, après avoir positionné l’environnement –MGMTDB, lancez la commande dbca avec les paramètres suivants :
dbca -silent -createPluggableDatabase -sourceDB -MGMTDB -pdbName NOMCLUSTER \
-createPDBFrom RMANBACKUP \
-PDBBackUpfile $ORACLE_HOME/assistants/dbca/templates/mgmtseed_pdb.dfb \
-PDBMetadataFile $ORACLE_HOME/assistants/dbca/templates/mgmtseed_pdb.xml \
-createAsClone true -internalSkipGIHomeCheck
Creating Pluggable Database
4% complete
12% complete
21% complete
38% complete
55% complete
85% complete
Completing Pluggable Database Creation
100% complete
Look at the log file "/u01/app/oracle/grid/cfgtoollogs/dbca/_mgmtdb/Monserveur01/_mgmtdb0.log" for further details.
Attention : assurez vous avant de bien avoir substitué les éventuels caractères « – » par des underscores « _ » dans le nom du cluster
Pour terminer l’opération, on va s’assurer que la base est bien démarrée.
Pour cela, sous le user grid et après avoir positionné l’environnement MGMTDB a l’aide de la commande oraenv, lancer la commande suivante :
srvctl status MGMTDB Database is enabled Instance -MGMTDB is running on node Monserveur01
Sur le serveur Monserveur01, sous le user grid et après avoir positionné l’environnement adéquat, lancez la commande :
mgmtca
Attention : assurez vous de bien lancer la commande mgmtca sur le serveur dont le nom est retourné par la commande srvctl status MGMTDB. Dans le cas contraire aucun message d’erreur ne sera retourné mais la connexion à la base ne se fera pas, et le processus sera à recommencer.
- redémarrez et réactivé la ressource crf
Enfin on réactive et on redémarre la ressource crf
sur chaque nœud du cluster , sous le user root , après avoir positionné l’environnement grid a l’aide de la commande oraenv, lancez les commandes suivantes :
crsctl modify res ora.crf -attr ENABLED=1 -init crsctl start res ora.crf -init CRS-2672: Attempting to start 'ora.crf' on 'noeud01' CRS-2676: Start of 'ora.crf' on 'noeud01' succeeded
Voila, notre base MGMTDB a été déplacée et l’acquisition des données d’audit est relancée sur l’ensemble des nœuds du cluster.
2. Quelques commandes utiles
Concernant le CHM, voici quelques commandes utiles.Celles-ci existaient déjà en 11G.
- Pour connaître le nom du nœud maitre,
en regle général le nœud ou tourne la base MGMTDB
oclumon manage -get MASTER Master = Nomserveur03
- Pour voir la liste des serveurs ou tourne le service Cluster Logger et la liste des nœuds surveillés
oclumon manage -get alllogger -details Logger = Nomserveur03 Nodes = Nomserveur01, Nomserveur03
- Pour connaître la taille du repository CHM
oclumon manage -get repsize CHM Repository Size = 136320 seconds
Etonnamment l’unité de mesure est la seconde.
La valeur doit être entre 3600 (1 heure) et 259200 ( 3 jours).
- Pour modifier la duré de rétention des données et la taille du repository CHM
Exemple pour reduire la période de rétention à 12h
oclumon manage -repos changeretentiontime 43200 The Cluster Health Monitor repository can support the desired retention for 2 hosts
Dans le cas ou l’on souhaite passer la période de rétention à 2 jours.
oclumon manage -repos changeretentiontime 172800 The Cluster Health Monitor repository is too small for the desired retention. Please first resize the repository to 2598 MB
Dans le cas présent le repository est trop petit. Il convient de l’agrandir avant d’augmenter la période de rétention.
L’unité est le MB.
oclumon manage -repos changerepossize 3000 The Cluster Health Monitor repository was successfully resized.The new retention is 199620 seconds.
- Pour retrouver le serveur qui est en charge de collecter les données pour le serveur courant :
oclumon manage -get mylogger Logger = Nomserveur03
- Edition des traces
Pour ce qui est de la description du retour de la commande oclumon dumpnodeview nous en avons vu un exemple plus haut . en voici donc un descriptif rapide :
oclumon dumpnodeview -allnodes -s "2015-01-18 00:00:00" -e "2015-01-19 15:10:00" -i 15
-allnodes ou -n liste,des,nœuds
-s date heure de debut
-e date heure de fin
-i intervalle en secondes entre 2 mesures , doit être un multiple de 5 .
Si -s et -e ne sont pas demander, on a un affichage en direct des données collectées. Pour interrompre l’affichage [CTRL] + [C].
Pour ce qui est du descriptif des données retournées, je vous renvoie à la doc en ligne
http://docs.oracle.com/database/121/CWADD/troubleshoot.htm#CWADD92247
- Dernière commande intéressante diagcollection.pl –collect
Celle-ci permet en cas de problème sur un cluster, de faire l’acquisition de l’ensemble des données nécessaires à un diagnostique par les équipes d’oracle.
Lancée sous root , après avoir positionné l’environnement grid, elle permet de générer des fichier Tar compressés dans le répertoire courant.
diagcollection.pl --collect Production Copyright 2004, 2010, Oracle. All rights reserved Cluster Ready Services (CRS) diagnostic collection tool ORACLE_BASE is /u01/app/oracle/grid The following CRS diagnostic archives will be created in the local directory. crsData_Monserveur _20150121_1539.tar.gz -> logs,traces and cores from CRS home. Note: core files will be packaged only with the --core option. baseData_Monserveur _20150121_1539.tar.gz -> logs,traces and cores from Oracle Base. Note: core files will be packaged only with the --core option. ocrData_Monserveur _20150121_1539.tar.gz -> ocrdump, ocrcheck etc coreData_Monserveur _20150121_1539.tar.gz -> contents of CRS core files in text format osData_Monserveur _20150121_1539.tar.gz -> logs from Operating System lsInventory_Monserveur _20150121_1539 ->Opatch lsinventory details Collecting crs data Collecting Oracle base data Collecting OCR data Collecting information from core files No corefiles found Collecting lsinventory details The following diagnostic archives will be created in the local directory. acfsData_Monserveur _20150121_1539.tar.gz -> logs from acfs log. Collecting acfs data Collecting OS logs Collecting sysconfig data
Oracle préconise de lancer cette commande sur l’ensemble des nœuds du cluster.
Liste des fichiers générés est la suivante
crsData_Monserveur_20150121_1539.tar.gz baseData_Monserveur _20150121_1539.tar.gz ocrData_Monserveur _20150121_1539.tar.gz lsInventory_Monserveur _20150121_1539 acfsData_Monserveur _20150121_1539.tar.gz osData_Monserveur _20150121_1539.tar.gz sysconfig_Monserveur _20150121_1539.txt
Lorsque acsf n’est pas utilisé, le message suivant apparaît :
acfsutil log: CLSU-00100: operating system function: open64 failed with error data: 2 acfsutil log: CLSU-00101: operating system error message: No such file or directory acfsutil log: CLSU-00103: error location: OOF_1 acfsutil log: CLSU-00104: additional error information: open64 (/dev/ofsctl) acfsutil log: ACFS-00502: Failed to communicate with the ACFS driver. Verify the ACFS driver has been loaded.
Voila, je pense avoir fait le tour de la question. En espérant vous avoir été utile.
