Blog

le 22/06/2010
Thomas Bordet
Oracle

Oracle Database 11g Release 2 Data Guard (6/5): Créer une standby logique avec le broker

Dans ce 6ème article de cette série consacrée à Oracle 11g Release 2 Data Guard, vous découvrirez comment créer une configuration physical standby à partir d’une sauvegarde disque grace à la commande DUPLICATE et sans se connecter à la target. Nous prendrons alors le soin, comme dans le premier article de la série de configurer le broker. Une fois cette première étape terminée, nous allons transformer la standby physique en standby logique. En effet, si l’opération est très bien documentée dans Oracle® Data Guard Concepts and Administration – 11g Release 2 (11.2) – Creating a Logical Standby Database, elle ne prend pas en compte l’existence du broker qui simplifie notablement l’opération et positionne, par exemple les paramètres log_archive_dest_n.
Cet article est le sixième de la série que je vous invite à découvrir ci-dessous :

Créer une Standby Physique avec `DUPLICATE ... BACKUP LOCATION`

Pour faire mes tests, j’ai utilisé Oracle 11g Release 2 sur Linux 32 bits. La base de données primaire et son instance s’appellent BLACK. La base de données standby s’appellera forcément BLACK mais son instance et son db_unique_name s’appelleront WHITE.

Service, fichier de mot de passe et configuration réseau

Configurer manuellement une base de données standby nécessite que vous commenciez par configurer le service pour cette nouvelle base de données, le fichier de mot de passe et les listeners et alias TNS. Commencez donc par le service; sur Linux et Unix, cela consiste à alimenter le fichier oratab comme ci-dessous :

$ echo "WHITE:/u01/app/oracle/product/11.2.0/db_1:Y" >> /etc/oratab

L’étape suivante consiste à créer un fichier de mots de passe pour notre nouvelle instance standby. Le mot de passe utilisé, ainsi que la politique de respect de la casse, pour SYS (si vous utilisez SYS) doit être identique à celui de la base de données primaire. Voici comment configurer ce mot de passe sur le serveur de la standby :

. oraenv
WHITE
cd $ORACLE_HOME/dbs
orapwd file=orapwWHITE entries=5

Ensuite, pour simplifier la mise en œuvre de la commande duplicate et de la gestion, effectuez des enregistrements statiques des instances dans les listeners respectifs de BLACK et de WHITE :

. oraenv
BLACK
cd $ORACLE_HOME/network/admin
cat listener.ora
[...]
SID_LIST_LISTENER =
   (SID_LIST =
      (SID_DESC =
         (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
         (SID_NAME = BLACK)
      )
     [...]
  )
lsnrctl reload LISTENER
. oraenv
WHITE
cd $ORACLE_HOME/network/admin
cat listener.ora
[...]
SID_LIST_LISTENER =
   (SID_LIST =
      [...]
      (SID_DESC =
         (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
         (SID_NAME = WHITE)
      )
   )
lsnrctl reload LISTENER

Enfin, sur tous les $ORACLE_HOME de vos configurations, ajoutez les alias TNS pour se connecter à BLACK et WHITE. Par exemple, dans mon cas, j’utilise le fichier tnsnames.ora et j’ai ajouté les entrées ci-dessous:

cat tnsnames.ora
BLACK =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = arkzoyd-black)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = BLACK)
    )
  )
WHITE =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = arkzoyd-white)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = WHITE)
    )
  )

Démarrer le broker et créez les fichiers de standby log

. oraenv
BLACK
sqlplus / as sysdba
alter system set dg_broker_start=true;
set num 15
select group#, thread#, bytes
   from v$log
  order by group#;
set num 15
select group#, thread#, bytes
   from v$standby_log
  order by group#;
alter database add standby logfile thread 1 group 4
   ('/u01/app/oracle/oradata/BLACK/standby04.log') SIZE 52428800;
alter database add standby logfile thread 1 group 5
   ('/u01/app/oracle/oradata/BLACK/standby05.log') SIZE 52428800;
alter database add standby logfile thread 1 group 6
   ('/u01/app/oracle/oradata/BLACK/standby06.log') SIZE 52428800;
exit;

Effectuez une sauvegarde de la base de données `BLACK`

Connectez-vous à la base de données primaire et effectuez une sauvegarde comme ci-dessous :

