Oracle Data Guard Most Used Commands

Note: Static “_DGMGRL” entries are no longer needed as of Oracle Database 12.1.0.2 and later release in Oracle Data Guard Broker configurations that are managed by Oracle Restart, RAC On Node or RAC as the Broker will use the clusterware to restart an instance. ( Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)

DGMGRL> connect sys@testdb
Password:
Connected to "TESTDB"
Connected as SYSDBA.
DGMGRL> show configuration;

Configuration - dg_testdb

Protection Mode: MaxPerformance
Members:
testdb - Primary database
stestdb - Physical standby database

Fast-Start Failover: Disabled

Configuration Status:
SUCCESS (status updated 20 seconds ago)

Switchover

DGMGRL> switchover to stestdb;
Performing switchover NOW, please wait...
New primary database "stestdb" is opening...
Oracle Clusterware is restarting database "testdb" ...
Connected to "TESTDB"
Switchover succeeded, new primary is "stestdb"

-- After switchover, run 'srvctl config database -d", the database role has been changed by Data Guard Broker automatically.

$ srvctl config database -d STESTDB
Database unique name: STESTDB
Database name: testdb
.
Start options: open
Stop options: immediate
Database role: PRIMARY

...
..
.

$ srvctl config database -d testdb
Database unique name: TESTDB
Database name: TESTDB
.
Start options: mount
Stop options: immediate
Database role: PHYSICAL_STANDBY

Show Lag

DGMGRL>  SHOW CONFIGURATION  lag

Configuration - dg_testdb

Protection Mode: MaxPerformance
Members:
testdb - Primary database
stestdb - Physical standby database
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 2 seconds (computed 0 seconds ago)

Fast-Start Failover: Disabled

Configuration Status:
SUCCESS (status updated 28 seconds ago)
DGMGRL> show database "stestdb";

Database - stestdb

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 322.00 KByte/s
Real Time Query: OFF
Instance(s):
TESTDB1
TESTDB2 (apply instance)

Database Status:
SUCCESS

TRANSPORT-ON / TRANSPORT-OFF

DGMGRL>  show database "testdb";

Database - testdb

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
TESTDB1
TESTDB2

Database Status:
SUCCESS

DGMGRL> EDIT DATABASE testdb SET STATE='TRANSPORT-OFF';
Succeeded.
DGMGRL> show database "testdb";

Database - testdb

Role: PRIMARY
Intended State: TRANSPORT-OFF
Instance(s):
TESTDB1
TESTDB2

Database Status:
SUCCESS

APPLY-ON / APPLY-OFF

DGMGRL>  show database "stestdb";

Database - stestdb

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 70 seconds ago)
Apply Lag: 0 seconds (computed 70 seconds ago)
Average Apply Rate: 114.00 KByte/s
Real Time Query: OFF
Instance(s):
TESTDB1
TESTDB2 (apply instance)

Database Status:
SUCCESS

DGMGRL> EDIT DATABASE stestdb SET STATE='APPLY-OFF';
Succeeded.
DGMGRL> show database "stestdb";

Database - stestdb

Role: PHYSICAL STANDBY
Intended State: APPLY-OFF
Transport Lag: 0 seconds (computed 215 seconds ago)
Apply Lag: 0 seconds (computed 215 seconds ago)
Average Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
TESTDB1
TESTDB2 (apply instance)

Database Status:
SUCCESS

Change apply instance

DGMGRL> edit database  TESTDB set state='apply-off';
Succeeded.

DGMGRL> edit database TESTDB set state='apply-on' with apply instance ='TESTDB1';

Succeeded.

Monitorable (Read-Only) Properties

DGMGRL>   show database verbose testdb;
...
..
.
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
LogXptStatus = '(monitor)'
SendQEntries = '(monitor)'
RecvQEntries = '(monitor)'
...
..
.

DGMGRL> show database testdb 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
INSTANCE_NAME STANDBY_NAME PROPERTY_NAME MEMORY_VALUE BROKER_VALUE

