Blog

Data Guard, Observer et Fast Start Failover

Cet article illustre la bascule automatique (aka Fast Start Failover) de Data Guard. Pour cela, vous devez mettre en oeuvre un troisième serveur sur un site indépendant des 2 autres et garantir que vous ne puissiez pas perdre la connectivité au site de production simultanément depuis le site de reprise et le site de surveillance. Le troisième serveur utilise un moteur Oracle Enterprise Edition et exécute un programme appelé « Observer » lancé depuis la ligne de commande dgmgrl.

Nous passerons les considérations d’architecture et de gestion pour assurer la fiabilité d’une telle configuration. L’objet ici est juste d’illustrer comment la configuration fonctionne.

Data Guard en mode Maximum Availability

Pour commencer, mettez en place une configuration Data Guard en mode Maximum Availability, c’est à dire avec une réplication synchrone des logs. Avec un peu de pratique, vous pourrez mettre en place cette configuration en moins de 30 minutes ; Si vous n’avez pas l’habitude, appuyez-vous sur 2 de mes articles pour mettre en place la configuration Data Guard avec la commande DUPLICATE FROM ACTIVE DATABASE puis pour activer le mode Maximum Availability et tester la bascule.

Notes :

  • Depuis Oracle 11.2, vous pouvez effectuer la configuration en mode Maximum Performance et donc avec une perte de données en cas de bascule. Evidemment, ce type de fonctionnement est à considérer avec précaution et je ne m’y risquerai pas à priori
  • J’ai légèrement modifié la commande duplicate dans le cas de ma configuration parce que mes controlfiles étaient gérés en OMF; dans ce cas, il suffit de supprimer le paramètres correspondant du fichier spfile comme ci-dessous : 
    DUPLICATE TARGET DATABASE FOR STANDBY
    FROM ACTIVE DATABASE DB_FILE_NAME_CONVERT 'BLACK','WHITE'
    SPFILE PARAMETER_VALUE_CONVERT 'BLACK','WHITE'
      RESET CONTROL_FILES
      SET DB_UNIQUE_NAME 'WHITE'
      SET LOG_FILE_NAME_CONVERT 'BLACK','WHITE';

Démarrer un « Observer »

Une fois la configuration en place, il suffit d’installer le moteur Oracle sur votre serveur tier et ajouter la configuration réseau pour voir toutes vos bases de données. Vous pouvez ensuite suivre la documentation Oracle 11.2 et en particulier cette section intitulée « Scenario 5: Enabling Fast-Start Failover and Starting the Observer ». Pour se faire, il suffit d’opérer les étapes ci-dessous :

  • Activer les flashback log sur vos bases Primaires et Standby

Note:
Il semble que l’activation, au moins en 11.2.0.2, ne nécessite plus que les instances soient en mode MOUNT et contrairement à ce qui était le cas auparavant.

Sur la base de données primaire, exécutez une séquence de commandes semblable à celle ci-dessous :

. oraenv
BLACK

mkdir /u01/app/oracle/oradata/BLACK/recoveryarea

sqlplus / as sysdba
show parameter recovery

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest       string
db_recovery_file_dest_size      big integer 0
recovery_parallelism       integer  0
alter system set db_recovery_file_dest_size=2G;
alter system set db_recovery_file_dest='/u01/app/oracle/oradata/BLACK/recoveryarea';
alter system set db_flashback_retention_target=3600;
alter database flahback on;
select flashback_on from v$database;

FLASHBACK_ON
------------------
YES
exit

Sur la base de données standby, exécutez une séquence de commandes semblable à celle ci-dessous :

. oraenv
WHITE

mkdir /u01/app/oracle/oradata/WHITE/recoveryarea

dgmgrl sys@white

show database white

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE

Database Status:
SUCCESS

edit database white set STATE='APPLY-OFF';
exit;

sqlplus / as sysdba

show parameter recovery

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest       string
db_recovery_file_dest_size      big integer 0
recovery_parallelism       integer  0
alter system set db_recovery_file_dest_size=2G;
alter system set db_recovery_file_dest='/u01/app/oracle/oradata/WHITE/recoveryarea';
alter system set db_flashback_retention_target=3600;
alter database flahback on;
select flashback_on from v$database;

FLASHBACK_ON
------------------
YES
exit

dgmgrl sys@white

show database white

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-OFF
  Transport Lag:   0 seconds
  Apply Lag:       1 minute 19 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE

Database Status:
SUCCESS

edit database white set STATE='APPLY-ON';
exit;
  • Créer et exécutez un script pour démarrer l’Observer

L’Observer est démarré depuis la commande DGMGRL mais de passe pas en arrière plan. Il faut donc créer un script que vous exécuterez avec nohup et qu’il faudra superviser pour démarrer un observer dans des conditions réelles d’utilisation ; voici l’exemple d’un tel script :

cat startObs.sh 
dgmgrl >>EOF
connect sys/manager1@black
start observer;
EOF

Utilisez ensuite la commande nohup pour exécuter votre script :

chmod +x startObs.sh 
nohup ./startObs.sh 2>&1 &

tail -f nohup.out
DGMGRL for Linux: Version 11.2.0.2.0 - Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> Connected.
DGMGRL> Observer started

Activer Fast Start Failover

Il convient ensuite d’activer fast start failover; pour cela, il suffit de passer une des commandes suivantes :

dgmgrl
connect sys@black
enable fast_start failover;
show fast_start failover;
Fast-Start Failover: ENABLED

  Threshold:        30 seconds
  Target:           white
  Observer:         red
  Lag Limit:        30 seconds (not in use)
  Shutdown Primary: TRUE
  Auto-reinstate:   TRUE

Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile            NO
    Stuck Archiver                  NO
    Datafile Offline               YES

  Oracle Error Conditions:
    (none)

show data
base black FastStartFailoverTarget;
  FastStartFailoverTarget = 'white'
show database white FastStartFailoverTarget;
  FastStartFailoverTarget = 'black'

Notez bien la valeur par défaut de auto-reinstate que nous allons illustrer.

La bascule

Pour tester la bascule, il suffit de se connecter à la base de données primaire et de l’arrêter, par exemple avec la commande kill -9 comme ci-dessous :

ps -ef |grep smon
oracle   13402     1  0 00:28 ?        00:00:01 ora_smon_BLACK
oracle   16841  7268  0 10:14 pts/0    00:00:00 grep smon
kill -9 13402

Après environ 30 secondes, si vous regardez le contenu de l’alert.log de la base standby, vous constaterez qu’elle passe base de données primaire. Voici l’extrait sur mon serveur :

 started logmerger process
Mon Oct 25 10:02:54 2010
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 26 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 26 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_5_6d9dmkd0_.log
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Mon Oct 25 10:14:57 2010
RFS[6]: Possible network disconnect with primary database
Mon Oct 25 10:14:57 2010
RFS[1]: Possible network disconnect with primary database
Mon Oct 25 10:14:57 2010
RFS[7]: Assigned to RFS process 13825
RFS[7]: Possible network disconnect with primary database
Mon Oct 25 10:14:57 2010
RFS[8]: Assigned to RFS process 13814
RFS[8]: Possible network disconnect with primary database
Mon Oct 25 10:15:27 2010
Attempting Fast-Start Failover because the threshold of 30 seconds has elapsed.
Mon Oct 25 10:15:28 2010
Data Guard Broker: Beginning failover
Mon Oct 25 10:15:28 2010
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Mon Oct 25 10:15:28 2010
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/white/WHITE/trace/WHITE_pr00_16725.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 981416
Mon Oct 25 10:15:28 2010
MRP0: Background Media Recovery process shutdown (WHITE)
Managed Standby Recovery Canceled (WHITE)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
Attempt to do a Terminal Recovery (WHITE)
Media Recovery Start: Managed Standby Recovery (WHITE)
 started logmerger process
Mon Oct 25 10:15:29 2010
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '10/25/2010 10:15:29'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 26 redo required
Terminal Recovery: 
Recovery of Online Redo Log: Thread 1 Group 5 Seq 26 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_5_6d9dmkd0_.log
Identified End-Of-Redo (failover) for thread 1 sequence 26 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 981417 time 10/25/2010 10:14:54
Media Recovery Complete (WHITE)
Terminal Recovery: successful completion
Mon Oct 25 10:15:29 2010
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance WHITE - Archival Error
ORA-16014: log 5 sequence# 26 not archived, no available destinations
ORA-00312: online log 5 thread 1: '/u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_5_6d9dmkd0_.log'
Forcing ARSCN to IRSCN for TR 0:981417
Attempt to set limbo arscn 0:981417 irscn 0:981417 
Resetting standby activation ID 417444333 (0x18e1b1ed)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN
ALTER DATABASE SWITCHOVER TO PRIMARY (WHITE)
Maximum wait for role transition is 15 minutes.
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/white/WHITE/trace/WHITE_rsm0_13672.trc
Standby terminal recovery start SCN: 981416
RESETLOGS after incomplete recovery UNTIL CHANGE 981417
Online log /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_1_6d9dd4bs_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_2_6d9dd5cl_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_3_6d9dd66l_.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 981415
Mon Oct 25 10:15:29 2010
Setting recovery target incarnation to 3
WARNING: STANDBY_FILE_MANAGEMENT initialization parameter is
not set to the value "AUTO".
This may cause recovery of the standby database to terminate
prior to applying all available redo data.
It may be necessary to use the ALTER DATABASE CREATE DATAFILE
command to add datafiles created on the primary database.
Switchover: Complete - Database mounted as primary
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY
Completed: ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY
ALTER DATABASE OPEN
Data Guard Broker initializing...
Mon Oct 25 10:15:29 2010
Assigning activation ID 417415009 (0x18e13f61)
LGWR: Primary database is in MAXIMUM AVAILABILITY mode
LGWR: Destination LOG_ARCHIVE_DEST_2 is using asynchronous network I/O
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
Thread 1 advanced to log sequence 2 (thread open)
Mon Oct 25 10:15:29 2010
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC0: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch
Thread 1 opened at log sequence 2
  Current log# 2 seq# 2 mem# 0: /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_2_6d9dd5cl_.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Oct 25 10:15:30 2010
SMON: enabling cache recovery
Mon Oct 25 10:15:30 2010
NSA2 started with pid=20, OS id=16921 
Mon Oct 25 10:15:30 2010
Error 1034 received logging on to the standby
PING[ARC2]: Heartbeat failed to connect to standby 'black'. Error is 1034.
Error 1034 received logging on to the standby
ARC0: Error 1034 Creating archive log file to 'black'
Archived Log entry 23 added for thread 1 sequence 1 ID 0x18e13f61 dest 1:
Archiver process freed from errors. No longer stopped
[13672] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:62640516 end:62640796 diff:280 (2 seconds)
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
**********************************************************
WARNING: Files may exists in db_recovery_file_dest
that are not known to the database. Use the RMAN command
CATALOG RECOVERY AREA to re-catalog any such files.
If files cannot be cataloged, then manually delete them
using OS command.
One of the following events caused this:
1. A backup controlfile was restored.
2. A standby controlfile was restored.
3. The controlfile was re-created.
4. db_recovery_file_dest had previously been enabled and
   then disabled.
**********************************************************
replication_dependency_tracking turned off (no async multimaster replication found)
Thread 1 advanced to log sequence 3 (LGWR switch)
  Current log# 3 seq# 3 mem# 0: /u01/app/oracle/oradata/WHITE/onlinelog/o1_mf_3_6d9dd66l_.log
Mon Oct 25 10:15:33 2010
Archived Log entry 24 added for thread 1 sequence 2 ID 0x18e13f61 dest 1:
Starting background process QMNC
Mon Oct 25 10:15:33 2010
QMNC started with pid=21, OS id=16935 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: ALTER DATABASE OPEN
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='WHITE';
ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='WHITE';
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_file_name_convert='BLACK','WHITE' SCOPE=SPFILE;
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/WHITE
ALTER SYSTEM SET log_archive_dest_state_2='RESET' SCOPE=BOTH;
Failover succeeded. Primary database is now WHITE.
ARC2: STARTING ARCH PROCESSES
Mon Oct 25 10:15:37 2010
Starting background process CJQ0
Mon Oct 25 10:15:37 2010
CJQ0 started with pid=34, OS id=16949 
Mon Oct 25 10:15:37 2010
ARC4 started with pid=35, OS id=16951 
ARC4: Archival started
ARC2: STARTING ARCH PROCESSES COMPLETE
krsk_srl_archive_int: Enabling archival of deferred physical standby SRLs
Archived Log entry 25 added for thread 1 sequence 26 ID 0x18e1b1ed dest 1:
Mon Oct 25 10:15:42 2010
FSFP started with pid=36, OS id=16968 
Shutting down archive processes
ARCH shutting down
ARC4: Archival stopped

Si vous regardez la sortie de l’observer, vous découvrirez que celui-ci a été déclencheur de l’action de bascule :

cat nohup.out
[...]
10:15:28.04  Monday, October 25, 2010
Initiating Fast-Start Failover to database "white"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "white"
10:15:36.66  Monday, October 25, 2010

Si vous redémarrer ensuite la base de données primaire en mode mount, vous verrez que celle-ci est effectivement re-instancié comme prévu par le paramétrage fast-start failover :

. oraenv
BLACK

sqlplus / as sysdba

alter database mount;

exit

Le fichier alert.log montre que la base est reconfigurée en standby après cette opération :

Lost write protection disabled
Completed: alter database mount
Mon Oct 25 10:22:13 2010
Starting Data Guard Broker (DMON)
Mon Oct 25 10:22:13 2010
INSV started with pid=24, OS id=17252 
Mon Oct 25 10:22:16 2010
NSV1 started with pid=25, OS id=17254 
Mon Oct 25 10:22:25 2010
NSV1 started with pid=25, OS id=17267 
Mon Oct 25 10:22:28 2010
RSM0 started with pid=21, OS id=17274 
FLASHBACK DATABASE TO SCN 981415
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 2 slaves
Mon Oct 25 10:22:33 2010
Recovery of Online Redo Log: Thread 1 Group 2 Seq 25 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_2_6d99mcgo_.log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 26 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_3_6d99mdbr_.log
Mon Oct 25 10:22:34 2010
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/BLACK
RFS[1]: Assigned to RFS process 17286
RFS[1]: Database mount ID mismatch [0x18e13f61:0x18e3290d] (417415009:417540365)
RFS[1]: Not using real application clusters
Incomplete Recovery applied until change 981416 time 10/25/2010 10:14:54
Flashback Media Recovery Complete
Completed: FLASHBACK DATABASE TO SCN 981415
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (BLACK)
Flush standby redo logfile failed:1649
Clearing standby activation ID 417444333 (0x18e1b1ed)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_1_6d99mbbs_.log
Clearing online log 1 of thread 1 sequence number 24
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_2_6d99mcgo_.log
Clearing online log 2 of thread 1 sequence number 25
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_3_6d99mdbr_.log
Clearing online log 3 of thread 1 sequence number 26
Clearing online redo logfile 3 complete
Completed: alter database convert to physical standby
Mon Oct 25 10:22:38 2010
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
License high water mark = 6
All dispatchers and shared servers shutdown
alter database CLOSE NORMAL
ORA-1109 signalled during: alter database CLOSE NORMAL...
alter database DISMOUNT
Completed: alter database DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Shutting down Data Guard Broker processes
Mon Oct 25 10:22:45 2010
Completed: Data Guard Broker shutdown
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabledMon Oct 25 10:22:47 2010

Stopping background process VKTM
Mon Oct 25 10:22:49 2010
Instance shutdown complete
Mon Oct 25 10:22:50 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfileBLACK.ora
System parameters with non-default values:
  processes                = 150
  sga_target               = 1200M
  control_files            = "/u01/app/oracle/oradata/BLACK/controlfile/o1_mf_6d99m7vk_.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "location=/u01/app/oracle/oradata/BLACK"
  log_archive_dest_2       = "service="white""
  log_archive_dest_2       = "LGWR SYNC AFFIRM delay=0 optional compression=enable max_failure=0 max_connections=1 reopen=300 db_unique_name="white" net_timeout=30"
  log_archive_dest_2       = "valid_for=(all_logfiles,primary_role)"
  log_archive_dest_state_2 = "ENABLE"
  log_archive_min_succeed_dest= 1
  fal
_server               = "white"
  log_archive_trace        = 0
  log_archive_config       = "dg_config=(BLACK,white)"
  log_archive_format       = "%t_%s_%r.dbf"
  log_archive_max_processes= 4
  archive_lag_target       = 0
  db_create_file_dest      = "/u01/app/oracle/oradata"
  db_recovery_file_dest    = "/u01/app/oracle/oradata/BLACK/recoveryarea"
  db_recovery_file_dest_size= 2G
  standby_file_management  = "MANUAL"
  db_flashback_retention_target= 3600
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=BLACKXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/BLACK/adump"
  audit_trail              = "DB"
  db_name                  = "BLACK"
  open_cursors             = 300
  pga_aggregate_target     = 398M
  dg_broker_start          = TRUE
  diagnostic_dest          = "/u01/app/oracle"
Mon Oct 25 10:22:50 2010
PMON started with pid=2, OS id=17296 
Mon Oct 25 10:22:50 2010
PSP0 started with pid=3, OS id=17298 
Mon Oct 25 10:22:51 2010
VKTM started with pid=4, OS id=17302 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Mon Oct 25 10:22:51 2010
GEN0 started with pid=5, OS id=17306 
Mon Oct 25 10:22:51 2010
DIAG started with pid=6, OS id=17308 
Mon Oct 25 10:22:51 2010
DBRM started with pid=7, OS id=17310 
Mon Oct 25 10:22:51 2010
DIA0 started with pid=8, OS id=17312 
Mon Oct 25 10:22:51 2010
MMAN started with pid=9, OS id=17314 
Mon Oct 25 10:22:51 2010
DBW0 started with pid=10, OS id=17316 
Mon Oct 25 10:22:51 2010
LGWR started with pid=11, OS id=17318 
Mon Oct 25 10:22:51 2010
CKPT started with pid=12, OS id=17320 
Mon Oct 25 10:22:51 2010
SMON started with pid=13, OS id=17322 
Mon Oct 25 10:22:51 2010
RECO started with pid=14, OS id=17324 
Mon Oct 25 10:22:51 2010
MMON started with pid=15, OS id=17326 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Mon Oct 25 10:22:51 2010
MMNL started with pid=16, OS id=17328 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Mon Oct 25 10:22:51 2010
DMON started with pid=19, OS id=17336 
Mon Oct 25 10:22:51 2010
alter database  mount
ARCH: STARTING ARCH PROCESSES
Mon Oct 25 10:22:55 2010
NSS2 started with pid=21, OS id=17342 
Mon Oct 25 10:22:55 2010
ARC0 started with pid=22, OS id=17344 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Successful mount of redo thread 1, with mount id 417534267
Allocated 4850252 bytes in shared pool for flashback generation buffer
Mon Oct 25 10:22:56 2010
ARC1 started with pid=23, OS id=17346 
Starting background process RVWR
Mon Oct 25 10:22:56 2010
RVWR started with pid=24, OS id=17348 
Physical Standby Database mounted.
Lost write protection disabled
Mon Oct 25 10:22:56 2010
ARC2 started with pid=25, OS id=17350 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
Mon Oct 25 10:22:56 2010
ARC3 started with pid=26, OS id=17352 
Completed: alter database  mount
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Starting Data Guard Broker (DMON)
Mon Oct 25 10:22:59 2010
INSV started with pid=27, OS id=17362 
Mon Oct 25 10:23:05 2010
NSV1 started with pid=28, OS id=17366 
Mon Oct 25 10:23:08 2010
RSM0 started with pid=29, OS id=17372 
Mon Oct 25 10:23:11 2010
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/BLACK
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
RFS[1]: Assigned to RFS process 17374
RFS[1]: Selected log 4 for thread 1 sequence 5 dbid 417469255 branch 733313729
Mon Oct 25 10:23:11 2010
RFS[2]: Assigned to RFS process 17376
RFS[2]: Selected log 5 for thread 1 sequence 4 dbid 417469255 branch 733313729
RFS[2]: New Archival REDO Branch(resetlogs_id): 733313729  Prior: 733275274
RFS[2]: Archival Activation ID: 0x18e13f61 Current: 0x0
RFS[2]: Effect of primary database OPEN RESETLOGS
RFS[2]: Incarnation entry added for Branch(resetlogs_id): 733313729 (BLACK)
Mon Oct 25 10:23:11 2010
Setting recovery target incarnation to 3
Mon Oct 25 10:23:11 2010
Archived Log entry 33 added for thread 1 sequence 4 ID 0x18e13f61 dest 1:
RFS[2]: Opened log for thread 1 sequence 26 dbid 417469255 branch 733275274
Archived Log entry 34 added for thread 1 sequence 26 rlc 733275274 ID 0x18e1b1ed dest 2:
Mon Oct 25 10:23:12 2010
RFS[3]: Assigned to RFS process 17378
RFS[3]: Opened log for thread 1 sequence 2 dbid 417469255 branch 733313729
RFS[2]: Opened log for thread 1 sequence 3 dbid 417469255 branch 733313729
Mon Oct 25 10:23:12 2010
RFS[4]: Assigned to RFS process 17380
RFS[4]: Opened log for thread 1 sequence 1 dbid 417469255 branch 733313729
Archived Log entry 35 added for thread 1 sequence 3 rlc 733313729 ID 0x18e13f61 dest 2:
Archived Log entry 36 added for thread 1 sequence 2 rlc 733313729 ID 0x18e13f61 dest 2:
Archived Log entry 37 added for thread 1 sequence 1 rlc 733313729 ID 0x18e13f61 dest 2:
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='BLACK';
ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='BLACK';
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET fal_server='white' SCOPE=BOTH;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (BLACK)
Mon Oct 25 10:23:13 2010
MRP0 started with pid=34, OS id=17382 
MRP0: Background Managed Standby Recovery process started (BLACK)
Changing standby controlfile to MAXIMUM AVAILABILITY level
RFS[1]: Selected log 5 for thread 1 sequence 6 dbid 417469255 branch 733313729
Mon Oct 25 10:23:17 2010
Archived Log entry 38 added for thread 1 sequence 5 ID 0x18e13f61 dest 1:
 started logmerger process
