Remarque préliminaire :
Les tests décrits dans ce post ont été réalisés sur Linux avec Oracle 10.1.0.6. Il est probable que les syntaxes nécessitent d’être adaptées en fonction de la version d’Oracle et du système d’exploitation utilisé.

2nd remarque préliminaire :
Vérifiez que votre base de données est en mode archivelog et testez la procédure avant de l’utiliser en production… Il se pourrait bien que les accès à votre base de données source soient compromis à un moment de la procédure !

Il y a quelques jours, on m’a demandé comment copier une base de données d’un DiskGroup ASM situé sur un serveur à un autre. Depuis ça trotte dans ma tête comme une chanson ringarde qu’on entend à la radio le matin et dont on n’arrive plus à se débarrasser. Sauf qu’en plus, après 2 matins, la question est toujours là : Comment faire ?

• « RMAN DUPLICATE » parait la réponse la plus évidente ; Enfin, si (a) vous pouvez accédez aux 2 serveurs simultanément avec RMAN et si (b) vous pouvez utiliser un espace de stockage des sauvegardes sur disques qui a le même nom des deux cotés (qu’il soit partagé ou non). A propos de (b), si avez des bandes ou que vous utilisez « from active database » d’Oracle 11g, ce n’est pas obligatoire !
• « RMAN RESTORE & RECOVER » est une solution qui fonctionne dans tous les cas et qui offre le terrible avantage, en plus de ne pas nécessiter de connexion réseau entre vos serveurs source et cible, de valider que vous serez capable le cas échéant de restaurer votre base de données sur un autre serveur.
• « RMAN BACKUP AS COPY » peut également, élégamment, remplacer la commande cp que vous feriez habituellement puisqu’en outre, il n’est pas nécessaire de passer votre base de données en mode BACKUP (BEGIN/END)
• La bonne vieille méthode du mode BACKUP (BEGIN/END) fonctionne aussi. Vous pourrez sans doute remplacer le « cp » par ftp ou WebDAV, ce que je ne m’aventurerai pas à faire sur autre chose qu’une demo. Vous pourrez surtout utiliser ce mode avec un mécanisme de copie ou de snapshot au niveau du stockage (EMC BCV, NetApp SnapClone, …). Dans ce dernier cas, pas le plus inintéressant, vous copierez le Disk Group complet. Allez voir cet article Alejandro Vargas à propos d’ASM et des BCV mais qui s’applique à toute une palette de technologies de stockage. J’imagine que cet article à un petit frère sur Metalink.

Revenons à la chanson ringarde que j’ai dans la tête depuis 3 jours : (La mélodie) Comment faire des tests sur mon desktop Ubuntu Gutsy Gibbon ? Merci à Dave Edwards qui m’a aidé, encore une fois, dans l’élaboration de la réponse à cette question sur ce post de mon autre blog ! (Le solo de batterie) Est-il possible de renommer un Disk Group et remonter le BCV dans la même instance ASM ? Alejandro Vargas répond catégoriquement non en 10g mais s’il existe un moyen en 11g, je trouverai ! (Les paroles) Existe-t-il une autre méthode pour copier une base de données ? La réponse est « oui » et c’est même la méthode la plus simple que je connaisse, même si, comme les autres, elle a ses limites : « Vous pouvez utiliser les capacités de création d’un clone de base de données de DBCA ! »

Pour commencer et pour mieux appréhender Oracle Database Configuration Assistant (DBCA) , vous pouvez configurer votre environnement Oracle et lancer la commande qui suit :

dbca -h

Pour copier votre base de données d’un environnement ASM à un autre environnement distinct, vous allez :

1. Créer un template de votre base de données; DBCA utilisera alors de manière cachée RMAN, sans arrêter la base de données, pour constituer l’ensemble des fichiers du template
2. Déplacer votre template d’un serveur à un autre par le moyen de votre choix (NFS, ftp/scp, umount/mount d’un système de fichier, …)
3. Créer une base de données à partir de votre template

Etape 1 : Créer un template de votre base de données

Nous supposerons que vous avez créé un répertoire /source/template pour stocker la copie de votre base de données et que votre base de données source s’appelle BLUJ. Positionnez l’environnement Oracle correspondant à celui de la base de données et lancez DBCA comme ci-dessous :

$ dbca -silent -createCloneTemplate    
     -sourceSID BLUJ                   
     -templateName BLUJ_template       
     -sysDBAPassword change_on_install 
     -maintainFileLocations false      
     -datafileJarLocation /source/template

La chaîne de caractère qui suit « -templateName » est le nom du template qui sera généré. Choisissez celui qui vous contient et notez le bien puisqu’il sera réutilisé lors de la création de la base de données sur votre cible. « -sysDBAPassword » indique le mot de passe de l’utilisateur SYS (ou d’un autre SYSDBA si vous utiliser en outre « -sysDBAUserName »). Utilisez « -maintainFileLocations false » pour pouvoir déplacer les fichiers dans un autre Disk Group sur votre cible.

Lorsque vous exécutez la commande (Utilisez nohup !), le résultat ressemble à ce qui suit :

Gathering information from the source database
4% complete
8% complete
13% complete
17% complete
22% complete
Backup datafiles
28% complete
88% complete
Creating template file
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/silent9.log" for further details.

3 fichiers sont générés :

• un fichier xml [templateName].dbc (i.e. BLUJ_template.dbc dans ce cas) situé dans $ORACLE_HOME/assistants/dbca/templates. Ce fichier contient la description du template
• un fichier de contrôle [templateName].ctl situé dans /source/template
• un fichier [templateName].dfb situé dans /source/template qui contient les fichiers de données de votre base de données source.

Etape 2 : Déplacer votre template d’un serveur à un autre

Vous avez le choix des armes ! Pour simplifier, nous dirons simplement que vous copiez l’ensemble des fichiers générés dans /source/template dans /cible/template et que vous copiez le fichier BLUJ_template.dbc dans le répertoire $ORACLE_HOME/assistants/dbca/templates que vous allez utiliser pour la cible.

Note :
C’est évident mais ça va mieux en le disant que la version du logiciel de base de données et que le système d’exploitation doivent être identiques entre la source et la cible.

Etape 3 : Créer une base de données à partir de votre template

Nous supposerons que le logiciel de base de données est installé sur votre machine cible. ASM est démarré et un Disk Group DGREDX est monté pour accueillir la copie de votre base de données. Nous appellerons la base de données cible REDX pour cet exemple

$ dbca -silent -createDatabase           
    -templateName BLUJ_template.dbc      
    -gdbName REDX                        
    -sysPassword c
hange_on_install       
    -systemPassword manager              
    -datafileJarLocation /cible/template 
    -storageType ASM                     
       -asmSysPassword change_on_install 
       -diskGroupName DGREDX             
    -totalMemory 250

La chaîne de caractère qui suit « -templateName » est le nom du template généré à l’étape 1. « -sysPassword » et « -systemPassword » indiquent les mots de passe de SYS et SYSTEM. « -datafileJarLocation » indique l’emplacement des fichiers du template ; ce paramètre n’est pas nécessaire si vous laissez les 2 fichiers dans le même endroit. « -asmSysPassword » indique le mot de passe de l’utilisateur SYS d’ASM tandis que « -diskGroupName » indique le DiskGroup dans lequel la base de données sera créée. « -totalMemory » indique la valeur de MEMORY_TARGET en Mega Octets et est une nouvelle option de 11g.

Lorsque vous exécutez la commande (Utilisez nohup), le résultat ressemble à ce qui suit :

Copying database files
1% complete
3% complete
37% complete
Creating and starting Oracle instance
40% complete
45% complete
50% complete
55% complete
56% complete
57% complete
60% complete
62% complete
Completing Database Creation
66% complete
70% complete
73% complete
77% complete
88% complete
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/REDX/REDX0.log" for further details.

Vous pouvez ensuite adapter le paramétrage à vos besoins. Vous vérifierez que les fichiers ont été créés dans ASM en interrogeant le dictionnaire de REDX :

$ source oraenv
ORACLE_SID = [REDX] ?
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 is /u01/app/oracle

$ sqlplus / as sysdba

SQL> select file_name
    from dba_data_files;

FILE_NAME
-----------------------------------------
+DGREDX/redx/datafile/users.261.646254099
+DGREDX/redx/datafile/undotbs1.260.646254099
+DGREDX/redx/datafile/sysaux.259.646254097
+DGREDX/redx/datafile/system.258.646254091

Conclusion

C’est, sans doute, la manière la plus simple de copier une base de données sans l’arrêter. C’est particulièrement adapté si votre base de données cible est un RAC puisque DBCA pourra, en outre, faire toute la configuration des instances en collaboration avec le clusterware. Pour ce qui est des limites, il ne semble pas possible en mode ligne de commande de positionnez les fichiers dans des Disk Group distinct et surtout, je n’ai trouvé aucun moyen de changer le parallélisme pour constituer le template et le restituer. Enfin, les capacités de DBCA restent assez obscures malgré tous mes efforts. Si vous savez comment maîtriser ses options ou où trouver la doc associée, faites-moi un signe !

PS: Vous pouvez tout faire en mode graphique si vous préférez utiliser le mulot

PS2 : Si vous voulez vous amuser et faire des tests en série, voici une autre commande très utile :

dbca -silent -deleteDatabase           
     -sourceDB REDX                    
     -sysDBAPassword change_on_install