Configurable (Changeable) Properties

DGMGRL>  SHOW DATABASE testdb  LogXptMode;
LogXptMode = 'ASYNC'

DGMGRL> EDIT DATABASE testdb SET PROPERTY LogXptMode='SYNC';
Property "logxptmode" updated

DGMGRL> SHOW DATABASE testdb LogXptMode;
LogXptMode = 'SYNC'

Validate database spfile

DGMGRL> validate database  TESTDB  spfile;
This command cannot be used for the primary database.

DGMGRL> validate database STESTDB spfile;
...
..
.

processes:
testdb (PRIMARY) : 3000
stestdb : 6400
...
..
.

Validate static connect identifier

DGMGRL> validate static connect identifier for all
Oracle Clusterware on database "testdb" is available for database restart.

Oracle Clusterware on database "stestdb" is available for database restart.

validate network configuration for all

DGMGRL> validate network configuration for all
Oracle Clusterware on database "testdb" is available for database restart.

Oracle Clusterware on database "stestdb" is available for database restart.

DGMGRL> validate network configuration for all
Connecting to instance "TESTDB2" on database "testdb" ...
Connected to "TESTDB"
Checking connectivity from instance "TESTDB2" on database "testdb" to instance "STESTDB2" on database "stestdb"...
Succeeded.
Checking connectivity from instance "TESTDB2" on database "testdb" to instance "STESTDB" on database "stestdb"...
Succeeded.
Connecting to instance "TESTDB1" on database "testdb" ...
Connected to "TESTDB"
Checking connectivity from instance "TESTDB1" on database "testdb" to instance "STESTDB2" on database "stestdb"...
Succeeded.
Checking connectivity from instance "TESTDB1" on database "testdb" to instance "STESTDB" on database "stestdb"...
Succeeded.
Connecting to instance "STESTDB2" on database "stestdb" ...
Connected to "STESTDB"
Checking connectivity from instance "STESTDB2" on database "stestdb" to instance "TESTDB2" on database "testdb"...
Succeeded.
Checking connectivity from instance "STESTDB2" on database "stestdb" to instance "TESTDB1" on database "testdb"...
Succeeded.
Connecting to instance "STESTDB" on database "stestdb" ...
Connected to "STESTDB"
Checking connectivity from instance "STESTDB" on database "stestdb" to instance "TESTDB2" on database "testdb"...
Succeeded.
Checking connectivity from instance "STESTDB" on database "stestdb" to instance "TESTDB1" on database "testdb"...
Succeeded.

Oracle Clusterware on database "testdb" is available for database restart.

Oracle Clusterware on database "stestdb" is available for database restart.

DGMGRL>

Validate primary and standby database

DGMGRL> validate database testdb

Database Role: Primary database

Ready for Switchover: Yes

Flashback Database Status:
ttestdb: Off

Managed by Clusterware:
testdb: YES

DGMGRL> validate database stestdb

Database Role: Physical standby database
Primary Database: testdb

Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)

Flashback Database Status:
testdb: Off
stestdb: Off

Managed by Clusterware:
testdb: YES
stestdb: YES

Oracle Duplicate a Database from a Standby Database

This post demonstrates how to duplicate an Oracle database from a standby database instead of from a primary database normally.

The environment list:

Primaey DBStandby DBDulicate DB
TESTDBSTBYDBDUDB

Assume that all tnsnames are already configured. Password file, spfile are also already configured as the following:

  1. Copy the password file from source database for the target database, or create a password file with the same password as source db.
  2. Add “(UR = A)” into source and target tnsnames.
  3. Add an entry into listener.ora for auxiliary instance static registration. You can create a temporary listener with a spare port without changing anything of the current listener.
  4. CLUSTER_DATABASe=false in spfile for auxiliary instance.

Please note when you create the password file, you have to add the database into cluster OCR first, otherwise the following errors will occur:

ASMCMD> pwcreate --dbuniquename DUPDB '+DATA2/DUPDB/password/pwddupdb'
Enter password: ***********
OPW-00021: Failed to retrieve DB password file location from the CRS resource
ASMCMD-9454: could not create new password file
$ srvctl add database -d DUPDB -oraclehome /u01/app/oracle/product/19.0.0/dbhome_1  -dbtype RAC  -domain world  -spfile +DATA2/DUPDB/PARAMETERFILE/spfileDUPDB.ora   -role PRIMARY  -startoption OPEN  -stopoption IMMEDIATE


ASMCMD> pwcreate --dbuniquename DUPDB '+DATA2/DUPDB/password/pwddupdb'
Enter password: ***********

$ srvctl modify database -db DUPDB -pwfile '+DATA2/DUPDB/password/pwddupdb'


-- The following error will occur if the database is not added into CRS before creating the password file:

ASMCMD> pwcreate --dbuniquename DUPDB '+DATA2/DUPDB/password/pwddupdb'
Enter password: ***********
OPW-00021: Failed to retrieve DB password file location from the CRS resource
ASMCMD-9454: could not create new password file

Start Up Duplicate Database in Nomount

SQL> startup nomount pfile='/tmp/initDUPDB.ora' ;

SQL> create spfile='+DATA2/DUPDB/PARAMETERFILE/spfileDUPDB.ora' from pfile='/tmp/initDUPDB1.ora' ;

$ cat $ORACLE_HOME/dbs/initDUPDB1.ora
spfile='+DATA2/DUPDB/PARAMETERFILE/spfileDUPDB.ora'

SQL> startup database nomount force;

Duplicate database when standby in Read Only Mode

$ srvctl stop database -db STBYDB

$ srvctl start database -db STBYDB -startoption "READ ONLY"

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY


SQL> alter database recover managed standby database cancel;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

$ rman target sys@stbydb auxiliary sys@dupdb
target database Password:
connected to target database: STDBYDB (DBID=123456789)
auxiliary database Password:
connected to auxiliary database: DUPDB (not mounted)

RMAN> duplicate target database to DUPDB from active database ;
...
...
.
contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 03-APR-25

RMAN>

Duplicate database when standby in Recovery( Mounted and Applying ) Mode

DGMGRL>  show configuration;

Configuration - dg_testdb

Protection Mode: MaxPerformance
Members:
testdb - Primary database
stbydb - Physical standby database

Fast-Start Failover: Disabled

Configuration Status:
SUCCESS (status updated 56 seconds ago)


DGMGRL> show database verbose "stbydb";

Database - stbydb

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 3.40 MByte/s
Active Apply Rate: 12.61 MByte/s
Maximum Apply Rate: 12.89 MByte/s
Real Time Query: OFF
Instance(s):
STBYDB1 (apply instance)
STBYDB2
...
Database Status:
SUCCESS

DGMGRL>
$ rman  target sys@stbydb auxiliary sys@dupdb
target database Password:
connected to target database: STBYDB (DBID=123456789)
auxiliary database Password:
connected to auxiliary database: DUPDB (not mounted)

RMAN> duplicate target database to DUPDB from active database ;
...
...
.
contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 03-APR-25

RMAN>

Duplicate database when standby in Non-Recovery ( Mounted and Non-applying ) Mode

DGMGRL> show database verbose "stbydb"
Database - stbydb

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 12 hours 39 minutes 52 seconds (computed 0 seconds ago)
Average Apply Rate: 46.00 KByte/s
Active Apply Rate: 1.17 MByte/s
Maximum Apply Rate: 12.89 MByte/s
Real Time Query: OFF
Instance(s):
STBYDB1 (apply instance)
STBYDB2

Database Error(s):
ORA-16766: Redo Apply is stopped

Database Warning(s):
ORA-16853: apply lag has exceeded specified threshold

...
..
.
Database Status:
ERROR

DGMGRL>
$ rman  target sys@stbydb auxiliary sys@dupdb
target database Password:
connected to target database: STDBYDB (DBID=123456789)
auxiliary database Password:
connected to auxiliary database: DUPDB (not mounted)