Mon Oct 25 10:23:18 2010
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Media Recovery start incarnation depth : 1, target inc# : 3, irscn : 981417
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_26_733275274.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 26 at SCN 0x0.ef9a9
Resetting standby activation ID 417444333 (0x18e1b1ed)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_1_733313729.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_2_733313729.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_3_733313729.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_4_733313729.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_5_733313729.dbf
Mon Oct 25 10:23:19 2010
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Media Recovery Waiting for thread 1 sequence 6 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 6 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_5
_6d9dl9h8_.log
Archived Log entry 39 added for thread 1 sequence 6 ID 0x18e13f61 dest 1:
Media Recovery Waiting for thread 1 sequence 7
Mon Oct 25 10:23:22 2010
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[5]: Assigned to RFS process 17392
RFS[5]: Selected log 4 for thread 1 sequence 7 dbid 417469255 branch 733313729
Recovery of Online Redo Log: Thread 1 Group 4 Seq 7 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_4_6d9dkyo5_.log

Dans ce cas également, vous pourrez constater dans le log de l’Observer que c’est celui-ci qui a reconfiguré l’ancienne instance primaire en standby :

10:22:24.31  Monday, October 25, 2010
Initiating reinstatement for database "black"...
Reinstating database "black", please wait...
Operation requires shutdown of instance "BLACK" on database "black"
Shutting down instance "BLACK"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "BLACK" on database "black"
Starting instance "BLACK"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "black" ...
Reinstatement of database "black" succeeded
10:23:23.97  Monday, October 25, 2010

Il ne vous restera plus, au moment qui vous semble le plus opportun, qu’à rebasculer les roles des bases de données primaires et standby :

dgmgrl

connect sys@black

show configuration

Configuration - worldwide

  Protection Mode: MaxAvailability
  Databases:
    white - Primary database
    black - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:
SUCCESS

switchover to black;
Performing switchover NOW, please wait...
New primary database "black" is opening...
Operation requires shutdown of instance "WHITE" on database "white"
Shutting down instance "WHITE"...
ORACLE instance shut down.
Operation requires startup of instance "WHITE" on database "white"
Starting instance "WHITE"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "black"show configuration;

Configuration - worldwide

  Protection Mode: MaxAvailability
  Databases:
    black - Primary database
    white - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:
SUCCESS


exit

Shutdown immediate vs Shutdown abort

Une question important est « Que ce passe-t-il si vous arrêtez l’instance manuellement ? ». La réponse n’est pas forcément celle à laquelle on pourrait s’attendre (vous attendiez-vous à quelque chose ?) :

  • Si vous arrêtez l’instance avec un shutdown immediate

La configuration ne bascule pas :

. oraenv
BLACK

sqlplus / as sysdba

shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

dgmgrl sys@white

show configuration;

Configuration - worldwide

  Protection Mode: MaxAvailability
  Databases:
    black - Primary database
    white - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:
ORA-01034: ORACLE not available
ORA-16625: cannot reach database "black"
DGM-17017: unable to determine configuration status

Vous pouvez attendre ; l’observer ne basculera pas la configuration.

  • Si vous arrêtez l’instance avec un shutdown abort

La configuration bascule dans ce cas

. oraenv
BLACK

sqlplus / as sysdba

shutdown abort;
ORACLE instance shut down.

dgmgrl sys@white

show configuration;

Configuration - worldwide

  Protection Mode: MaxAvailability
  Databases:
    white - Primary database
      Warning: ORA-16817: unsynchronized fast-start failover configuration

    black - (*) Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover: ENABLED

Configuration Status:
WARNING

Le log de l’observer montre bien cette bascule :

12:07:55.36  Monday, October 25, 2010
Initiating Fast-Start Failover to database "white"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "white"
12:07:57.81  Monday, October 25, 2010

Redémarrage « Startup Open »

Quand vous manipulez des configurations avec un broker Data Guard, mieux vaut démarrer vos instances avec startup mount et laisser la base s’ouvrir dans le bon mode, cela étant, une question décente est « Que se passe-il lorsqu’on redémarre la base en mode open après une bascule ? ». La réponse est plutôt satisfaisante ; le démarrage échoue :

SQL> startup 
ORACLE instance started.

Total System Global Area 1255473152 bytes
Fixed Size      1343888 bytes
Variable Size    335548016 bytes
Database Buffers   905969664 bytes
Redo Buffers     12611584 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from being opened

et la base de données est réinstanciée par l’observer comme le montre le log :

12:21:45.27  Monday, October 25, 2010
Initiating reinstatement for database "black"...
Reinstating database "black", please wait...
Operation requires shutdown of instance "BLACK" on database "black"
Shutting down instance "BLACK"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "BLACK" on database "black"
Starting instance "BLACK"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "black" ...
Reinstatement of database "black" succeeded
12:22:43.61  Monday, October 25, 2010

Si vous voulez plus de détails, l’alert.log montre ce qui suit :

Mon Oct 25 12:21:22 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfileBLACK.ora
System parameters with non-default values:
  processes                = 150
  sga_target               = 1200M
  control_files            = "/u01/app/oracle/oradata/BLACK/controlfile/o1_mf_6d99m7vk_.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "location=/u01/app/oracle/oradata/BLACK"
  log_archive_dest_2       = "service="white""
  log_archive_dest_2       = "LGWR SYNC AFFIRM delay=0 optional compression=enable max_failure=0 max_connections=1 reopen=300 db_unique_name="white" net_timeout=30"
  log_archive_dest_2       = "valid_for=(all_logfiles,primary_role)"
  log_archive_dest_state_2 = "ENABLE"
  log_archive_min_succeed_dest= 1
  fal_server               = "white"
  log_archive_trace        = 0
  log_archive_config       = "dg_config=(BLACK,white)"
  log_archive_format       = "%t_%s_%r.dbf"
  log_archive_max_processes= 4
  archive_lag_target       = 0
  db_create_file_dest      = "/u01/app/oracle/oradata"
  db_recovery_
file_dest    = "/u01/app/oracle/oradata/BLACK/recoveryarea"
  db_recovery_file_dest_size= 2G
  standby_file_management  = "MANUAL"
  db_flashback_retention_target= 3600
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=BLACKXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/BLACK/adump"
  audit_trail              = "DB"
  db_name                  = "BLACK"
  open_cursors             = 300
  pga_aggregate_target     = 398M
  dg_broker_start          = TRUE
  diagnostic_dest          = "/u01/app/oracle"
Mon Oct 25 12:21:22 2010
PMON started with pid=2, OS id=21794 
Mon Oct 25 12:21:22 2010
PSP0 started with pid=3, OS id=21796 
Mon Oct 25 12:21:23 2010
VKTM started with pid=4, OS id=21798 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Mon Oct 25 12:21:23 2010
GEN0 started with pid=5, OS id=21803 
Mon Oct 25 12:21:23 2010
DIAG started with pid=7, OS id=21806 
Mon Oct 25 12:21:23 2010
DBRM started with pid=8, OS id=21808 
Mon Oct 25 12:21:23 2010
DIA0 started with pid=9, OS id=21810 
Mon Oct 25 12:21:23 2010
MMAN started with pid=10, OS id=21812 
Mon Oct 25 12:21:23 2010
DBW0 started with pid=11, OS id=21814 
Mon Oct 25 12:21:23 2010
LGWR started with pid=12, OS id=21816 
Mon Oct 25 12:21:23 2010
CKPT started with pid=13, OS id=21818 
Mon Oct 25 12:21:23 2010
SMON started with pid=14, OS id=21820 
Mon Oct 25 12:21:23 2010
RECO started with pid=15, OS id=21822 
Mon Oct 25 12:21:23 2010
MMON started with pid=16, OS id=21824 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Mon Oct 25 12:21:23 2010
MMNL started with pid=17, OS id=21826 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Mon Oct 25 12:21:23 2010
DMON started with pid=20, OS id=21833 
Mon Oct 25 12:21:23 2010
ALTER DATABASE   MOUNT
Mon Oct 25 12:21:27 2010
NSS2 started with pid=22, OS id=21839 
Successful mount of redo thread 1, with mount id 417492739
Allocated 4847104 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Mon Oct 25 12:21:27 2010
RVWR started with pid=23, OS id=21841 
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Mon Oct 25 12:21:27 2010
ALTER DATABASE OPEN
Data Guard Broker initializing...
Data Guard Broker initialization complete
Data Guard: verifying database primary role...
Starting Data Guard Broker (DMON)
Mon Oct 25 12:21:31 2010
INSV started with pid=24, OS id=21844 
Mon Oct 25 12:21:35 2010
NSV1 started with pid=25, OS id=21846 
Mon Oct 25 12:21:39 2010
Data Guard: version check completed
Data Guard determines a failover has occurred - this is no longer a primary database
ORA-16649 signalled during: ALTER DATABASE OPEN...
Mon Oct 25 12:21:45 2010
NSV1 started with pid=25, OS id=21858 
Mon Oct 25 12:21:49 2010
RSM0 started with pid=26, OS id=21864 
Mon Oct 25 12:21:52 2010
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/BLACK
RFS[1]: Assigned to RFS process 21866
RFS[1]: Database mount ID mismatch [0x18e2cfb5:0x18e26f03] (417517493:417492739)
RFS[1]: Not using real application clusters
FLASHBACK DATABASE TO SCN 1068923
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 2 slaves
Flashback Media Recovery Log /u01/app/oracle/oradata/BLACK/1_22_733315278.dbf
Flashback Media Recovery Log /u01/app/oracle/oradata/BLACK/1_23_733315278.dbf
Flashback Media Recovery Log /u01/app/oracle/oradata/BLACK/1_24_733315278.dbf
Flashback Media Recovery Log /u01/app/oracle/oradata/BLACK/1_25_733315278.dbf
Flashback Media Recovery Log /u01/app/oracle/oradata/BLACK/1_26_733315278.dbf
Mon Oct 25 12:21:55 2010
Recovery of Online Redo Log: Thread 1 Group 2 Seq 27 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_2_6d99mcgo_.log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 28 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_3_6d99mdbr_.log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 29 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_1_6d99mbbs_.log
Incomplete Recovery applied until change 1068924 time 10/25/2010 12:07:23
Flashback Media Recovery Complete
Completed: FLASHBACK DATABASE TO SCN 1068923
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (BLACK)
Flush standby redo logfile failed:1649
Clearing standby activation ID 417532016 (0x18e30870)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_1_6d99mbbs_.log
Clearing online log 1 of thread 1 sequence number 29
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_2_6d99mcgo_.log
Clearing online log 2 of thread 1 sequence number 27
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_3_6d99mdbr_.log
Clearing online log 3 of thread 1 sequence number 28
Clearing online redo logfile 3 complete
Completed: alter database convert to physical standby
Mon Oct 25 12:21:59 2010
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
License high water mark = 5
All dispatchers and shared servers shutdown
alter database CLOSE NORMAL
ORA-1109 signalled during: alter database CLOSE NORMAL...
alter database DISMOUNT
Completed: alter database DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Shutting down Data Guard Broker processes
Mon Oct 25 12:22:05 2010
Completed: Data Guard Broker shutdown
ARCH: Archival disabled due to shutdown: 1089Mon Oct 25 12:22:07 2010
Stopping background process VKTM

