Dans certains cas, on est parfois contraint de déplacer les fichiers d’une base de données comme pour :
- un problème de place
- un changement d’infrastructure en cas de problème de performance
- un passage sous ASM
- etc…
Quelque soit le cas, plusieurs solutions sont envisageables.
La plus simple :
On met a disposition a disposition les directories sous un nom temporaire.
On arrête la base.
A l’aide d’une commande OS on copie les fichiers de base de données de l’emplacement d’origine vers la nouvelle destination.
On renomme les directories temporaire en directories d’origine
Et enfin, on redémarre la base de données.
Suivant la volumétrie de la base cela peut prendre plus ou moins de temps, mais c’est efficace.
Seul problème, ce n’est pas possible pour les bases sous ASM. Elle ne permet pas non plus le passage de l’architecture filesystem vers ASM
Autre solution qui nécessitera aussi un arrêt de la base
Faire un backup du controlfile à l’aide de la commande
Alter database backup controlfile to trace as 'mon_controlfile.bck' resetlogs;
Editez le fichier généré et modifier la localisation des fichiers de base de données.
Les redologs
GROUP 1 ('/u02/redoa/MABDD/redo1a.rdo',
'/u02/redob/ MABDD /redo1b.rdo')
SIZE 400M BLOCKSIZE 512,
Devient
GROUP 1 ('/u02/redoa/NEWBDD/redo1a.rdo',
'/u02/redob/ NEWBDD /redo1b.rdo')
SIZE 400M BLOCKSIZE 512,
Les dbf
DATAFILE '/u02/oradata/ MABDD /system01.dbf', '/u02/oradata/ MABDD /sysaux01.dbf', '/u02/oradata/ MABDD /undotbs01.dbf', ...
Devient
DATAFILE '/u02/oradata/ NEWBDD /system01.dbf', '/u02/oradata/ NEWBDD /sysaux01.dbf', '/u02/oradata/ NEWBDD /undotbs01.dbf', ...
Les dbf temporaires
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/MABDD/temp01.dbf' SIZE 32767M REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
Devient
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/NEWBDD/temp01.dbf' SIZE 32767M REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
Et ainsi de suite
Déplacez les fichiers de base de données.
Redémarrez la base à l’aide du script modifié.
Le tour est joué. Cette solution a l’avantage de marcher que l’on soit en filesystem ou en ASM . Elle permet la migration de l’architecture Filesystem vers ASM, mais encore une fois, selon la taille de la base elle peut prendre beaucoup de temps.
Autre méthode possible mais moins efficace,
Tablespace par tablespace ,
mettre ce dernier offline
Alter tablespace MON_TABLESPACE offline NORMAL;
A l’aide d’une commande OS, Copiez les dbf associés vers leur nouvelle localisation
Renommez les dbf au niveau Oracle
Alter tablespace MON_TABLESPACE rename datafile '/u02/oradata/MABDD/mon_tablespace_01.dbf'
to '/u02/oradata/NEWBDD/mon_tablespace_01.dbf';
Remettre le tablespace online.
Alter tablespace MON_TABLESPACE online ;
La base reste ouverte, mais une partie des données est indisponible. On est donc dans un mode très dégradé. De plus se pose le problème des tablespaces system et undo que l’on ne peut pas déplacer avec cette méthode.
Et enfin celle qui permet le minimum d’indisponibilité et qui a ma préférence :
le déplacement des fichiers a l’aide de RMan
Un seul prés requis :
La base doit être en mode ARCHIVELOG.
Repérez les fichiers à déplacer et générer les commandes RMAN adéquates.
pour déplacer tous les fichiers d’une base
select 'copy datafile' || file# || ' to ''' || name ||''' ;' from v$datafile;
pour une base avec 9 dbf, on obtient un script du genre :
copy datafile 9 to '/u02/oradata/MABDD/indx_tbs_01.dbf' ; copy datafile 8 to '/u02/oradata/MABDD/data_tbs_04.dbf' ; copy datafile 7 to '/u02/oradata/MABDD/data_tbs_03.dbf' ; copy datafile 6 to '/u02/oradata/MABDD/data_tbs_02.dbf' ; copy datafile 5 to '/u02/oradata/MABDD/data_tbs_01.dbf' ; copy datafile 4 to '/u02/oradata/MABDD/user_01.dbf' ; copy datafile 3 to '/u02/oradata/MABDD/undotbs1_01.dbf' ; copy datafile 2 to '/u02/oradata/MABDD/sysaux_01.dbf' ; copy datafile 1 to '/u02/oradata/MABDD/system_01.dbf' ;
Editez le script obtenu et modifiez la localisation des fichiers. Attention si le nom du fichier est au format OMF il faut le modifier en un nom plus parlant.
copy datafile 9 to '/u02/oradata/NEWBDD/indx_tbs_01.dbf' ; copy datafile 8 to '/u02/oradata/NEWBDD/data_tbs_04.dbf' ; copy datafile 7 to '/u02/oradata/NEWBDD/data_tbs_03.dbf' ; copy datafile 6 to '/u02/oradata/NEWBDD/data_tbs_02.dbf' ; copy datafile 5 to '/u02/oradata/NEWBDD/data_tbs_01.dbf' ; copy datafile 4 to '/u02/oradata/NEWBDD/user_01.dbf' ; copy datafile 3 to '/u02/oradata/NEWBDD/undotbs1_01.dbf' ; copy datafile 2 to '/u02/oradata/NEWBDD/sysaux_01.dbf' ; copy datafile 1 to '/u02/oradata/NEWBDD/system_01.dbf' ;
Un fois fait, connectez vous a rman et lancez la liste des commandes précédemment obtenue.
rman target / @mon_script_de copy
la base est ouverte donc disponible. le temps de copie n’a donc pas d’importance.
une fois la copie terminée, il faut arrêter la base et la redémarrer en mode mount.
si seul quelques fichiers ont été déplacés lancer les commandes suivantes sous RMAN:
rman target / switch datafile 9 to copy; recover datafile 9;
si tous les fichiers ont été déplacés :
rman target / switch database to copy; recover database;
une fois cela fait, si nécessaire, il reste à déplacer les dbf temporaires, les redolog et pourquoi pas les controlfiles.
les redologs
cela se fait à chaud en ajoutant de nouveaux groupe et en supprimant les anciens.
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 11 ('/u02/redoa/NEWBDD/redo_11a.log','/u02/redob/NEWBDD/redo_11b.log') SIZE 200M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 12 ('/u02/redoa/NEWBDD/redo_12a.log','/u02/redob/NEWBDD/redo_12b.log') SIZE 200M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 13 ('/u02/redoa/NEWBDD/redo_13a.log','/u02/redob/NEWBDD/redo_13b.log') SIZE 200M;
ALTER DATABASE DROP LOGFILE THREAD 1 GROUP 1;
ALTER DATABASE DROP LOGFILE THREAD 1 GROUP 2;
ALTER DATABASE DROP LOGFILE THREAD 1 GROUP 3;
Même chose pour les fichiers temporaires.
pour les controlfiles, il faut , au préalable, modifier le paramètre d’initialisation
alter system set control_files='/u02/ctrla/NEWBDD/control01.ctl','/u02/ctrlb/NEWBDD/control02.ctl' sid='*' scope=spfile;
Puis, profitez de arrêt la base pour copier les controlfiles à leurs nouvelles localisations et redémarrez la base.
Une fois le bon fonctionnement validé, on peut supprimer les fichiers toujours présents sur l’ancienne infrastructure.
Sous Rman
delete copy of datafile 1; delete copy of datafile 2; … delete copy of datafile n;
Et voila. Le temps d’indisponibilité dépend de l’activité de la base. Plus la base est active plus le recover va être long. Un retour arrière est possible. La manip est simple et sécurisé car on n’utilise que des technologies Oracle.
Faite votre choix et à vous de jouer.
