Oracle 11g Release 2 Data Guard (3/5) : Automatic Block Media Recovery

Le « Block Media Recovery » ou BMR est la possibilité de restaurer un bloc Oracle en cas de corruption. Jusqu’à Oracle 11g Database Release 1, seul Oracle Oracle Recovery Manager, RMAN, permet de restaurer simplement un bloc. Avec la version 11.2 de la base de données, lorsque vous utilisez Active Data Guard et que vous utilisez une standby database et Real Time Query, les corruptions de données sont corrigées automatiquement. Cette nouvelle fonctionnalité permet d’éviter les erreurs ORA-01578 de manière automatique et quasiment transparente. Cette article illustre cette fonctionnalité à travers une méthode simple pour corrompre, tour à tour, la base de données primaire et la standby.

Cet article est le troisième d’une série plus large que je vous invite à découvrir ci-dessous :

Il s’agit d’un tour d’horizon assez complet de l’état de l’art de Data Guard en 11g Release 2. Bien sur, si vous avez d’autres idées, n’hésitez pas à les partager en laissant vos commentaires…

Préambule

Pour commencer, il faut configurer une standby physique en « real time query ». Pour cela, je vous renvoie au premier article et au second article de la série. Dans la configuration qui suit, BLACK est la base de données primaire et WHITE, la base de données standby en real time apply. J’ai effectué mes tests sur Linux x86.

Corruption d’un bloc sans une Standby « Real Time Query »

Pour commencer, vous pouvez désactiver la base de données standby « Real Time Query » pour visualiser ce qu’il se passe lorsque un bloc est corrompu sans Active Data Guard. Pour cela, connectez-vous à la standby avec le client du broker et démarrer la base standby en mode mount :

Pour la suite, nous allons répérer un bloc à corrompre. Pour cet exemple, nous allons utiliser la table exemple SCOTT.EMP. Le package DBMS_ROWID permet de repérer le bloc d’une ligne à partir de son rowid :

Nous allons donc corrompre le bloc 151 de notre datafile. Pour cela, nous allons utiliser la commande dd qui est facile à utiliser lorsque vous n’utilisez pas Automatic Storage Manager (Avec ASM, il faut d’abord repérer la position des extents du datafiles dans le diskgroup). Après que vous ayez corrompu le bloc, Oracle vous retourne l’erreur ORA-01578 lorsque vous tentez d’y accéder :

Note
le paramètre conv=notrunc de la commande dd permet de ne pas tronquer le fichier après le bloc que vous modifiez, ce qui est le comportement par défaut.

Corriger un bloc corrompu avec la base de données Standby « Real Time Query »

Pour corriger le bloc corrompu, vous pouvez bien entendu utiliser Recovery Manager; Au lieu de celà, nous allons simplement activer la standby en mode « Real Time Query » :

Maintenant, il suffit d’accéder au bloc corrompu sur la base de données primaire pour corriger l’erreur :

L’erreur est corrigée, comme par magie. Pour comprendre ce qui s’est passé, allez voir le fichier alert.log et vous y découvrirez un message indiquant que la correction automatique du bloc a été déclenchée. Voici le-dit extrait sur ma base de données :

Quel est l’impact de la correction automatique de la corruption ?

Re-faîtes le même test, cette fois-ci en ayant déjà la base de données en mode « Real Time Query »

  • Sans corruption de données

  • Avec corruption de données

Vous pouvez encore vérifier dans le fichier alert.log que la gestion automatique du « Block Media Recovery » a été déclenchée. Vous constaterez que si l’impact n’est pas transparent, il est relativement négligeable; bien sur, ce temps dépend du lag de la standby.

Corruption de la base de données Standby

La gestion automatique de la corruption de bloc est également disponible sur la standby. Pour vous en persuader, vous pouvez effectuer le même test depuis la base standby en mode « Real Time Query ». Remarquez que dans ce cas, voulu(*) ou pas une erreur est renvoyée à l’utilisateur :

Si vous ré-exécutez la requête, le bloc est corrigé :

Le fichier alert.log montre que la corruption est détectée :

Conclusion

Ces changements, à priori mineurs, à la lumière de ces tests, non seulement fonctionnent mais apportent un vrai plus à l’infrastructure Active Data Guard. Et ce n’est qu’un début puisque dans le prochain article, nous testerons la possibilité offerte par la standby « Real Time Query » de garantir la fraicheur des données interrogée sur la base secondaire. J’espère pouvoir vous faire partager notre enthousiasme pour ces nouvelles fonctionnalités. Qu’en pensez-vous ?