Shutting down archive processes
Archiving is disabled
Mon Oct 25 12:22:09 2010
Instance shutdown complete
Mon Oct 25 12:22:09 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfileBLACK.ora
System parameters with non-default values:
  processes                = 150
  sga_target               = 1200M
  control_files            = "/u01/app/oracle/oradata/BLACK/controlfile/o1_mf_6d99m7vk_.ctl"
  db_block
_size            = 8192
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "location=/u01/app/oracle/oradata/BLACK"
  log_archive_dest_2       = "service="white""
  log_archive_dest_2       = "LGWR SYNC AFFIRM delay=0 optional compression=enable max_failure=0 max_connections=1 reopen=300 db_unique_name="white" net_timeout=30"
  log_archive_dest_2       = "valid_for=(all_logfiles,primary_role)"
  log_archive_dest_state_2 = "ENABLE"
  log_archive_min_succeed_dest= 1
  fal_server               = "white"
  log_archive_trace        = 0
  log_archive_config       = "dg_config=(BLACK,white)"
  log_archive_format       = "%t_%s_%r.dbf"
  log_archive_max_processes= 4
  archive_lag_target       = 0
  db_create_file_dest      = "/u01/app/oracle/oradata"
  db_recovery_file_dest    = "/u01/app/oracle/oradata/BLACK/recoveryarea"
  db_recovery_file_dest_size= 2G
  standby_file_management  = "MANUAL"
  db_flashback_retention_target= 3600
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=BLACKXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/BLACK/adump"
  audit_trail              = "DB"
  db_name                  = "BLACK"
  open_cursors             = 300
  pga_aggregate_target     = 398M
  dg_broker_start          = TRUE
  diagnostic_dest          = "/u01/app/oracle"
