11.2 CRS+10.2 RAC: Echec de démarrage des instances 10g au démarrage du CRS

Lorsque vous utilisez le grid infrastructure 11.2.0.1 avec des bases de données 11.2 et des bases de données 10g, vous constatérez que les ressources des BD 11g ont des dépendences avec les diskgroups, mais pas les BD 10g.

Pour le constatez, nous utiliserons une bd 11gR2 (P039) et une bd 10g (P035). Les deux BDs ont leurs SPFILE dans des diskgroups.

Les ressources liées à ces deux BDs dans le clusterware sont respectivement ora.p039.db et ora.P035.db (vous remarquerez le "p" minuscule pour la bd 11g: avec la 11g, la ressource est créée avec une lettre minuscule même si la bd a été ajoutée au clusterware avec une lettre majuscule).

Vérifions leurs dépendances avec les diskgroups:

Pour ce qui concerne la ressource de la bd 11g: ora.p039.db

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res ora.p039.db -p
NAME=ora.p039.db
TYPE=ora.database.type
ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
ACTIVE_PLACEMENT=1
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
AUTO_START=always
...
SERVER_POOLS=ora.P039
SPFILE=+SYSGRP01/P039/spfileP039.ora
START_DEPENDENCIES=weak(type:ora.listener.type,global:type:ora.scan_listener.type,uniform:ora.ons,uniform:ora.eons) hard(ora.FRAGRP01.dg,ora.FRAGRP02.dg,ora.SYSGRP01.dg,ora.DATAGRP01.dg)
START_TIMEOUT=600
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(intermediate:ora.asm,shutdown:ora.FRAGRP01.dg,shutdown:ora.FRAGRP02.dg,shutdown:ora.SYSGRP01.dg,shutdown:ora.DATAGRP01.dg)
STOP_TIMEOUT=600
UPTIME_THRESHOLD=1h
USR_ORA_DB_NAME=
USR_ORA_DOMAIN=WORLD
USR_ORA_ENV=
USR_ORA_FLAGS=
USR_ORA_INST_NAME=
USR_ORA_INST_NAME@SERVERNAME(ucl02b)=P0391
USR_ORA_INST_NAME@SERVERNAME(ucl02c)=P0392
USR_ORA_OPEN_MODE=open
USR_ORA_OPI=false
USR_ORA_STOP_MODE=immediate
VERSION=11.2.0.1.0
oracle@ucl02b:/u01/home/dba/oracle>

On constate que la BD 11g a une dépendance avec les diskgroups FRAGRP01, FRAGRP02, SYSGRP01 et DATAGRP01

Pour ce qui concerne la ressource de la bd 10g: ora.P035.db

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res ora.P035.db -p
NAME=ora.P035.db
TYPE=application
ACL=owner:oracle:rwx,pgrp:dba:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=/u02/home/dba/oracle/product/grid11gr2/bin/racgwrap
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/appagent
AUTO_START=restore
...
SERVER_POOLS=
START_DEPENDENCIES=
START_TIMEOUT=0
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=
STOP_TIMEOUT=0
...
oracle@ucl02b:/u01/home/dba/oracle>

La BD 10g n'a aucune dépendance avec les diskgroups.

La conséquence est que lorsque le CRS démarre, il ne s'assure pas que tous les diskgroups soient déjà montés avant qu'il essaie de démarrer les BDs 10g. Donc les BDs 10g ne démarrent pas au démarrage du CRS (elles ne démarrent que si le diskgroup dans lequel se trouvent leurs SPFILE est monté auparavant, ce qui est aléatoire).

Pour constater la raison pour laquelle la BD 10g n'a pu démarrer, il regarder le fichier $ORACLE10g_HOME/log/hostname/racg/imon_$SID.log