RMAN> duplicate target database to DUPDB from active database ;
...
...
.
contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 03-APR-25

RMAN>

From the above tests, we can see the duplicate process will

1) switch archivelogs on PRIMARY
2) copy archived logs onto new duplicated database
3) apply the archived logs onto new database finally before OPEN new database.

so, no matter standby database is either

1) OPEN READ ONLY MODE
2) MOUNTED and RECOVERY MODE
3) MOUNTED and NON RECOVERY MODE

DUPLICATE from standby database all works well.

The common errors and solutions

RMAN-04006: error from auxiliary database: ORA-12528: TNS:listener: all appropriate instances are blocking new connections

This error is generated because STATIC REGISTRATION on listener was not done. To fix this, we need to add an entry of SID_LIST_LISTENER into listener.ora.

RMAN-04006: error from auxiliary database: ORA-12537: TNS:connection closed

This error was generated by missing the (UR = A) from tnsnames.

RMAN-04006: error froRMAN-06136: Oracle error from auxiliary database: ORA-17629: Cannot connect to the remote database server
ORA-17627: ORA-01017: invalid username/password; logon denied
ORA-17629: Cannot connect to the remote database serverm auxiliary database: ORA-01017: invalid username/password; logon denied

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/03/2025 15:29:36
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: Oracle error from auxiliary database: ORA-17629: Cannot connect to the remote database server
ORA-17627: ORA-01017: invalid username/password; logon denied
ORA-17629: Cannot connect to the remote database server
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/03/2025 16:28:42
RMAN-05501: aborting duplication of target database
RMAN-05614: Passwords for target and auxiliary connections must be the same when using active duplicate

This error is because password file was not copied to duplicate database, or the password is different.

ORA-12720: operation requires database is in EXCLUSIVE mode

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/03/2025 16:50:17
RMAN-05501: aborting duplication of target database
RMAN-06136: Oracle error from auxiliary database: ORA-01503: CREATE CONTROLFILE failed
ORA-12720: operation requires database is in EXCLUSIVE mode

set parameter “cluster_database=FALSE”

OEM Generic Alert Log Error With Message “Dumping Current Patch Information”

Database alert log shows entry of patch description injected in alert log (this is a RDBMS feature which is introduced)

Solution

From RDBMS side:

Set below parameters defined at the spfile or pfile level in the database, to avoid dumping the patch information in alert log.

-- To avoid dumping the parameters information
_log_segment_dump_parameter=FALSE

To avoid dumping the patches information
_log_segment_dump_patch=FALSE

— —- OR ——-

From OEM side :

– Go to Database target > Monitoring > Metric and Collection settings > Database alert log metric
– Click on Edit for ‘Generic Alert log Error’

– Bottom left hand corner there is a section called Alert Log Filter Expression’

– Modify the ‘Alert Log Filter Expression’ and replace with value below

.*ORA-0*(54|604|1142|1146)\D.*|Patch Description.*|$

This will capture all Patch Description.* entries in Database alert log and omit/suppress these alert (prevent alert from being triggered)

If you don’t want to miss error like ORA-00604, then modify the filter expression as needed.

.*ORA-0*(54|1142|1146)\D.*|Patch Description.*|$

This will not suppress any error like ORA-00604.

OPW-00021: Failed to retrieve DB password file location from the CRS resource

When create Oracle password file in ASM, the following errors occur:

$ orapwd file='+DATA1/TESTDB/PASSWORD/pwdTESTDB' dbuniquename='TESTDB'

Enter password for SYS:

OPW-00021: Failed to retrieve DB password file location from the CRS resource

RESOLUTION

Add database and instances into CRS by running ‘srvctl’, but do not specify “-pwfile ‘+DATA1/TESTDB/PASSWORD/pwdTESTDB’:

$ srvctl add database -d TESTDB  -oraclehome /u01/app/oracle/product/19.0.0/dbhome_1  -dbtype RAC  -domain world  -spfile +DATA1/TESTDB/PARAMETERFILE/spfileTESTDB.ora   -role PRIMARY  -startoption OPEN  -stopoption IMMEDIATE

then

$  orapwd file='+DATA1/TESTDB/PASSWORD/pwdTESTDB' dbuniquename='TESTDB'

Enter password for SYS:
SQL> select * from v$pwfile_users;

Run the following commnad, we can see ‘-pwfile ‘+DATA1/TESTDB/PASSWORD/pwdTESTDB’ has been added into configuration automatically when we create password file.

$ srvctl config database -d TESTDB
...
Database unique name: TESTDB
Database name:
Oracle home: /u01/app/oracle/product/19.0.0/dbhome_1
Oracle user: oracle
Spfile: +DATA1/TESTDB/PARAMETERFILE/spfileTESTDB.ora
Password file: +DATA1/TESTDB/PASSWORD/pwdTESTDB
Domain: world
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
...
..
.

Physical Standby Data Guard Health Check

Check N+1 standby redo logs are created on both primary and standby

— on primary

SQL> SELECT thread#, group#, sequence#, bytes, archived, status 
FROM v$standby_log
order by thread#, group#;


THREAD# GROUP# SEQUENCE# BYTES ARC STATUS
---------- ---------- ---------- ---------- --- ----------
1 11 0 1073741824 YES UNASSIGNED
1 12 0 1073741824 YES UNASSIGNED
1 13 0 1073741824 YES UNASSIGNED
2 21 0 1073741824 YES UNASSIGNED
2 22 0 1073741824 YES UNASSIGNED
2 23 0 1073741824 YES UNASSIGNED

6 rows selected.

— on standby

SQL> SELECT thread#, group#, sequence#, bytes, archived, status 
FROM v$standby_log
order by thread#, group#;

THREAD# GROUP# SEQUENCE# BYTES ARC STATUS
---------- ---------- ---------- ---------- --- ----------
1 11 0 1073741824 NO UNASSIGNED
1 12 328 1073741824 YES ACTIVE
1 13 0 1073741824 YES UNASSIGNED
2 21 0 1073741824 NO UNASSIGNED
2 22 234 1073741824 YES ACTIVE
2 23 0 1073741824 YES UNASSIGNED

6 rows selected.

Check primary & standby database protection mode and switchover status.

— On Primary

SQL>SELECTNAME,OPEN_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME,
    SWITCHOVER_STATUS FROM V$DATABASE;

NAME      OPEN_MODE    DATABASE_R PROTECTION_MODE      DB_UNIQUE_ SWITCHOVER_STATUS
--------- ------------ ---------- -------------------- ---------- --------------------
TESTDB    READ WRITE   PRIMARY    MAXIMUM PERFORMANCE  TESTDB     TO STANDBY

— ON standby

SQL>SELECTNAME,OPEN_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME,
    SWITCHOVER_STATUS FROM V$DATABASE;

NAME      OPEN_MODE  DATABASE_R PROTECTION_MODE      DB_UNIQUE_ SWITCHOVER_STATUS
--------- ---------- ---------- -------------------- ---------- --------------------
TESTDB    MOUNTED   PHYSICAL STANDBY    MAXIMUM PERFORMANCE  STBYDB     NOT ALLOWED

Check maximum archive log sequences

— ON primary

SQL> select  THREAD#,STATUS,ENABLED,GROUPS,INSTANCE, MAX(SEQUENCE#) 
FROM gv$THREAD
group by THREAD#,STATUS,ENABLED,GROUPS,INSTANCE ;

THREAD# STATUS ENABLED GROUPS INSTANCE MAX(SEQUENCE#)
---------- ------ -------- ---------- ---------- --------------
2 OPEN PUBLIC 2 TESTDB2 234
1 OPEN PUBLIC 2 TESTDB1 328

— On standby

