Description du mode de backup à chaud (BEGIN BACKUP), par Franck Pachot

Publié le par

Ce document tente d’expliquer exactement ce qui arrive lorsque vous utilisez ALTER TABLESPACE ... BEGIN BACKUP et ALTER TABLESPACE  ...  END BACKUP, et pourquoi il est obligatoire de l’utiliser lorsque la sauvegarde à chaud se fait avec un outil qui est extérieur à Oracle (tels que les sauvegardes faites à partir de l’OS utilisant cp, tar, la BCV, etc)
Il donne également une réponse aux questions suivantes, fréquemment posées:

  • Est-ce qu’ Oracle continue d’écrire dans les fichiers (datafiles) lorsque la tablespace est en mode backup ?
  • A quoi sert la commande ALTER DATABASE BEGIN BACKUP ?
  • Pourquoi le mode backup n’est pas utilisé avec RMAN ?
  • Que se passe-t-il si vous faites une sauvegarde sans avoir fait le BEGIN BACKUP ?
  • Que faire si l’instance se plante alors que vous êtes en mode backup ?
  • Comment vérifier quels datafiles sont en mode backup ?
  • Quels sont les archive logs minimum à garder avec la sauvegarde à chaud?
  • Pourquoi utiliser des backups par des commandes OS au lieu de RMAN?
  • Pourquoi la commande BEGIN BACKUP peut prendre du temps ?

Sauvegarde offline (‘hors ligne’ ou ‘à froid’)

Une sauvegarde à froid est très simple: la base de données a été arrêtée proprement (pas après le plantage de l’instance, ni avec un shutdown abort) de sorte que:

  • tous les datafiles sont cohérent (ils ont le même SCN) et aucun redo n’est nécessaire en cas de restauration (d’ailleurs, on ne sauvegarde pas les redo dans ce cas)
  • les datafiles sont fermés (offline): ils ne seront pas mis à jour pendant l’opération de copie

Ainsi, le backup peut être restauré entièrement et la base de données ne peut être ouverte sans faire une récupération (recovery).

Sauvegarde online (‘en ligne’ ou ‘à chaud’)

Une sauvegarde à chaud effectue la copie des fichiers pendant que la base est ouverte. Cela signifie que la copie est incohérente et nécessitera d’appliquer du redo pour être utilisable.
Le media recovery est l’opération qui consiste à appliquer les journaux (redo log) sur les fichiers restaurés afin de rejouer les modifications telles qu’elles ont été faites dans les fichiers d’origine.

Lorsque la copie est faite avec Oracle (RMAN), Oracle copie les blocs de données vers les backupsets de telle sorte qu’il sera capable de les restaurer et de faire le recover dessus.

Mais lorsque la copie se fait à partir du système d’exploitation (c’est à dire avec un outil qui ne connaît pas la structure interne des fichier Oracle), plusieurs problèmes se posent:

  • incohérence de l’entête de fichier (header inconsistency): Rien garantit que les fichiers sont copiés du début vers la fin. Donc l’entête du fichier peut refléter un état correspondant au début ou à la fin de la copie.
  • blocs fracturés (fractured blocks): Rien ne garantit qu’un bloc Oracle est lu en un seul i/o, de sorte que deux moitiés d’un bloc peuvent correspondre à deux moments différents.
  • cohérence de sauvegarde (backup consistency): Durant son exécution, la copie va lire des données qui correspondent à différents instants. Le recovery est capable de faire avancer l’état d’un block passé, mais ne peut pas faire revenir en arrière un bloc futur. Le recovery doit donc se poursuivre au moins jusqu’au SCN de l’instant de fin de la copie.

Donc, tout est lié à la cohérence de la copie: la cohérence entre les fichiers de données (datafiles), la cohérence à l’intérieur de ces fichiers, et la cohérence au sein des blocs de données. Et il faut garder cette cohérence dans les fichiers courants de la base (évidemment) mais aussi dans la copie, le backup, puisqu’elle sera nécessaire en cas de restauration.

Mode BACKUP

Le but de ALTER TABLESPACE … BEGIN BACKUP and ALTER TABLESPACE … END BACKUP est de prendre des mesures spéciales lors de l’écriture dans les datafiles en cours afin de rendre leur copie utilisable, quelle que soit la manière dont la copie est faite, et ce sans affecter les opérations courantes.

Rien ne devrait être changé pour les fichiers courants, mais, comme la copie se fait par un outil externe, la seule façon d’avoir quelque chose de spécial dans la copie est de le faire dans les fichiers courants, avant qu’ils soient copiés, et de tout remettre en ordre à la fin.

L’enjeu est d’avoir une copie cohérente qui peut être récupérée par le recovery, sans avoir aucun contrôle sur le programme externe qui fait cette copie, et ce avec un impact minimum sur la base courante.

Afin de résoudre les 3 problèmes exposés ci-dessus, l’instance qui fera le recovery doit savoir:

  • que les fichiers ont besoin de recovery, à partir de quel moment (SCN) les redo sont à appliquer
  • comment réparer les blocs fracturés
  • et jusqu’à quel SCN au minimum le recovery doit se faire

Pendant le mode BACKUP, pour chaque datafile dans le tablespace en BEGIN BACKUP, voici ce qui se passe:

1 РLorsque la commande BEGIN BACKUP est ex̩cut̩e:

  • Le flag de sauvegarde à chaud dans les en-têtes de fichier de données est défini, afin que la copie soit identifiée comme étant une copie de sauvegarde à chaud.
    Il s’agit de gérer la question de cohérence de sauvegarde lorsque la copie sera utilisée pour une reprise.
  • Un checkpoint est lançé pour les fichiers du tablespace, afin qu’il ne reste plus de modifications faites en mémoire et non encore écrites sur disque (dirty buffers).
    La commande BEGIN BACKUP ne rends la main que lorsque ce checkpoint est terminé.

2 – Pendant le mode BACKUP:

  • L’en-tête des fichiers (datafile header) est figé, de sorte que la copie reflète l’état du ‘chackpoint SCN’ correspondant au début du backup.
    Ainsi, quand la copie sera restaurée, Oracle saura qu’il doit commencer le recovery à ce SCN pour applique les journaux archivés (archived logs).
    C’est pour résoudre le problème de l’incohérence de l’en-tête.
    Cela signifie que les futurs checkpoints ne vont pas mettre à jour le SCN de l’entête du fichier (mais ils ne mettre à jour un ‘backup SCN’ quand même)
  • Chaque première modification faite sur un bloc en mémoire (buffer cache) écrira le bloc complet dans les journaux (redo thread) alors que le comportement par défaut est d’écrire seulement le vecteur de changement.
    C’est pour résoudre le problème des bloc fracturé. Il peut y avoir un bloc fracturé dans la copie, mais il sera remplacé en totalité lors du recovery.

Cela signifie que tout se passe comme d’habitude, sauf pour les deux opérations suivantes:
– Le checkpoint, qui ne change pas le SCN de l’entête de fichier.
– La modification d’un bloc, la première fois qu’il est modifié depuis son entrée dans le cache, l’image complète du bloc est enregistrée dans les journaux.
Les insert en mode direct (direct-path) ne passent pas par le buffer cache, mais de toute façon ils écrivent toujours des blocs entiers, donc le bloc entier se retrouve dans les journaux (si l’on est pas en nologging)

3 РLorsque la commande END BACKUP est ex̩cut̩e:

  • Un enregistrement de redo qui marque la fin du mode backup est écrit dans les journaux, de sorte que si la copie est restaurée, le recovery doit se poursuivre au moins jusqu’à ce point. C’est pour résoudre le problème de la cohérence du backup.
  • Le flag de sauvegarde à chaud dans les en-têtes datafile est remis à zéro.
  • Le SCN de l’en-tête est mis à jour avec le SCN courant.

