Erreur de connexion à la base de données sous Microsoft Windows

La majeure partie du temps, je travaille sur les plate-formes Unix et Linux et, dernièrement, j'ai eu à installer et configurer une nouvelle base de données sous Oracle Fail Safe sous Microsoft Windows.

L'installation s'est très bien déroulé. Lorsque rendu à l'étape d'ajouter la base de données au groupe de ressources du cluster, nous avions rencontré des erreurs qui mentionnaient qu'il était incapable de se connecter à la base de données. Afin de diagnostiquer le problème, j'ai alors démarré un invite de commandes puis démarré SQL*Plus. J'étais aucunement capable de me connecter à celle-ci, que se soit avec "/ as sysdba" ou avec une chaîne de connexion.

Avec "/ as sysdba", j'obtenais l'erreur "ORA-12560:TNS:protocol adapter error" tandis que lorsque je mentionnais une chaîne de connexion définie dans le "tnsnames.ora", je recevais l'erreur "ORA-12518 Tns: Listener could not hand off client connection".

Après avoir vérifié le statut du "listener", la configuration dans les fichiers listener.ora, tnsnames.ora, sqlnet.ora, etc.. j'ai alors pensé que, dans le merveilleux monde de Windows, il y a des services pour la base de données Oracle... En ouvrant le gestionnaire de services, j'ai remarqué aussitôt que le service "OracleInstanceORCL" n'était pas démarré. Je l'ai tout simplement démarré puis j'ai été en mesure de me connecter avec SQL*Plus des deux façons mentionnées précédemment.

L'envergure du problème n'est pas toujours proportionnel aux efforts déployés à le résoudre.

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é.

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.

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');