. oraenv
BLACK
rman target /
host 'mkdir -p /u01/app/oracle/backup/BLACK';
backup as compressed backupset
       to destination '/u01/app/oracle/backup/BLACK'
       database plus archivelog;
exit;

Une fois la base de données sauvegardée, utilisez la méthode de votre choix (NFS, scp,…) pour que les fichiers soient accessibles depuis le serveur de standby:

. oraenv
WHITE
scp -r black:/u01/app/oracle/backup/BLACK /u01/app/oracle/backup/WHITE

Créer la base de données standby

Pour créer la base de données standby, utilisez la commande duplicate sans vous connecter à la target en adaptant le script ci-dessous:

. oraenv
WHITE
rman auxiliary /
startup clone nomount;

Un message comme celui ci-dessous s’affiche :

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/db_1/dbs/initWHITE.ora'
starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started
Total System Global Area     159019008 bytes
Fixed Size                     1335192 bytes
Variable Size                 75497576 bytes
Database Buffers              75497472 bytes
Redo Buffers                   6688768 bytes

Vous n’avez plus ensuite qu’à créer l’arborescence pour vos fichiers ; visiblement RMAN est capable de créer certains répertoires mais je n’ai pas eu l’opportunité de tester sans créer les répertoires pour les datafiles et archivelogs :

host 'mkdir -p /u01/app/oracle/oradata/WHITE/archivelogs';

Lancer enfin la commande duplicate comme ci-dessous; vous remarquerez l’utilisation de seulement 4 paramètres :

DUPLICATE TARGET DATABASE
   FOR STANDBY
   BACKUP LOCATION '/u01/app/oracle/backup/WHITE'
      DB_FILE_NAME_CONVERT 'BLACK','WHITE'
      SPFILE
          PARAMETER_VALUE_CONVERT 'BLACK','WHITE'
          SET LOG_FILE_NAME_CONVERT 'BLACK','WHITE'
          SET DB_UNIQUE_NAME 'WHITE'
          NOFILENAMECHECK;

Il ne vous reste plus qu’à patienter et le cas échéant, superviser l’avancement de la sauvegarde avec v$rman_status et v$session_longops; si vous n’utilisez qu’une base de test, en moins de 3 minutes, vous aurez constitué la base de données standby; voici un exemple d’exécution de la commande :

Starting Duplicate Db at 01-NOV-09
contents of Memory Script:
{
   restore clone spfile to  '/u01/app/oracle/product/11.2.0/db_1/dbs/spfileWHITE.ora' from
 '/u01/app/oracle/backup/WHITE/BLACK/backupset/2009_11_01/o1_mf_ncsnf_TAG20091101T194505_5gvov9ly_.bkp';
   sql clone "alter system set spfile= ''/u01/app/oracle/product/11.2.0/db_1/dbs/spfileWHITE.ora''";
}
executing Memory Script
Starting restore at 01-NOV-09
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=96 device type=DISK
channel ORA_AUX_DISK_1: restoring spfile from AUTOBACKUP /u01/app/oracle/backup/WHITE/BLACK/backupset/2009_11_01/o1_mf_ncsnf_TAG20091101T194505_5gvov9ly_.bkp
channel ORA_AUX_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 01-NOV-09
sql statement: alter system set spfile= ''/u01/app/oracle/product/11.2.0/db_1/dbs/spfileWHITE.ora''
contents of Memory Script:
{
   sql clone "alter system set  audit_file_dest =
 ''/u01/app/oracle/admin/WHITE/adump'' comment=
 '''' scope=spfile";
   sql clone "alter system set  control_files =
 ''/u01/app/oracle/oradata/WHITE/control01.ctl'', ''/u01/app/oracle/oradata/WHITE/control02.ctl'' comment=
 '''' scope=spfile";
   sql clone "alter system set  dispatchers =
 ''(PROTOCOL=TCP) (SERVICE=WHITEXDB)'' comment=
 '''' scope=spfile";
   sql clone "alter system set  log_archive_dest_1 =
 ''location=/u01/app/oracle/oradata/WHITE/archivelogs'' comment=
 '''' scope=spfile";
   sql clone "alter system set  LOG_FILE_NAME_CONVERT =
 ''BLACK'', ''WHITE'' comment=
 '''' scope=spfile";
   sql clone "alter system set  db_unique_name =
 ''WHITE'' comment=
 '''' scope=spfile";
   shutdown clone immediate;
   startup clone nomount;
}
executing Memory Script
sql statement: alter system set  audit_file_dest =  ''/u01/app/oracle/admin/WHITE/adump'' comment= '''' scope=spfile
sql statement: alter system set  control_files =  ''/u01/app/oracle/oradata/WHITE/control01.ctl'', ''/u01/app/oracle/oradata/WHITE/control02.ctl'' comment= '''' scope=spfile
sql statement: alter system set  dispatchers =  ''(PROTOCOL=TCP) (SERVICE=WHITEXDB)'' comment= '''' scope=spfile
sql statement: alter system set  log_archive_dest_1 =  ''location=/u01/app/oracle/oradata/WHITE/archivelogs'' comment= '''' scope=spfile
sql statement: alter system set  LOG_FILE_NAME_CONVERT =  ''BLACK'', ''WHITE'' comment= '''' scope=spfile
sql statement: alter system set  db_unique_name =  ''WHITE'' comment= '''' scope=spfile
Oracle instance shut down
connected to auxiliary database (not started)
Oracle instance started
Total System Global Area     263639040 bytes
Fixed Size                     1335892 bytes
Variable Size                 92278188 bytes
Database Buffers             163577856 bytes
Redo Buffers                   6447104 bytes
contents of Memory Script:
{
   restore clone standby controlfile from  '/u01/app/oracle/backup/WHITE/BLACK/backupset/2009_11_01/o1_mf_ncsnf_TAG20091101T194505_5gvov9ly_.bkp';
}
executing Memory Script
Starting restore at 01-NOV-09
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=10 device type=DISK
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/WHITE/control01.ctl
output file name=/u01/app/oracle/oradata/WHITE/control02.ctl
Finished restore at 01-NOV-09
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=10 device type=DISK
contents of Memory Script:
{
   set newname for tempfile  2 to
 "/u01/app/oracle/oradata/WHITE/temp02.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/u01/app/oracle/oradata/WHITE/system01.dbf";
   set newname for datafile  2 to
 "/u01/app/oracle/oradata/WHITE/sysaux01.dbf";
   set newname for datafile  3 to
 "/u01/app/oracle/oradata/WHITE/undotbs01.dbf";
   set newname for datafile  4 to
 "/u01/app/oracle/oradata/WHITE/users01.dbf";
   set newname for datafile  5 to
 "/u01/app/oracle/oradata/WHITE/example01.dbf";
   restore
   clone database
   ;
}
executing Memory Script
executing command: SET NEWNAME
renamed tempfile 2 to /u01/app/oracle/oradata/WHITE/temp02.dbf in control file
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 01-NOV-09
using channel ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/WHITE/system01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/WHITE/sysaux01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/WHITE/undotbs01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/WHITE/users01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/WHITE/example01.dbf
channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/backup/WHITE/BLACK/backupset/2009_11_01/o1_mf_nnndf_TAG20091101T194505_5gvoskr1_.bkp
channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/backup/WHITE/BLACK/backupset/2009_11_01/o1_mf_nnndf_TAG20091101T194505_5gvoskr1_.bkp tag=TAG20091101T194505
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:01:15
Finished restore at 01-NOV-09
contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script
datafile 1 switched to datafile copy
input datafile copy RECID=6 STAMP=701812621 file name=/u01/app/oracle/oradata/WHITE/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=7 STAMP=701812621 file name=/u01/app/oracle/oradata/WHITE/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=8 STAMP=701812622 file name=/u01/app/oracle/oradata/WHITE/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=9 STAMP=701812622 file name=/u01/app/oracle/oradata/WHITE/users01.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=10 STAMP=701812622 file name=/u01/app/oracle/oradata/WHITE/example01.dbf
Finished Duplicate Db at 01-NOV-09

Créer et activer la configuration Data Guard

Pour terminer la configuration, il suffit de créer la configuration dans le broker et de l’activer; l’ensemble du paramétrage de la “managed” standby sera créé en conséquence :

. oraenv
BLACK
dgmgrl /
create configuration rainbow as
    primary database is BLACK
    connect identifier is BLACK;
