You are on page 1of 3

Sauvegarde & restauration d'une base à froid avec

RMAN.
Encore une fois parlons un peu des sauvegardes. On distingue deux types de sauvegarde :

• Les sauvegardes dites à froid. Dans ce cas la base est inaccessible aux utilisateurs et l'on effectue une
simple copie de fichier qu'il conviendra de restaurer en cas de soucis.
• Les sauvegardes à chaud. Vous aurez compris, qu'il s'agit d'effectuer une sauvegarde base ouverte
pendant que les utilisateurs continuent de travailler sur leur base préférée. C'est généralement ce type de
configuration que l'on retrouve en mode de production ou l'on ne peut pas se permettre d'arrêter une
base pour la sauvegarder.

Cependant dans certains cas (Bureau d'étude, Editeur, environnement de test,..) on peut souhaiter mettre en place
une stratégie de sauvegarde sans pour autant que cela ne devienne trop compliqué.

Encore une fois, un peu de reflexion avant d'agir permettra de gagner du temps par la suite et d'éviter des
situations de crise.

Partons du postulat que la base est volumineuse et que pour tout arranger bon nombre de table contiennent des
colonnes de type CLOB.

Remarques : Les imports de tables ayant des colonnes de type BLOB sont tres long, car traités ligne à
ligne.

Solution 1: export pour la sauvegarde / import pour la restauration.

Par rapport notre cas d'étude, cela peut être envisageable mais risque de prendre énormément de temps.
Du coup en cas de perte de données, la restauration peut devenir problématique:

• Durée d'import / export relativement longue.
• En mode panique, on ne pense pas à tout. Et on peut oublier par exemple de créer les tables contenant
les CLOB (si on utilise toujours l'utilitaire imp.exe), de faire la redirection de tablespace (impdp.exe), et
surement d'autres problématiques qui ne me viennent pas à l'esprit.

Solution 2:On arrête la base, et on copie l'ensemble des fichier de la base sur bande ou vers un emplacement de
secours.

Du coup pour restaurer, il suffit d'arrêter à nouveau la base et de recopier les fichiers.
Comme tout le monde le sait, l'administration des bases et les tests de restauration chez la plupart des éditeurs
sont d'une priorité haute.(Ironie -) ). Du coup lors de la restauration, la probabilité qu'il manque un fichier de
données est assez haute et du coup la restauration de votre base devient des plus compliquée.

Je vous propose d'arrêter le "bricolage" et d'utilise ce qu'ORACLE a bien voulu mettre à notre disposition.
Je veux bien sur nommer RMAN (Recovery Manager).

Pour pouvoir restaurer, il faut bien sur avoir une sauvegarde.

Avant d'effectuer celle-ci, connecter vous avec un vous user de test, et créer quelques tables et remplissez les.
A moins que vous ayez (ce qui doit être le cas) des schémas applicatifs avec ce qu'il faut.

Etape 1: Effectuons une sauvegarde à froid de la base :

t2. SQL> DROP TABLE T3. RMAN target / RMAN> STARTUP MOUNT..t3.. RMAN> QUIT Remarque : A travers cet exemple. Original ?) Oups ! je voulais faire le contraire !! Vite passons en mode panique. un collègue de bonne volonté supprime les fichiers liés au tablespace SYSTEM (qui bien sûr n'étaient pas sauvegardés)==> lois de MURPHY (emmerdement maximum). RMAN> RESTORE DATABASE. on constate que RMAN dispose des droits permettant de stopper ou démarrer une base ! Etape 2 : Retournons dans SQL PLUS SQL> TRUNCATE TABLE T1. sqlplus / nolog SQL> CONNECT LAO/LAO --(c'est mon user de test avec trois table t1. RMAN> ALTER DATABASE OPEN. Tapez tout simplement et sans trembler CANCEL puis . . un petit message qui indique "Fin de restore dans DD/MM/YY" RMAN> QUIT Encore un petit effort.. Là vous recevez quelques insultes de notre ami ORACLE. Démarrer >Exécuter > cmd SET ORACLE_SID=ORADB ( si jamais il y a plusieurs bases sur votre poste).Démarrer > Executer > cmd sqlplus / nolog SQL> CONNECT / AS SYSDBA SQL> SHUTDOWN IMMEDIATE. Vous pouvez toujours y aller avec votre dump ! Etape 3 : On stoppe le mode panique et on se souvient qu'on avait pris le temps de réfléchir pour palier à ce genre de soucis. RMAN> BACKUP FULL DATABASE. SQL> CONNECT / AS SYSDBA SQL> SHUTDOWN IMMEDIATE. Si tout se passe bien. sqlplus / nolog SQL> CONNECT / AS SYSDBA SQL> RECOVER DATABASE UNTIL CANCEL. Et pendant que ma base est arrêté. SQL> QUIT RMAN target / RMAN> STARTUP MOUNT.

Conclusion: Cette méthode revient au même qu'a la solution proposée numéro 2: A un petit détail près. A bienôt. sans RMAN). LAO. un message indiquant "Base de données modifiée" Soyons fou !! SQL> CONNECT LAO/LAO Et maintenant vous pouvez vérifier ! les tables sont toutes la.SQL> ALTER DATABASE OPEN RESETLOGS. Et la oh magie. c'est que RMAN s'occupe pour vous de savoir quels fichiers il faut sauvegarder et surtout ou ils se situent ! Pour ceux qui aiment se faire mal aux neurones. . nous verrons dans un prochain article comment faire la même chose mais manuellement (Solution 2. et avec le même nombre de lignes qu'au moment de la sauvegarde.