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 :
- Le 1er article, présente comment créer une configuration Data Guard en 5 minutes, en plus du temps de copie de la base de données et comment effectuer une transition des roles des bases de données
- Le 2nd article, présente comment changer le mode de protection, activer la compression, Snapshot Standby et Real Time Query
- Le 3ème article illustre le fonctionnement de la correction automatique de blocs corrumpus sur la base de données primaire et standby
- Le 4ème article démontre comment garantir la fraicheur des données sur la standby
- Le 5ème article illustre l’utilisation du Block Change Tracking File sur la base standby et l’utilisation de la commande
recover database noredopour gérer la perte d’un fichier archivelog - Le 6ème article (celui-ci) illustre la constitution d’une standby physique sans se connecter à la base primaire puis la conversion de cette standby physique en standby logique
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
BLACKetWHITEsont 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.


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.
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!
Many thanks for referencing my post !
Have a look at the last one : Clusterware and Automatic Failover !
Cheers,
Gilles
Paypal pour SEOPanel – Faites Plaisir a vos visiteurs ou clients. Aidez-les dans leurs referencements avec les Outils SEO de SEOPanel. Installez votre SEOPanel avec son Interface de Paiement Paypal. Visitez notre site. pagerank, seo analyse,sitemap.