Plutôt que de la traduire, je résume ici les idées principales pour aider à la lecture pour les francophones. Et n’hésitez pas à poser des questions ici.

Comportement d’Oracle lorsqu’il n’y a pas d’index sur la clé étrangère

L’idée qu’il faut toujours indexer les clés étrangères vient des anciennes versions où on se retrouvait avec un verrou table (TM-Share) lorsqu’on on modifiait une table.
Sous Oracle 7, c’est la table parent qui est vérouillée lorsqu’on insère un enregistrement dans la table fille. Puis à partir de la 8i c’est l’inverse: la table fille est vérouillée lorsqu’on supprime un enregistrement de la table parent.

Mais cela a été vite optimisé en 9i: ce verrou est relâché dès que la ligne parent est supprimée. Le verrou ne reste pas jusqu’à la fin de la transaction. C’est la raison pour laquelle on peut lire parfois qu’il n’y a plus de problème de verrou lorsque la clé étrangère n’est pas indexée. C’est faux. C’est juste que le verrou dure moins longtemps.

Mais il ne faut pas oublier que si la clé étrangère n’est pas indexée, alors la suppression d’une ligne parent devra faire un full scan de la table fille. Parce qu’il faudra vérifier que rien ne référence le parent qu’on veut supprimer. Et si la table fille est grosse, ça peut durer longemps. Et donc le verrou va quand même durer longtemps. Et pendant ce temps, toute modification sur la table sera bloquée, même si elle n’a rien à voir avec le parent qu’on est en train de supprimer.

Sur les version courantes d’Oracle il est donc nécessaire d’avoir un index sur la clé étrangère lorsque on a les 2 conditions suivantes:

1. On peut supprimer (delete) une ligne de la table référencée (parent). C’est aussi le cas si l’on modifie (update) la colonne référencée. Mais on ne devrait pas modifier une clé normalement. On doit aussi penser aux cas des delete cascade, au cas de merge, etc.
2. Et si la table fille est grande et/ou a beaucoup d’activité de modification dessus. Si ce n’est pas le cas, le verrou table n’aura pas une grande conséquence. Mais si c’est le cas, on peut bloquer toute l’application pendant un long moment.

En quoi un index peut aider ?

La première chose, c’est que l’index sur la clé étrangère permettra de vérifier rapidement qu’il n’y a pas d’enregistrements qui référenceraient la ligne qu’on supprime, sans avoir à faire un full table scan. Avant tout, on crée les index pour des raisons de performance d’accès.

La deuxième chose, c’est qu’en plus, lorsque Oracle va lire cet index, il va pouvoir vérifier qu’il n’y a pas d’insert en cours, même non encore commité. Parce que un insert va toujours dans un block bien précis dans un index.

S’il n’y a pas d’index, mais seulement la table pour vérifier, alors un insert peut aller n’importe où et il faut donc verrouiller toute la table pour empêcher cela. S’il y a un index, il suffit de verrouiller le bloc d’index correspondant à la valeur du parent pour la durée de l’opération de delete.

Quel index est possible ?

Si l’on crée systématiquement un index sur toutes les clés étrangères, on va se retrouver avec de nombreux index superflus. Parce ce que ce qu’il suffit d’avoir c’est un index qui commence par les colonnes indexées.
Je rappelle l’idée: si l’index permet de retrouver directement une (potentielle) ligne fille, alors il peut aussi servir à éviter de verrouiller toute la table.

Exemple:

Sur la table suivante:

table CHILD (a,b,c) ... references PARENT(a,b)

Les index suivants permettent d’éviter les verrous table lors d’un delete sur la table PARENT:

Par contre, ceux-là ne peuvent pas être utilisés pour ce but:

il est donc important de ne pas indexer aveuglément, mais de choisir les index qui sont utiles pour les performances des accés aux données. Ensuite, on vérifie qu’ils permettent aussi d’éviter les cas de verrou table s’ils peuvent avoir lieu.

Comment vérifier quels verrous sont posés ?

On a vu que le verrou est relâché dès que l’opération de suppression est finie. il ne reste pas jusqu’à la fin de la transaction. il est donc parfois difficile de le voir en test avec peu d’utilisateurs concurrents. On peut par contre utiliser l’event 10704 pour vérifier exactement quels verrous sont posés. La présentation montre un exemple avec son interprétation.