oracle@ucl02b:/u01/home/dba/oracle/product/10.2.0.4.0/log/ucl02b/racg> vi imon_P035.log
...
SQL*Plus: Release 10.2.0.4.0 - Production on Thu May 28 11:54:27 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Enter user-name: Connected to an idle instance.
SQL> ORA-01565: error in identifying file '+SYSGRP01/P035/spfileP035.ora'
2010-05-28 11:54:28.765: [ RACG][6] [16851][6][ora.P035.P0352.inst]: ORA-17503: ksfdopn:2 Failed to open file +SYSGRP01/P035/spfileP035.ora
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-01078: failure in processing system parameters
SQL> Disconnected
...

On constate bien qu'il ne peut ouvrir le spfile. Cela est dû au fait que le diskgroup SYSGRP01 ne soit pas encore monté au moment où le CRS essaie de démarrer la bd P035.

Pour les BDs 11gR2, ce problème ne se pose pas car à cause de la dépendance qui existe avec les diskgroups, il s'assure que tous les diskgroups dont dépend une bd 11g soient montés avant qu'il ne démarre la bd 11g.

Ce problème est décrit dans un bug interne (non publié): Bug 8448079 -- 11.2 CRS+10.2 RAC DB INSTANCE FAILED TO START AFTER BOUNCING CRS STACK

Il sera corrigé dans le patchset 11.2.0.2.

Mais en attendant la correction, Oracle propose de désactiver les ressources des diskgroups au niveau du clusterware afin d'empêcher que le paramètre «asm_diskgroups» soit positionné à NULL pendant le «crsctl stop crs».

Puis positionner manuellement le paramètre «asm_diskgroups» au niveau de toutes les instances ASM du cluster.

Exemple: pour désactiver les ressources diskgroup et positionner le paramètre asm_diskgroups

Vérifions le status des diskgroups dans le clusterware avant de les désactiver:

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res -t
...
ora.DATAGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.FRAGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.FRAGRP02.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c
ora.SYSGRP01.dg
ONLINE ONLINE ucl02b
ONLINE ONLINE ucl02c

Tous les diskgroups sont ONLINE dans le clusterware.

La désactivation des ressources se fait à partir d'un seul noeud du cluster

oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g FRAGRP01
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g FRAGRP02
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g SYSGRP01
oracle@ucl02b:/u01/home/dba/oracle> srvctl disable diskgroup -g DATAGRP01

Vérifions encore le status des diskgroups dans le clusterware:

oracle@ucl02b:/u01/home/dba/oracle> crsctl stat res -t
...
ora.DATAGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.FRAGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.FRAGRP02.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c
ora.SYSGRP01.dg
OFFLINE OFFLINE ucl02b
OFFLINE OFFLINE ucl02c

Les diskgroups sont maintenant OFFLINE.

Positionner le paramètre au niveau de chaque instance ASM du cluster (le faire sur chaque noeud)

export ORACLE_HOME=$GRID_HOME
export ORACLE_SID=+ASM1
$ORACLE_HOME/bin/sqlplus / as sysasm
sql> alter system set asm_diskgroups='FRAGRP01','FRAGRP02','SYSGRP01','DATAGRP01' scope=both SID='+ASM1';

Si les BDs 11gR2 et les BDs 10g sont dans les mêmes diskgroups, il faut enlever la dépendance entre les BDs 11g et les diskgroups:

export ORACLE_HOME=$BD11gR2_HOME
export ORACLE_SID=P0391
oracle@ucl02b:/u01/home/dba/oracle> srvctl modify database -d P039 -z

Note:

1. Dans la version actuelle du clusterware (11.2.0.1), à chaque fois que vous démarrez une BD 11gR2, la dépendance avec les diskgroups revient automatiquement.
2. Par conséquent, chaque fois qu'on arrête une BD 11gR2, il faut enlever la dépendance avec les diskgroups avant de la démarrer.
3. C'est l'une des raisons pour lesquelles oracle conseille de mettre les BDs 11gR2 et les BDs 10g dans des diskgroups différents.