Vous avez un magnifique cluster Grid 11gR2 à 6 nœuds qui héberge de nombreuses bases métier en RAC.
Besoin d’arrêter l’un des serveurs du cluster pour une maintenance ? Pas de souci, il suffit de déplacer les services vers les nœuds actifs restants et voilà, aucune indisponibilité pour l’utilisateur ou au pire une reconnexion aux applications !
C’était hélas sans compter sur la base technique qui accompagne votre ETL ou le serveur d’applications, et qui elle, n’a pas été créée en RAC mais seulement en standalone pour simplifier l’architecture ou économiser quelques ressources. L’opération d’arrêt n’est du coup plus aussi simple à cause de ces bases …
Pour éviter ces désagréments, il vous faut  rapidement convertir ces bases standalone vers du Rac OneNode  dans le cluster pour pouvoir ensuite les déplacer en une commande vers les autres nœuds du cluster.
Il existe plusieurs méthodes pour arriver à ce résultat – via DBCA par exemple – je vais vous décrire dans cet article la procédure de conversion via l’outil Rconfig fourni avec la distribution Oracle 11g.

Rconfig

Cet outil permet de convertir une base de données initialement mono instance et non RAC en une base RAC ou RAC One Node.
La base à migrer doit donc être définie de type SINGLE dans l’infrastructure grid (srvctl add database -c SINGLE …)
L’outil s’appuie sur un fichier de configuration xml dont deux templates se trouvent sous $ORACLE_HOME/assistants/rconfig/sampleXMLS

• ConvertToRAC_AdminManaged.xml
• ConvertToRAC_PolicyManaged.xml

• Patch 17429745 appliqué sur tous les nœuds du cluster
• Cluster configuré et opérationnel (stockage partagé, équivalence ssh)
• Binaires Oracle compilés avec l’option RAC
• Existence d’un service au niveau grid défini sur l’instance Standalone
• Le fichier spfile de l’instance doit se trouver initialement dans ASM (ou CFS)
• Le stockage partagé pour la base (diskgroups ASM DATA et FRA) doit pré-exister
• Le fichier /etc/oratab doit être accessible en écriture

Principe de la conversion Standalone vers Rac OneNode

Au niveau de la base de données cible, il n’y a pas de différence entre une base Rac OneNode et une base RAC à 2 instances. De ce fait, il est possible de convertir l’une en l’autre très simplement via la commande srvctl convert database.
La différence se fait au niveau de la déclaration dans Grid Infrastructure (srvctl add database) qui conditionne le comportement au démarrage et la possibilité de relocalisation : une commande srvctl start database ne démarrera toujours qu’une seule instance en RAC One Node.
Le point le plus notable est qu’en RAC One Node, le suffixe du nom des instances est imposé et contiendra un caractère underscore. Après conversion en RAC One Node, une base single MADB aura pour instances :

• MADB_1 : sur le nœud primaire
• MADB_2 : sur le nœud de secours après relocalisation par srvctl reloacate

La conversion d’une base Single vers RAC One Node est donc similaire à la conversion vers une base RAC et réalise globalement les opérations suivantes :

• Ajout des redologs du thread 2
• Ajout d’un Undo tablespace pour l’instance 2
• Modification du paramètre cluster_database à la valeur TRUE
• Création d’une instance <ORACLE_SID>_1 au lieu de ORACLE_SID
• Ajout des paramètres de l’instance 2
• Activation du thread 2
• Activation du mode Archivelog

Les composants RAC suivants seront ajoutés par la conversion :

• Undo tablespace et redologs groupes de l’instance 2 de même taille que ceux de l’instance 1
• Vues RAC créées via l’exécution du script catclust.sql
• Paramètres RAC ajoutés dans le spfile : cluster_database, thread, instance_id, …

Point importants :

1. Le tablespace UNDO de l’instance 2 qui sera créé par rconfig sera nommé UNDO_2,  vous pourriez donc vous retrouver avec un tablespace UNDOTBS1 et un tablespace UNDO_2.
2. De même, les groupes de redologs du thread 2 s’appelleront GROUP_n.
3. Les redologs files et datafiles d’undo porteront un nom OMF.

