Data Guard Cheatsheet

Currently being updated, this statement will be removed when I have completed this section

Terminology

Primary database A production database

A database that can become the primary database, should the primary
Standby database
fail
EOR End Of Redo
LWGR Log Writer process
LNS Log Network Server
ORL Online Redo Log
RFS Remote File Server
SRL Standby Redo Log file
SYNC and ASYNC Synchronous and Asynchronous

Log Files

DG alert Log drc<db_unique_name>.log

Alert Log alert_<SID>.log
# change the instance name to reflect the one you have choosen and the path you installed
oracle

prod1 (alert log): /u01/app/oracle/diag/rdbms/prod1/PROD1/trace/alert_PROD1.log

Logfile locations prod1 (DG log): /u01/app/oracle/diag/rdbms/prod1/PROD1/trace/[Link]

prod1dr (alert log): /u01/app/oracle/diag/rdbms/prod1dr/PROD1DR/trace/alert_PROD1DR.log

prod1dr (DG log): /u01/app/oracle/diag/rdbms/prod1dr/PROD1DR/trace/[Link]
## You can get the log locations from the below view

identify log files col name for a25

col value for a65;
select name, value from v$diag_info;

Data Guard Broker

# Primary Database server

DGMGRL> create configuration prod1 as

Create base > primary database is prod1
configuration > connect identifier is prod1;

Configuration "prod1" created with primary database "prod1"

# Primary Database server - if you have setup db_unique_name, tnsname and
log_archive_dest_n

DGMGRL> add database prod1dr;

# Primary Database server - the full command set

Add the standby
database DGMGRL> connect sys/password
DGMGRL> add database prod1dr
> as connect identifier is prod1dr
> maintained as physical;

Database "prod1dr" added

Display DGMGRL> show configuration
configuration
Display Database DGMGRL> show database verbose prod1
# Primary Database server
Enabling the
configuration DGMGRL> enable configuration
Enabled.
EDIT CONFIGURATION SET PROPERTY <name>=<value>
EDIT DATABASE <db_name> SET PROPERTY <name>=<value>
Edit configuration EDIT INSTANCE <in_name> SET PROPERTY <name>=value>

There are many options see the broker section for more information
Troubleshooting (Monitoring commands and log files)
configuration DGMGRL> show configuration;
DGMGRL> show database prod1;
DGMGRL> show database prod1dr;

# There are a number of specific information commands, here are the most used
database DGMGRL> show database prod1 statusreport;
DGMGRL> show database prod1 inconsistentProperties;
DGMGRL> show database prod1 inconsistentlogxptProps;
DGMGRL> show database prod1 logxptstatus;
DGMGRL> show database prod1 latestlog;
# change the instance name to reflect the one you have choosen

prod1 (alert log): /u01/app/oracle/diag/rdbms/prod1/PROD1/trace/alert_PROD1.log

Logfiles prod1 (DG log): /u01/app/oracle/diag/rdbms/prod1/PROD1/trace/[Link]

prod1dr (alert log): /u01/app/oracle/diag/rdbms/prod1dr/PROD1DR/trace/alert_PROD1DR.log

prod1dr (DG log): /u01/app/oracle/diag/rdbms/prod1dr/PROD1DR/trace/[Link]

There are a number of commands that you can use to change the state of the database

turn off/on the redo DGMGRL> edit database prod1 set state=transport-off;
transport service for all Primary
standby databases DGMGRL> edit database prod1 set state=transport-on;
DGMGRL> edit database prod1dr set state=apply-off;
turn off/on the apply state Standby
DGMGRL> edit database prod1dr set state=apply-on;
DGMGRL> edit database prod1dr set state=apply-off;
put a database into a real-
Standby sql> alter database open read only;
time query mode DGMGRL> edit database prod1dr set state=apply-on;
# Choose what level of protection you require
sql> alter database set standby to maximize performance;
sql> alter database set standby to maximize availability;
change the protection mode Primary sql> alter database set standby to maximize protection;