Configuration "rainbow" created with primary database "black"
add database white
    as connect identifier is white
    maintained as physical;
Database "white" added
show configuration
Configuration - rainbow
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
enable configuration;
Enabled.
show configuration verbose;
Configuration - rainbow
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Pour terminer, enregistrez les alias TNS statique dans le nouveau paramètre d’Oracle 11g Release 2 StaticConnectIdentifier; cela simplifie la lisibilité de la configuration ainsi que les arrêts/démarrages des instances depuis le broker:

edit database white set property StaticConnectIdentifier='WHITE';
edit database black set property StaticConnectIdentifier='BLACK';
exit

Oops ! Les fichiers temporaires ne sont pas renommés. Pourtant le script fait apparaître la nouvelle destination dans la commande duplicate. Pire ! Si BLACK et WHITE sont sur le même serveur, quand je supprime le fichier de WHITE, il est supprimé du système de fichier même lorsqu’il est utilisé par BLACK. Vous ferez donc très attention dans votre configuration à ce problème en particulier lors du premier changement de role de votre base de données

Convertir la standby physique en standby logique avec le broker

Dans la suite de cet article, nous allons maintenant convertir la standby physique en standby logique avec l’aide du broker

Avant de procéder, assurez-vous que les fichiers temporaires des 2 bases ne sont pas en conflit comme décrit dans la section précédente

Pour commencer, nous allons arrêter le processus d' »APPLY » et vérifier que la base standby est en mode MOUNTED :

. oraenv
BLACK
dgmgrl /
edit database white
  set state=APPLY-OFF;
show database white;
Database - white
Role:            PHYSICAL STANDBY
Intended State:  APPLY-OFF
Transport Lag:   0 seconds
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
WHITE
Database Status:
SUCCESS
exit

Supprimer la Physical standby de la configuration du Broker

Nous allons maintenant changer la configuration du broker et supprimer la standby physique :

. oraenv
BLACK
dgmgrl /
remove database white preserve destinations;

Vérifier les type de données et les tables sans clés

Avant de transformer la base de standby en stanby logique, nous allons vérifier que tous les types de notre base de données sont supportés et que les tables qui seront maintenues par la standby logiques on une clé. Exécutez la requête suivante sur la base de données BLACK :

. oraenv
BLACK
sqlplus / as sysdba
select owner, table_name
  from dba_logstdby_not_unique
 where (owner, table_name) not in
       (select distinct owner, table_name
          from dba_logstdby_unsupported)
           and bad_column='Y';
no rows selected    
select distinct owner, table_name
         from dba_logstdby_unsupported;
[...]

Capturer le dictionnaire de données sur la base de données primaire

Pour créer une configuration Logical Standby, il faut constituerle MVDD et pour cela, capturer le dictionnaire de données sur la base de données source (BLACK). Assurez-vous également qu’il n’y a pas de transaction en cours. Pour cette opération, vous utiliserez le package dbms_logstdby comme ci-dessous :

. oraenv
BLACK
sqlplus / as sysdba
exec dbms_logstdby.build;
exit;

Appliquer les logs sur la standby

La base de données standby peut désormais être synchronisée jusqu’au point où elle pourra être transformée en standby logique. Pour ce faire, exécutez les étapes ci-dessous :

. oraenv
WHITE
sqlplus / as sysdba
alter database recover
    to logical standby WHITE;
Database altered.

Ouvrir la base de données standby avec un ResetLogs

Ouvrez la standby physique avec un resetlogs :

shutdown
ORA-01507: database not mounted
ORACLE instance shut down.
startup mount
ORACLE instance started.
Total System Global Area  263639040 bytes
Fixed Size      1335892 bytes
Variable Size    104861100 bytes
Database Buffers   150994944 bytes
Redo Buffers      6447104 bytes
Database mounted.
alter database open resetlogs;
Database altered.

exit;

Reconstruire la configuration du Broker

Vous pouvez désormais reconstruire la configuration du broker en ajoutant WHITE comme standby logique à votre configuration. Cette opération est très simple et effectue la multitude d’étapes que vous devrez effectuer manuellement comme décrit dans le manuel sinon :

. oraenv
BLACK
show configuration
Configuration - worldwide
Protection Mode: MaxPerformance
Databases:
black - Primary database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
add database white
  as connect identifier is white
  maintained as logical;