SQL> select  THREAD#,STATUS,ENABLED,GROUPS,INSTANCE, MAX(SEQUENCE#) 
FROM gv$THREAD
group by THREAD#,STATUS,ENABLED,GROUPS,INSTANCE ;

THREAD# STATUS ENABLED GROUPS INSTANCE MAX(SEQUENCE#)
---------- ------ -------- ---------- ---------- --------------
2 OPEN PUBLIC 2 TESTDB2 234
1 OPEN PUBLIC 2 TESTDB1 328

Check archived logs are applied or not until the maximum sequences 

— On primary

SQL>  SELECT THREAD#,DEST_ID,APPLIED,max(SEQUENCE#)  FROM V$ARCHIVED_LOG where DEST_ID>1 group by THREAD#,APPLIED,DEST_ID;

   THREAD#    DEST_ID APPLIED   MAX(SEQUENCE#)
---------- ---------- --------- --------------
         1          2 YES                  327
         2          2 YES                  233

On standby

SQL> SELECT THREAD#,DEST_ID,APPLIED,max(SEQUENCE#)  
FROM V$ARCHIVED_LOG
where APPLIED='YES'
group by THREAD#,APPLIED,DEST_ID;

THREAD# DEST_ID APPLIED MAX(SEQUENCE#)
---------- ---------- --------- --------------
1 1 YES 327
2 1 YES 233

Check recovery progress with gv$managed_standby  view.

— On primary

SQL>  select INST_ID,process,pid,status,sequence# from gv$managed_standby order by 1,2;

INST_ID PROCESS PID STATUS SEQUENCE#
---------- --------- ------------------------ ------------ ----------
1 ARCH 70960 CLOSING 327
1 ARCH 70964 CLOSING 320
1 ARCH 70914 CLOSING 317
1 ARCH 70956 CLOSING 318
1 DGRD 70921 ALLOCATED 0
1 DGRD 70917 ALLOCATED 0
1 DGRD 9311 ALLOCATED 0
1 DGRD 87854 ALLOCATED 0
1 LNS 87745 WRITING 328
2 ARCH 45746 CLOSING 232
2 ARCH 45884 CLOSING 230
2 ARCH 45829 CLOSING 233
2 ARCH 45559 CLOSING 231
2 DGRD 123096 ALLOCATED 0
2 DGRD 45652 ALLOCATED 0
2 DGRD 45897 ALLOCATED 0
2 DGRD 45491 ALLOCATED 0
2 LNS 45891 WRITING 234

18 rows selected.

On standby

SQL>  select INST_ID,process,pid,status,sequence# from gv$managed_standby order by 1,2;

INST_ID PROCESS PID STATUS SEQUENCE#
---------- --------- ------------------------ ------------ ----------
1 ARCH 19160 CLOSING 229
1 ARCH 19189 CLOSING 327
1 ARCH 19208 CLOSING 319
1 ARCH 19230 CLOSING 326
1 DGRD 19173 ALLOCATED 0
1 DGRD 19178 ALLOCATED 0
1 MRP0 28123 APPLYING_LOG 234
1 RFS 59847 RECEIVING 328
2 ARCH 74638 CLOSING 233
2 ARCH 74715 CLOSING 227
2 ARCH 74711 CLOSING 232
2 ARCH 74705 CLOSING 230
2 DGRD 74693 ALLOCATED 0
2 DGRD 74661 ALLOCATED 0
2 RFS 76404 IDLE 0
2 RFS 115608 RECEIVING 234
2 RFS 76410 IDLE 0

17 rows selected.

Check Dataguard status

— on standby only

SQL> select name, value from V$DATAGUARD_STATS;

NAME VALUE
-------------------------------- ------------------------------
transport lag +00 00:00:00
apply lag +00 00:00:00
apply finish time +00 00:00:00.000
estimated startup time 41

Check recovery process

— on standby only

SQL>  select to_char(start_time, 'DD-MON-RR HH24:MI:SS') start_time,
item, round(sofar/1024,2) "MB/Sec"
from v$recovery_progress
order by start_time;

