Sauvegarde à chaud de tablespaces

Quelle que soit le type de sauvegarde, de base de données, de fichier de données, de tablespaces, …, si celle-ci est éffectuée base “ouverte” cela implique que la base fonctionne en mode Archive Logs car les journaux archivés sont indispensables à la restauration des données ainsi sauvegardées. Si ce mode de sauvegarde peut s’avérer pratique dans certains, on verra par la suite que celui-ci altère les performances et au final n’est pas conseillé.

La sauvegarde de tablespace à chaud permet au DBA de ne jamais stopper son instance de production et de ne jamais interrompre l’accès aux données (par exemple en mettant les tablespaces offline, ce qui enlève l’intéret de la sauvegarde à chaud).

Le principe est de provoquer un CHECKPOINT afin de s’assurer que tous les datafiles d’un tablespace sont synchronisés (au même niveau de SCN) et d’indiquer à Oracle qu’à dater de cet instant, les transactions provoquent des écritures dans les datafiles mais ceux ci ne sont plus synchronisés avec les datafiles des données en cours de sauvegarde, la sauvegarde est dite “incohérente”.

Lorsque la sauvegarde physique des fichiers de données d’un tablespace en mode “sauvegarde à chaud”, on l’indique à Oracle et celui-ci va alors synchroniser l’ensemble des fichiers de données de la database.

Les séquences suivantes suffisent à sauvegarder à chaud un tablespace T :

alter tablespace T begin backup;

host copy /data/madatabase/tablespaces/T/*.dbf
          /data/madatabasesau/sauvegardes/tablespaces/T/

alter tablespace T end backup;

Pendant la copie des datafiles (entre le begin backup et le end backup), les blocs Oracle d’un fichier de données ne sont donc pas automatiquement synchronisés avec les SCN présents dans les entêtes des mêmes fichiers de données.

L’état des tablespaces en cours de sauvegarde peut être visualisé grace à la vue v$backup.

Remarque: Lorsque un tablespace en cours de sauvegarde est solicité pour des mises à jour, des informations de récupérations supplémentaires sont alors stoquées dans les fichiers de journaux et les journaux archivés, ce qui peut provoquer un nombre très importants de fichiers journaux comparé à une production en mode normal. De plus, cette écriture supplémentaire peut altérer les performances globales de l’accès aux données de la database, c’est pour cela que ce mode de sauvegarde n’est pas recommandé.