11g ASM Rolling Upgrade et Oracle Database 10g

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! »

4 réflexions sur “11g ASM Rolling Upgrade et Oracle Database 10g”

  1. Si. Il faut simplement utiliser la commande srvctl qui vient avec la base de donnees et pas celle qui vient avec le clusterware. Tu peux verifier sous Linux avec which srvctl que c’est la version 10g que tu utilises.

    Note qu’il y a un bug a propos du Rolling upgrade ASM: Bug 7436280 – ASM rolling upgrade to 11.1.0.7 fails in RAC environments

  2. Salut Grégory,
    Tu abordes un sujet qui m’intéresse tout particulièrement.
    On m’a en effet demandé d’installer un RAC avec le clusterware et l’instance ASM en 11g mais avec le moteur des bases RAC en 10gR2.
    Tout s’est bien deroulé si ce n’est que les bases en 10g refuse d’obeir aux commande srvctl (du genre srvctl start instance -d orcl -i orcl1) invoquant le pretexte suivant:

    PRKR-1078 : Database orcl cannot be administered using current version of srvctl

    Dois-je en deduire que le clusterware 11g ne peux pas s’interfacer avec des bases de 10gR2 ???

    Thx
    -phil-

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *