Clonage d'une base avec RMAN

Samedi 4 octobre 2008 6 04 /10 /Oct /2008 15:07

Clonage d'une base avec RMAN

Bonjour à tous,

REMARQUE: Cet Article est un des premiers de mon blog et cependant d'après les statistiques, il s'agit d'un des articles les plus "lu" ou du moins accèdé. Il serait interessant pour moi que vous preniez le temps d'y laisser un petit commentaire pour m'indiquer si il vous a été utile ou ce qui a manqué pour vous aider. Merci par avance.

Voici donc mon premier thème. On ne peut pas dire que je commence par le plus simple. En effet nous allons "cloner" une base. Pour cela nous allons utiliser RMAN, outil fourni gracieusement par ORACLE et dont l'objet premier est de s'occuper des sauvegardes.
Pour beaucoup, effectuer une sauvegarde consiste à faire des exports ...
Nous essaierons de montrer dans un prochaine article que cela n'est :

Pas performant.
Pas suffisant.

A part pour ceux qui font partie du monde de la production ou de l'exploitation, RMAN n'est peut être pas familier.
Je pense notamment aux editeurs de logiciel qui s'appuient sur une base comme ORACLE.
Or pour avoir travaillé preque 8 ans chez des editeurs, je sais que l'on est souvent confrontés à des problèmes de duplication d'environnement (Dev vers test, test vers pre-prod...)

Alors on peut faire des exports, des imports, mais lorsqu'il s'agit de de repeter ces opérations sur des bases volumineurses, nous sommes vite confrontés à des problèmes de "temps" !

Pour commencer avec quelque chose de simple, nous allons dupliquer une base dans un environnement WINDOWS sur la même machine.

Envrionnement :
ORACLE 10.2.0.1 (Personnal Edition) avec un OS classique : WINDOWS XP PRO.

Une base à dupliquer qui a pour SID ORADB.

Etape 1: Passer notre base en mode "ARCHIVELOG"

Demarrer > Executer > cmd.exe

lancer l'utilitaire SQL+ en tapant sqlplus / nolog

SQL> Connect / as sysdba (attention, il faut etre en local pour executer cette commande)
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Etape 2: Effectuer une sauvegarde complète de la base.

Demarrer > Executer > cmd.exe

Dans le cas, ou nous avons plusieurs bases sur notre machine, nous positionnons la variable d'environnement sur la base à dupliquer.

SET ORACLE_SID=ORADB

Nous pouvons maintenant appeler l'utilitaire rman en tapant tout simplement dans l'invite de commande RMAN

Remarques: Par défaut les fichiers de sauvegardes, et les fichier d'archives sont placés dans la FRA (Flash Recovery Area). A l'installaltion d'ORACLE, cette zone a une valeur maximal de 2 G. Si vous disposez d'une base volumineuse, il convient d'augmenter cette taille.

Se connecter en System:

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE= 10 G;

Nous pouvons également modifier l'emplacement de la FRA (par défaut /ORACLE_HOME/flash_recovery_area/)

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST=C:\My_FRA_Dest;

RMAN> CONNECT TARGET /
RMAN> BAKCUP FULL DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;

Etape 3: Créer l'arborescence pour acceuillir la base clonée.

ex: C:\ORACLE\PRODUCT\10.2.0\admin\ORADB pour les répertoires pfile,udump,bdump,...
et C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORADB pour les fichiers de données, redo, ....

Si nous voulons que la nouvelle base s'appelle DUP, il faut alors créer une arborescence du type
C:\ORACLE\PRODUCT\10.2.0\admin\DUP et créer les différents répertoires comme pour ORADB
et également créer C:\ORACLE\PRODUCT\10.2.0\ORADATA\DUP à vide.

Etape 4: Créer un fichier init.ora pour la base DUP.

Pour cela, nous allons tout simplement compier le ini.ora (qui peut avoir un autre nom) qui se trouve dans C:\ORACLE\PRODUCT\10.2.0\admin\ORADB\pfile dans C:\ORACLE\PRODUCT\10.2.0\admin\DUP\pfile

Pour simplifier, si ce n'est pas le cas, renommez le init.ora

Il va maintenant falloir editer ce fichier init.ora pour remplacer ORADB par DUP partout dans le fichier (emplacement de fichier, nom de base), utiliser la fonction "rechercher & remplacer" de votre editeur pour etre sur de ne pas en oublier.

Cela n'est cependant pas suffisant, nous allons ajouter à la fin de notre fichier init.ora fraichement modifié les deux lignes suivantes:

DB_FILE_NAME_CONVERT=('ORADB','DUP')
INSTANCE_NAME='DUP'

ATTENTION : Modifier également le cas échéant les paramètres relatifs à la mémoire (SGA & PGA) afin de ne pas utiliser la totalité de la RAM disponible sur votre PC.

Etape 5 : Créer une nouvelle instance.

Demarrer > Executer > cmd.exe puis tapez la commande suivante
ORADIM -new -sid DUP

Etape 6: Démarrer l'instance créer.

Nous allons démarrer l'instance DUP en mode no mount et indiquer le fichier ora à utiliser pour lancer l'intance.
Demarrer > Executer > cmd.exe

SET ORACLE_SID=DUP
sqlplus / nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP NOMOUNT pfile='c:\ORACLE\PRODUCT\10.2.0\admin\pfile\init.ora';
SQL> DISCONNECT;
SQL> QUIT

Etape 7: Clonage de la base ORADB

Demarrer > Executer > cmd.exe puis :

SET ORACLE_SID=DUP
rman target sys/oracle@ORADB auxiliary /
RMAN> DUPLICATE TARGET DATABASE TO DUP
pfile=C:\ORACLE\PRODUCT\10.2.0\admin\pfile\init.ora
logfile
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\redo01.dbf' size 50m,
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\redo02.dbf' size 50m,
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\redo01.dbf' size 50m;

Il suffit d'attendre un peu, et finalement la duplication se termine, connectez vous alors à DUP et verifiez que vos users, schemas sont bien présents.

Conclusion: Bon nombre de personnes pensent que la duplication de base ou l'utilisation de RMAN sont des choses complexes. Je ne remettrai pas en cause le fait que la problématique des sauvegardes n'est pas aisée, mais finalement si vous prenez le temps d'effectuer les 7 étapes ci-dessus, vous vous rendrez compte qu'en moins de trente minutes vous aurrez effectué un clonage de base en utilisant RMAN !

Si vous avez passé votre base en ARCHIVELOG pour effectuer ces opérations, je vous conseille de la repasser en mode NOARCHIVELOG. Pour cela rien de plus simple.

Demarrer > Executer > cmd.exe

lancer l'utilitaire SQL+ en tapant sqlplus / nolog

SQL> Connect / as sysdba (attention, il faut etre en local pour executer cette commande)
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE NOARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Liens utiles:

Clonage d'une base en mode no archivelog sur un serveur distant
Clonage d'une base en mode archivelog sur un serveur distant

LAO.

Plus
- Email
- Lien
- Imprimer

Par LAO - Publié dans : Clonage de base - Communauté : ORACLE
Ecrire un commentaire - Voir les 10 commentaires

Précédent : Amis d'ORACLE, bonjour ! Retour à l'accueil Suivant : Flashback ou l'art de la magie (1ère...

Commentaires

Merci pour ces articles clairs et bien détaillés. Les exemples sont vraiment appréciables, bonne continuation !!

Commentaire n°1 posté par Guillaume le 10/12/2008 à 10h31

De, rien pensez à vous inscrire à la news letter pour être averti de la présence de nouveaux articles.
LAO.

Réponse de LAO le 10/12/2008 à 10h40

