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 :

Démarrer > Executer > cmd

sqlplus / nolog
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE;
SQL> QUIT

RMAN target /
RMAN> STARTUP MOUNT;
RMAN> BACKUP FULL DATABASE;
RMAN> ALTER DATABASE OPEN;
RMAN> QUIT

Remarque : A travers cet exemple, 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;

SQL> DROP TABLE T3;

sqlplus / nolog
SQL> CONNECT LAO/LAO --(c'est mon user de test avec trois table t1,t2,t3. Original ?)

Oups ! je voulais faire le contraire !!

Vite passons en mode panique;

SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE;

Et pendant que ma base est arrêté, 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).

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.

Démarrer >Exécuter > cmd

SET ORACLE_SID=ORADB ( si jamais il y a plusieurs bases sur votre poste).

RMAN target /
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
.... Si tout se passe bien, un petit message qui indique "Fin de restore dans DD/MM/YY"

RMAN> QUIT

Encore un petit effort,

sqlplus / nolog
SQL> CONNECT / AS SYSDBA
SQL> RECOVER DATABASE UNTIL CANCEL;

Là vous recevez quelques insultes de notre ami ORACLE.

Tapez tout simplement et sans trembler CANCEL puis
SQL> ALTER DATABASE OPEN RESETLOGS;
Et la oh magie, 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, et avec le même nombre de lignes qu'au moment de
la sauvegarde.

Conclusion: Cette méthode revient au même qu'a la solution proposée numéro 2: A un petit détail près, 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, sans RMAN).

A bienôt;

LAO.