Dataguard - Configuration

 

Bonjour !
Nous nous sommes quittés la semaine passée avec un petit article sur la création d'une P.S.D (Physical Standby Database) à l'aide de dbca : http://www.lami-dba.com/2018/05/dataguard-create-standby-database.html
Nous avons maintenant une base principale (ou Primary), et une base de secours (ou Standby). Cependant si on reste en l'état, notre base de secours va rester figé et ne représentera notre base primaire qu'au moment de sa création....
 

Il va donc y avoir un minimum de configuration à faire pour que ma standby soit mise à jour de façon automatique. Comme je l'avais indiqué dans l'article précédent, deux options:

• La méthode que je nommerai "A l'ancienne", (et il n'y a rien de péjoratif la dedans)
• Uitilisation du broker (dgmgrl).

Aujourd'hui nous allons parler de la première méthode.Pour que tout cela fonctionne il faut évidemment que la partie "network" d'un point de vue Oracle soit OK. Et donc que listener & tnsnames.ora soient configurés sur mes deux serveurs.
Sur mon serveur primaire (rasta)

listener.ora

[oracle@rasta admin]$ cat listener.ora
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = rastadb)
    )
  )

LISTENER =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rasta.localdomain)(PORT = 1521))
  )

Sur mon serveur de secours (prettyboy)

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = rastadb)
    )
  )

LISTENER =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prettyboy.localdomain)(PORT = 1521))
  )

Et sur mes deux serveurs un tnsnames.ora avec les deux mêmes entrées.

PRETTY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = prettyboy)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = rastadb)
    )
  )

RASTA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rasta)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = rastadb)
    )
  )

Remarque : avant d'aller plus loin on test que tout cela fonctionne dans les deux sens (tnsping & connexion en sys). Lors de la création de la standby nous avions vu que nous avions le même fichier de password sur les deux serveurs...Mais comme le dit (je ne me souviens plus qui d'ailleurs) "La confiance n'exclue pas le contrôle !"

Et coté base de données...
Un petit état des lieux s'impose..
 

Rasta:(serveur principale)

Prettyboy (serveur de secours)

Toujours lors de la création de standby, nous avions vu qu'avant de la créer, il fallait s'assurer que la base soit en mode "FORCE LOGGING" . Ce qui est bien sur mon cas.

SQL>
SQL> select FORCE_LOGGING from v$database;

FORCE_LOGGING
---------------------------------------
YES

Si jamais ça n'était pas le cas... il n'est pas trop tard ;)

SQL>
SQL> ALTER DATABASE FORCE LOGGING;

Database altered.

SQL>

Nous pouvons maintenant configurer notre DG (trop long à écrire Dataguard ;))
sur les deux serveurs.

LOG_ARCHIVE_CONFIG va nous indiquer quelles sont les bases impliquées dans notre DG.
ATTENTION : Les valeurs indiquées rastadb, rastastby correspondent aux DB_UNIQUE_NAME !

SQL>
SQL> alter system set log_archive_config = 'DG_CONFIG=(rastadb,rastastby)' scope=both;

System altered.

SQL>

Il va maintenant falloir indiquer à ma base primaire (rastadb) ou et comment envoyer mes transactions sur la base secondaire.
Remarque : Evidemment ma base est en archivelog, et j'utise la FRA (Fast Recovery Area) pour gérer tout cela. Cependant, je vais devoir indiquer à ma base qu'en plus de générer mes archives en local (FRA), il va falloir également les envoyer vers ma base de secours.
On notera ici le début de la syntaxe SERVICE=PRETTY .... PRETTY correspond à l'alias crée dans le tnsnames.ora en début d'article.Histoire de ne pas me perdre dans toutes les options possibles, je ne rentrerai pas dans le détail (peut être un prochain article), mais globalement la syntaxe parle d'elle même.

SQL>
SQL> alter system set log_archive_dest_2='SERVICE=PRETTY NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=rastastby' scope=both;

System altered.

SQL>

Lors de la vie de notre DG nous serons amenés à intervertir les rôles entre les deux bases. Je vais donc également indiquer à ma base standby sur prettybox que le jour ou elle aura le role de base primaire, elle devra envoyer ses redo vers rasta. Donc sur ma base standby (sur prettyboy)

SQL>
SQL> alter system set log_archive_dest_2='SERVICE=RASTA NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=rastadb' scope=both;

System altered.

SQL>

Il me reste un paramètre à initialiser : FAL_SERVER. Va permettre à ma standby d'identifier qui est la base primaire et aller réclamer son du en cas d'un gap d'archive par exemple.
Sur rasta 

SQL>
SQL> alter system set fal_server=PRETTY scope=both;

System altered.

SQL>

Sur prettyboy

SQL>
SQL> alter system set fal_server=RASTA scope=both;

System altered.

SQL>

Et voila nous sommes prêt... Notre configuration est terminée (je parle ici d'une configuration à minima). Il nous reste à dire à notre standby de communiquer avec la primaire et d'appliquer les redo qui en proviennent.

SQL>
SQL>  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL>

Generons un peu d'archives sur ma base primaire...

SQL>
SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';

select * from (
SELECT sequence#, first_time, next_time
FROM   v$archived_log
ORDER BY sequence# desc)
where rownum < 5;
Session altered.

SQL> SQL>   2    3    4    5

 SEQUENCE# FIRST_TIME           NEXT_TIME
---------- -------------------- --------------------
       299 29-MAY-2018 09:48:17 29-MAY-2018 09:48:20
       299 29-MAY-2018 09:48:17 29-MAY-2018 09:48:20
       298 29-MAY-2018 09:48:16 29-MAY-2018 09:48:17
       298 29-MAY-2018 09:48:16 29-MAY-2018 09:48:17

SQL>

Et maintenant vérifions coté standby...

SQL>
SQL> select * from (
SELECT sequence#, first_time, next_time, applied
FROM   v$archived_log
ORDER BY sequence# desc)
where rownum < 5;
  2    3    4    5
 SEQUENCE# FIRST_TIME           NEXT_TIME            APPLIED
---------- -------------------- -------------------- ---------
       299 29-MAY-2018 09:48:17 29-MAY-2018 09:48:20 YES
       298 29-MAY-2018 09:48:16 29-MAY-2018 09:48:17 YES
       297 29-MAY-2018 09:37:02 29-MAY-2018 09:48:16 YES
       296 29-MAY-2018 09:36:59 29-MAY-2018 09:37:02 YES

SQL>

Nous voyons bien que les archives ont été transféré et appliqué !

Remarque : Je n'ai pas parlé dans cet article des standby redo et c'est volontaire ;) Un prochain article abordera le sujet ;).
Enjoy !