Remarques :

  1. Le cas du bloc fracturé est rare, puisqu’il n’arrive que lorsque l’io de la copie est fait en même temps que l’i/o de l’écriture. Mais le seul moyen d’éviter le problème est de faire la journalisation du bloc entier pour chaque bloc qui risque d’être écrit sur disque durant la copie, au cas où.
  2. Si la taille de l’I/O de la copie est multible de la taille du bloc Oracle (par exemple un backup fait avec bs = 1M dd), cette journalisation supplémentaire ne semble pas nécessaire car le cas du bloc fracturé ne peut pas arriver.
  3. Le checkpoint du BEGIN BACKUP est indispensable pour couvrir tous les cas possibles de blocs fracturés. Sinon, il pourrait rester un dirty buffer modifié avant le begin backup (donc sans l’image complète dans le redo) et qui pourrait être écrit sur disque en même temps que la copie.
  4. Ce logging supplémentaire n’est fait que lorsque le bloc est pour la première fois modifié depuis qu’il est en buffer cache. Si le même bloc est rechargé à nouveau dans le buffer cache, le logging supplémentaire aura lieu à nouveau. Je n’ai pas vu cela dans la documentation, mais un test en faisant un ‘flush buffer_cache’ peut le prouver.

Conséquence sur la copie (le backup)

Lorsque la copie a été fait entre begin backup et le end backup, la copie est entièrement disponible pour être restaurée (restore) et récupérée (recovery) à l’aide des journaux archivés (archived logs) qui ont été générés depuis le begin backup.
Une fois les fichiers restaurés, Oracle voit que le SCN est plus ancien que celui en cours et indique que la base de données a besoin de faire un recovery.

Le recovery doit se faire jusqu’à un point ultérieur à la fin du backup, afin que nous soyons sûrs qu’il n’y a pas de blocs dans le fichier qui viennent du futur.

Conséquence sur la base de données courante

Toutes les opérations peuvent être effectuées pendant le mode de sauvegarde à chaud.
Toutefois, comme le redo généré est plus important, le backup doit être fait au cours d’une période de faible activité. Et pour la même raison, il est préférable de sauvegarder les tablespaces les uns après les autres au lieu de les mettre tous en backup.

En outre, il n’est pas possible d’arrêter la base de données (shutdown) lorsqu’un tablespace en mode backup.
C’est parce que, comme l’en-tête de datafile est figée avec un SCN ancien, le fichier serait considéré comme nécessitant un recovery.

Cependant, cela ne peut pas être évité en cas de plantage (ou de shutdown abort) et le démarrage de la base donnera le message suivant:
ORA-1113: le fichier … Nécessite une récupération
C’est seul le cas que je connaisse où l’instance recovery n’est pas automatique, vous avez besoin de faire ‘alter database … end backup; ‘avant d’ouvrir la base de données.

Questions fréquentes

Est-ce qu’ Oracle continue d’écrire dans les fichiers (datafiles) lorsque la tablespace est en mode backup ?
Oui, bien sûr, si ce n’était pas le cas, on ne l’appellerait pas ‘sauvegarde en ligne’.

A quoi sert la commande ALTER DATABASE BEGIN BACKUP ?
Cette commande met tous les tablespaces en mode backup.
On l’a vu, c’est une mauvaise pratique de mettre tous les tablespaces en mode backup, car il est préférable de minimiser la journalisation supplémentaire.

Oracle a introduit ce raccourci pour une seule raison: quand il s’agit de faire un backup en utilisant le mirroring de la baie (BCV, FlashCopy, etc), cette copie concerne tous les fichiers en même temps, et elle ne dure que quelques secondes. Dans ce cas, il est plus facile d’utiliser cette commande pour mettre tous les tablespaces en mode de sauvegarde à chaud.

Pourquoi ce mode n’est pas utilisé avec les sauvegardes RMAN ?
RMAN est un outil Oracle, qui connaît la structure de fichiers, et la façon dont ils sont écrits.
Il sait donc comment lire les fichiers de sorte que la copie soit cohérente: écrire la bonne version de l’en-tête du fichier, lire les blocs avec un I/O dont la taille est multiple de la taille du bloc Oracle afin qu’il n’y ait pas de blocs fracturés , et vérifier le début et la fin du bloc pour détecter s’il es fracturé (dans ce cas, il relit le bloc pour obtenir une image cohérente).

C’est un des avantages parmi tant d’autres de l’utilisation de RMAN pour les sauvegardes.

Que faire si vous faites une sauvegarde en ligne sans mettre les tablespaces en mode de sauvegarde?
Si vous ne mettez pas le tablespace en mode backup, vous n’êtes pas certains que la copie est récupérable. C’est peut être le cas, mais la copie peut aussi être incohérente.