Conclusion et conseils

Lorsque une table parent peut avoir des delete dessus, même si c’est rare, même si c’est indirect (delete cascade) alors les tables filles peuvent se retrouver verrouillées s’il n’y a pas un index qui commence par les colonnes de la clé étrangère.
Si La table fille est grande et/ou si il y a beaucoup de modifications dessus, ce verrou peut durer et peut bloquer toute modification.
Dans ce cas, il faut indexer les clés étrangère. Mais pas aveuglément: on doit réfléchir à l’ordre des colonnes, à utiliser un index qui sert aussi à autre chose, etc.

Par contre, les clés étrangères vers des tables de référence statiques n’ont pas besoin d’index. Sauf bien sûr pour des raisons d’accès si on a besoin pour une jointure entre les deux table et que la sélectivité est assez forte pour bénéficier d’un index..

En test, on peut savoir exactement si une opération est susceptible de verrouiller la table fille avec l’event 10704 . C’est important car il y a quelques cas particuliers (des bugs par exemple). au moindre doute, il faut donc tester avec votre version d’Oracle, sur votre modèle de données.

En production, il faut réagir si on voit des wait events ‘enq: TM‘ avec des verrous en mode 4 (Share) ou 5 (SSX). Même s’ils sont anodins maintenant, ils seront bloquants un jour lorsqu’il y aura plus de données ou plus d’activité.

Enfin, il ne faut pas voir la nécessité d’indexer certaines clés étrangères comme quelque chose de contraignant. Dans la plupart des cas l’index en question est nécessaire pour des raisons de performance, pour que le delete n’ait pas à faire un full scan de la table fille. Et le comportement d’Oracle est alors plutôt performant: aucun verrou n’est posé. Et cela depuis les plus anciennes version d’Oracle.

Un dernier point: si vous pensez que le mieux est de ne pas déclarer les contraintes d’intégrité référentielles en base de données, mais de les gérer au niveau de l’application, alors vous aurez des problèmes dès que vous aurez plusieurs utilisateurs concurrents. Soit vous risquez d’avoir une inconsistance de données, soit vous devrez verrouiller toute la table jusqu’à la fin de la transaction. Car les mécanismes interne d’Oracle que l’on vient de voir (relâcher le verrou avant la fin de la transaction, ou utiliser le bloc d’index pour voir les insert non commités) et qui sont très performants ne sont pas accessibles par l’application…

C’est parfois difficile d’aborder un rapport AWR ou Statspack qui comprends 50 pages de statistiques, dont seulement quelques unes sont utiles dans un contexte donné. J’ai vu plusieurs personnes qui ne savent pas vraiment par où commencer. Et sans une approche méthodique, c’est facile de perdre du temps sur des choses qui ne feront pas gagner un un temps significatif dans l’amélioration du temps de réponse.

Cette présentation montre une approche méthodique: en partant du temps passé en base de données (DB time) pour voir si le rapport est pertinent ou pas, puis en prenant les éléments du ‘Top 5 events’ en montrant où aller chercher les détails qui permettent de comprendre la raison d’un problème de performance, comment le résoudre, et estimer le gain en temps de réponse que peut apporter la résolution.

microsecondes (1000000ème de seconde):

TIME_WAITED_MICRO, WAIT_TIME dans V$SESSION_WAIT, V$SYSTEM_EVENT, V$SESSION_EVENT, V$ACTIVE_SESSION_HISTORY
CPU_TIME, ELAPSED_TIME dans V$SQL, V$SQLAREA
WAIT_TIME dans V$LATCH, V$LATCH_PARENT, V$LATCH_CHILDREN
ACTIVE_TIME dans V$SQL_WORKAREA, V$SQL_WORKAREA_ACTIVE

millisecondes (1000ème de seconde):

CPU_WAIT_TIME dans V$ENQUEUE_STAT

secondes:

CTIME dans V$LOCK

La liste est non exhaustive, et les commentaires sont bienvenus pour la mettre à jour

Mais ajouter un index a un coût et va pénaliser les insert/deletes ainsi que les updates qui touchent aux colonnes indexées.