Merci pour tous ces articles de qualité. A propos de la duplication via RMAN, j'aimerais avoir quelques éclaircissements : 1- Le mode archivelog est-il nécessaire pour effectuer la duplication. J'ai une base de prod qu'il m'est impossible de mettre en archivelog (refus du client à cause de problème d'éspace disque), mais dont j'aimerais cloner les données sur la base de Dev. 2- La procédure décrite ici est valable pour un clonage sur le même serveur. Dans mon cas, les bases de Prod et de Dev sont sur deux serveurs distincts (normal !). La procédure sera-t-elle grandement modifiée ou suffira-t-il simplement d'indiquer par un paramétrage judicieux l'emplacement de la base de Dev ? Un grand merci d'avance.

Commentaire n°2 posté par wahren le 06/01/2009 à 11h37

Bonjour,

Merci pour les encouragements.
-1/ Effectivement, même si la base n'est pas en archivelog, cela devrait fonctionner.Si jamais tu fais le test avant moi, n'hesites pas à me faire un retour.
-2/ La procédure de clonage, sur un host différent reste très proche. Je ferai un article complet dessus (très ) prochainement.

Laurent

Réponse de LAO le 06/01/2009 à 14h23

Bonjour, J'ai effectué le clonage avec succès de ma base sans archivelog. Il m'a semblé nécessaire d'avoir non seulement la sauvegarde à froid de la base, mais en plus les fichiers log de la base source au moment de la sauvegarde (chose à confirmer). Voilà mes étapes : 1- préparer le serveur pour avoir le même filesysteme que le serveur d'origine (de Prod). 2- Préparer les fichiers de configuration *.ora 3- Récupérer le coldbackup de la base d'origine ainsi que les fichiers log au moment de la sauvegarde. 4- Restauration RMAN : $> rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Jeu. Janv. 15 12:38:48 2009 Copyright (c) 1982, 2005, Oracle. All rights reserved. connecté à la base de données cible (non démarrée) RMAN> set dbid=; --> ce dbid apparaît dans le nom de la sauvegarde du fichier de contrôle C--20090115-00 exécution de la commande : SET DBID RMAN> startup nomount; instance Oracle démarrée Total System Global Area (SGA) 901775360 octets Fixed Size 1293720 octets Variable Size 583008872 octets Database Buffers 314572800 octets Redo Buffers 2899968 octets RMAN> run { set controlfile autobackup format for device type disk to '/%F'; restore controlfile from '\C--20090115-00'; --> sauvegarde du fichier de contrôle alter database mount; restore database; recover database; alter database open resetlogs; } Et ça marche comme sur des roulettes ! Ne pas oublier de faire une sauvegarde de la nouvelle base tout de suite après le clonage.

Commentaire n°3 posté par Wahren le 20/01/2009 à 14h31

Bonjour,

Merci pour les informations. Tu n'as pas essayé avec la fonction duplicate ? Car du coup, ton opération ressemble plus à une restauration qu'un clonage. Dans le cas ou tu voudrais intégrer cette base dans un plan de sauvegarde avec utilisation d'un catalog, cela risquerait de poser un problème vu qu'elles auront le même SID.
Encore merci pour le retour.

LAO

Réponse de LAO le 20/01/2009 à 14h39

Désolé pour la mise en forme de mon post !

Commentaire n°4 posté par Wahren le 20/01/2009 à 15h13

Pas grave !

Réponse de LAO le 20/01/2009 à 15h25

En reprenant la réponse que j'ai donnée par mail, je dirais que je n'ai pas utilisé la commande DUPLICATE car à l'origine mon soucis était de mettre en place une procédure de récupération de la base après un crash système. Donc je ne suis sensé n'avoir de la base source que les sauvegardes (dans mon cas, sauvegarde RMAN à froid sauvegardée par TSM dans un serveur de secours). La procédure que j'ai présentée ici, est donc prévue pour être utilisée dans le cas d'un PRA (ou DRP). Wahren

Commentaire n°5 posté par Wahren le 21/01/2009 à 00h59

Bonjour LAO et compliments pour votre site et vos informations sur le clonage...

J'ai une question (peut-être de néophyte) à poser...

Comment pouvez-vous reprendre le Dump full ‘RMAN’ de l’instance source d’un client et l'implémenter sur une de nos base cible quand celle-ci se trouve sur un autre serveur et qu'il n'y a pas de lien entre les serveurs (et les instances) du client et les nôtres (ils ont leur propre RMAN et nous le notre !)

En fait, le dump full et les archivelogs (de la base source) me seront envoyés par FTP et qu'il faudra que je me débrouille avec...

Est-ce possible, quand il y a vraiment une étanchéité entre deux serveurs et deux instances, de reprendre tout le bazar à partir d'un envoi FTP de la full et des logs du client ?

Quand je lis sur l’étape 5 de votre article

RMAN target sys/*****@DB1_SRV1 auxiliary /
run
etc…

Il semblerait qu’il faille se connecter à l’instance source sur le serveur source du client… Or moi, je n’aurais que des ‘fichiers’ dumps envoyés par FP…

J’ai peut-être mal compris le problème et peut-être alors pouvez-vous m’éclairer…

Commentaire n°6 posté par Vincent le 17/08/2010 à 16h07

Bonjour,

Merci pour cet article simple et clair.

Cdlt,

Hamid

Commentaire n°7 posté par Hamid le 12/10/2010 à 11h32

Merci pour les remerciements !

LAO

Réponse de LAO le 12/10/2010 à 16h09

Bonjour,

Je rencontre un problème avec votre procédure de clonage. J'ai suivi vos instructions mais suite à la commande 'DUPLICATE TARGET DATABASE TO DBDUP' (ma base vide s'appelle DBDUP et celle qui contient les schémas d'origine s'appelle DBJMN) il faut renseigner le fichier init.ora. Dans votre commande 'pfile='C:ORACLEPRODUCT10.2.0adminpfileinit.ora', je ne sais pas de quel init.ora il 'sagit. Logiquement, il doit s'agir du init.ora de ma base vide DBDUP.

Je précise encore que j'utilise votre procédure de clonage avec un serveur Oracle 11gR2 tournant sous Windows XP Pro. Est-ce incompatible avec votre procédure de clonage ?

Voici les messages d'erreurs:

canal ORA_AUX_DISK_1 : dÚmarrage de la restauration de l'ensemble de sauvegarde des fichiers de donnÚes
canal ORA_AUX_DISK_1 : restauration de fichier de contr¶le
canal ORA_AUX_DISK_1 : lecture de l'ÚlÚment de sauvegarde D:ORACLEFLASH_RECOVERY_AREADBJMNBACKUPSET2011_01_26O1_MF
_NCSNF_TAG20110126T090216_6MZOB1CQ_.BKP
canal ORA_AUX_DISK_1: ORA-19504: Úchec de crÚation du fichier "D:ORACLEFLASH_RECOVERY_AREADBDUPCONTROL02.CTL"
ORA-27040: erreur lors de la crÚation du fichier : crÚation impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 3) Le chemin d'accÞs spÚcifiÚ est introuvable.
ORA-19600: le fichier d'entrÚe est control file (D:ORACLE112DBORADATADBDUPDBDUPCONTROL01.CTL
Fin de restore dans 26/01/11

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande Duplicate Db Ó 01/26/2011 09:21:37
RMAN-03015: une erreur s'est produite dans le script stockÚ Memory Script
RMAN-06136: erreur ORACLE provenant de la base de donnÚes auxiliaire : ORA-00205: erreur lors de l'identification du fic
hier de contr¶le; consultez le journal d'alertes

Ayant constaté que le sous-répertoire DBDUP n'existait pas sous FLASH_RECOVERY_AREA, je l'ai créé puis j'ai relancé l'ensemble des commandes sans me reconnecter à RMAN = rman target sys/oracle@DBJMN auxiliary / et j'ai obtenu un autre message d'erreur que voici:

RMAN> duplicate target database to DBDUP pfile='D:OracleadminDBDUPpfileinit.ora'
2> logfile
3> 'D:Oracle112DBoradataDBDUPDBDUPredo01.dbf' size 50m,
4> 'D:Oracle112DBoradataDBDUPDBDUPredo02.dbf' size 50m,
5> 'D:Oracle112DBoradataDBDUPDBDUPredo03.dbf' size 50m;

DÚmarrage de Duplicate Db dans 26/01/11
utilisation du canal ORA_AUX_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande Duplicate Db Ó 01/26/2011 09:31:56
RMAN-05520: non-concordance des noms de base de donnÚes : DBJMN dans l'instance auxiliaire et DBDUP dans la commande

Sauriez-vous me dire ce qui se passe et quelle est la solution à ce problème ?

Cordiales salutations
Jean-Michel

Commentaire n°8 posté par Jean-Michel le 26/01/2011 à 10h01

Bonjour, A l'époque le test était avec une 10g donc je ne "certifie " pas que cela fonctionne sous 11gR2, même si je pense qu'il ne doit pas y avoir de soucis. Juste pour remettre le contexte. Il s'agit d'un clonage mais sur la même machine (il y a également deux autres articles sur le clonage). Donc la base d'origine démarre avec pfile (ou spfile). Mais pour la base destination, je suis obligé de créer un pfile (le fameux init.ora). C'est ce fichier que j'utilise plus loin dans la base pour démarrer l'instance cible. "STARTUP NOMOUNT pfile='c:\ORACLE\PRODUCT\10.2.0\admin\pfile\init.ora';" Evidemment vous êtes libre au niveau des chemins. @+ LAO

Réponse de LAO le 28/01/2011 à 13h14

Merci LAO pour votre réponse et la deuxième tentative a été la bonne :)
Maintenant, je souhaiterais pouvoir configurer une console EM pour cette nouvelle base clonée. Savez-vous comment faire ?

Encore merci et excellente journée

Jean-Michel

Commentaire n°9 posté par Jean-Michel le 02/02/2011 à 09h41

Bonjour, J'avais écris un petit article sur la désinstallation / installation (par script): http://www.lao-dba.com/article-25766784.html C'était sur du 10gR2 (y a peut être des adaptations pour la 11g). Sinon, il suffit de l'installation via DBCA. @+ LAO

Réponse de LAO le 02/02/2011 à 14h17

Bonjour, juste pour dire merci pour cet article qui m'a bien édifié sur le clonnage de la Base de données.

Bonne continuation

A+ Ferdinand

Commentaire n°10 posté par Ferdinand le 29/08/2011 à 22h22

Merci pour le "remerciement". Ca fait toujours plaisir de savoir que ce qu'on fait peut être utile ! @+

Réponse de LAO le 31/08/2011 à 07h40