Le but du clonage est de mettre à disposition des équipes de développement ou de recette une copie de la base de production a un instant T. Pour ce faire, on part d’une sauvegarde de la base faite à l’aide de l’utilitaire RMAN. L’intérêt de partir d’une sauvegarde plutôt que de dupliquer directement la base de production ( ce qui est possible sans sauvegarde depuis la version 11gR2) est que l’on ne perturbe pas le fonctionnement de la base d’origine qui est généralement une base de production.
On abordera ici le clonage d’une base en standalone vers une base en standalone , d’une base en RAC vers une base en standalone , une base en RAC vers une base en RAC et une base en standalone vers une base en RAC.
Attention, Il s’agit ici d’une copie physique d’une base sur une autre. Une fois le clonage terminé, les users et password de la base clonée sont les mêmes que sur la base d’origine. Tout ce qui pouvait faire la spécificité de la base de destination, et qui n’est pas un paramètre d’initialisation, a disparu.
Partons du principe que l’on veuille cloner la base de production BDDPROD sur la base de recette BDDR7.
Les prérequis :
Cela peut paraître trivial, mais les versions des bases de données doivent être identique.
- Recherche de l’espace disque nécessaire.
Pour cela on exécutera la requête suivante sur la base BDDPROD
select fs_name ||’@#@’||to_char( floor((sum(vol)/1024/1024)+0.5))
from
(
select substr(f.file_name,1,instr(f.file_name ,’/’,-2)-1) fs_name , sum(bytes) vol
from dba_data_files f
group by substr(f.file_name,1,instr(f.file_name ,’/’,-2)-1)
union
select substr(member,1,instr(member,’/’,-1)-1) fs_name,sum(bytes) vol
from v$logfile m,v$log l
where l.group#=m.group#
and type = ‘ONLINE’
group by substr(member,1,instr(member,’/’,-1)-1)
union
select substr(name,1,instr(name,’/’,-1)-1) fs_name,0 vol
from v$controlfile
where IS_RECOVERY_DEST_FILE = ‘NO’
group by substr(name,1,instr(name,’/’,-1)-1)
union
select substr(name,1,instr(name,’/’,-1)-1) fs_name,sum(bytes) vol
from v$tempfile
group by substr(name,1,instr(name,’/’,-1)-1)
)
group by fs_name;
Cette requête ramène le volume de fichier de base de données par filesystem ou volume ASM. On a donc une bonne estimation de la volumétrie minimum à mettre en place sur l’environnement clone
Par exemple
/localisation/control/file 0M
/localisation/redo/log 600M
/localisation/data/files_1 500G
/localisation/temp/files 32G
/localisation/undo/dbf 64G
A partir des informations recueillies précédemment, on peut contrôler que l’on dispose bien des volumes disques sur l’environnement clone.
Par exemple
/nouvelle/localisation/control/file 600M
/nouvelle/localisation/redo/log 10240M
/nouvelle/localisation/data/files_1 600G
/nouvelle/localisation/temp/files 64G
/nouvelle/localisation/undo/dbf 120G
- Mise a jour du paramétrage de la base clone.
Suivant le cas de figure les modifications sont les suivantes :
Dans le cas de clonage de base standalone vers une base standalone pas de modifications de paramétrage à faire du coté de la base BDDR7.
Dans le cas de clonage d’une base en standlone vers une base en RAC, il faut modifier les paramètres suivants dans le fichier d’initialisation ( pfile ou spfile ) de la base BDDR7.
*._no_recovery_through_resetlogs=TRUE
*.cluster_database=false
Dans le cas de clonage d’une base en RAC vers une base en RAC, il faut modifier les paramètres suivants dans le fichier d’initialisation ( pfile ou spfile ) de la base BDDR7.
*._no_recovery_through_resetlogs=TRUE
*.cluster_database=false
Dans le cas de clonage d’une base en RAC vers une base en standalone, il faut modifier le paramètre suivant dans le fichier d’initialisation ( pfile ou spfile ) de la base BDDR7
*._no_recovery_through_resetlogs=TRUE
- Mise a jour du fichier tnsnames.ora
Le serveur sur lequel la base de recette est installée doit pouvoir se connecter à la base de données de production. Il faut donc configurer le fichier tnsnames.ora en conséquence.
- mise en place de l’environnement TSM si TSM est utilisé
Si on utilise TSM et TDPO pour effectuer les sauvegardes, il faut que le serveur supportant la base clone puisse lire les sauvegardes de la base de production. Pour cela, il faut récupérer des fichiers de paramétrage TDPO du le serveur de production pour les copier sur le serveur de recette en les renommant.
Les fichiers à récupérer sont :
/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt
à renommer en
/opt/tivoli/tsm/client/oracle/bin64/tdpo_${TARGET_HOST}.opt
et
/opt/tivoli/tsm/client/oracle/bin64/TDPO.${TARGET_HOST}_ORA
à ne surtout pas renommer.
- Dans le cas de sauvegarde sur disque,
les fichiers de sauvegardes doivent être visibles des 2 environnements recette et production.
création du script de clonage mon_scripts_rman.
CONNECT TARGET sys/${SYS_PWD}@${TARGET_SID};
CONNECT AUXILIARY / ;
run
{
allocate auxiliary channel c1 type ‘SBT_TAPE’ parms ‘ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_${TARGET_HOST}.opt)’;
allocate auxiliary channel c2 type ‘SBT_TAPE’ parms ‘ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_${TARGET_HOST}.opt)’;
duplicate target database to ${ORACLE_SID}
db_file_name_convert = (
‘/localisation/control/file’,’/nouvelle/localisation/control/file’
,’/localisation/data/files_1′,’/nouvelle/localisation/data/files_1′
,’/localisation/temp/files’,’/nouvelle/localisation/temp/files’
,’/localisation/undo/dbf}’,’/nouvelle/localisation/undo/dbf’
)
until time « to_date(‘2012-03-03:14:00:00′,’YYYY-MM-DD:HH24:MI:SS’) »
logfile
GROUP 1 ( ‘/localisation/redo/log/redo1a.rdo’ , ‘/nouvelle/localisation/redo/log/redo1b.rdo’ ) size 204800K ,
GROUP 2 ( ‘/localisation/redo/log/redo2b.rdo’ , ‘/nouvelle/localisation/redo/log/redo2a.rdo’ ) size 204800K ,
GROUP 3 ( ‘/localisation/redo/log/redo3b.rdo’ , ‘/nouvelle/localisation/redo/log/redo3a.rdo’ ) size 204800K ;
}
Lancement du scripts de clonage
- avec catalogue Rman
rman rcvcat ${RMAN_USR}/${RMAN_PWD}@${RMAN_BDD}
@mon_script_rman
- Sans catalogue Rman
rman
@mon_script_rman
- mise a jour du paramétrage de la base clone
Dans le cas de clonage d’une base en standlone vers une base en RAC, il faut modifier les paramètres suivants dans le fichier d’initialisation ( pfile ou spfile ) de la base BDDR7.
*.cluster_database=TRUE
et supprimer le paramètre *._no_recovery_through_resetlogs des paramètres d’initialisation
Dans le cas de clonage d’une base en RAC vers une base en RAC, il faut modifier les paramètres suivants dans le fichier d’initialisation ( pfile ou spfile ) de la base BDDR7.
*.cluster_database=TRUE
et supprimer le paramètre *._no_recovery_through_resetlogs des paramètres d’initialisation
Dans le cas de clonage d’une base en RAC vers une base en standalone, il faut
supprimer le paramètre *._no_recovery_through_resetlogs des paramètres d’initialisation de la base BDDR7
Actions complémentaires liées au clonage de base standalone vers RAC
Une fois l’instance 1 du RAC cloné démarrée, il y a des opérations supplémentaires à effectuer. En effet lors du clonage d’une base en standalone, les redologs associés aux threads utilisés par les autres instances du RAC ne sont pas créés. Ils n’existent pas sur l’instance d’origine. Il faut donc les créés de toute pièce.
Pour cela, on se connecte sys sur l’instance1 du RAC.
On crée de nouveaux groupes de redologs attachés au thread des autres instances du RAC
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 21 (+NOUVELLE/localisation/redo/log/redo_21.log’) SIZE 10240K
On Active les différents threads ainsi créés.
ALTER DATABASE ENABLE THREAD 2
On crée les undos tablespaces supplémentaires, 1 par instance supplémentaire du RAC :
CREATE SMALLFILE UNDO TABLESPACE « UNDOTBS2 » DATAFILE ‘+NOUVELLE/localisation/undo/dbf/undotbs02.dbf’ SIZE 1024M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE 10240M
On peut maintenant démarrer les autres instances du RAC.