Fichier de paramétrage de rconfig

Le template du ficher xml de configuration se trouve dans le répertoire $ORACLE_HOME/assistants/rconfig/sampleXMLs qui contient 2 fichiers (administrator et policy managed)
Copier le fichier ConvertToRAC_AdminManaged.xml dans un autre emplacement pour le personnaliser  (en changeant le nom si besoin)
Voici à quoi ressemble ce fichier, les champs à personnaliser sont listés plus loin:

ORACLE_HOME
ORACLE_HOME


sys
xxxxx
sysdba






Prefixe

Le fichier ci-dessus suppose que la base est initialement stockée sous ASM, sinon il faut renseigner les champsTargetDatabaseArea et TargetFlashRecoveryArea.
Pour convertir une base vers RAC One Node, au lieu de RAC, ne pas oublier de dé-commenter la ligne  <n:RacOneNode dans le fichier.
Les champs à configurer sont les suivants :

• SourceDBHome : Oracle Home de la base à convertir
• TargetDBHome : identique à SourceDBHome sauf cas particulier
• SourceDBInfo SID : Oracle SID de l’instance de la base à convertir
• Password : mot de passe du compte « SYS »
• Node name : Nom du serveur courant où s’exécute la base standalone
• RacOneNode servicename : Nom d’un service cluster associé à la base (doit préexister)
• InstancePrefix : Préfixe des instances OneNode sur les nœuds, elles s’appelleront dans cet exemple <Prefixe>_1 sur le nœud nominal, <Prefixe>_2 après bascule sur un autre nœud
• Convert verify : Paramètre permettant de vérifier le paramétrage et certains prérequis avant l’exécution
  – YES : Tests de prérequis et exécution de la conversion
  – NO : Pas de tests de prérequis, lance directement la conversion
  – ONLY : Mode vérification de prérequis seulement

Exemple de conversion

Vérifier que la base de données à convertir est ouverte et qu’il n’y a plus de connexions applicatives.
L’instance standalone sera arrêtée durant la conversion mais il est nécessaire que cette dernière soit lancée sur une base ouverte.
Lancer l’outil de conversion rconfig en tant que propriétaire du noyau oracle et en spécifiant en paramètre le fichier .xml de paramétrage.
Il faut d’abord exécuter la conversion avec le paramètre Convert verify = ONLY afin de valider les prérequis.
S’il n’y a pas d’erreur, la conversion peut ensuite être lancée avec Convert verify = NO
Voici ci dessous l’exemple d’une conversion réussie.
Les logs seront localisés sous $ORACLE_BASE/cfgtoollogs/rconfig
$rconfig ./ConvertToRAC_AdminManaged.xml

Operation Succeeded




/oracle/oradb/11.2.0.a/ora






     

La conversion dure quelques minutes seulement.
Une instance PREFIXE_1 est démarrée sur le nœud où a lieu la conversion, une instance PREFIXE_2 sera démarrée sur le nœud destination lorsque vous ferez la relocalisation en ligne (relocate online). Le fichier init<SID>.ora avec le nouveau nom d’instance sera automatiquement créé !
Le fichier /etc/oratab sera également mis à jour automatiquement.
Il ne reste plus qu’à modifier les différentes chaines de connexion utilisant un SID pour les remplacer par un nom de service.
Vous pouvez maintenant tester une relocalisation : srvctl relocate database -d <dbun> -n <serveur destination>
A noter que la relocalisation peut être faite vers n’importe quel serveur du grid sans l’avoir ajouté au préalable dans la liste des serveurs candidats (cette liste sera mise à jour après un relocate réussi).
Pour pouvoir se connecter sysdba à distance, il faudra créer les fichiers de mot de passe orapw<SID> sur tous les serveurs destination potentiels.
Certes, il vous a fallu stopper le temps de la conversion les accès à la base traitée, mais maintenant vous avez à disposition toute la souplesse de la configuration Grid et à l’avenir vous pourrez arrêter n’importe lequel de vos nœuds de votre cluster avec un minimum d’indisponibilité pour tout vos utilisateurs, ce qui était votre objectif initial.