Il y a cependant des cas où Oracle peut combiner deux indexes.
C’est le cas par exemple des indexes bitmap. On peut avoir un index bitmap sur chaque colonne, et Oracle va combiner les bitmaps avant d’aller voir la table (en utilisant des opérateurs binaire AND et OR sur les bitmaps). Mais ce n’est pas le sujet de cet article.

Il y a aussi un cas particulier avec les indexes ‘normaux': c’est le chemin d’accès ‘INDEX JOIN‘: les 2 indexes sont lus, et sont réunis, comme si l’on faisait une jointure sur le rowid, et la sortie de cette opération est équivalente à un index qui contiendrait toutes les colonnes.

Voici un exemple de cette opération ‘index join’, le but de cet exemple était de répondre à la question suivante, sur le forum dba-village: ‘Que signifient les indexes index$_join$_9 et index$_join$_8′ dans un plan d’exécution, et ‘comment les remplacer par mes propres indexes ?‘

Je commence par créer une table avec 2 colonnes (n1 et n2):

Et je crée un index sur chaque colonne:

Je met autotrace à ‘trace explain’ pour afficher le plan d’exécution, mais pas le résultat:

SQL> set autotrace trace explain

et je lance un select avec des prédicats sur n2 et n2:

SQL> select n1,n2 from t where n2 is not null and n1=3;

------------------------------------------------------------------------------------------- 

| Id  | Operation              | Name             | Rows  | Bytes | Cost (%CPU)| Time     | 

------------------------------------------------------------------------------------------- 

|   0 | SELECT STATEMENT       |                  |    97 |  2522 |     3  (34)| 00:00:01 | 

|*  1 |  VIEW                  | index$_join$_001 |    97 |  2522 |     3  (34)| 00:00:01 | 

|*  2 |   HASH JOIN            |                  |       |       |            |          | 

|*  3 |    INDEX RANGE SCAN    | TI1              |    97 |  2522 |     1   (0)| 00:00:01 | 

|*  4 |    INDEX FAST FULL SCAN| TI2              |    97 |  2522 |     1   (0)| 00:00:01 | 

-------------------------------------------------------------------------------------------> 

Predicate Information (identified by operation id): 

--------------------------------------------------- 

   1 - filter("N2" IS NOT NULL AND "N1"=3) 

   2 - access(ROWID=ROWID) 

   3 - access("N1"=3) 

   4 - filter("N2" IS NOT NULL)

On peut voir la jointure sur les indexes:

• (3) un RANGE SCAN de l’index TI1 pour avoir les ROWID qui vérifient le prédicat n1=3.
  Le résultat est mis en table de hachage pour le HASH JOIN
• (4) un FULL SCAN de l’index TI2 pour avoir les ROWID qui vérifient le prédicat n2 is not null
• (2) un HASH join de ce résulat avec le premier. On voit la condition de jointure ROWID=ROWID
• (1) Le résultat de cette opération, appelé index$_join$_001, a les colonnes ROWID, N1 et N2, exactement comme si on avait un index concaténé sur (N1,N2)

Mainenant, je crée un index similaire:

Et j’exécute la même requête:

SQL> select n1,n2 from t where n2 is not null and n1=3;

------------------------------------------------------------------------- 

| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     | 

------------------------------------------------------------------------- 

|   0 | SELECT STATEMENT |      |    97 |  2522 |     2   (0)| 00:00:01 | 

|*  1 |  INDEX RANGE SCAN| TI12 |    97 |  2522 |     2   (0)| 00:00:01 | 

------------------------------------------------------------------------- 

Predicate Information (identified by operation id): 

--------------------------------------------------- 

   1 - access("N1"=3) 

       filter("N2" IS NOT NULL)

On voit alors que l’index a été utilisé, et que le coût est un peu meilleur.
Reste à voir si ce gain est justifié par rapport au coût d’avoir une index supplémentaire à maintenir lors des inser/delete/update.

• 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)

• Idée reçue: le mode de sauvegarde à chaud cesse d’écrire dans les fichiers de données (Jérémie Wilton)
• Note MetaLink: 1050932,6 «Pourquoi les datafiles sont toujours en cours d’écriture durant une sauvegarde à chaud ?
• AskTom « Sauvegarde et restauration – pourquoi du redo supplémentaire est-il généré. »

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