Changer d’ORACLE_HOME, lorsque vous faites un « upgrade » vers une version supérieure ou vers un Patch Set, offre plusieurs avantages; Cela permet:

• de conserver le ORACLE_HOME précédent sur le serveur et ainsi de faciliter le plan de retour arrière ^[1]
• de changer le chemin du ORACLE_HOME ^[2] et ainsi d’assurer la consistance avec les dénominations standard d’OFA,
• d’installer la nouvelle version ainsi que d’appliquer les patchs recommandés en général (cf 756671.1- Oracle Recommended Patches) ou pour des modules particuliers (e.g. 437838.1 – Streams Specific Patches), sans impacter la disponibilité de votre base de données ^[3].

Seulement, ce qui est une formalité dans le cas d’une single instance, nécessite plusieurs adaptations dans le cas de RAC… Voici ces modifications que vous devez réaliser lorsque vous changez une base de données RAC d’ORACLE_HOME sans l’aide des assistants^[4].

Remarque:
Gardez à l’esprit que les ressources ne doivent pas forcément être enregistrées dans le clusterware pour fonctionner; vous pouvez démarrer une instance avec SQL*Plus sans qu’il y ait de ressource associée dans l’OCR ou que la ressource ne soit pas paramétrée correctement (pour l’instant). Il en est de même pour ASM ou pour les listeners. Par contre, il est fondamental qu’en fonctionnement régulier les ressources du cluster existent et soient correctement paramétrées car elles supervisent les services Oracle. Vous pouvez donc temporairement démarrer une ressource alors qu’elle n’est pas encore configurée correctement dans le cluster et ainsi réduire l’indisponibilité de votre RAC lors d’un upgrade.

Changer le ORACLE_HOME des listeners

Si vous utilisez Oracle 11g, vous n’avez sans doute pas besoin de changer le ORACLE_HOME des listeners. En effet vous pourrez utiliser le ORACLE_HOME d’ASM et les nouvelles capacités de rolling upgrade du logiciel. Vous pouvez ainsi simplement mettre à jour chaque serveur séparément comme vous le faites pour le cluster.

Si vous voulez malgré tout, changer votre configuration, vous pouvez utiliser srvctl config listener
puis srvctl modify listener pour obtenir le résultat attendu. Cela arrivera, par exemple, si votre ORACLE_HOME précédent était une version 10g ou si vous utilisez le même ORACLE_HOME pour vos instances et vos listeners.

Dans le cas d’Oracle 10g, changer le ORACLE_HOME du listener est plus compliqué. La seule méthode supportée consiste à utiliser netca sur l’ancien ORACLE_HOME pour dé-enregistrer le listener et le réutiliser avec le nouveau ORACLE_HOME pour le ré-enregistrer. La bonne nouvelle, c’est que l’opération peut-être réalisée serveur par serveur. La mauvaise, c’est que la commande netca /silent /deinst /nodeinfo serverX ne fonctionne généralement pas. La méthode que j’utilise personnellement en 10g consiste donc à supprimer la ressource avec les outils du clusterware (même si ce n’est pas supporté) et utiliser netca seulement pour la reconfigurer:

cd $ORA_CRS_HOME/bin

export LSNR_RSC=`./crs_stat | grep "^NAME=" | grep ".lsnr$" |   
        grep `$ORA_CRS_HOME/bin/olsnodes -l` | 
        cut -d = -f 2`

echo $LSNR_RSC

./crs_stop $LSNR_RSC
# ou si la commande précédente échoue:
# ./crs_stop $LSNR_RSC -f

./crs_unregister $LSNR_RSC

Une fois le listener supprimé, vous pouvez le recréer avec netca en mode silent:

cd $ORACLE_HOME/network/admin

mv listener.ora listener.ora.bak

which netca
ps -ef |grep [t]ns

export DISPLAY=:0

export nodename=`hostname | cut -d . -f 1`
echo $nodename

