Créer une standby physique et configurer le Broker Data Guard est très simple. Si vous n’aimez pas Enterprise Manager et sa console web, vous trouverez ci-dessous l’ensemble des étapes nécessaires pour effectuer cette opération manuellement avec Recover Manager (RMAN).

Pour les besoins de cette explication, voici quelques précisions quant à l’environnement de test utilisé pour rédiger ce qui suit :

• La base de données et l’instance primaire s’appellent ORCL
• L’instance de standby s’appellera GARK
• La base de données Oracle est la version 10.2.0.3 sur Oracle Enterprise Linux (A peu prêt RHEL 4).
• Les bases de données primaire et standby sont sur la même machine (dans le même ORACLE_HOME). La procédure est similaire avec 2 bases de données sur des machines différentes.
• Le serveur s’appelle « arkzoyd »
• Le stockage utilisé est ASM. L’ensemble des fichiers résident dans le diskgroup +DATA.

Voici les 10 étapes qui vous permettront d’arriver à une configuration

Etape 1 – Passer la base de données primaire en mode Archivelog

La standby physique est une copie de la base de données primaire. Elle est mise à jour grâce à un process de « Redo Apply », c’est à dire un recover des fichiers de Redo Logs sur cette base de données. Il faut transmettre les Archive/Redo Logs sur la machine de standby. Pour cela, il faut s’assurer que la base de données primaire est en mode Archivelog et que les opérations sont journalisées. Pour cela, effectuez les opérations qui suivent :

oracle$ export ORACLE_SID=ORCL
oracle$ sqlplus / as sysdba
SQL> select dbid, name, log_mode, force_logging
from v$database;
DBID NAME LOG_MODE FOR
———- ——— ———— —
1137540194 ORCL NOARCHIVELOG NO

si la base de données n’est pas en mode archivelog, il faut passer l’instance en mode mount pour activer ce mode pour la base de données. Vérifiez également que les paramètres des archivelogs sont bien définis (i.e. les paramètres log_archive_dest_n , log_archive_dest_state_1 et log_archive_format). On supposera que l’on utilise ASM et que les archivelogs sont stockés dans un diskgroup noté +BACKUP. Pour cela, effectuez les opérations qui suivent :

SQL> alter system set log_archive_dest_1=’LOCATION=+BACKUP’ scope=both;
SQL> alter system set log_archive_dest_state_1=enable scope=both;
SQL> alter system set log_archive_format=’%t_%s_%r.dbf’ scope=spfile;
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> alter system archive log current;
SQL> set lines 120
SQL> col name format a80
SQL> select sequence#, name
from v$archived_log
order by sequence#;
SQL> alter system archive log current;
SQL> select sequence#, name
from v$archived_log
order by sequence#;

Forcez la base de données à journaliser toutes les opérations, y compris les opérations déclarées comme NOLOGGING, comme peut l’être la création d’une table avec la commande qui suit.
SQL> alter database force logging;
SQL> select dbid, name, log_mode, force_logging
from v$database;
DBID NAME LOG_MODE FOR
———- ——— ———— —
1137540194 ORCL ARCHIVELOG YES

Remarque :
Si la création d’une table n’est pas journalisée, la table ne pourra pas être créée dans la base de données standby. On voit ici une des limites des bases de données standby ! Cette limite peut être dépassée, sur des environnement de type data warehouse, par exemple, en fusionnant régulièrement des sauvegardes incrémentales sur une copie distante de la base de données. Et c’est une autre histoire…

Etape 2 – Configurer le service et le fichier de password de la standby

Sous Linux, mettez à jour le fichier /etc/oratab. Sous Windows, il faut utiliser le fichier l’utilitaire « oradim ». Voici un exemple de mise à jour du fichier oratab :
oracle$ echo GARK:/u01/oracle/product/10.2.0/db_1:N >>/etc/oratab
oracle$ cat GARK:/u01/oracle/product/10.2.0/db_1:N >>/etc/oratab

Il faut ensuite créer le fichier de mot de passe. On supposera que le mot de passe de SYS est « manager1 ». Pour cela, tapez la ligne ci-dessous :
oracle$ $ORACLE_HOME/bin/orapwd file=$ORACLE_HOME/dbs/orapwGARK
password=manager1 entries=5 force=y
Attention
le nom et l’emplacement du fichier de mot de passe dépend de la plateforme. Sous windows, il s’agit d’%ORACLE_HOME%/database/PWDGARK.ORA.

Etape 3 – Créer un fichier spfile pour démarrer l’instance standby.

Nous allons partir du spfile de l’instance primaire, générer un init.ora et le modifier
oracle$ export ORACLE_SID=ORCL
oracle$ sqlplus / as sysdba
SQL> create pfile=’/tmp/initGARK.ora’ from spfile;
SQL> exit;

Poussez le fichier sur la seconde machine dans /tmp/initGARK.ora et modifiez-le comme indiqué ci-dessous :

