Pendant une migration vers le grid infrastructure 11.2.0.1 (clusterware et ASM), il est utile de savoir où sont les fichiers logs générés pour mieux investiguer en cas de problème.
1- Le premier des logs à observer est celui généré dans le répertoire log de «l'inventory», dépendamment de votre environnement $ORACLE_BASE/oraInventory/logs.
oracle@ucl02b:/u01/home/dba/oracle/oraInventory/logs> ls -alrt
...
-rw-rw---- 1 oracle dba 996622 Jun 4 20:52 installActions2010-06-04_06-11-37PM.log
...
oracle@ucl02b:/u01/home/dba/oracle/oraInventory/logs>
Ce fichier contiendra toutes les informations pendant la phase d'installation des binaires et de copie vers les autres noeuds du cluster.
2- Le deuxième emplacement à observer est le répertoire «$GRID_HOME/cfgtoollogs»
Pendant la phase d'exécution du script «rootupgrade.sh», les logs sont générés dans le répertoire «$GRID_HOME/cfgtoollogs/crsconfig» .
Pendant la phase de configuration des composants (Netca, ASM, etc), les logs sont générés dans le répertoire «$GRID_HOME/cfgtoollogs/cfgfw».
Exemple:
Contenu du répertoire «cfgtoollogs»:
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs> ls -al
total 66
drwx------ 6 oracle dba 1536 Jun 5 08:24 .
drwxr-xr-x 63 root dba 1536 Jun 4 18:36 ..
drwx------ 2 oracle dba 1536 Jun 4 20:51 cfgfw
-rw------- 1 oracle dba 5516 Jun 4 20:51 CfmLogger_2010-06-04_08-08-48-PM.log
-rw------- 1 oracle dba 5516 Jun 4 20:51 CfmLogger_2010-06-04_08-08-49-PM.log
-rwx------ 1 oracle dba 212 Jun 4 20:08 configToolAllCommands
-rwx------ 1 oracle dba 0 Jun 4 20:08 configToolAllCommands.bak
-rwx------ 1 oracle dba 213 Jun 4 20:51 configToolFailedCommands
-rwx------ 1 oracle dba 0 Jun 4 20:51 configToolFailedCommands.bak
drwxrwxr-x 2 oracle dba 512 Jun 4 18:36 crsconfig
drwxr-xr-x 3 oracle dba 512 Jun 5 08:24 opatch
-rw------- 1 oracle dba 1653 Jun 4 20:46 oracle.assistants.asm_2010-06-04_08-08-48-PM.log
-rw------- 1 oracle dba 1653 Jun 4 20:46 oracle.assistants.asm_2010-06-04_08-08-49-PM.log
-rw------- 1 oracle dba 557 Jun 4 20:09 oracle.assistants.netca.client_2010-06-04_08-08-48-PM.log
-rw------- 1 oracle dba 557 Jun 4 20:09 oracle.assistants.netca.client_2010-06-04_08-08-49-PM.log
-rw------- 1 oracle dba 1125 Jun 4 20:51 oracle.crs_2010-06-04_08-08-48-PM.log
-rw------- 1 oracle dba 1125 Jun 4 20:51 oracle.crs_2010-06-04_08-08-49-PM.log
drwxrwx--- 2 oracle dba 1024 Jun 4 20:52 oui
-rw------- 1 oracle dba 0 Jun 4 20:08 OuiConfigVariables_2010-06-04_08-08-47-PM.log
-rw------- 1 oracle dba 0 Jun 4 20:08 OuiConfigVariables_2010-06-04_08-08-48-PM.log
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs>
Contenu du répertoire «crsconfig»:
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs/crsconfig> ls -al
total 104
drwxrwxr-x 2 oracle dba 512 Jun 4 18:36 .
drwx------ 6 oracle dba 1536 Jun 5 08:24 ..
-rwxrwxr-x 1 oracle dba 49434 Jun 4 18:43 rootcrs_ucl02b.log
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs/crsconfig>
Contenu du répertoire «cfgfw»:
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs/cfgfw> ls -al
total 58
drwx------ 2 oracle dba 1536 Jun 4 20:51 .
drwx------ 6 oracle dba 1536 Jun 5 08:24 ..
-rw------- 1 oracle dba 7932 Jun 4 20:51 CfmLogger_2010-06-04_06-28-16-PM.log
-rw------- 1 oracle dba 6668 Jun 4 20:51 CfmLogger_2010-06-04_08-08-46-PM.log
-rw------- 1 oracle dba 1653 Jun 4 20:46 oracle.assistants.asm_2010-06-04_06-28-18-PM.log
-rw------- 1 oracle dba 1653 Jun 4 20:46 oracle.assistants.asm_2010-06-04_08-08-47-PM.log
-rw------- 1 oracle dba 557 Jun 4 20:09 oracle.assistants.netca.client_2010-06-04_06-28-17-PM.log
-rw------- 1 oracle dba 557 Jun 4 20:09 oracle.assistants.netca.client_2010-06-04_08-08-47-PM.log
-rw------- 1 oracle dba 1125 Jun 4 20:51 oracle.crs_2010-06-04_06-28-17-PM.log
-rw------- 1 oracle dba 1125 Jun 4 20:51 oracle.crs_2010-06-04_08-08-46-PM.log
-rw------- 1 oracle dba 0 Jun 4 18:28 OuiConfigVariables_2010-06-04_06-28-17-PM.log
-rw------- 1 oracle dba 0 Jun 4 20:08 OuiConfigVariables_2010-06-04_08-08-47-PM.log
oracle@ucl02b:/u02/home/dba/oracle/product/grid11gr2/cfgtoollogs/cfgfw>
vendredi 25 juin 2010
mardi 22 juin 2010
Raccourci pour rappeler la dernière connexion SQL
Pour rappeler la dernière connexion SQL au niveau du prompt unix, l'on peut utiliser le raccourci «!sql».
Exemple:
oracle@juliet:/u01/home/dba/oracle> !sql
sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mar. Juin 22 14:44:33 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,Data Mining, Oracle Database Vault and Real Application Testing options
SQL>
Note:
«sqlplus / as sysdba» était la dernière connexion sql utilisée au niveau du prompt unix.
Exemple:
oracle@juliet:/u01/home/dba/oracle> !sql
sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mar. Juin 22 14:44:33 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,Data Mining, Oracle Database Vault and Real Application Testing options
SQL>
Note:
«sqlplus / as sysdba» était la dernière connexion sql utilisée au niveau du prompt unix.
Echec de démarrage d'une bd RAC 11.2.0.1 avec SRVCTL
Je viens de rencontrer un problème lors du démarrage d'une bd RAC 11.2.0.1.
La bd (toutes les instances) démarre correctement lorsque j'utilise SQLPLUS.
Mais lorsque je l'arrête et je veux la redémarrer avec SRVCTL, je reçois un message d'erreur qui dit que l'un de mes paramètres d'initialisation est invalide:
oracle@ucl02b:/u01/home/dba/oracle> srvctl start instance -d P039 -i P0391
PRCR-1013 : Failed to start resource ora.p039.db
PRCR-1064 : Failed to start resource ora.p039.db on node ucl02b
ORA-00119: invalid specification for system parameter %s
CRS-2674: Start of 'ora.p039.db' on 'ucl02b' failed
Le message d'erreur qui s'affiche dans le fichier d'alerte est le suivant:
USER (ospid: 3898): terminating the instance due to error 119
Instance terminated by USER, pid = 3898
Après quelques recherches, je me suis rendu compte que le problème était lié au SCAN (Single Client Access Naming).
Avec la version 11.2.0.1, le paramètre REMOTE_LISTENER est positionné avec le nom du SCAN comme suit:
REMOTE_LISTENER='crs_lab-scan:1521' -- ou crs_lab-scan est le nom du scan.
Dans mon cas, le scan n'était plus fonctionnel au niveau du DNS.
Les commandes suivantes me retournaient des erreurs:
oracle@ucl02b:/u01/home/dba/oracle> nslookup crs_lab-scan
;; connection timed out; no servers could be reached
ou
oracle@ucl02b:/u01/home/dba/oracle> ping crs_lab-scan
ping: unknown host crs_lab-scan
Après avoir corrigé le problème au niveau du DNS (par l'équipe qui en a la charge), le scan est redevenu fonctionnel et j'ai pu démarrer ma BD.
Conclusion:
Si une bd rac 11.2.0.1 qui démarre avec sqlplus réfuse de démarrer avec srvctl (srvctl fait plus de validations au démarrage), une bonne piste serait de vérifier le REMOTE_LISTENER.
La bd (toutes les instances) démarre correctement lorsque j'utilise SQLPLUS.
Mais lorsque je l'arrête et je veux la redémarrer avec SRVCTL, je reçois un message d'erreur qui dit que l'un de mes paramètres d'initialisation est invalide:
oracle@ucl02b:/u01/home/dba/oracle> srvctl start instance -d P039 -i P0391
PRCR-1013 : Failed to start resource ora.p039.db
PRCR-1064 : Failed to start resource ora.p039.db on node ucl02b
ORA-00119: invalid specification for system parameter %s
CRS-2674: Start of 'ora.p039.db' on 'ucl02b' failed
Le message d'erreur qui s'affiche dans le fichier d'alerte est le suivant:
USER (ospid: 3898): terminating the instance due to error 119
Instance terminated by USER, pid = 3898
Après quelques recherches, je me suis rendu compte que le problème était lié au SCAN (Single Client Access Naming).
Avec la version 11.2.0.1, le paramètre REMOTE_LISTENER est positionné avec le nom du SCAN comme suit:
REMOTE_LISTENER='crs_lab-scan:1521' -- ou crs_lab-scan est le nom du scan.
Dans mon cas, le scan n'était plus fonctionnel au niveau du DNS.
Les commandes suivantes me retournaient des erreurs:
oracle@ucl02b:/u01/home/dba/oracle> nslookup crs_lab-scan
;; connection timed out; no servers could be reached
ou
oracle@ucl02b:/u01/home/dba/oracle> ping crs_lab-scan
ping: unknown host crs_lab-scan
Après avoir corrigé le problème au niveau du DNS (par l'équipe qui en a la charge), le scan est redevenu fonctionnel et j'ai pu démarrer ma BD.
Conclusion:
Si une bd rac 11.2.0.1 qui démarre avec sqlplus réfuse de démarrer avec srvctl (srvctl fait plus de validations au démarrage), une bonne piste serait de vérifier le REMOTE_LISTENER.
NLS_NUMERIC_CHARACTERS dans un environnement SPATIAL 11.2.0.1
J'aimerais partager avec vous un problème que nous avons rencontré avec le paramètre NLS_NUMERIC_CHARACTERS chez l'un de nos clients.
Le client utilise la fonctionnalité Spatial de la version 11.2.0.1 d'oracle database server.
Vous savez que la valeur du paramètre NLS_NUMERIC_CHARACTERS a une importance capitale pour les affichages de valeurs numériques par exemple.
À titre d'exemple, selon le pays dans lequel vous vous trouvez, $100,000 n'a pas la même valeur que $100.000.
Le problème que nous avons rencontré est le suivant:
Le client utilise la valeur «, » (virgule et espace) pour le nls_numeric_characters.
Mais après l'utilisation de certains opérateurs de SPATIAL tels que SDO_WITHIN_DISTANCE , SDO_RELATE ou la création d'index de type spatial (CREATE INDEX ... INDEXTYPE SPATIAL_INDEX)... je ne peux pas les énumérer tous ici..., la valeur du nls_numeric_characters change automatiquement pour devenir «.,» (point et virgule) dans la session de l'utilisateur. Ce qui a un impact catastrophique pour le client car toutes les opérations subséquentes utilisent la nouvelle valeur dans cette session.
Si vous rencontrez ce problème, il s'agit du bug 9824831.
Comment reproduire le problème?
1- Vérifier la valeur actuelle du nls_numeric_characters:
-- Pour voir le problème, il faut que la valeur du nls_numeric_characters soit différente de «.,» (point et virgule) au départ.
sqlplus hetche/hetche
select * from nls_session_parameters;
2- Si la valeur de votre nls_numeric_characters est égale à «.,» (point et virgule), la changer comme suit dans la même session, sinon sauter cette étape:
exec dbms_session.set_nls('nls_numeric_characters','", "');
-- La nouvelle valeur devrait être «, » (virgule espace)
3- Créer une table qui contient un champ de type spatial:
create table test_geomt ( champ_geo mdsys.sdo_geometry);
4- Créer par exemple un index de type spatial sur la table précédemment créée:
-- La création de l'index pourrait retourner des erreurs, mais ce n'est pas grave, le plus important c'est la tentative de création de l'index.
CREATE INDEX SEGRO_01_SIX ON test_geomt
(champ_GEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS('tablespace=USERS')
NOPARALLEL;
5- Voir de nouveau la valeur du nls_numric_characters dans la même session que précédemment:
select * from nls_session_parameters;
Vous verrez que la valeur est devenue «.,» (point et virgule). La tentative de création d'un index de type spatial a modifié la valeur du nls_numeric_characters dans ma session.
On aurait obtenu le même résultat si on avait utilisé l'un des opérateurs cités précédemment (et bien d'autres que je n'ai pas cités).
Par exemple:
select * from test_geomt where sdo_within_distance(champ_geo, mdsys.sdo_geometry(2001,1557057,sdo_point_type(906132,494472,null),null,null),'DISTANCE =1')='TRUE' ;
Pour corriger ce problème, appliquer le patch 9824831
Le client utilise la fonctionnalité Spatial de la version 11.2.0.1 d'oracle database server.
Vous savez que la valeur du paramètre NLS_NUMERIC_CHARACTERS a une importance capitale pour les affichages de valeurs numériques par exemple.
À titre d'exemple, selon le pays dans lequel vous vous trouvez, $100,000 n'a pas la même valeur que $100.000.
Le problème que nous avons rencontré est le suivant:
Le client utilise la valeur «, » (virgule et espace) pour le nls_numeric_characters.
Mais après l'utilisation de certains opérateurs de SPATIAL tels que SDO_WITHIN_DISTANCE , SDO_RELATE ou la création d'index de type spatial (CREATE INDEX ... INDEXTYPE SPATIAL_INDEX)... je ne peux pas les énumérer tous ici..., la valeur du nls_numeric_characters change automatiquement pour devenir «.,» (point et virgule) dans la session de l'utilisateur. Ce qui a un impact catastrophique pour le client car toutes les opérations subséquentes utilisent la nouvelle valeur dans cette session.
Si vous rencontrez ce problème, il s'agit du bug 9824831.
Comment reproduire le problème?
1- Vérifier la valeur actuelle du nls_numeric_characters:
-- Pour voir le problème, il faut que la valeur du nls_numeric_characters soit différente de «.,» (point et virgule) au départ.
sqlplus hetche/hetche
select * from nls_session_parameters;
2- Si la valeur de votre nls_numeric_characters est égale à «.,» (point et virgule), la changer comme suit dans la même session, sinon sauter cette étape:
exec dbms_session.set_nls('nls_numeric_characters','", "');
-- La nouvelle valeur devrait être «, » (virgule espace)
3- Créer une table qui contient un champ de type spatial:
create table test_geomt ( champ_geo mdsys.sdo_geometry);
4- Créer par exemple un index de type spatial sur la table précédemment créée:
-- La création de l'index pourrait retourner des erreurs, mais ce n'est pas grave, le plus important c'est la tentative de création de l'index.
CREATE INDEX SEGRO_01_SIX ON test_geomt
(champ_GEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS('tablespace=USERS')
NOPARALLEL;
5- Voir de nouveau la valeur du nls_numric_characters dans la même session que précédemment:
select * from nls_session_parameters;
Vous verrez que la valeur est devenue «.,» (point et virgule). La tentative de création d'un index de type spatial a modifié la valeur du nls_numeric_characters dans ma session.
On aurait obtenu le même résultat si on avait utilisé l'un des opérateurs cités précédemment (et bien d'autres que je n'ai pas cités).
Par exemple:
select * from test_geomt where sdo_within_distance(champ_geo, mdsys.sdo_geometry(2001,1557057,sdo_point_type(906132,494472,null),null,null),'DISTANCE =1')='TRUE' ;
Pour corriger ce problème, appliquer le patch 9824831
mardi 15 juin 2010
Comment savoir si un patch peut s'appliquer en mode ROLLING?
En environnement RAC, certains patches peuvent s'appliquer en mode rolling c'est à dire que l'environnement reste disponible pendant que le patch s'applique.
Le patch s'applique donc noeud par noeud. Seul le noeud sur lequel le patch est en train d'être appliqué est indisponible.
Pour savoir si un patch peut s'appliquer en mode rolling, à partir du répertoire dans lequel le patch a été décompressé, voir le fichier «etc/config/inventory.xml».
Dans le fichier inventory.xml, rechercher la ligne qui contient «online_rac_installable».
Si la valeur est TRUE alors le patch peut s'appliquer en mode rolling.
Exemple:
oracle@juliet:/u01/home/dba/oracle> gunzip p8730312_112010_SOLARIS64.zip
oracle@juliet:/u01/home/dba/oracle> cd 8730312/etc/config
oracle@juliet:/u01/home/dba/oracle/8730312/etc/config> cat inventory.xml | grep 'online_rac_installable'
OU
oracle@juliet:/u01/home/dba/oracle/8730312/etc/config> grep 'online_rac_installable' inventory.xml
L'on devrait avoir le résultat suivant:
<online_rac_installable>true</online_rac_installable>
vendredi 4 juin 2010
Configuration NTP pour le grid infrastructure 11.2.0.1
En migrant l'un de mes environnements (clusterware/ASM 11.1.0.6) vers le grid infrastructure 11.2.0.1 sur la plateforme SPARC Solaris 64-bit, j'ai rencontré le problème suivant:
Après avoir terminé la phase d'installation des binaires, en exécutant le script «rootupgrade.sh», le noeud sur lequel j'exécutais le sript a redémarré et j'ai obtenu le message d'erreur suivant:
CRS-2674: Start of 'ora.cssd' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.cssd' on 'racnode2'
CRS-2681: Clean of 'ora.cssd' on 'racnode2' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'racnode2'
CRS-2677: Stop of 'ora.diskmon' on 'racnode2' succeeded
CRS-4000: Command Start failed, or completed with errors.
CRS-2672: Attempting to start 'ora.cssd' on 'racnode2'
CRS-2672: Attempting to start 'ora.diskmon' on 'racnode2'
CRS-2674: Start of 'ora.diskmon' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.diskmon' on 'racnode2'
CRS-5016: Process "/u02/home/dba/oracle/product/grid11gr2/bin/diskmon" spawned by agent
"/u02/home/dba/oracle/product/grid11gr2/bin/orarootagent.bin" for action "clean" failed: details at "(:CLSN00010:)"
in /u02/home/dba/oracle/product/grid11gr2/log/ucl03a/agent/ohasd/orarootagent_root/orarootagent_root.log"
CRS-2681: Clean of 'ora.diskmon' on 'racnode2' succeeded
CRS-2674: Start of 'ora.cssd' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.cssd' on 'racnode2'
CRS-2681: Clean of 'ora.cssd' on 'racnode2' succeeded
CRS-4000: Command Start failed, or completed with errors.
Command return code of 1 (256) from command: /u02/home/dba/oracle/product/grid11gr2/bin/crsctl start resource
ora.ctssd -init -env USR_ORA_ENV=CTSS_REBOOT=TRUE
Start of resource "ora.ctssd -init -env USR_ORA_ENV=CTSS_REBOOT=TRUE" failed
Failed to start CTSS
Failed to start Oracle Clusterware stack
Ce message se trouve aussi dans le log:
$GRID_HOME/cfgtoollogs/crsconfig/rootcrs_ucl03a.log où ucl03a est le nom de mon serveur.
Plusieurs forums et Note Metalink parlent de problème de firewall au niveau des serveurs du cluster. Mais dans mon cas, il n'y a aucun firewall.
Je me suis finalement rendu compte que c'est le NTP (Network Time Protocol) qui n'était pas configuré comme recommandé par Oracle. Le NTP permet de synchroniser le temps au niveau des serveurs du cluster.
À ce niveau, Oracle nous laisse le choix:
- Si nous ne voulons plus utiliser le NTP ou s'il n'a jamais été configuré au niveau de notre cluster, le clusterware démarrera le CTSS (Cluster Time Synchronisation Service).
- Sinon si nous utilisons le NTP et que nous voulons continuer à l'utiliser, alors nous devons apporter une légère modification.
Cette modification doit être faite par un admin unix.
Il faut ajouter les lignes suivantes au fichier de configuration du NTP:
slewalways yes
disable pll
Exemple:
#
# The local (undisciplined Solaris) clock is identified as 127.127.1.0.
#
# Some type of primary clock is important; but, it does not have
# to be the local kernel clock.
#
server «mettre ici le nom du serveur avec lequel on synchronise notre serveur local»
slewalways yes
disable pll
Redémarrer xntpd avec la commande:
/usr/sbin/svcadm restart ntp.
Note: il faut savoir que lorsque vous utilisez Sun Cluster (ce n'est pas nécessaire pour mettre en place un RAC, mais dans mon cas, il est utilisé), le fichier de configuration n'est pas «/etc/inet/ntp.conf» mais plutot «/etc/inet/ntp.conf.cluster».
Après avoir reconfiguré ou désactivé le NTP, suivre la procédure décrite dans la Note 969254.1 (permet de faire un downgrade) pour revenir à l'état avant le debut de la migration:
- Suivre la section Failure during rootupgrade.sh
- Puis Failure before rootupgrade.sh (cela devrait supprimer le répertoire 11.2 et détacher la nouvelle installation de l'inventory)
- S'assurer que votre environnement est bien fonctionnel, puis reprendre la migration depuis le début et croisez les doigts...
Après avoir terminé la phase d'installation des binaires, en exécutant le script «rootupgrade.sh», le noeud sur lequel j'exécutais le sript a redémarré et j'ai obtenu le message d'erreur suivant:
CRS-2674: Start of 'ora.cssd' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.cssd' on 'racnode2'
CRS-2681: Clean of 'ora.cssd' on 'racnode2' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'racnode2'
CRS-2677: Stop of 'ora.diskmon' on 'racnode2' succeeded
CRS-4000: Command Start failed, or completed with errors.
CRS-2672: Attempting to start 'ora.cssd' on 'racnode2'
CRS-2672: Attempting to start 'ora.diskmon' on 'racnode2'
CRS-2674: Start of 'ora.diskmon' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.diskmon' on 'racnode2'
CRS-5016: Process "/u02/home/dba/oracle/product/grid11gr2/bin/diskmon" spawned by agent
"/u02/home/dba/oracle/product/grid11gr2/bin/orarootagent.bin" for action "clean" failed: details at "(:CLSN00010:)"
in /u02/home/dba/oracle/product/grid11gr2/log/ucl03a/agent/ohasd/orarootagent_root/orarootagent_root.log"
CRS-2681: Clean of 'ora.diskmon' on 'racnode2' succeeded
CRS-2674: Start of 'ora.cssd' on 'racnode2' failed
CRS-2679: Attempting to clean 'ora.cssd' on 'racnode2'
CRS-2681: Clean of 'ora.cssd' on 'racnode2' succeeded
CRS-4000: Command Start failed, or completed with errors.
Command return code of 1 (256) from command: /u02/home/dba/oracle/product/grid11gr2/bin/crsctl start resource
ora.ctssd -init -env USR_ORA_ENV=CTSS_REBOOT=TRUE
Start of resource "ora.ctssd -init -env USR_ORA_ENV=CTSS_REBOOT=TRUE" failed
Failed to start CTSS
Failed to start Oracle Clusterware stack
Ce message se trouve aussi dans le log:
$GRID_HOME/cfgtoollogs/crsconfig/rootcrs_ucl03a.log où ucl03a est le nom de mon serveur.
Plusieurs forums et Note Metalink parlent de problème de firewall au niveau des serveurs du cluster. Mais dans mon cas, il n'y a aucun firewall.
Je me suis finalement rendu compte que c'est le NTP (Network Time Protocol) qui n'était pas configuré comme recommandé par Oracle. Le NTP permet de synchroniser le temps au niveau des serveurs du cluster.
À ce niveau, Oracle nous laisse le choix:
- Si nous ne voulons plus utiliser le NTP ou s'il n'a jamais été configuré au niveau de notre cluster, le clusterware démarrera le CTSS (Cluster Time Synchronisation Service).
- Sinon si nous utilisons le NTP et que nous voulons continuer à l'utiliser, alors nous devons apporter une légère modification.
Cette modification doit être faite par un admin unix.
Il faut ajouter les lignes suivantes au fichier de configuration du NTP:
slewalways yes
disable pll
Exemple:
#
# The local (undisciplined Solaris) clock is identified as 127.127.1.0.
#
# Some type of primary clock is important; but, it does not have
# to be the local kernel clock.
#
server «mettre ici le nom du serveur avec lequel on synchronise notre serveur local»
slewalways yes
disable pll
Redémarrer xntpd avec la commande:
/usr/sbin/svcadm restart ntp.
Note: il faut savoir que lorsque vous utilisez Sun Cluster (ce n'est pas nécessaire pour mettre en place un RAC, mais dans mon cas, il est utilisé), le fichier de configuration n'est pas «/etc/inet/ntp.conf» mais plutot «/etc/inet/ntp.conf.cluster».
Après avoir reconfiguré ou désactivé le NTP, suivre la procédure décrite dans la Note 969254.1 (permet de faire un downgrade) pour revenir à l'état avant le debut de la migration:
- Suivre la section Failure during rootupgrade.sh
- Puis Failure before rootupgrade.sh (cela devrait supprimer le répertoire 11.2 et détacher la nouvelle installation de l'inventory)
- S'assurer que votre environnement est bien fonctionnel, puis reprendre la migration depuis le début et croisez les doigts...