Accueil Nos publications Blog Les sauvegardes sous Oracle

Les sauvegardes sous Oracle

 “Des routes !!! Là où nous allons… On n’a pas besoin de route !” Les fans reconnaîtront l’une des phrases du fameux docteur Emmet Brown de retour vers le futur. Vous allez nous dire, “Mais quel est le rapport avec les bases de données ???!!!!” C’est que nous, DBA, nous mettons facilement dans la peau de ce bon vieux Doc lorsque l’on reçoit un appel alarmé de nos Marty préférés (les utilisateurs/MOE etc…) après une suppression malencontreuse de données en production et qu’il nous faut sortir nos DeLorean pour retourner dans le futur :).

Le but de cet article est de présenter succinctement les différentes méthodes de sauvegarde des données d’une base de données.

Une relecture de notre article sous l’organisation des objets sous Oracle peut être utile afin de mieux appréhender ce qui va suivre.

Il y a deux types de sauvegardes :

– la sauvegarde physique, qui est la sauvegarde des fichiers composant la base de données (datafiles, controlfile, archivelog, etc…)

– la sauvegarde logique, qui est la sauvegarde des données à proprement parler.

Les sauvegardes logiques

La sauvegarde logique consiste à enregistrer des données de la base sur un fichier externe. Ce fichier contient simplement les commandes SQL à exécuter pour obtenir les données ; ce fichier n’est pas lisible en l’état (à la différence de MySQL).

Oracle fournit l’utilitaire Export  jusqu’en 9i et Data Pump Export à partir de la 10g qui lit les données à extraire pour les insérer dans ce fichier. On appelle couramment ce fichier export ou dump (datapump). Oracle fournit également l’utilitaire Import jusqu’en 9i et Data Pump Import à partir de là 10g pour recharger cet enregistrement.

L’export peut servir pour faire une sauvegarde complète d’une base de données, la sauvegarde est dite FULL, mais en règle générale un DBA ne base pas la politique de sauvegarde d’une base de production sur les exports même si celle-ci est petite.

L’export est la sauvegarde d’une lecture de la base à instant donné T et ne permet pas d’avoir une sauvegarde cohérente de la base, c’est à dire avec l’ensemble des datafiles ayant le même numéro de changement ou SCN. De plus une restauration à l’instant T+1 ne pourra pas se faire avec un export au temps T.

La principale raison du manque de cohérence de cette sauvegarde est qu’un export ne va pas enregistrer la façon dont est organisée la base (emplacement des datafiles sur les filesystems) ni son paramétrage (taille des mémoires etc…) ; il ne sauvegarde que la structure des tables et leurs données.
Par ailleurs, un export est un cliché à un instant T de la base ; impossible de remettre la base à un instant T+1 avec cet export.

A l’import, il faudra préparer la base cible avec les mêmes tablespaces, datafiles pour pouvoir recevoir les données.

Il sert en général pour :

– une sauvegarde logique de la base

– en vue d’une montée de version du moteur Oracle

– la sauvegarde ou le transfert d’un schéma ou d’une table

Le dernier point est intéressant lorsque l’on ne souhaite rafraîchir qu’un seul schéma ou une seule table d’une base hors production : l’export est alors ciblé (donc rapide et peu volumineux) et la base cible (hors-prod) est déjà présente.

La sauvegarde physique

La sauvegarde physique consiste en une copie de l’ensemble des fichiers composant la base de données :

– fichiers de contrôle, les controlfiles

– fichier d’initialisation, le pfile ou le spfile

– fichiers de données, les datafiles

– les journaux de transactions, les redologs

La sauvegarde peut se faire à froid c’est à dire base arrêtée ou à chaud (uniquement avec le mode ArchiveLog). Le DBA met alors la base en mode begin backup ce qui permet à la copie des fichiers d’être cohérente et de pouvoir les réutiliser pour une restauration. Pour les bases de production, la restauration de ces fichiers peut être complétée par l’application des journaux de transactions archivés, archivelogs, afin de restaurer la base jusqu’à un moment donné ; la précision peut être à la seconde.

Depuis la 9i, Oracle propose l’utilitaire rman, pour Recovery MANager, afin de gérer les sauvegardes et les restaurations des bases de données. Il permet d’effectuer des sauvegardes complètes ou partielles. On parle couramment de backup.

Les sauvegardes complètes, dites full, sont des sauvegardes de l’ensemble des blocs de la base.

Les sauvegardes partielles, dites incrémentielles, sont des sauvegardes des blocs modifiés depuis une précédente sauvegarde full ou incrémentielle. Il existe deux type de sauvegarde incrémentielle : la différentielle ou la cumulative, mais comprendre ces deux types n’est pas le but de cet article.

Ces sauvegardes peuvent être faites à chaud ou à froid.

Une stratégie de sauvegarde possible est de faire une sauvegarde full à froid le week-end (ce qui permet en plus aux DBA d’avoir un créneau horaire pour faire des modifications de paramétrages internes) et des sauvegardes incrémentielles à chaud en semaine comme spécifié dans le schéma ci-dessous.

La restauration d’une base en date du mercredi s’effectuera donc en restaurant le backup full du week-end puis en appliquant les différents backups incrémentaux jusqu’au mercredi. C’est ce qu’on appelle le recover.

Une restauration rman est en générale une restauration d’une base entière mais on peut choisir de restaurer un ensemble de tablespaces uniquement, ce qui peut être pratique lorsqu’on veut restaurer un schéma qui utilise un tablespace pour les données et un tablespace pour les index.

Et maintenant, retournons vers le futur !!! 

Oracle fournit d’autre outils afin de pouvoir récupérer des données tels que le flashback query apparu en 9i et qui permet à un DBA d’interroger une table à une date passée.

Ce mécanisme a été amélioré en 10g et permet à présent aux DBAs de :

– récupérer des données au niveau d’une ligne ou d’une table

– de récupérer une table qui aurait été droppée (supprimée)

– voir même de récupérer une base entière (si l’option flashback database est utilisée)

Mais pour les deux premières récupérations les DBAs doivent être prévenus assez tôt parceque les données que l’on souhaite récupérer ne sont pas gardées indéfiniment par les mécanismes d’Oracle : par défaut la rétention est d’une journée.

Maintenant que vous savez un peu tout sur les sauvegardes de bases de données Oracle il ne nous reste plus qu’à monter dans nos DeLorean et remonter le temps.