Oracle Dataguard : Mise en place d’une solution de haute disponibilité !

Présentation du concept

Oracle Dataguard est une solution dite de haute disponibilté. Cela consiste à effectuer un basculement d’une base de données (primaire/primary) vers une ou plusieurs autres bases de données (secondaire/standby). Cette méthode est totalement transparente pour les utilisteurs clients.

Les raisons de mettre en place un Data Guard peuvent être multiples :

  • La base de données ou le serveur nécessite d’être arrêtés et on reporte toute l’activité vers la ou les bases secondaires. Une des bases secondaires devient primaire, et la primaire devient secondaire.
  • Des traitements lourds doivent être effectués sur la base, ce qui pourrait gravement impacter les performances. Pour cela, on bascule sur une base secondaire et on applique le traitement sur une base secondaire. La base primaire continuant son activité normalement.

Il existe deux manières de créer des standby dans l’optique de construire un Data Guard :

  • Une physical standby : les fichiers de redo logs de la primary sont récupérés pour être ensuite appliqués sur la standby.
  • Une logical standby : les commandes SQL passées sur la primary sont exécutés sur la standby.L’avantage de la base en logical standby est qu’elle reste accessible en lecture/écriture contrairement à la physical standby qui ne peut être que lue.

 Ici, nous nous intéresserons à la logical standby.

Configuration

Pour parvenir à nos fins, plusieurs étapes sont nécessaires avant de faire fonctionner le Data Guard.

Dans un premiers temps, nous devons configurer correctement les services réseaux d’Oracle. En effet deux fichiers importants sont à modifier, puisqu’il s’agit de listener.ora et tnsnames.ora.

Listener.ora est un fichier placé coté serveur, rentrant en compte dans le processus d’écoute de la base. Il va aiguiller les clients en fournissant de précieuses informations :

  • Le nom des instances
  • Le chemin des instances
  • La configuration réseau (protocole, nom d’hôte, port…)

Le fichier tnsnames.ora est, quand à lui, situé coté client. Il doit contenir toutes les informations d’accès pour pouvoir consulter les services.

Il est désormais temps de s’occuper des fichiers de configuration de l’instance de nos bases primaires et secondaires. Ces fichiers comportent de nombreux paramètres servant à configurer l’instance lors de son lancement. Nous pouvons les consulter et même modifier dynamiquement par la suite à l’aide de la vue v$instance.

initINSTA.ora : fichier de configuration de la base primaire 

control_files='/u01/app/oracle/oradata/INSTA/control01.ctl','/u01/app/oracle/flash_recovery_area/I NSTA/control02.ctl'

db_unique_name = INSTA
instance_name='INSTA'

FAL_Client='INSTAPRI' 
FAL_Server='INSTADGLOC'

Log_archive_format='INSTA_%t_%s_%r.arc' Log_archive_config='DG_CONFIG=(INSTA,INSTADG)'
Log_archive_dest_1='Location=/u01/app/oracle/oradata/INSTA/backup VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=INSTA'
Log_archive_dest_2='Service=INSTADGLOC LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 

db_unique_name=INSTADG delay=1'

Log_archive_dest_state_1='ENABLE' Log_archive_dest_state_2='ENABLE'

log_file_name_convert='/u01/app/oracle/oradara/INSTADG','/u01/app/oracle/oradata/INSTA' db_file_name_convert='/u01/app/oracle/oradara/INSTADG','/u01/app/oracle/oradata/INSTA'

remote_login_passwordfile='EXCLUSIVE' Standby_File_Management='auto' 

On constate que ce fichier comporte des informations sur l’instance à laquelle il est relié, mais aussi de nombreuses références à notre base de secours. Examinons de plus près certains paramètres :

  • FAL_Client : pointage vers le service Oracle Net client
  • FAL_Server : pointage vers le service Oracle Net server
  • Log_archive_format : format de nom des fichiers redo logs
  • Log_archive_config : autorise ou non le transfert des redû logs entre les bases spécifiées dans DG_CONFIG
  • Log_archive_dest_1 : stockage des redo logs comme une base classique
  • Log_archive_dest_2 : stockage des redo logs vers une base distante
  • log_file_name_convert : conversion des noms des redo logs entre nos bases
  • db_file_name_convert : conversion des noms des bases de données

Nous avons donc défini tous les paramètres nécessaires au basculement. De cette façon, nous savons désormais comment passer de la base primaire à notre base secondaire.

Cependant, le chemin n’est pas complet puisque le chemin retour n’est pas encore établi.

Il suffit donc de configurer le fichier initINSTADG.ora de la même manière mais en inversant les valeurs :

  • Les FAL_Client et FAL_Server permuttent leurs valeurs.
  • On permute les valeurs contenues dans Log_archive_config
  • On permute Log_archive_dest_1 avec Log_archive_dest_2
  • log_file_name_convert et db_file_name_convert permuttent leurs valeurs respectives

Switchover

Le switchover est une manoeuvre volontaire, relativement rapide à effectuer, permettant le basculement entre la primary base et la standby.

Ce basculement peut être nécessaire le temps d’une mise à jour, maintenance etc sur le serveur hôte de la base. Pour ce faire, tout une suite de commandes sont à exécuter, à la fois sur la base primaire et la base secondaire.

Une fois l’opération terminée, les rôles sont inversés : la primaire devient secondaire et la secondaire devient primaire. L’opération est renouvelable à l’infini.

Le processus est disponible en suivant le lien ci-dessous :

Dataguard Oracle 11gR2


Laisser un commentaire

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