# display the configuration

DGMGRL> show configuration

Redo Processing

Redo Processes (Primary and Standby Databases)

Processes There are a number of Oracle background processes that play a key role, first the
primary database

 LGWR - log writer process flushes from the SGA to the ORL files
 LNS - LogWriter Network Service reads redo being flushed from the redo
buffers by the LGWR and performs a network send of the redo to the standby
 ARCH - archives the ORL files to archive logs, that also used to fulfill
gap resolution requests, one ARCH processes is dedicated to local redo log
activity only and never communicates with a standby database

The standby database will also have key processes

  RFS - Remote File Server process performs a network receive of redo
transmitted from the primary and writes the network redo to the standby
redo log (SRL) files.
 ARCH - performs the same as the primary but on the standby
 MRP - Managed Recover Process coordinates media recovery management,
recall that a physical standby is in perpetual recovery mode
 LSP - Logical Standby Process coordinates SQL apply, this process only
runs in a logical standby
 PR0x - recovery server process reads redo from the SRL or archive log
files and apply this redo to the standby database.

Real-Time Apply
sql> alter database recover managed standby database using current logfile
Enable real-time apply disconnect;
sql> select recovery_mode from v$archive_dest_status where dest_id = 2;
Determine if real-time RECOVERY_MODE
apply is enabled --------------------------
MANAGED REAL-TIME APPLY
Tools and views to monitor redo
select process, client_process, thread#, sequence#, status from
v$managed_standby;

## primary (example)

PROCESS CLIENT_P THREAD# SEQUENCE# STATUS

--------- -------- ---------- ---------- ------------
ARCH ARCH 1 58 CLOSING
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 1 59 CLOSING
ARCH ARCH 1 56 CLOSING
LNS LNS 1 60 WRITING
LNS LNS 1 60 WRITING

## physical standby (example)

PROCESS CLIENT_P THREAD# SEQUENCE# STATUS

--------- -------- ---------- ---------- ------------
ARCH ARCH 0 0 CONNECTED
Background processes ARCH ARCH 1 55 CLOSING
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 1 59 CLOSING
RFS N/A 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS LGWR 1 60 IDLE
MRP0 N/A 1 60 APPLYING_LOG

## Logical standby (example)

PROCESS CLIENT_P THREAD# SEQUENCE# STATUS

--------- -------- ---------- ---------- ------------
ARCH ARCH 1 55 CLOSING
ARCH ARCH 1 10 CLOSING
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 0 0 CONNECTED
RFS UNKNOWN 0 0 IDLE
RFS LGWR 1 60 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
select * from v$dataguard_stats;
Information on Redo Data Note: this indirectly shows how much redo data could be lost if the primary db
crashes
Redo apply rate select to_char(snapshot_time, 'dd-mon-rr hh24:mi:ss') snapshot_time,
thread#, sequence#, applied_scn, apply_rate
from v$standby_apply_snapshot;
 Note: this command can only run when the database is open
select to_char(start_time, 'dd-mon-rr hh24:mi:ss') start_time,
item, round(sofar/1024,2) "MB/Sec"
Recovery operations from v$recovery_progress
where (item='Active Apply Rate' or item='Average Apply Rate');

Logical Standby
select owner from dba_logstdby_skip where statement_opt = 'INTERNAL SCHEMA' order by
owner;
schema that are not
maintained by SQL
Note: system and sys schema are not replicated so don't go creating tables in these
apply
schemas, the above command should return about 17 schemas (Oracle 11g) that are
replicated.
Check tables with
select distinct owner, table_name from dba_logstdby_unsupported;
unsupported data select owner, table_name from logstdby_unsupported_tables;
types
## Syntax