Database "white" added
enable configuration;
Enabled.
show configuration;
Configuration - worldwide
Protection Mode: MaxPerformance
Databases:
black - Primary database
white - Logical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
enable configuration;
Enabled.
show configuration
Configuration - worldwide
Protection Mode: MaxPerformance
Databases:
black - Primary database
white - Logical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Note:
Cela peut prendre plusieurs minutes pour que la standby et que sa base de données primaire arrivent dans l’état attendu ; soyez patient ! Toutefois si après 10 minutes la configuration est toujours en erreur, vérifiez le fichier alert.log et corrigez les erreurs potentielles.

Changer les propriétés de la configuration

Changez les propriétés de la configuration pour faciliter le switchover et modifier le mode de protection le cas échéant :

edit database white
     set property StaticConnectIdentifier=white;
edit database black
     set property StaticConnectIdentifier=black;
edit database white set property LogXptMode='SYNC';
edit database black set property LogXptMode='SYNC';
edit configuration
     set protection mode as MaxAvailability;
show configuration;

Tester la standby logique

Une fois la configuration effectuée, testez-là. Assurez-vous que tous les changements effectués sur la base de données primaire sont propagés sur la standby logique avec un test sur les données d’une table par exemple :

. oraenv
BLACK
sqlplus / as sysdba
update scott.emp
    set sal=10000
  where ename='KING';
commit;
exit;
. oraenv
WHITE
sqlplus / as sysdba
select sal
  from scott.emp
 where ename='KING';
SAL
-----
10000

Vous pouvez également effectuer un changement de role de vos bases de données pour valider que la configuration fonctionne comme attendu :

. oraenv
BLACK
dgmgrl /
switchover to white;
Performing switchover NOW, please wait...
Switchover succeeded, new primary is "white"
show configuration;
Configuration - rainbow
  Protection Mode: MaxAvailabilityhttp://easyteam.wordpress.com/wp-admin/post.php?post=1728&action=edit&message=10
  Databases:http://easyteam.wordpress.com/wp-admin/paid-upgrades.php
    white - Primary database
    black - Logical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Conclusion

Voilà qui termine, cette fois espérons pour de bon, ma série d’articles à propos de Data Guard 11g Release 2. Auriez-vous toléré que je ne parle pas des standby logiques ? Remarquez que si le travail est terminé pour moi, ce n’est pas le cas pour vous puisqu’il est désormais possible de configurer un process de capture Oracle Streams à partir d’une standby logique. Il ne vous reste donc plus qu’à suivre la procédure documentée dans la section suivante : Oracle® Data Guard Concepts and Administration – 11g Release 2 (11.2) – 10.6.6 Running an Oracle Streams Capture Process on a Logical Standby Database.

Thomas Bordet

Voir tous ses articles

5 réflexions sur “Oracle Database 11g Release 2 Data Guard (6/5): Créer une standby logique avec le broker”

Ping : Mes blogs classés par thèmes | EASYTEAM
Gilles Haro
23/12/2010 à 20:19

Oky, je viens de voir l’origine de ton commentaire sur mon blog 😉
A mon tour d’en faire un constructif : duplicate target database for standby from active database épargne de gros efforts !!
Globalement, on peut dire que plus les versions avancent, plus c’est simple. Mais l’important, c’est de comprendre ce qu’il y a derrière !
@bientôt.
1. arkzoyd
  23/12/2010 à 21:03
  
  Gilles,
  Tu parles aussi français ; tu es plein de talents ;-P. Tu fais peut-être référence au premier article de la série.
  Ce que j’apprécie avec ton article à propos de Data Guard, c’est quelque chose du genre :
  » Les idiots ignorent la complexité. Les pragmatiques en souffrent. Certains parviennent à l’éviter. Les génies la suppriment. » Epigrams on Programming, Alan J. Perlis
  Au fait, ma réponse à ton article est sur mon blog!
  1. Gilles
    11/01/2011 à 18:54
    
    Many thanks for referencing my post !
    Have a look at the last one : Clusterware and Automatic Failover !
    Cheers,
    Gilles
Ping : Learning … this week « Oracle DB 10g & 11g Tops

Les commentaires sont fermés.