On peut supposer que la copie est cohérente, si elle est effectuée dans les conditions suivantes

  • incompatibilité en-tête: Si la copie de fichiers se fait du début à la fin, alors l’en-tête devrait refléter le bon SCN
  • blocs fracturés: Si la copie se fait avec des I/O dont la taille est multiple de la taille du bloc Oracle, alors vous ne devriez pas avoir de blocs fracturés
  • La cohérence de sauvegarde: Si vous prenez soin de poursuivre le recovery au delà du point où la copie s’est terminée, vous ne devriez pas avoir incohérence

Mais il peut y avoir d’autres mécanismes internes qui ne sont pas documentées, de sorte que nous ne pouvons pas être sûrs que cette liste est exhaustive.
Et, comme ce n’est pas supporté, nous ne pouvons pas compter sur une sauvegarde faite comme ça. Notez que vous n’aurez pas de message d’erreur.

Que faire si l’instance plante alors que les tablespaces est en mode de sauvegarde à chaud ?
Lorsque vous démarrez la base de données après le crash, Oracle va signaler qu’il faut faire un recovery. C’est parce que le SCN a été gelé, et c’est le comportement nécessaire: si vous restaurez le fichier copié, il devra être récupéré, et la seule façon pour Oracle de faire cela est d’agir sur le fichier courant afin que ce soit reflété sur la copie.

Dans ce cas, vous pouvez simplement faire:

ALTER DATABASE END BACKUP; ALTER DATABASE OPEN;

pour ouvrir la base de données.

Mais la sauvegarde n’est pas utilisable, il faut le faire de nouveau.

Comment faire pour vérifier si les datafiles sont en mode de sauvegarde

La vue V$BACKUP montre les datafiles qui sont actuellement en mode de sauvegarde (status=’ACTIVE’).

Certains anciens documents parlent de la colonne FUZZY de V$DATAFILE_HEADER.

C’est parce que dans les versions précédentes (<9i) le begin backup mets à zéro le online fuzzy bit dans l’en-tête fichier, et le remet à ‘fuzzy’ lors du end backup.

Depuis 9i, le online fuzzy bit n’est mis à zéro que lorsque fichier de données est offline ou en lecture seule (read-only), et non pas pour le mode de sauvegarde à chaud.

Quels sont les archive logs minimum à garder avec la sauvegarde à chaud?
La sauvegarde en ligne est inutilisable s’il n’y a pas au moins la possibilité de restaurer les journaux d’archivage:
– à partir du journal qui était le journal courant (current redo log) lorsque la sauvegarde a commencé,
– jusqu’au journal qui a été archivé juste après que la sauvegarde complète ai été terminée.

Cela suffit pour faire une récupération incomplète (incomplete media recovery) jusqu’au point qui correspond au moment de la fin de la sauvegarde.
Les archivelog suivants seront nécessaires pour amener la base jusqu’au point le plus proche du moment de la panne.

Pourquoi utiliser les sauvegardes OS au lieu de RMAN

La meilleure façon de faire des sauvegardes en ligne est d’utiliser RMAN qui a de nombreuses de fonctionnalités que vous ne pouvez pas avoir avec les sauvegardes OS.

Pourtant, la sauvegarde OS sont encore utile lors de l’utilisation des outils OS qui peuvent copier une base de données entière en quelques secondes, en utilisant un split de miroir (BCV, FlashCopy, etc), pour des bases de données très volumineuses.

Pourquoi la commande BEGIN BACKUP peut prendre du temps?
BEGIN BACKUP doit faire un checkpoint des blocs de la tablespace concernée qui ont été modifiés en mémoire (dirty buffers) , de sorte qu’il n’y ait pas d’écriture que ne soit protégée par la journalisation supplémentaire.
La durée de ce checkpoint est proportionnelle à la taille du buffer cache et du nombre de datafiles.
La performance de BEGIN BACKUP a été améliorée dans 10g.

Références (en Anglais)

L’article original en anglais se trouve ici. Il date de la version Oracle 10gR2

Laisser un commentaire