Même si vous faites de votre mieux pour faire partir vos projets avec 11g (j’en ai déjà quelques un à mon actif, l’avantage de travailler dans plusieurs pays :-), il arrive encore des moments où vous arrivez à cours d’arguments et où 10.2 s’avère la solution la plus pragmatique. C’est un peu l’histoire de ces 2 semaines passées à Riyadh, pour une grande banque du Golfe.

Je passe les détails; en substance, l’architecture retenue est constituée d’un cluster de 6 serveurs AIX 6 Power 6 avec au total 14 instances de bases de données en 10g. Mais voilà, la disponibilité est une des clés de cette configuration et, à bien y réfléchir, avoir à arrêter toutes les bases de données pour appliquer un patch set sur ASM, n’est pas vraiment une option : Vive ASM 11g Rolling Upgrade ?

Nous avons donc testé qu’il est bien possible d’appliquer un Patch Set sur les instances ASM même lorsque compatibility.asm et compatibility.rdbms sont 10.1 et que plusieurs bases de données 10.2 utilisent ces disques diskgroups.

Pour commencer, nous avons installé un clusterware 11.1.0.6 ainsi qu’un ORACLE_HOME 11.1.0.6 pour ASM. En dehors de l’absolu nécessité d’exécuter rootpre.sh ainsi que slibclean sur tous les serveurs, l’installation est aussi simple que sous Linux (cf mon post sur le blog de Pythian); les disques avec nos bases de données ont été reconnus sans problème et remontés en mode de compatibilité 10.1 sur nos nouvelles instances ASM.

Ensuite, nous avons installé les logiciels et patch set pour nos bases de données 10.2 en ignorant les erreurs relatives à la version du clusterware. Enregistrer la bases de données et les instances dans le clusterware dans la configuration du clusterware nécessite que vous utilisiez la version de srvctl qui vient avec le logiciel 10.2 sous peine que dbca ne fonctionne plus ensuite; supprimer et recréer les ressources corrige facilement ce problème.

Nous y étions; prêt à installer 11.1.0.7 sans indisponibilité pour nos bases de données. Le clusterware est mis a jour de la même façon qu’avec 10.2; utilisez juste root111.sh au lieu de root102.sh. Pour ASM, la méthode est légèrement différente:

• Arrêtez les instances de base de données du serveur 1

srvctl stop instance -d RACDB -i RACDB1
srvctl stop instance -d OTHERDB -i OTHERDB1

• Passez ASM en mode « Rolling Upgrade »

. oraenv
+ASM1

sqlplus / as sysdba

alter system start rolling migration to '11.1.0.7.0';

select sys_context('sys_cluster_properties', 'cluster_state') 
  from dual;

exit;

• Arrêtez ASM et le listener associé

srvctl stop asm -n rac-server1

srvctl stop listener -n rac-server1

• Appliquez 11.1.0.7 sur ASM

$ cd /distrib/patch11107/Disk1

$ export DISTRIB=`pwd`

$ ./runInstaller -silent                                     
   -responseFile $DISTRIB/response/enterprise.rsp            
   UNIX_GROUP_NAME="dba"                                     
   FROM_LOCATION=$DISTRIB/stage/products.xml                 
   ORACLE_HOME=$ORACLE_HOME                                  
   ORACLE_BASE=$ORACLE_BASE                                  
   ORACLE_HOME_NAME="OraASM11_Home"                          
   CLUSTER_NODES={"rac-server1","rac-server2","rac-server3"} 
   REMOTE_NODES={}                                           
   ACCEPT_LICENSE_AGREEMENT=false                            
   METALINK_USERNAME=""

$ su -

# cd /u01/app/oracle/products/11.1.0/asm_1

# ./root.sh

• Redémarrez ASM, le listener et vos instances

$ srvctl listener -n rac-server1

$ srvctl start asm -n rac-server1

$ srvctl instance -d RACDB -i RACDB1

$ srvctl instance -d OTHERDB -i OTHERDB1

Une fois que vous avez vérifié que tout va bien, que l’application fonctionne et que vous n’avez aucune erreur dans les alert.log, vous pouvez réitérer les opérations précédentes sur l’ensemble des serveurs jusqu’à ce que tous les ORACLE_HOME ASM soient mis à jour en 11.1.0.7. Ensuite, terminez la mise à jour d’ASM:

. oraenv
+ASM1

sqlplus / as sysdba

alter system stop rolling migration;

exit;

Et voilà, c’est tout! Un grand merci à Fred et les autres membres du Oracle/IBM JSC pour le coup de main… J’attends la confirmation que VIO est également certifié avec ASM 11g et que le prochain RedBook RAC 11g! Mais, « that looks good! »