• Modifiez l’ensemble des paramètres qui pointent vers des répertoires de sorte qu’ils pointent vers une structure qui conviennent à votre base de données de standby (e.g. audit_file_dest, background_dump_dest, core_dump_dest, user_dump_dest) puis créer l’arborescence correspondante comme dans l’exemple ci-dessous :
  oracle$ mkdir -p /u01/admin/GARK/adump
  oracle$ mkdir -p /u01/admin/GARK/bdump
  oracle$ mkdir -p /u01/admin/GARK/cdump
  oracle$ mkdir -p /u01/admin/GARK/udump
  oracle$ mkdi
  r -p /u01/admin/GARK/pfile
• Modifiez le paramètre control_files pour qu’il pointe vers un fichier différent (ou dans le cas de ASM, un alias comme +DATA/GARK/CONTROLFILE/control01.dbf)
• Ajoutez le paramètre db_unique_name=’GARK’.
• Positionnez les paramètres db_file_name_convert, log_file_name_convert, log_archive_config et standby_file_management pour permettre la translation des arborescences de ORCL vers GARK et déclarer toutes les bases qui font parties de la configuration. Si vous utilisez ASM, ce n’est pas utile de changer les paramètres *_file_name_convert, sauf si vous voulez changer la base de données de diskgroup. Voici, ci-dessous un exemple de paramétrage possible :
  db_file_name_convert=’ORCL’,’GARK’
  log_file_name_convert=’ORCL’,’GARK’
  log_archive_config=’DG_CONFIG=(GARK,ORCL)’
  standby_file_management=’AUTO’
• Paramètrez l’endroit où seront stockés les fichiers d’archives envoyés sur la standby :
  standby_archive_dest=’+BACKUP’
• Mettez en place les paramètres fal_client et fal_server de résolution des GAP dans les fichiers archivelogs :
  fal_client=’GARK’
  fal_server=’ORCL’
• Paramétrez les destinations des archives sur le système de fichiers et sur un service distant avec les paramètres log_archive_dest_1 et log_archive_dest_2 :
  log_archive_dest_1=’LOCATION=+BACKUP VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=GARK’
  log_archive_dest_2=’SERVICE=ORCL LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL’

Démarrez l’instance GARK sur la seconde machine sur le spfile :
oracle$ export ORACLE_SID=GARK
oracle$ sqlplus / as sysdba
SQL> startup nomount pfile=’/tmp/initGARK.ora’;
SQL> create spfile from pfile=’/tmp/initGARK.ora’;
SQL> shutdown abort;
SQL> startup nomount;

Etape 4 – Créer une copie « FOR STANDBY » du controlfile et une sauvegarde de la base de données

Dans un premier temps, créez un répertoire accessible depuis la machine primaire pour stocker la sauvegarde de la base de données ainsi que la copie du controlfile « FOR STANDBY » :
oracle$ mkdir -p /u01/backups/ORCL

Ensuite faîte une copie du controlfile « FOR STANDBY » avec RMAN :
oracle$ export ORACLE_SID=ORCL
oracle$ rman target=/ nocatalog
RMAN> configure default device type to disk;
RMAN> configure device type disk backup type to compressed backupset;
RMAN> configure channel device type disk format ‘/u01/backups/ORCL/%U’;
RMAN> copy current controlfile for standby to ‘/u01/backups/ORCL/control01.dbf’;

Enfin faîtes une sauvegarde de la base de données toujours aver Recovery Manager
RMAN> backup database plus archivelog;

Attention
il faut faire un recover de la standby jusqu’à un SCN supérieur au SCN du moment de la constitution de la copie du controlfile « FOR STANDBY ». Si vous prévoyez d’utiliser un backup existant (sur disque ou bande), effectuez un switch du log courant, effectuer une sauvegarde des archivelog et mettez-le à disposition sur la machine de standby.

Etape 5 – Créer les alias TNS pour les 2 instances :

Il faut déclarer les instances de manière statique dans les listeners afin de pouvoir accéder aux instances même lorsque les instances ne sont pas démarrées.

Pour cela, ajoutez dans le fichier listener.ora de la première machine (si le listener s’appelle LISTENER). Si le fichier n’existe pas, vous pouvez utiliser netmgr (Network Manager) :
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=ORCL)
(ORACLE_HOME=/u01/oracle/product/10.2.0/db_1)
(SID_NAME=ORCL)
)
)

Ajoutez dans le fichier listener.ora de la deuxième machine (si le listener s’appelle LISTENER) :
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(GLOBAL_DBNAME=GARK)
(ORACLE_HOME=/u01/oracle/product/10.2.0/db_1)
(SID_NAME=GARK)
)
)

Si vous utilisez le même listener dans les 2 cas, mettez simplement les 2 SID_DESC dans le paramètre SID_LIST. Ensuite, il faut créer les alias TNS. Utilisez le même nom pour les alias et les instances. Ajoutez sur TOUTES les machines ou dans une configuration centralisée des chaînes de connexion semblables à celles ci-dessous :
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = arkzoyd)(PORT = 1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
)

GARK =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = arkzoyd)(PORT = 1521))
)
(CONNECT_DATA =
(SID = GARK)
)
)