netca /silent  
    /responsefile $ORACLE_HOME/network/install/netca_typ.rsp 
    /nodeinfo $nodename

srvctl status nodeapps -n $nodename

Si vous utilisez une configuration spéciale pour votre listener (e.g. adresses supplementaires, external procedure, enregistrement statique des instances, parametres…), vous pouvez simplement recopier le précédent fichier listener.ora.

Changer le ORACLE_HOME d’ASM

Changer le ORACLE_HOME d’ASM est très simple et s’effectue en quelques secondes. En 11g, vous pouvez utiliser le rolling upgrade de ASM comme discuté dans « 11g ASM Rolling Upgrade et Oracle Database 10g« . Sinon, vous devez arrêter toutes les instances ASM du RAC avant de changer la version d’une instance; suivez les étapes ci-dessous, si vous changez d’ORACLE_HOME:

• arrêter la ressource ASM,
• copier les fichiers init.ora, spfile, password file et tnsnames.ora,
• vérifier la configuration d’ASM stockée dans le cluster,
• Modifier le ORACLE_HOME de la ressource,
• redémarrer ASM

# Get Current Host/Instance/ORACLE_HOME

export nodename=`$ORA_CRS_HOME/bin/olsnodes -l`
echo $nodename

cd $ORA_CRS_HOME/bin

export instance_name=` srvctl config asm -n `$ORA_CRS_HOME/bin/olsnodes -l` 
                  |awk '{ print $1}'`

echo $instance_name

export old_oh=`srvctl config asm -n `$ORA_CRS_HOME/bin/olsnodes -l` 
                  |awk '{ print $2}'`

echo $old_oh

# Stop all the ASM instances
# Only for the 1st instance you restart!!!

for i in `$ORA_CRS_HOME/bin/olsnodes`;do
echo "Stopping ASM on $i..."
srvctl stop asm -n $i
done

# Copy all the files in the new ORACLE_HOME

echo $ORACLE_HOME
export new_oh=$ORACLE_HOME

cd $new_oh/dbs
cp -p $old_oh/dbs/init$instance_name.ora   $new_oh/dbs
cp -p $old_oh/dbs/spfile$instance_name.ora $new_oh/dbs
cp -p $old_oh/dbs/orapw$instance_name      $new_oh/dbs
cp -p $old_oh/network/admin/tnsnames.ora   $new_oh/network/admin
cp -p $old_oh/network/admin/sqlnet.ora     $new_oh/network/admin

# Check the stored ASM configuration
srvctl config asm -n $nodename

# Change the stored configuration
# Run this step as ROOT:
srvctl modify asm -n $nodename -i $instance_name -o $new_oh

# Start ASM
srvctl start asm -n $nodename
srvctl status asm -n $nodename

# If there is any problem check the alert.log
# and the crsd logs

Changer le ORACLE_HOME d’une base de données et de toutes ses instances

Les instances ne stockent pas leur ORACLE_HOME; seul la base de données y fait référence. Pour changer cette information dans le cluster, il suffit donc de modifier la variable à cet unique endroit; pour ce faire, utiliser < code>srvctl comme ci-dessous:

# cluster database list:
srvctl config database

# Assuming ORCL is the registered resource
# for the database; display the configuration:
srvctl config database -d ORCL -a

# Change the ORACLE_HOME, if $new_oh is
# the new ORACLE_HOME. Run the command below
# as root:
srvctl modify database -d ORCL 
                    -o $new_oh

Changer le ORACLE_HOME des nodeapps

Vous ne devriez pas avoir à changer les ORACLE_HOME des nodeapps puisque ceux-ci référencent, en principe, le répertoire du clusterware. Toutefois, vous pouvez toujours utiliser srvctl modify nodeapps si celui-ci n’a pas été correctement paramétrés. Pour visualiser rapidement la valeur de ce paramètre, utilisez ocrdump -stdout -keyname comme ci-dessous:

