Similarité entre Oracle et PostgreSQL

PostgreSQL et Oracle ont des architectures qui se ressemblent. Tous les deux offrent des fonctionnalités similaires tel que le partitionnement, les vues matérialisées, le parallélisme, des mécanismes de réplications qui se nomment "Data Guard" chez Oracle et "Streaming Replication" et "Hot Standby" du côté de ProgreSQL. À noter qu'il n'y a pas d'équivalent d'Oracle RAC dans le monde de PostgreSQL.

Pour les sauvegardes et le recouvrement, il existe un outil de sauvegarde et de récupération qui se nomme "Barman". N'ayez crainte, ça n'a rien à voir avec les établissements où l'on consomme de l'alcool, Barman est plutôt l'acronyme pour "Backup And Recovery MANager".

Pour en connaitre davantage : https://lnkd.in/dKmWeH3

Voting Disk corrompu et... aucune sauvegarde!

Suite à un "downgrade" du clusterware 11gR2 à la version 10gR2 (10.2.0.4), nous n'avons pas réussi à redémarrer le CRS correctement. Après quelques investigations dans les différents fichiers de trace (.log), j'ai alors remarqué le message suivant dans le fichier "cssd.log"

ERROR:   clssnmvReadFatal: voting device corrupt (0x00000000/0x00000000/0//dev/vd1_sys_1g)

Pour remédier à ce problème, nous avons du recréer le "voting disk" car nous n'avions aucune sauvegarde à notre disposition ni de mirroring... chose à ne pas faire.

Voici les étapes effectuées. Ceci a été effectué sur une plate-forme AIX dont les produits Oracle étaient de la version 10gR2 (10.2.0.4)

• Arrêt complet du clusterware

Dans notre cas, la commande "crsctl stop crs" ne fonctionnait pas alors nous avons désactivé le démarrage automatique (init.crs disable) puis redémarrer chacun des noeuds.

• Ajout d'un nouveau raw device

L'administrateur de système nous a alloué un nouveau disque d'une capacité d'un gigaoctet.

• Afficher le voting disk actuel

#crsctl query css votedisk

Cette commande nous a retourné le nom complet du voting disk (ex. /dev/vd1_sys_1g)

• Ajouter un voting disk en précisant l'emplacement exact

# crsctl add css votedisk [/chemin/nom] -force

Ex. # crsctl add css votedisk /dev/vd1_sys_2g -force

• Détruire le voting disk corrompu en spécifiant le chemin complet

# crsctl delete css votedisk [/chemin/nom] -force

Ex. # crsctl delete css votedisk /dev/vd1_sys_1g -force

• Redémarrer le cluster

# crsctl start crs

• Vérifier le nouveau voting disk

# crsctl query css votedisk

Suite à toutes ces étapes, nous nous sommes empressé de recommander la mise en place d'une sauvegarde du voting disk dans la procédure de sauvegarde existante et, de créer au minimum un second voting disk.

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

Modifier l'information réseau contenu dans l'OCR

Si vous obtenez les messages :

PRVG-1513 : Failed to retrieve current selection of public and private network classifications for node
PRVG-11050 : No matching interfaces "" for subnet "" on nodes "racnode1"

Il est fort possible que l'information contenu dans l'OCR ne soit pas correcte. Pour remédier à cela, vous devrez procéder comme suit pour vérifier les interfaces définis dans l'OCR puis de la redéfinir selon votre cas.

voici un exemple :

• Afficher les interfaces présents sur le noeud

$ oifcfg iflist -p -n
en3  10.2.2.0  UNKNOWN  255.255.255.0
en0  10.25.9.0  PRIVATE  255.255.255.0

• Afficher les interfaces définis par la commande "setif"

$ oifcfg getif
en0  10.25.9.0  global  public
en3  10.2.1.0  global  cluster_interconnect

En comparant les adresses IP des interfaces, on remarque qu'un d'elle est incorrecte (10.2.1.0). On doit supprimé cette entrée pour la réinsérer avec la bonne adresse IP (10.2.2.0) :

$ oifcfg delif -global en3

$ oifcfg setif -global en3/10.2.2.0:cluster_interconnect

L'interface de configuration "OIFCFG" permet de définir et de gérer les interfaces réseau. Il permet d'allouer et libérer les interfaces réseaux,d'utiliser des interfaces réseau spécifiques et obtenir des informations de configuration des composant.De plus, vous pouvez utiliser "OIFCFG" sur une instance unique et des environnements impliquant Oracle Clusterware.

Configuration des interfaces de l'interconnect

Lors de la vérification de la configuration d'un cluster existant de la version 10gR2 (runcluvfy.sh) en prévision de le mettre à niveau à la version 11gR2 (11.2.0.3), nous avions reçu le message suivant :

WARNING:
Could not find a suitable set of interfaces for the private interconnect
Checking subnet mask consistency...
Subnet mask consistency check passed for subnet "10.2.190.0".
PRVG-11055 : Interfaces configured with subnet number "192.168.2.0" have multiple subnets masks
PRVG-11056 : subnet masks "255.255.255.0" are configured with subnet number "192.168.2.0" on nodes "qaora05t"
PRVG-11056 : subnet masks "255.255.255.224" are configured with subnet number "192.168.2.0" on nodes "qaora06t"
Subnet mask consistency check failed.

Result: Node connectivity check failed

Nous avons dû modifier le "netmask" au niveau du serveur "srvbd02" pour qu'il soit identique sur les 2  noeuds (serveurs) du cluster, voici les étapes réalisées :

$oifcfg iflist -p -n
en2  10.2.190.0  PRIVATE  255.255.255.0
en4  192.168.2.0  PRIVATE  255.255.255.0

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xfffffe00 broadcast 192.168.2.31
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Le "netmask" qui est égale à "0xffffffe0" doit être modifié pour être "0xffffff00" :

#chdev -l en4 -a netaddr=192.168.2.14 -a netmask=0xffffff00

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xffffff00 broadcast 192.168.2.255
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Suite à ce changement, le « cluster verify » à passer sans erreur.


Ce cluster était sur une plateforme IBM AIX 5.3 64bits.

Un merci tout spécial à mon collègue Nabil Ben Tekaya. Grâce à ses yeux de lynx, il a remarqué la différence au niveau des masques réseau.

Recompilation de packages PL/SQL sous Oracle RAC 11gR2

Suite à la mise en place d'une nouvelle version d'un package PL/SQL, certaines applications obtenaient l'erreur suivante :

ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04065: not executed, altered or dropped stored procedure "ABC.PKG_CALC_PAMNT"
ORA-06508: PL/SQL: could not find program unit being called: "ABC.PKG_CALC_PAMNT"
ORA-06512: at "ABC.PKG_FACTRN", line 4

Habituellement, cette erreur disparait dès le prochain accès au package. C'est le cas pour la session active sauf que, lorsqu'il y avait une nouvelle connexion avec le même compte Oracle, l'erreur réapparaissait.

Étrangement, cette erreur ne se produisait pas pour certaines applications... pourquoi? Et bien, c'est surement parce que nous utilisons les services Oracle pour la répartition de la charge sur les différents noeuds hébergeant les instances du Cluster RAC 11gR2. Compte tenu que cette erreur était, disons-le, absurde, j'ai commencé à douter de la "fraîcheur" des caches en mémoire. Après quelques essais, je me suis rendu compte que le problème survenait sur une instance et non sur les autres. J'ai alors décidé de forcer une réinitialisation du "shared pool" pour que la nouvelle définition de l'objet y soit stockée. Pour ce faire, j'ai exécuté la commande : "Alter system flush shared_pool;" et, effectivement, l'erreur n'a par réapparu.

Comportement des statistiques systèmes en mode RAC

Lors de la collecte des statistiques systèmes d'un environnement RAC, on peut déclencher la collecte à partir de n'importe quelle instance. Tout s'effectue correctement... À vrai dire, pas exactement car les autres instances attachées au cluster ne prennent pas en compte les nouvelles valeurs.

Je me suis aperçu de ce problème quand une requête est devenue gourmande. Le plan d'exécution de la requête était complètement différent sur 2 instances. En me connectant sur l'une des instances du cluster, j'ai vérifié les valeurs des statistiques (select * from sys.aux_stats$). C'est à ce moment que j'ai remarqué qu'elles avaient été régénérées récemment et l'un de mes collègues me l'a confirmé. J'ai aussi eu la confirmation que la lenteur avait été observée depuis la date de la régénération des statistiques. Donc, je pouvais déduire que la collecte de statistiques systèmes était l'élément déclencheur.

Que se soit sur l'une ou l'autre des instances du cluster, les mêmes statistiques sont supposées être utilisées dont je suspecte que le problème soit au niveau de la mémoire ou d'une certaine cache. J'ai tenté une simple purge du "shared pool" et celle des données mais sans succès. Comme à l'habitude, j'ai fait une petite recherche sur Metalink et effectivement, il y a un problème de répertorier sur la base de données 10.2.0.3. (ID 7645777.8) concernant un plan d'exécution différent sur des instances RAC. La solution : Recycle the instances... Qu'est-ce que cela veut dire exactement ?!? J'imagine que c'est l'équivalent d'un redémarrage d'instance et, si c'est le cas, et bien, je ne peux pas me le permettre. Vu que ce bug concerne les statistiques systèmes alors, j'ai décidé de pousser la vérification en influençant l'optimisateur pour qu'il n'utilise pas les statistiques liées au CPU. Pour ce faire, j'ai utilisé le hint "NO_CPU_COSTING". Les résultats furent concluants, j'ai obtenu le même plan d'exécution que sur l'instance où la requête est optimale.

Tant qu'à pousser, j'ai décidé d'effectuer une trace de l'optimisateur sur l'exécution de la requête sur chacune des instances avec la commande :

ALTER SESSION SET EVENTS '10053 trace name context forever, level 1'

Les 2 fichiers de trace ont démontrés que les statistiques systèmes sont différentes donc ça confirme que l'optimisateur n'utilise pas les mêmes valeurs d'une instance à l'autre... Inquiétant ?

Après réflexion, je me suis dit, pourquoi ne pas répéter ou presque les mêmes étapes de collecte de statistiques systèmes mais cette fois-ci, en étant connecté sur l'instance n'ayant pas le même comportement ou si vous préférez, le même plan d'exécution. Alors, j'ai effectué ceci :

-- Établir une connexion sur l'instance qui n'utilise pas les nouvelles valeurs
connect sys@inst1 as sysdba

-- Prendre une copie des statistiques actuelles
Drop table stats_bkp;
EXECUTE DBMS_STATS.CREATE_STAT_TABLE ('SYS','stats_bkp','SYSAUX');
EXECUTE DBMS_STATS.EXPORT_SYSTEM_STATS (stattab => 'stats_bkp', statid => 'stats_bkp', statown => 'SYS');
select * from sys.stats_bkp;

-- Charger les valeurs
execute DBMS_STATS.DELETE_SYSTEM_STATS;
EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS (stattab => 'stats_bkp', statid => 'stats_bkp', statown => 'SYS');
select * from sys.aux_stats$;

-- Initialiser les espaces mémoires
Alter system flush shared_pool;
Alter system flush buffer_cache;

Et bien oui, ça fonctionne! La requête a maintenant le même plan d'exécution que sur l'autre instance. Stop! Le problème s'est déplacé sur l'autre instance... oups! Ok, alors, je vais refaire la même chose, mais cette fois-ci sur l'instance où le problème s'est déplacé. Suite à l'exécution des commandes précédentes, le plan d'exécution est redevenu celui d'auparavant et, sans impacter le plan d'exécution sur l'autre instance.

Je crois qu'un redémarrage de l'instance aurait pu régler le problème sauf que lorsque nous sommes sur un environnement de production, cela n'est pas toujours une solution et ce, même si c'est un environnement RAC à moins que vous preniez le temps de déplacer tous les services vers une autre instance puis que vous patientez jusqu'à ce que toutes les sessions se soient reconnectés vers la nouvelle instance.

Oracle Clusterware 11gR2

Oracle Clusterware est la composante majeure d’Oracle Grid Infrastructure et constitue la base d’Oracle Real Application Cluster (RAC). Oracle Clusterware permet de former un groupe de serveurs et de les faire fonctionner comme un seul système. Il permet de gérer l’ensemble des ressources, des processus et des applications du cluster tout en gérant et assurant la stabilité des nœuds.

Oracle Clusterware est composé principalement de deux éléments : le « voting disk » et l'OCR (Oracle Cluster Registry). Le « voting disk » est tout simplement un fichier qui contient et gère les informations de tous les nœuds liés au cluster et, l'OCR est un fichier qui gère le cluster et configuration RAC.

Depuis la version 11g Release 2, les fichiers de l’OCR et des voting disks peuvent maintenant être stockés dans ASM. D’ailleurs, cette façon de faire est conseillée par Oracle.
Dans les versions antérieures, la sauvegarde des « voting disks » en utilisant la commande « dd » était une tâche nécessaire suite à l’installation. Avec Oracle Clusterware 11gR2, la sauvegarde et la restauration d'un « voting disk » en utilisant la commande « dd » n'est plus supportée ni requise car ils sont sauvegardés automatiquement dans l’Oracle Cluster Registry (OCR) dès qu’un changement de configuration se produit. De plus, les données d’un « voting disks » sont automatiquement restaurées et appliquées sur un disque nouvellement ajouté.

Nouveautés intéressantes avec Clusterware 11gR2

Server Pool

• Division logique du cluster en pools de serveurs.
• Regroupement de serveurs ayant une charge similaire
• Gérer avec les outils crsctl (applications) et srvctl (Oracle)
• Définit par 3 principaux attributs (min, max, importance) ou une liste prédéfinie des nœuds
• Utilisation de règles (policies) pour contrôler l’utilisation du pool

Single Client Access Name (SCAN)

• Utilisé par les clients pour établir une connexion à n’importe quelle base de données du cluster
• Aucun changement nécessaire à la configuration de connexion d’un client advenant un changement au cluster
• Balancement de la charge parmi les instances desservit par un service
• Transparence lors d’un déplacement d’instance (failover)
• Permet aux clients d’utiliser une connexion de type « EZConnect » ou JDBC simple

Grid Plug and Play (GPnP)

• Simplifie l’ajout, le remplacement, et la suppression d’un noeud du cluster
• Permettre au cluster de gérer ses propres adresses IP virtuelles (Grid Naming Service)

Oracle Grid Infrastructure 11gR2

À partir d’Oracle 11g Release 2, Oracle Clusterware combiné à Oracle Automatic Storage Management (ASM) est devenu Oracle Grid Infrastructure.

Oracle Grid Infrastructure peut être déployé autant pour un environnement à multiples instances que simple instance (stand alone).

Pour les bases de données à simple instance, Oracle Grid Infrastructure permet de mettre en place une infrastructure légère de haute disponibilité. Cette option inclut deux composantes : Oracle Restart et Oracle ASM.

Pour les bases de données à multiple instance (RAC), Oracle Grid Infrastructure permet de mettre en place une réelle infrastructure de haute disponibilité regroupant plusieurs serveurs. Cette option inclut deux composantes : Oracle Clusterware et Oracle ASM.

Voyage dans le... passé

La mise à niveau d'une base de données Oracle nous force à se questionner sur la possibilité d'un retour arrière. En effet, malgré que nous prenions toutes les précautions possibles et que
nous testions les applications, un problème important peut surgir et nous forcer à réaliser un retour arrière vers les versions de bases de données originales.

Le retour arrière n'est jamais l'idéal sauf qu'il vaut mieux prévoir une méthode afin de minimiser les impacts et les problèmes. C'est à ce moment que la fonctionnalité "FLASHBACK DATABASE" attire mon attention.

Flashback Database permet de ramener la base de données entière à un état dans le passé. Elle utilise des journaux (Flashback log) et, quand elle est activée, ces journaux sont créés à l'emplacement nommé « flash recovery area ». Oracle s'occupe de créer, détruire et redimensionner les journaux automatiquement. À l'occasion, il faut vérifier l'espace qui est disponible pour le flashback area.

Pour utiliser le « flashback database », le « flash recovery area » doit être mis en place.

Voici quelques prés requis :

ACTIVATION DES FONCTIONNALITÉS
Pour utiliser la fonctionnalité « FLASHBACK DATABASE », Le mode d'archive et la fonctionnalité « flashback database » doit être activé sur la base de données.

Voici comment vérifier l'état des fonctionnalités :

SELECT flashback_on, log_mode
FROM v$database;

Vérifier la valeur des paramètres lies à la fonctionnalité « flashback
database » :

col name format A30 wrap
col value format A20 wrap
SELECT inst.instance_name, parm.name, parm.value
FROM gv$parameter parm, gv$instance inst
WHERE parm.inst_id = inst.inst_id
and (name LIKE '%flashback%'or name LIKE '%recovery%')
order by 1,2;

Initialiser les paramètres pour le « Flashback » :

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+FRAGRP01' SCOPE= BOTH;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G SCOPE=BOTH;

Fermer l'instance :

Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer
toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount »

startup mount exclusive;

Activer le mode ARCHIVE (si nécessaire)

Alter database archivelog;

Activer la fonctionnalité « FLASHBACK DATABASE »

Alter database flashback on;

CRÉATION DU POINT DE RESTAURATION
Un point de restauration doit être marqué dans le temps pour être en mesure de le référer dans l'éventualité où nous en aurions besoin. Ce point de restauration doit être créé avant la migration de la base de données.

Voici comment procéder pour créer le point de restauration :

Fermer l'instance :

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Créer le point de restauration :

CREATE RESTORE POINT avant_upgrade GUARANTEE FLASHBACK DATABASE;

Vérifier l'existence de point de restauration créé précédemment :

SELECT NAME, SCN, TIME,
DATABASE_INCARNATION# DI,
GUARANTEE_FLASHBACK_DATABASE,
STORAGE_SIZE FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

Fermer l'instance :

shutdown immediate

À partir de ce point, la migration peut débuter.

PARTICULARITÉS
Il ne faut pas modifier la valeur du paramètre « COMPATIBLE ». Autrement, le mécanisme de retour arrière peut ne pas fonctionner adéquatement. Le changement de valeur va identifier tous les fichiers de la base de données comme étant des fichiers de la nouvelle version et, vous
observerez une erreur semblable lors du démarrage de l'instance :

ORA-00201: control file version 10.2.0.4.0 incompatible with ORACLE version
10.2.0.3.0
ORA-00202: control file: '+FRAGRP01/orcl/controlfile/current.263.660837815'

RESTAURATION
Si vous devez ramener votre base de données à l'état où elle était avant la migration, il vous suffit de suivre ces étapes :

Fermer l'instance:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount

Restaurer la base de données au point de restauration :

Flashback database to restore point avant_upgrade;

Fermer l'instance :

shutdown immediate

N'oubliez pas de réinitialiser toutes les variables d'environnement incluant ceux des autres noeuds si vous êtes sur un environnement RAC.

Après avoir réinitialisé les variables d'environnements, il faut :

Démarrer l'instance:

startup mount

Ouvrir la base de données en initialisant les journaux :

Alter database open resetlogs;

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

N'oubliez pas de reprendre une copie de sauvegarde de la base de données.

DÉSACTIVATION DE LA FONCTIONNALITÉ
Pour désactiver la fonctionnalité « FLASHBACK DATABASE », voici les étapes à
suivre :

Voici comment le vérifier :

SELECT flashback_on FROM v$database;

Fermer l'instance :
Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Désactiver la fonctionnalité « FLASHBACK DATABASE » :

Alter database flashback off;

Cette solution de retour en arrière s'applique seulement dans le cas où la migration ne s'effectue pas correctement. Toutes les transactions suivant la migration, incluant celles provenant des applications maisons, seront perdues si un retour en arrière est effectué.

Probleme de notification : Tablespace Space Used % sur instance RAC

Depuis quelque temps, je soupçonnais des problèmes de notification avec les instances RAC définies dans Oracle EM Grid Control.

Je me suis alors bâtit un cas d'essai. J'ai créé un tablespace contenant une seule table. Celle-ci a été remplie jusqu'au bouchon en m'aidant de la vue DBA_OBJECTS. (Insert into ... Select * from dba_objects)

La requête ci-dessous permet d'afficher les alertes que la base de données a rencontrées :

SELECT REASON
, METRIC_VALUE
, MESSAGE_TYPE
, TO_CHAR(CREATION_TIME,'DD-MON-YYYY HH24:MI:SS')
, HOST_ID
FROM SYS.DBA_OUTSTANDING_ALERTS;

J'y ai alors trouvé une alerte à propos du tablespace créé pour mon cas d'essai :

REASON
-------------------------------------------------------
METRIC_VALUE MESSAGE_TYPE TO_CHAR(CREATION_TIM HOST_ID
------------ ------------ -------------------- --------
Tablespace [TEST_OEM_EC] is [90 percent] full
90 Warning 28-FEB-2009 20:48:04 MOMSVR


Étrange! l'alerte est inscrite dans la base de données mais elle n'est pas envoyé vers Enterprise Manager ?!?

J'ai décidé de vérifier si l'agent était ble et bien enregistrer à la base de données ORCL :

select agent_name from SYSTEM.AQ$_INTERNET_AGENTS order by agent_name;

Cette requête doit retourner au minimum un enregistrement qui contient un nom d'agent dont le nom est constitué du nom de l'hôte, du port et du SID de la base de données.

Ex : MOMSRV_1830_ORCL1

Ce n'était pas mon cas... La requête m'a affiché un autre agent avec un port différent. En fait, c'était un ancien agent qui fut déjà installé auparavant.

J'ai finalement trouvé de l'information à propos d'un bug à ce sujet et Oracle recommande de faire ce qui suit et ce, même si la configuration est déjà présente dans Oracle EM Grid Control.

Dans la console EM :

1. Cliquer sur le "cluster" en question
2. Au bas de la page, cliquer sur le lien intitulé "Monitoring Configuration"
3. Parcourir les étapes de configuration même si elles ont déjà été faites

Sur chacun des noeuds :

$ emctl stop agent
$ emctl start agent
$ emctl clearstate agent

J'ai refait mon test de notification et tout à fonctionné correctement.

Pour terminer en beauté, j'ai décidé de supprimer l'ancien agent inscrit. Pour ce faire, j'ai exécuté la commande suivante :

exec dbms_aqadm.DROP_AQ_AGENT('MOMSRV_3872_ORCL1');

Reconfiguration d'un Management Agent pour OMS (Grid)

Pour que l'Agent communique correctement avec Oracle Management Service, j'ai dû reconfigurer complètement l'agent et toutes les composantes du Grid propre à cet hôte.

1. Arrêter l'agent

cd $ORACLE_HOME
emctl stop agent

2. Supprimer toutes les composantes liés à l'hôte dont l'agent y est installé.

Sous SQL*Plus, se connecter avec SYSMAN au référentiel de l'OMS pour supprimer complètement l'agent

exec mgmt_admin.cleanup_agent('NomAgent:NoPort');

3. Nettoyer les répertoires de l'agent

cd $ORACLE_HOME/sysman/emd
/usr/bin/rm -rf agntstmp.txt lastupld.xml recv/* collection/* upload/* state/*

cd $ORACLE_HOME/hôte/sysman/emd
/usr/bin/rm -rf agntstmp.txt lastupld.xml recv/* collection/* upload/* state/*

La commande "emctl clearstate agent" peut aussi être utilisé pour faire le ménage cependant, je ne crois pas qu'elle soit aussi efficace que la commande "rm -rf".

4. Configurer l'agent sur l'hôte

Dans mon cas, c'est un agent installé sur un cluster RAC à 3 noeuds

agentca -f -n nom_cluster -c "hôte1,hôte2,hôte3"

4. Sécuriser la communication entre l'Agent et OMS

emctl secure agent

5. Charger les informations dans OMS

emctl upload

Et, pour terminer. il suffit de naviguer dans la console Oracle EM Grid Control et de configurer les cibles découvertes :

- Se connecter à la console
- Cliquer sur "Setup", "Agents"
- Choisir un agent en particulier puis cliquer sur le bouton configurer

Exécution préautorisée (SSH) entre noeud d'un cluster RAC

Aujourd’hui, j‘ai rencontré l’erreur ci-dessous en tentant de déployer un correctif de Management Agent pour Oracle EM Grid Control :

Error PRKC 1044- failed to check remote command execution setup for node… using shells /usr/bin/ssh and /usr/bin/rsh
: Connection Refused

Cette erreur est occasionnée par le fait que les serveurs ne peuvent pas communiquer ensemble avec l’utilitaire SSH sans être obligé de saisir un mot de passe.

Pour remédier à ce problème, il faut configurer SSH entre les nœuds d’un cluster. Voici comment faire :

En supposant que les nœuds du cluster s’appellent RAC1, RAC2 et RAC3.

Il faut se connecter avec le compte Unix que vous utiliser pour installer les logiciels Oracle et effectuer ce qui suit sur chaque nœud du cluster:

cd $HOME
mkdir ~/.ssh
chmod 700 ~/.ssh
/usr/bin/ssh-keygen -t rsa
/usr/bin/ssh-keygen -t dsa

Ensuite, sur chacun des nœuds, il faut ajouter les identifiants, générés par l’étape précédente, au fichier « authorized_keys » puis le copier afin que chacun des nœuds en possède une copie :

Nœud : RAC1

cd $HOME/.ssh
cat id_rsa.pub >> authorized_keys
cat id_dsa.pub >> authorized_keys
scp authorized_keys rac2:/u01/home/dba/oracle/.ssh

Nœud : RAC2

cd $HOME/.ssh
cat id_rsa.pub >> authorized_keys
cat id_dsa.pub >> authorized_keys
scp authorized_keys rac3:/u01/home/dba/oracle/.ssh

Nœud : RAC3

cd $HOME/.ssh
cat id_rsa.pub >> authorized_keys
cat id_dsa.pub >> authorized_keys
scp authorized_keys rac1:/u01/home/dba/oracle/.ssh
scp authorized_keys rac2:/u01/home/dba/oracle/.ssh


Pour vérifier le fonctionnement du SSH sans que celui-ci demande la saisie d’un mot de passe, établissez une connexion entre chacun des nœuds, par exemple, à partir du noeud RAC1, effectuez la commande suivante :

$ ssh rac2 date

Cette commande doit retourner la date sans demander de saisir un mot de passe.

Que des problèmes avec ces cibles

Dernièrement, j'ai détruit, de peine et de misère, toutes les cibles (targets) liés à trois noeuds d'un cluster RAC dans Oracle EM Grid Control.

Lors de la découvert des cibles, je recevais une erreur à propos d'une violation de contrainte unique :

ORCL.WORLD: Saving ORCL.WORLD_ORCL1 ...java.sql.SQLException:
ORA-00001: unique constraint (SYSMAN.MGMT_TARGET_PROPERTIES_PK) violated
ORA-06512: at "SYSMAN.EM_TARGET", line 1918
ORA-06512: at "SYSMAN.MGMT_TARGET", line 2705
ORA-06512: at line 1 -

La solution qui m'a permit de sortir de cette impasse fut la note "728650.1" sur Oracle Metalink.

Voici les étapes à suivre :

1. Connect to repository database as sysman user and execute:
CREATE TABLE mgmt_tgt_prop_bug6884963 AS
SELECT * FROM mgmt_target_properties WHERE
TARGET_GUID not in (select target_guid from mgmt_targets) AND
TARGET_GUID not in (select target_guid from mgmt_targets_delete);

Verify that this table has been created properly by checking the numberof rows in this table and compare it with this query:

SELECT * FROM mgmt_target_properties
WHERE TARGET_GUID not in
(select target_guid from mgmt_targets)
AND TARGET_GUID not in
(select target_guid from mgmt_targets_delete);

2. Now remove these rows from mgmt_target_properties:

DELETE FROM mgmt_target_properties WHERE
TARGET_GUID not in (select target_guid from mgmt_targets) AND
TARGET_GUID not in (select target_guid from mgmt_targets_delete);

commit;

Où est le listener ?

J’utilise Oracle Enterprise Manager Grid Control 10g pour la gestion de toutes les composantes Oracles. À ma grande surprise, j’ai remarqué que les programmes d’écoute (listeners) n’étaient pas ajoutés dans les cibles (target) de chaque hôte.

Je me suis alors penché sur ce problème. J’ai essayé l’assistant de configuration d’agent « agentca » avec l’option « -d » pour forcer une redécouverte des composantes sur l’hôte.

Bingo! Ça l’a fonctionné ! En plus de découvrir mes programmes d’écoute, des composantes du répertoire OID (LDAP) présent sur cet hôte ont été ajoutées.

Voici les options pouvant être utilisées :

-n Spécifier le nom du cluster (CLUSTER_NAME)
-c Spécifier la liste des nœuds d’un cluster
-t Ne pas redémarrer l’agent après une reconfiguration ou une redécouverte
-d Redécouvrir les cibles sur l’hôte
-f Reconfigurer l’agent
-i Spécifier l’emplacement du fichier « oraInst.loc »
-h Afficher l’aide sur les options disponibles