• 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