dbms_logstdby.skip (
stmt in varchar2,
schema_name in varchar2 default null,
object_name in varchar2 default null,
proc_name in varchar2 default null,
use_like in boolean default true,
esc in char1 default null
skip replication of );
tables
## Examples
execute dbms_logstdby.skip(stmt => 'DML', schema_name => 'HR', object_name =>
'EMPLOYEE');
execute dbms_logstdby.skip(stmt => 'SCHEMA_DDL', schema_name => 'HR', object_name =>
'EMPLOYEE');

# skip all DML operations

execute dbms_logstdby.skip(stmt => 'DML', schema_name => 'HR', object_name => '%');
stop SQL apply
execute dbms_logstdby.instantiate_table(schema_name => 'HR', table_name =>
'EMPLOYEE', DBLINK => 'INSTANTIATE_TABLE_LINK');
execute dbms_logstdby.skip(stmt => 'DML', schema_name => 'HR', object_name =>
'EMPLOYEE');
start SQL apply
revoke a skipped table
Note: the dblink should point to the primary database, we have to stop SQL apply as
the instantiate table procedure uses Oracle's data pump network interface to lock
the source table to obtain the SCN at the primary database, it then releases the
lock and gets a consistent snapshot of the table from the primary database, it
remembers the SCN associated with the consistent snapshot.
display what tables are select owner, name, use_like, esc from dba_logstdby_skip where statement_opt =
being skipped 'DML';
setting the guard on a alter database guard standby;
database
Inside SQL Apply
List the above select * from v$logstdby_process
processes
Increase the LCR cache # Set the cache size to 200MB
size execute dbms_logstdby.apply_set('MAX_SGA', 200);
How much LCR cache select used_memory_size from v$logmnr_session where session_id = (select value from
is being used v$logstdby_stats where name = 'SESSION_ID');
setting SQL apply
mode for the execute dbms_logstdby.apply_set (name => 'PRESERVE_COMMIT_ORDER', value => FALSE);
application
Determine the number select name, value from v$logstdby_stats where name = 'DDL TXNS DELIVERED';
of DDL statements
 NAME VALUE
since the last restart ------------------------------------------------------------------------
DDL TXNS DELIVERED 510
select status_code as sc, status from v$logstdby_process where type = 'BUILDER';

sc status
displaying the barrier ------------------------------------------------------------------------------------
-
44604 BARRIER SYNCHRONIZATION ON DDL WITH XID 1.15.256 (WAITING ON 17 TRANSACTIONS)
Tuning SQL Apply
# Set the MAX_SERVERS to 8 x the number of cores
MAX_SERVERS execute dbms_logstdby.apply_set ('MAX_SERVERS', 64);
# Set the MAX_SGA to 200MB
MAX_SGA execute dbms_logstdby.apply_set ('MAX_SGA', 200);
# Set the Hash table size to 10 million
_HASH_TABLE_SIZE execute dbms_logstdby.apply_set ('_HASH_TABLE_SIZE', 10000000);
DDL defer DDLs to off-peak hours
# Set the PERSERVE_COMMIT_ORDER to false
Preserve commit order execute dbms_logstdby.apply_set (name => 'PRESERVE_COMMIT_ORDER', value => FALSE);
# apply lag: indicates how current the replicated data at the logical standby is
# transport lag: indicates how much redo data that has already been generated is
missing at the logical # standby in term of redo records
lagging SQL Apply
select name, value, unit from v$dataguard_stats;

select name, value from v$logstdby_stats where name like 'TRASNACTIONS%';

Name Value
------------------------------------------------------------------------------------
SQL Apply component -----------------
bottleneck TRANSACTIONS APPLIED 3764
TRANSACTIONS MINED 4985

The mined transactions should be about twice the applied transaction, if this
decreases or staying at a low value you need to start looking at the mining engine.
select count(1) as idle_preparers from v$logstdby_process where type = 'PREPARER'
and STATUS_CODE = 16166;
Make sure all preparers
are busy IDLE_PREPARER
----------------------------
0
select used_memory_size from v$logstdby_session where session_id = (select value
from v$logstdby_stats where name = 'LOGMINER SESSION ID');
Make sure the peak
size is well below the USED_MEMORY_SIZE
amount allocated ----------------------------
32522244
select (available_txn - pinned_txn) as pipleline_depth from v$logstdby_session where
session_id (select value from v$lostdby_stats where name = 'LOGMINER SESSION ID');

PIPELINE_DEPTH
verify that the preparer ----------------------------
does not have enough 8
work for the applier
processes select count(*) as applier_count from v$logstdby_process where type = 'APPLIER';

APPLIER_COUNT
----------------------------
20
Setting max_servers execute dbms_logstdby.apply_set('MAX_SERVERS', 36);
and preparers execute dbms_logstdby.apply_set('PREPARE_SERVERS', 3);
display the pageout ## Run this first
activity select name, value from v$logstdby_stats where name line '%PAGE%' or name like
'%UPTIME' or name like '%IDLE%';

## Run the second time about 10 mins later

select name, value from v$logstdby_stats where name line '%PAGE%' or name like
'%UPTIME' or name like '%IDLE%';
 Now subtract one from the other and work out the percentage rate, if pageout has
increase above 5% then increase the MAX_SERVERS
## By default SQL apply should be one-sixth of the number of applier processes

select (available_txn - pinned_txn) as pipleline_depth from v$logstdby_session where

session_id (select value from v$lostdby_stats where name = 'LOGMINER SESSION ID');

PIPELINE_DEPTH
----------------------------
256

select count(1) as idle_applier from v$logstdby_process where type = 'APPLIER' and

unassigned large statuscode = 16166;
transactions
IDLE_APPLIER
---------------------------
12

## Now look for the unassigned large transactions

select value from v$logstdby_stats where name = 'LARGE TXNS WAITING TO BE ASSIGNED';

VALUE
---------------------------
12

Monitoring
# Use the thread# when using RAC an detect missing sequences
archive gap logs
select thread#, low_sequence#, high_sequence# from v$archive_gap;
select max(sequence#), thread# from v$archived_log group by thread#;

## you can use the dg_archivelog_monitor.sh script, which accepts three

delays in redo transport parameters, primary, physical
## and the archive log threshold (# of archive logs)

dg_archivelog_monitor.sh <primary> <standby> <threshold>

## On the primary run the below
select [Link]#, [Link]#
from
Identify the missing logs (select thread#, sequence# from v$archived_log where dest_id=1) L
on the primary where [Link]# not in
(select sequence# from v$archived_log where dest_id=2 and thread# =
[Link]#);
select to_char(start_time, 'DD-MON-RR HH24:MI:SS') start_time, item , sofar from
v$recovery_progress
apply rate and active where item in ('Active Apply Rate', 'Average Apply Rate', 'Redo Applied');
monitoring
Note: the redo applied is measured in megabytes, while the average apply rate
and the active apply rate is measured in kilobytes.
col name for a13
col value for a13
col unit for a30
set lines 132
transport and apply lag select name, value, unit, time_computed from v$dataguard_stats where name in
('transport lag', 'apply lag');

## use the dg_time_lag.ksh script

dg_time_lag.ksh
col client_pid for a10;
Viewing the status of the
managed recovery process select pid, process, status, client_process, client_pid, thread#, sequence#,
block#, blocks from v$managed_standby;
Switchover, Failover and FSFO

Quick Switchover and Failover (no checking)

## Start the switcover on the original primary
alter database commit to switchover to standby;

Complete ## On the new primary complete the switchover

Switchover alter database commit to switchover to primary;

## Now open the database on the new primary

alter database open;
## Start the failover
alter database commit to switchover to primary;

Complete Failover # Change the level of protection that you require

sql> alter database set standby to maximize performance;
sql> alter database set standby to maximize availability;
sql> alter database set standby to maximize protection;
Broker switchover DGMGRL> switchover to prod1lr

Complete Physical Switchover with checks

Action Step Commands
## check the syn status, it should say yes (run on the standby)
sql> select db_unique_name, protection_mode, synchronization_status,
synchronized from v$archive_dest_status

## if it says NO then lets make further checks (run on the standby)

check redo has
1 sql> select client_process, process, sequence#, status from v$managed_standby;
been received
## now check on the primary we should be one in front (run on the primary)
sql> select thread#, sequence#, status from v$log;

Note: if using a RAC environment make sure you check each instance
## check that MRP (applying_log) matches the RFS process, if the MRP line is
missing then you need to
## start the apply process, you also may see the status of wait_for_gap so wait
check that redo has until the gap have been
been applied 2 ## resolved first
(physical)
sql> select client_process, process, sequence#, status from v$managed_standby;

## if you are using a logical standby then you need to check the following to
confirm the redo has been
## applied
check that redo has
sql> select applied_scn, latest_scn, mining_scn from v$logstdby_progress;
been applied 3
(logical) ## if the mining scn is behind you may have a gap check this by using the
following

sql> select status from v$logstdby_process where type = 'READER';

show any running sql> select process, operation, [Link], mbytes_processed pct, [Link] from
4
jobs or backups v$rman_status r, v$session s where [Link]=[Link];
sql> alter system set log_archive_trace=8129;
increase logging
5
level (if required) ## to turn it off again
sql> alter system set log_archive_trace=0;
check for active ## Display the active sessions
6
sessions sql> select program, type from v$session where type='USER';
## make sure the status is "to standby", if you get "sessions active", then
check the stop those sessions (see above command to identify
7
switchover status ## sessions)
sql> select switchover_status from v$database;
tail the log alert log
8 tail alert??.log
file
 ## on the primary, after this command completes you will have two physical
standbys

switchover sql> alter database commit to switchover to physical standby with session
9
(primary) shutdown;

Note: at this point if you want to rollback this switchover see

my troubleshooting section to get ot back to normal
check the
10 sql> select switchover_status from v$database;
switchover status
complete the
switchover 11 sql> alter database commit to switchover to primary with session shutdown;
(physical)
open the new
12 sql> alter database open;
primary
sql> shutdown immediate;
finish off the old sql> startup mount;
13
primary sql> alter database recover managed standby database using current logfile
disconnect;

Complete Logical Switchover with checks

Action Step Commands
## check the syn status, it should say yes (run on the standby)
sql> select db_unique_name, protection_mode, synchronization_status,
synchronized from v$archive_dest_status

## if it says NO then lets make further checks (run on the standby)

check redo has sql> select client_process, process, sequence#, status from
1
been received v$managed_standby;

## now check on the primary we should be one in front (run on the primary)
sql> select thread#, sequence#, status from v$log;

Note: if using a RAC environment make sure you check each instance
## check that MRP (applying_log) matches the RFS process, if the MRP line
is missing then you need to
## start the apply process, you also may see the status of wait_for_gap so
check that redo wait until the gap have been
has been applied 2 ## resolved first
(physical)
sql> select client_process, process, sequence#, status from
v$managed_standby;

## if you are using a logical standby then you need to check the following
to confirm the redo has been
## applied
check that redo
sql> select applied_scn, latest_scn, mining_scn from v$logstdby_progress;
has been applied 3
(logical) ## if the mining scn is behind you may have a gap check this by using the
following

sql> select status from v$logstdby_process where type = 'READER';

show any running sql> select process, operation, [Link], mbytes_processed pct, [Link]
4
jobs or backups from v$rman_status r, v$session s where [Link]=[Link];
sql> alter system set log_archive_trace=8129;
increase logging
5
level (if required) ## to turn it off again
sql> alter system set log_archive_trace=0;
check for active ## Display the active sessions
6
sessions sql> select program, type from v$session where type='USER';
## make sure the status is "to standby", if you get "sessions active",
check the then stop those sessions (see above command to identify
7
switchover status ## sessions)
sql> select switchover_status from v$database;
tail the log alert 8 tail alert??.log
log file
sql> alter database prepare to switchover to logical standby;
Prepare the
9 ## confirm that the prepare has started to happen, you should now see
primary standby "preparing switchover"
sql> select switchover_status from v$database;
sql> alter database prepare to switchover to primary;

## confirm that the prepare has started to happen, you should see
"preparing dictionary"
Prepare the logical
10 sql> select switchover_status from v$database;
standby
## wait a while until the dictionary is built and sent and you should see
"preparing switchover"
sql> select switchover_status from v$database;
## you should now see its in the state of "to logical standby"
Check primary
11
database state sql> select switchover_status from v$database;
the last chance to ## On the primary
CANCEL the sql> alter database prepare to switchover cancel;
switchover (no 12
going back after ## on the logical
this) sql> alter database prepare to switchover cancel;
switchover the
primary to a logical 13 sql> alter database commit to switchover to logical standby;
standby
## check that its ready to become the primary, you should see "to primary"
switchover the
sql> select switchover_status from v$database
logical standby to 14
a primary ## Complete the switchover
sql> alter database commit to standby to primary;
start the apply
15 sql> alter database start logical standby apply immediate;
process

Complete Physical/Logical failover with checks

Action Step Commands
## This will tell you the lag time

select name, value, time_computed from v$dataguard_stats where name like '%lag%';
Check redo
1
applied ## You can also use the SCN number

select thread#, sequence#, last_change#, last_time from v$standby_log;

## Start by telling the apply process that this standby is going to be the new
primary, and to apply all
## the redo that it has

alter database recover managed standby database cancel;

alter database recover managed standby database finish;

## At this point the protection mode is lowered

the failover select protection_mode from v$database;

process (physical 2
standby) ## Now issue the switchover command and then open the database

alter database commit to switchover to primary with session shutdown;

alter database open;

## Startup the other RAC instances if using RAC

## You can then raise the protection mode (if desired)

set standby database to maximum protection;

the failover 2 alter database activate logical standby database finish apply;
process (logical
standby)

Bringing back the old Primary

Ste
Action Commands
p
## Since redo is applied by SCN we need he failover SCN from the new primary

select to_char(standby_became_primary_scn) failover_scn from v$database;

FAILOVER_SCN
-----------------------------------------------
7658841

## Now flashback the old primary to this SCN and start in mount mode
startup mount;
bring back the
flashback database to scn 7658841;
old primary
1 alter database convert to physical standby;
(physical shutdown immediate;
standby) startup mount;

## hopefully the old primary will start to resolve any gap issues at the next log
switch, which means we can start the MRP
## process to get this standby going to catchup as fast as possible

alter database recover managed standby database using current logfile disconnect;

## eventually the missing redos will be sent to the standby and applied, bring us
back to synchronization again.
bring back the 2 ## again we need to obtained the SCN
old primary select merge_change# as flashback_scn, processed_change# as recovery_scn from
(logical standby) dba_logstdby_history where stream_sequence# = (select max(stream_sequence#)-1 from
dba_logstdby_history);

flashback_scn recovery_scn
---------------------------------------------------------
7658941 7659568

## Now flashback the old primary to this SCN and start in mount mode
startup mount;
flashback database to scn 7658841;
alter database convert to physical standby;
shutdown immediate;
startup mount;

## Now we need to hand feed the archive logs from the primary to the standby (old
primary) into the MRP
## process, so lets get those logs (run on the primary)

select file_name from dba_logstdby_log where first_changed# <= recovery_scn and

next_change# > flashback_scn;

## Now you will hopefully have a short list of the files you need, now you need to
register them with
## the standby database (old primary)

alter database register logfile '<files from above list>';

## Now you can recover up to the SCN but not including the one you specify
recover managed standby database until change 7659568;

## Now the standby database becomes a logical standby as up to this point it has
been a physical one.
alter database active standby database;

## Lastly you need tell your new logical standby to ask the primary for a new copy
of the dictionary and
## all the redo in between. The SQL Apply will connect to the new primary using the
database link and
## retrieve the LogMiner dictionary, once the dictionary has been built, SQL Apply
will apply all the
## redo sent from the new primary and get itself synchronized
 create public database link reinstatelogical connect to system identified by
password using 'service_name_of_new_primary_database';

alter database start logical standby apply new primary reinstatelogical;

Use the Broker to bring back the old Primary
Use the broker to DGMGRL> failover to prod1dr;
n/a DGMGRL> reinstate database prod1;
do it all for you

Fast Start Failover (FSFO)

Monitor a specific condition DGMGRL> enable fast_start failover condition "Corrupted Controlfile";
via the Broker DGMGRL> enable fast_start failover condition "Datafile Offline";
Display conditions that are DGMGRL> show fast_start failover;
be monitored
Select the standby to DGMGRL> edit database prod1 set property FastStartFailoverTarget = 'prod1dr';
become the primary DGMGRL> edit database prod1dr set property FastStartFailoverTarget = 'prod1';
change threshold DGMGRL> edit configuration set property FastStartFailoverTargetThreshold = 45;
lag limit DGMGRL> edit configuration set property FastStartFailoverLagLimit = 60;
abort primary if in a hung DGMGRL>edit configuration set property FastStartFailoverPmyShutdown = true;
state
reinstate primary after a DGMGRL>edit configuration set property FastStartFailoverAutoReinstate = true;
failover
DGMGRL> enable fast_start failover;

Enable FSFO ## Display the configuration

DGMGRL> show fast_start failover;

Other sections of interest

Active Data Guard - see active data guard

Backups and Recovey - see backups and recovery

Troubleshooting - see troubleshooting

My complete setup guide - see complete setup guide

Data guard Concepts quick reference & commands Cheat Sheet

Data guard Cheat sheet
Required Redo Transport Attributes for Data Protection Modes
Maximum Availability Maximum Performance(Default) Maximum Protection
AFFIRM NOAFFIRM AFFIRM
SYNC ASYNC SYNC
DB_UNIQUE_NAME DB_UNIQUE_NAME DB_UNIQUE_NAME
The AFFIRM attribute is used to specify that redo received from a redo source database is not acknowledged until it
has been written to the standby redo log.
The NOAFFIRM attribute is used to specify that received redo is acknowledged without waiting for received redo to
be written to the standby redo log.
LOG_ARCHIVE_DEST_STATE_n Initialization Parameter Values
Value Description
ENABLE Redo transport services can transmit redo data to this destination. This is the default.
DEFER Redo transport services will not transmit redo data to this destination.
ALTERNATE This destination will become enabled if communication to its associated destination fails.

How to set the protection mode:

Set the data protection mode.
Sample set up:
DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG= (BOSTON, CHICAGO, DENVER)'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE) REOPEN=60
COMPRESSION=ENABLE DB_UNIQUE_NAME=CHICAGO'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
LOG_ARCHIVE_DEST_3='SERVICE=DENVER SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)
REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=DENVER'
LOG_ARCHIVE_DEST_STATE_3='ENABLE'
standby_file_management = auto

Execute the following SQL statement on the primary database:

SQL> ALTER DATABASE
SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};
How to determine the most recently archived redo log file
Perform the following query on the redo source database to determine the most recently archived sequence number
for each thread:
SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;
Determine the most recently archived redo log file at each redo transport destination.
Perform the following query on the redo source database to determine the most recently archived redo log file at
each redo transport destination:
SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#
2> FROM V$ARCHIVE_DEST_STATUS
3> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';

DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ#

------------------ ------ ---------------- -------------
/private1/prmy/lad VALID 1 947
standby1 VALID 1 947

Manual Gap Resolution

Perform the following query at the physical standby database to determine if there is redo gap on a physical standby
database:
SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 7 10
Perform the following query on the primary database to locate the archived redo log files on the primary database
(assuming the local archive destination on the primary database is LOG_ARCHIVE_DEST_1):
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND
2> DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc
Copy these log files to the physical standby database and register them using the ALTER DATABASE REGISTER
LOGFILE. For example:
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
 Redo Transport Wait Events
Wait Event Description
LNS wait on Total time spent waiting for redo transport sessions to be established to all ASYNC and SYNC
ATTACH redo transport destinations
LNS wait on Total time spent waiting for redo data to be written to all ASYNC and SYNC redo transport
SENDREQ destinations
LNS wait on Total time spent waiting for redo transport connections to be terminated to
DETACH all ASYNC and SYNCredo transport destinations

Role Transitions
A database operates in one of the following mutually exclusive roles: primary or standby. Data Guard enables you to
change these roles dynamically by issuing the SQL statements described in this chapter, or by using either of the
Data Guard broker's interfaces. Oracle Data Guard supports the following role transitions:
 Switchover
Allows the primary database to switch roles with one of its standby databases. There is no data loss during a
switchover. After a switchover, each database continues to participate in the Data Guard configuration with its new
role.
 Failover
Changes a standby database to the primary role in response to a primary database failure. If the primary database
was not operating in either maximum protection mode or maximum availability mode before the failure, some data
loss may occur. If Flashback Database is enabled on the primary database, it can be reinstated as a standby for the
new primary database once the reason for the failure is corrected.

Performing a Switchover to a Physical Standby Database

1. Verify that the primary database can be switched to the standby role.
Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database. For example:
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected
A value of TO STANDBY or SESSIONS ACTIVE indicates that the primary database can be switched to the standby
role.
2. Initiate the switchover on the primary database.
Issue the following SQL statement on the primary database to switch it to the standby role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH
SESSION SHUTDOWN;

3. Shut down and then mount the former primary database.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

4. Verify that the switchover target is ready to be switched to the primary role.

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
5. Switch the target physical standby database role to the primary role.
Issue the following SQL statement on the target physical standby database:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

6. Open the new primary database.

SQL> ALTER DATABASE OPEN;
7. Start redo apply on the new physical standby database.
For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT FROM SESSION;

Performing a Failover to a Physical Standby Database

Step 1 Identify and resolve any redo gaps.
Query the V$ARCHIVE_GAP view to determine if there are any redo gaps on the target standby database.
For example:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
2. Stop Redo Apply.
Issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3. Finish applying all received redo data.
Issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
If the error condition cannot be resolved, a failover can still be performed (with some data loss) by issuing the
following SQL statement:
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Verify that the target standby database is ready to become a primary database.
Query the SWITCHOVER_STATUS column of the V$DATABASE view on the target standby database.
For example:
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY
Switch the physical standby database to the primary role.
Issue the following SQL statement:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
Open the new primary database.
SQL> ALTER DATABASE OPEN;
Quick ref commands:
===================================================================

Startup commands
-----------------------------------------------------------------------
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect;
alter database recover managed standby database;
alter database recover managed standby database using current logfile;
recover managed standby database delay 60;

To remove a delay from a standby

------------------------------------------------------------------------
alter database recover managed standby database cancel;
alter database recover managed standby database nodelay disconnect;
alter database recover managed standby database nodelay;

Cancel managed recovery

---------------------------------------------------------------------
alter database recover managed standby database cancel;

Register a missing log file alter database register physical logfile '';If FAL doesn't work and it says the log is
already registered
alter database register or replace physical logfile '';

If that doesn't work, try this...

shutdown immediate
startup nomount
alter database mount standby database;
alter database recover automatic standby database;

wait for the recovery to finish - then cancel

shutdown immediate
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect;
Disable/Enable archive log destinations
alter system set log_archive_dest_state_2 = 'defer';alter system set log_archive_dest_state_2 = 'enable';
Turn on fal tracing on the primary dbalter system set LOG_ARCHIVE_TRACE = 128;

Stop the Data Guard broker

alter system set dg_broker_start=false;