export nodename=`$ORA_CRS_HOME/bin/olsnodes -l`
echo $nodename

ocrdump -stdout -keyname DATABASE.NODEAPPS.$nodename.ORACLE_HOME

Changer les ORACLE_HOME dans oratab

L’inconvénient de changer le ORACLE_HOME de votre base de données, vous l’aurez donc compris, tient dans le fait que celui-ci peut être utilisé dans de nombreux endroits; bien sur, il doit être référencé dans le fichier oratab mais il est possible que vous l’ayez stockés dans de nombreux autres endroits comme les fichiers de profile (/etc/profile, /etc/profile.d, .profile, .bashrc, .bash_profile,…), les scripts ou les outils de sauvegarde, de supervision, de nettoyage, la configuration de module comme DBD:Oracle ou encore certain rapports. Assurez-vous de faire l’inventaire de ces scripts avant de commencer votre mise à jour. Voici comment modifier cette variable dans le fichier oratab; on supposera que old_oh et new_oh sont respectivement les anciens et nouveaux ORACLE_HOME :

export old_str=`echo $old_oh|sed -e 's/\//\\\//g'`
export new_str=`echo $new_oh|sed -e 's/\//\\\//g'`
ed /etc/oratab <<EOF
%s/$old_str/$new_str/g
wq
EOF
unset old_str
unset new_str

Changer les ORACLE_HOME correspondants dans le Grid Control

Le ORACLE_HOME est généralement utilisé par les outils de supervision; c’est en particulier le cas pour le Grid Control. Une fois que vous avez changé une variable sur le serveur, vous devez réfléter ce changement dans la configuration du Grid Control. Pour ce faire, sélectionnez la cible modifiée et cliquez sur le bouton configure:

• Si vous avez modifié le ORACLE_HOME de votre base de données, connectez vous au Grid Control et sélectionnez la cible « cluster database » database correspondante; modifiez la propriété: « Oracle home path ». Comme pour la resource dans le clusterware, cette information n’est pas stockée dans les instances.
• Si vous avez modifié le ORACLE_HOME de vos listener, sélectionnez les cibles « listener » correspondantes et modifiez les propriétés « listener.ora » et « Oracle Home »
• Si vous avez modifié le ORACLE_HOME de vos instances ASM, sélectionnez la cible « Automatic Storage Manager » correspondante et modifier la propriété: « Oracle home path ».

Voilà ce que vous devez savoir faire un upgrade de RAC en utilisant un nouvel ORACLE_HOME. Racontez-moi vos exploits!

[1] Si vous voulez conserver le ORACLE_HOME pour faciliter un retour arrière et, malgré tout, le supprimer des disques, vous pouvez le détacher et le compresser. Vous pourrez toujours le rattacher ou le cloner comme décrit dans ce post: « Cloner un ORACLE_HOME d’une base de données RAC 10g« .

[2] Il est recommandé de ne pas inclure le numéro de version majeur d’Oracle (e.g 10.2.0, 11.1.0), contrairement à ce qu’il est parfois écrit dans la documentation, dans le chemin du clusterware. N’incluez pas non plus ce numéro dans le chemin d’ASM s’il est installé en RAC à partir de 11g. Cette dénomination, sans numéro de version, permet d’effectuer une mise à jour « In-Place » comme recommandé dans ces 2 cas.

[3] Pour un Patch Set et dans le cas d’un RAC 2 noeuds, vous pouvez mettre à jour le logiciel sur un seul noeud en gardant ainsi l’autre noeud avec la précédente version; Pour cela, scinder l’inventory avec runInstaller -silent -UpdateNodeList ... -local. sur les 2 serveurs avec Oracle 10g; avec Oracle 11g, vous pouvez utiliser la possibilité qui est offerte de mettre à jour les logiciels séparemment sur des noeuds différents.

[4] Une alternative intéressante consiste utiliser DBUA en mode silent, au moins pour la base de données.