(*) La base de données standby a un SCN plus petit, même très proche, que le SCN de la base de données primaire; il est possible que la requête doivent être arrêtée parce que la standby ne peut pas garantir que le bloc remonté ne contient pas des données modifiées depuis. Ceci dépend de la manière dont le bloc est accédé et il se peut que ce soit une limite de l’implémentation actuelle (malgré la présence des UNDO). Il faudrait activer les traces sur la primaire et démonter le mécanisme pour en savoir plus. Y a-t-il un curieux/courageux pour comprendre ce qu’il se passe plus en détail ?

Gregory Guillou

About Gregory Guillou

Gregory Guillou has written 767 post in this blog.

Senior Technical Architect at Easyteam

13 thoughts on “Oracle 11g Release 2 Data Guard (3/5) : Automatic Block Media Recovery

  1. Pingback: Active Data Guard 11g Release 2 (5/5) : BCTF et RECOVER NOREDO sur la Standby | EASYTEAM

  2. Pingback: Active Data Guard 11g Release 2 (5/5) : BCTF et RECOVER NOREDO sur la Standby | EASYTEAM LE BLOG

  3. Pingback: Oracle Database 11g Release 2 Data Guard (7/5): Observer et Fast Start Failover « EASYTEAM LE BLOG

  4. Pingback: Oracle Database 11g Release 2 Data Guard (6/5): Créer une standby logique avec le broker « EASYTEAM LE BLOG

  5. Hervé

    D’après ce qui est dit dans la documentation, meme sans accéder au bloc, la correction doit pouvoir se faire au moment de l’application des logs.

    Reply
    • Arkzoyd

      Effectivement; sur la standby. Je n’ai pas testé ce scénario mais si un bloc est corrompu puis modifié… La correction pourrait être automatique. Je vais vérifier

      Reply
  6. arkzoyd

    Pour continuer la discussion précédente, j’ai fait le test avec RMAN. Dans ce cas :
    1) le bloc corrompu est détecté
    2) Il n’est pas automatiquement corrigé.
    3) Advise Failure indique de passer la commande « recover datafile 4 block 151; »
    4) La dite commande utilise la standby (je n’ai pas de backup ni de datafilecopy pour aller au bout
    5) après ça, le backup passe

    Après avoir corrumpu le bloc, voici la sortie de mes commandes RMAN:

    J’ai mis en gras la ligne intéressante; C’est dommage, le fichier alert.log ne dit pas comment le BMR c’est fait:

    Comme on peut s’y attendre le résultat est le même pour la commande VALIDATE.

    Reply
    • arkzoyd

      Pour que RMAN puisse tirer parti de la base de données standby, il faut que celle ci soit en mode Real Time Query; Si la base de données n’est qu’en recover, il faudra fair un BMR à partir d’une sauvegarde.

      Reply
  7. arkzoyd

    Chaque bloc en plus d’avoir une structure définie contient des checksums. C’est d’ailleurs comme ça que la corruption est détectée. C’est aussi pour ça que créer un datafile prend du temps; et que Exadata va beaucoup plus vite pour créer des grosses bases de données, même vide comparé à une base Oracle sans Exadata Cell Storage Server;

    La corruption est détectée lorsque le bloc est monté en mémoire, en effet.

    Ta question est très intéressante, parce qu’elle en amène un autre à laquelle je ne sais pas répondre:

    Réponse 1 (simple) : Si le bloc n’est jamais accédé, il n’est jamais corrigé mais cela n’a pas d’impact puisqu’il n’est jamais accédé : Quoique en janvier l’année prochaine ou lors d’un archivage dans 3 ans !

    Réponse 2 (plus compliquée) : Tu accèdes aux blocs pour faire tes sauvegardes, ou les valider; c’est d’ailleurs une des raisons pour lesquelles il vaut mieux utiliser RMAN ou valider les blocs régulièrement. Mais dans ce cas, je ne sais pas si les corruptions sont corrigées

    Reply
      • arkzoyd

        En faisant des sauvegardes avec RMAN, ou en validant les datafiles de manière régulière, on peut éviter de découvrir une corruption 6 mois après. Cela dit, la question reste ouverte, à savoir si Active Data Guard résoud, dans ce cas également le problème de corruption. Je testerai.

        Reply
  8. Arnaud Ladrière

    Génial cet article !

    la détection du bloc corrompu par le noyau se fait comment ? c’est au moment ou tu le lis qu’il le détecte ? Que se passe-t-il si personne ne lit ce bloc, dans ce cas ?

    Reply

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

%d blogueurs aiment cette page :