Détecter la désynchronisation d'un Oracle Data Guard

L’arrivée sur de nouveaux systèmes installé par d’autres DBA chez divers clients est souvent l’occasion de voir de nouvelles choses.
Récemment, j’ai été contacté par une équipe de supervision qui s’apercevait de désynchronisation d’une base de données en Data Guard.
Première chose, comprendre comment la supervision a été faite. Rien de plus simple, un collègue a fait implémenter un script de vérification des logs via la vue V$MANAGED_STANDBY.
Script simple, vérification du numéro de log appliqué courant et log arrivé sur RFS.
Si une désynchronisation vient à arriver, c’est donc le numéro de log qui est remonté.
Le soucis, c’est justement qu’à un moment ou à un autre, la machine virtuel freeze et une désynchronisation se produit.
Après vérification, ce freeze a lieu chaque snapshot VMWare…
En revanche et par acquis de conscience, j’ai effectué une vérification des paramètres de l’instance primaire.
Celle-ci était configurée en SYNC et AFFIRM.
Pour ceux qui ne sont pas coutumiers des niveaux de protection, en voici un condensé :

  • Maximum Availability
      (Disponibilité maximum) : Niveau de protection maximum sans affecter la disponibilité de la primaire, les transactions ne validait qu’après écriture en local et sur au moins une base de données standby.

    Maximum Performance

      (Performance maximum) : Niveau de protection maximum sans affecter les performances de la primaire, les transactions sont validées en local le plus tôt possible mais si de façon asynchrone sur la ou les secondaires.

    Maximum Protection

      (Protection maximum) : Niveau de protection permettant de supprimer la perte de données en cas de plantage de la primaire. Pour ce faire, les transactions ne doivent être écrites en local et vers au moins une secondaire avant d’être commité de façon pérenne.

Pour se changer le mode de protection de votre base de données, il vous faut modifier le paramètre LOG_ARCHIVE_DEST_n :

Disponibilité Maximum Performance Maximum Protection Maximum
AFFIRM NOAFFIRM AFFIRM
SYNC NOSYNC SYNC

Nota : certains changements de mode nécessitent un redémarrage de l’instance primaire.
Pour en revenir à mon client, le Data Guard était configuré en Max Performance. Je m’attendais donc à avoir une paramètre LOG_ARCHIVE_DEST_2 :

SERVICE=TOTO LGWR ASYNC VALID_FOR(....)

Quelle n’a pas été ma suprise lorsque je me suis aperçu que LOG_ARCHIVE_DEST_2 avait cette forme :

SERVICE=TOTO LGWR SYNC AFFRIM VALID_FOR(....)

Quelle est la signification de ce paramétrage SYNC + AFFIRM ?
Lors de l’envoi de l’archivelog par la primaire vers la secondaire, avant de valider une transaction, la primaire attend que la secondaire ait bien reçu la transaction ET elle attend que la secondaire ait bien pris en compte l’instruction.
Que se passe-t-il sur une primaire si la secondaire n’est pas en capacité de répondre directement que le log a bien été pris en compte ?
Il apparaît justement un déphasage dans la vue V$MANAGED_STANDBY et votre serviteur est donc appelé par la supervision. La modification du paramétrage des instances (passage en ASYNC) a permis de supprimer ce message tout en assurant le mode de protection demandé par le client.
La correction est aussi visible dans l’alert.log de la base secondaire où les message suivants apparaissaient :

Archived Log entry 93 added for thread 1 sequence 2421 ID 0xdfbaef24 dest 1:
Media Recovery Log /oradata/xxxxxx/flash_recovery_area/XXXXXX/archivelog/2014_03_12/o1_mf_1_2421_9l0oorpy_.arc
Media Recovery Waiting for thread 1 sequence 2422 (in transit)
Recovery of Online Redo Log: Thread 1 Group 11 Seq 2422 Reading mem 0
 Mem# 0: /oradata/xxxxxx/flash_recovery_area/XXXXXX/onlinelog/stb_redo11.log
Wed Mar 12 14:44:01 2014
RFS[73]: Possible network disconnect with primary database
Wed Mar 12 14:48:48 2014
RFS[74]: Assigned to RFS process 8429
RFS[74]: Identified database type as 'physical standby': Client is ARCH pid 21654
Wed Mar 12 14:48:49 2014
RFS[75]: Assigned to RFS process 8431
RFS[75]: Identified database type as 'physical standby': Client is ARCH pid 10856
RFS[75]: Selected log 11 for thread 1 sequence 2422 dbid -551846430 branch 805673600
Wed Mar 12 14:48:49 2014
Archived Log entry 94 added for thread 1 sequence 2422 ID 0xdfbaef24 dest 1:
Wed Mar 12 14:48:49 2014
Media Recovery Waiting for thread 1 sequence 2423
Wed Mar 12 14:48:52 2014
RFS[76]: Assigned to RFS process 8433
RFS[76]: Identified database type as 'physical standby': Client is LGWR SYNC pid 2412

Après modification, le log est redevenu propre et ces connexions / déconnexions n’apparaissent plus.
En espérant avoir pu vous aider à identifier un problème.

Laisser un commentaire

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