START_TIME ITEM MB/Sec
------------------ -------------------------------- ----------
28-FEB-25 22:07:39 Active Apply Rate 1.33
28-FEB-25 22:07:39 Active Time 34.95
28-FEB-25 22:07:39 Apply Time per Log .68
28-FEB-25 22:07:39 Average Apply Rate .12
28-FEB-25 22:07:39 Checkpoint Time per Log 0
28-FEB-25 22:07:39 Redo Applied 18
28-FEB-25 22:07:39 Last Applied Redo 0
28-FEB-25 22:07:39 Log Files .05
28-FEB-25 22:07:39 Maximum Apply Rate 69.75
28-FEB-25 22:07:39 Recovery ID 0
28-FEB-25 22:07:39 Elapsed Time 144.17

11 rows selected.

Check gap status between primary and standby database

SQL>select status, gap_status from v$archive_dest_status where dest_id = 2;

STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP

Appendix – Monitoring Data Guard Configuration Health Using SQL

on primary database

GoalQueryExpected Results
Check if any remote standby archive destination is getting errors. 
Check if all remote standby archive destinations is enabled or “VALID”.
select sysdate,status,error from gv$archive_dest_status
where type=’PHYSICAL’ and status!=’VALID’ or error is not null;
Good behavior – no rows returned.
If query returns rows, then raise an alert with the returned data.
Check if any nologging activity has occurred on the primary for the last day.
select file#, name, unrecoverable_change#, unrecoverable_time
from v$datafile
where unrecoverable_time>(sysdate – 1);
Good behavior – no rows returned.
If query returns rows, then the standby is vulnerable and the subsequent file needs to be refreshed on the standby. 
Detect gaps on the standby select sysdate,database_mode,recovery_mode, gap_status from v$archive_dest_status where type=’PHYSICAL’ and gap_status!=’NO GAP’;Good behavior – no rows returned.
If query returns rows, then there’s an existing gap between the primary and the standby.  Subsequent action is to run the same query on the standby, if the output is identical, then no action required.  If the output on the standby does not match the primary then the datafile on the standby should be refreshed.
Assess if any severe Data Guard event occurred in the last daySQL> select * from v$dataguard_status where severity in (‘Error’,’Fatal’) and TIMESTAMP > sysdate -1;Good behavior – no rows returned.
If query returns rows then the result should raise an alert with the returned output.
FOR SYNC ENVIRONMENTS ONLY:
 
Assess if running in Maximum Availability mode and configuration is in sync.
select sysdate,protection_mode, synchronized, synchronization_status from v$archive_dest_status where type=’PHYSICAL’ and synchronization_status !=’OK’;Good behavior – no rows returned.
If query returns rows then the result should raise an alert with the returned output.

on standby

GoalQueryExpected Results
Determine if there is a transport lagselect name,value,time_computed,datum_time from v$dataguard_stats where name=’transport lag’ and value > ‘+00 00:01:00’;Good behavior – no rows are returned. 
If no rows are returned then this implies that there is no transport lag 
 
Determine if there is an apply lagselect name,value,time_computed,datum_time from v$dataguard_stats where name=’apply lag’ and value > ‘+00 00:01:00’;Good behavior – no rows are returned. 
If no rows are returned then this implies that there is no apply lag 
 
Standby data file check (offline files or files that are not accessible)select * from v$datafile_header where 
status =’OFFLINE’ 
or ERROR is not null;
Good behavior – no rows returned.
Any rows returned will show which file(s) are having IO or recovery issues.
 
Verify that the Media Recovery Process is currently running. select * from v$managed_standby 
where process like ‘MRP%’;
Good behavior – rows returned.
If no rows are returned then the MRP process is not running.
Assess if any severe Data Guard event occurred in the last dayselect * from v$dataguard_status where 
severity in (‘Error’,’Fatal’) and 
timestamp > (sysdate -1);
Good behavior – no rows returned.
If query returns rows, then the result should raise an alert with the returned output.