Mon Oct 25 12:22:10 2010
PMON started with pid=2, OS id=21883 
Mon Oct 25 12:22:10 2010
PSP0 started with pid=3, OS id=21885 
Mon Oct 25 12:22:11 2010
VKTM started with pid=4, OS id=21887 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Mon Oct 25 12:22:11 2010
GEN0 started with pid=5, OS id=21891 
Mon Oct 25 12:22:11 2010
DIAG started with pid=6, OS id=21893 
Mon Oct 25 12:22:11 2010
DBRM started with pid=7, OS id=21895 
Mon Oct 25 12:22:11 2010
DIA0 started with pid=8, OS id=21897 
Mon Oct 25 12:22:11 2010
MMAN started with pid=9, OS id=21899 
Mon Oct 25 12:22:11 2010
DBW0 started with pid=10, OS id=21901 
Mon Oct 25 12:22:11 2010
LGWR started with pid=11, OS id=21903 
Mon Oct 25 12:22:11 2010
CKPT started with pid=12, OS id=21905 
Mon Oct 25 12:22:11 2010
SMON started with pid=13, OS id=21907 
Mon Oct 25 12:22:11 2010
RECO started with pid=14, OS id=21909 
Mon Oct 25 12:22:11 2010
MMON started with pid=15, OS id=21911 
Mon Oct 25 12:22:11 2010
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=16, OS id=21913 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Mon Oct 25 12:22:11 2010
DMON started with pid=19, OS id=21920 
Mon Oct 25 12:22:11 2010
alter database  mount
ARCH: STARTING ARCH PROCESSES
Mon Oct 25 12:22:15 2010
NSS2 started with pid=21, OS id=21927 
Mon Oct 25 12:22:15 2010
ARC0 started with pid=22, OS id=21929 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Successful mount of redo thread 1, with mount id 417481011
Allocated 4850252 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Mon Oct 25 12:22:16 2010
ARC1 started with pid=23, OS id=21931 
Mon Oct 25 12:22:16 2010
RVWR started with pid=24, OS id=21933 
Physical Standby Database mounted.
Lost write protection disabled
Mon Oct 25 12:22:16 2010
ARC2 started with pid=25, OS id=21935 
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC1: Becoming the heartbeat ARCH
ARC1: Becoming the active heartbeat ARCH
Mon Oct 25 12:22:16 2010
ARC3 started with pid=26, OS id=21937 
Completed: alter database  mount
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Starting Data Guard Broker (DMON)
Mon Oct 25 12:22:19 2010
INSV started with pid=27, OS id=21947 
Mon Oct 25 12:22:24 2010
NSV1 started with pid=28, OS id=21951 
Mon Oct 25 12:22:28 2010
RSM0 started with pid=29, OS id=21957 
Mon Oct 25 12:22:29 2010
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/BLACK
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
RFS[1]: Assigned to RFS process 21959
RFS[1]: Selected log 4 for thread 1 sequence 4 dbid 417469255 branch 733320476
Mon Oct 25 12:22:29 2010
RFS[2]: Assigned to RFS process 21961
RFS[2]: Selected log 5 for thread 1 sequence 3 dbid 417469255 branch 733320476
RFS[2]: New Archival REDO Branch(resetlogs_id): 733320476  Prior: 733315278
RFS[2]: Archival Activation ID: 0x18e2cfb5 Current: 0x0
RFS[2]: Effect of primary database OPEN RESETLOGS
RFS[2]: Incarnation entry added for Branch(resetlogs_id): 733320476 (BLACK)
Mon Oct 25 12:22:29 2010
Setting recovery target incarnation to 5
Mon Oct 25 12:22:29 2010
Archived Log entry 111 added for thread 1 sequence 3 ID 0x18e2cfb5 dest 1:
Mon Oct 25 12:22:29 2010
RFS[3]: Assigned to RFS process 21965
RFS[3]: Opened log for thread 1 sequence 29 dbid 417469255 branch 733315278
Archived Log entry 112 added for thread 1 sequence 29 rlc 733315278 ID 0x18e30870 dest 2:
RFS[2]: Opened log for thread 1 sequence 1 dbid 417469255 branch 733320476
Mon Oct 25 12:22:29 2010
RFS[4]: Assigned to RFS process 21963
RFS[4]: Opened log for thread 1 sequence 2 dbid 417469255 branch 733320476
Archived Log entry 113 added for thread 1 sequence 1 rlc 733320476 ID 0x18e2cfb5 dest 2:
Archived Log entry 114 added for thread 1 sequence 2 rlc 733320476 ID 0x18e2cfb5 dest 2:
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='BLACK';
ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='BLACK';
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET fal_server='white' SCOPE=BOTH;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (BLACK)
Mon Oct 25 12:22:34 2010
MRP0 started with pid=35, OS id=21969 
MRP0: Background Managed Standby Recovery process started (BLACK)
Changing standby controlfile to MAXIMUM AVAILABILITY level
RFS[1]: Selected log 5 for thread 1 sequence 5 dbid 417469255 branch 733320476
Mon Oct 25 12:22:35 2010
Archived Log entry 115 added for thread 1 sequence 4 ID 0x18e2cfb5 dest 1:
 started logmerger process
Mon Oct 25 12:22:39 2010
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Media Recovery start incarnation depth : 1, target inc# : 5, irscn : 1068925
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_29_733315278.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 29 at SCN 0x0.104f7d
Resetting standby activation ID 417532016 (0x18e30870)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_1_733320476.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_2_733320476.dbf
Mon Oct 25 12:22:40 2010
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Media Recovery Log /u01/app/oracle/oradat
a/BLACK/1_3_733320476.dbf
Media Recovery Log /u01/app/oracle/oradata/BLACK/1_4_733320476.dbf
Media Recovery Waiting for thread 1 sequence 5 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 5 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_5_6d9dl9h8_.log
Mon Oct 25 12:22:41 2010
Archived Log entry 116 added for thread 1 sequence 5 ID 0x18e2cfb5 dest 1:
Media Recovery Waiting for thread 1 sequence 6
Mon Oct 25 12:22:42 2010
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[5]: Assigned to RFS process 21977
RFS[5]: Selected log 4 for thread 1 sequence 6 dbid 417469255 branch 733320476
Recovery of Online Redo Log: Thread 1 Group 4 Seq 6 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/BLACK/onlinelog/o1_mf_4_6d9dkyo5_.log

Evidemment si vous arrêtez dans l’intervalle, la nouvelle primaire et l’observer avant de redémarrer l’ancienne primaire, celle-ci s’ouvre et n’est pas ré-instanciée… Cela dit, il faut bien réfléchir à un moment ou à un autre à ce qu’on fait, non ?

Image de Thomas Bordet
Thomas Bordet
Voir tous ses articles
Articles récents

Mentions légales & Politique de confidentialité