Etape 6 – Instancier la base de données standby à partir des sauvegardes RMAN

Il faut pousser les fichiers de sauvegarde jusqu’à la machine de standby de sorte que les fichiers soient disponibles pour la restauration et le recover depuis la machine de standby. Vous pouvez utiliser pour cela la méthode de votre choix : FTP, SCP ou même un umount/mount si vos disques sont partagés.

Ensuite utiliser la commande RMAN qui suit sur la machine primaire :
oracle$ export ORACLE_SID=ORCL
oracle$ rman target=/ auxiliary=sys@gark
RMAN> run
{
duplicate target database for standby
nofilenamecheck
dorecover;
}
Pour éviter les erreurs, vous pouvez utiliser la commande « SET UNTIL SEQUENCE » pour préciser jusqu’à quel archivelog vous voulez effectuer le recover.

Etape 7 – Modifier les paramètres de l’instance primaire

Sur l’instance primaire vous pouvez mo
difier les paramètres dynamiques comme ce qui suit :
oracle$ export ORACLE_SID=ORCL
oracle$ sqlplus / as sysdba
SQL> alter system set fal_server=’GARK’ scope=both;
SQL> alter system set fal_client=’ORCL’ scope=both;
SQL> alter system set log_archive_config=’DG_CONFIG=(GARK,ORCL)’ scope=both;
SQL> alter system set standby_file_management=’AUTO’ scope=both;
SQL> alter system set log_archive_dest_2=’SERVICE=GARK LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=GARK’ scope=both;
Dans cette section en particulier, en plus de décrire les bases de données qui font parties de la configuration, vous indiquez à l’instance qu’elle doit désormais envoyer ses archivelogs sur l’instance standby.

Etape 8 – Démarrer le processus d’Apply sur la base de données Standby

Pour cela, connectez-vous à l’instance de standby et tapez ce qui suit :
oracle$ export ORACLE_SID=GARK
oracle$ sqlplus / as sysdba
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Etape 9 – Tester que les archives sont envoyées et appliquées sur la base de données standby

Pour cela, connectez-vous à l’instance primaire et effectuez 2 ou 3 switch de log :
oracle$ export ORACLE_SID=ORCL
oracle$ sqlplus / as sysdba
SQL> alter system archive log current;
SQL> alter system archive log current;

Vous pouvez vérifier que les archive logs ont été générées :
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Enfin, connectez-vous à l’instance standby pour vérifier que les fichiers ont été receptionnés et correctement appliqués sur la standby :
oracle$ export ORACLE_SID=GARK
oracle$ sqlplus / as sysdba
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Si ce n’est pas le cas, vérifiez dans les fichiers alert.log des 2 instances ORCL et GARK la raison pour laquelle les fichiers ne sont pas acheminés ou appliqués.

Etape 10 – Démarrer le Broker Data Guard et créer la configuration

Si la première instance de base de données, vous pouvez démarrer le process DMON qui sert à gérer l’infrastructure distribuée du Broker. Pour cela, effectuez ce qui suit :
oracle$ export ORACLE_SID=ORCL
oracle$ sqlplus / as sysdba
SQL> alter system set dg_broker_start=true scope=both;
SQL> exit;

Effectuez la même opération sur l’instance de standby :
oracle$ export ORACLE_SID=GARK
oracle$ sqlplus / as sysdba
SQL> alter system set dg_broker_start=true scope=both;
SQL> exit;

Ensuite, connectez-vous au broker Data Guard en mode ligne de commande
dgmgrl
DGMGRL> connect /

Créez la configuration Data Guard en décrivant la configuration de la primaire comme ceci :
DGMGRL> CREATE CONFIGURATION ‘DEMO’ AS
PRIMARY DATABASE IS ‘ORCL’
CONNECT IDENTIFIER IS ORCL;

Ajoutez les informations nécessaires pour ajouter la standby à la configuration :
DGMGRL> ADD DATABASE ‘GARK’ AS
CONNECT IDENTIFIER IS GARK
MAINTAINED AS PHYSICAL;

Enfin, activez la configuration :
DGMGRL> enable configuration;

La configuration prend quelques minutes pour être complètement activée. Vous pouvez valider que l’opération s’est correctement déroulée en tapant la commande ci-dessous :
DGMGRL> show configuration;

Si une opération ne se déroule pas comme attendu et que le résultat de l’activation de la configuration n’est pas SUCCESS, vous pouvez visualiser les message d’erreurs sur chacune des deux bases de données à l’aide de la commande suivante :
DGMGRL> show database ‘ORCL’ ‘LatestLog’;
DGMGRL> show database ‘GARK’ ‘LatestLog’;

… Et voilà, si votre base de données primaire est déjà en archivelog et qu’elle utilise un fichier SPFILE, l’ensemble de cette configuration s’effectue sans aucune indisponibilité et en quelques minutes (ou heures si vous déplacer des tera-octets). Avec un peu d’entraînement (et/ou avec Perl), vous créerez des standby à la chaîne ! Mais c’est une autre histoire et, surtout, plus la mienne…

GarK!