REMARQUE: Cet Article est un des premiers de mon blog et cependant d'après les statistiques, il s'agit de l'un des article 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.
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 sauvegarde à chaud. Vous aurrez compris, qu'il s'agit d'effectuer une sauvegarde base ouverte pendant que les utilisateur 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'arreter 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 CLOB 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'ésprit.
Solution 2:On arrete 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'arreter à 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 editeurs sont d'une priorité haute.(Ironie -) ). Du coup lors de la restauration, la probalité 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'arreter 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'effecuter 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 etre 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 arreté, un collégue de bonne volonté supprime les fichiers liés au tablespace SYSTEM (qui bien sur 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 >Executer > 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;
La 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 maintanant 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.
