INTRODUCTION:
As an Oracle DBA, setting up Data Guard is only half the job.
The real responsibility starts after the setup — making sure redo is shipping, applying correctly, and that there are no hidden gaps or errors.
Over time, I’ve built a simple daily verification checklist that helps me quickly confirm whether a Data Guard environment is healthy or needs attention.
In this blog, I’m sharing the Oracle views and commands I use regularly to verify transport status, apply status, gaps, and broker errors in Oracle Data Guard.
Daily Data Guard Verification Checklist
This checklist can be run in 5–10 minutes and gives a clear picture of Data Guard health.
Press enter or click to view image in full size
- 1.Check Transport Lag and Apply Lag
This is always my first check.
It shows:
Transport lag (redo shipping delay)
Apply lag (redo apply delay)
Estimated apply rate
SELECT name, value, time_computed
FROM v$dataguard_stats;
What to look for:
Transport Lag → Delay in redo shipping from primary
Apply Lag → Delay in redo being applied on standby
Estimated Apply Rate → Speed at which redo is applied
If lag keeps increasing, it’s a sign to investigate network, disk, or apply processes.
- 2.Verify Redo Transport Status
Next, I confirm whether redo is actually being shipped from the primary.
SELECT dest_id, status, error
FROM v$archive_dest_status;
What to look for:
STATUS should be VALID
INACTIVE is acceptable if the destination is not currently used
ERROR column should be NULL
Any non-null error here means redo transport is broken or unstable.
- 3.Check Managed Standby Processes
This step confirms whether redo is being received and applied.
SELECT process, status, sequence#
FROM v$managed_standby;
Important processes:
MRP → Managed Recovery Process (must be running on standby)
RFS → Remote File Server (receives redo)
LNS → Log Network Server (on primary)
If MRP is not running, redo may be received but not applied.
- 4.Detect Redo Gaps
Redo gaps are silent killers in the Data Guard.
SELECT * FROM v$archive_gap;
What it means:
If no rows are returned → no gaps
If rows are returned → standby is missing archive logs
In such cases, logs must be restored manually or via RMAN.
- 5.Check Broker Errors and Warnings
If you are using Data Guard Broker, this view is extremely useful.
SELECT timestamp, message
FROM v$dataguard_status
ORDER BY timestamp DESC;
Why this matters:
Shows broker-detected issues
Captures warnings and configuration errors
Often points directly to misconfiguration
This is one of the fastest ways to spot problems early.
- 6. Confirm Archive Log Application
To ensure logs are continuously applied on standby:
SELECT applied_scn, applied_time
FROM v$standby_log;
What to verify:
APPLIED_SCN should keep increasing
APPLIED_TIME should be recent
If values are stagnant, redo apply is likely stopped.
- 7.Broker Health Check Using DGMGRL
For a high-level health check, I always use DGMGRL.
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE VERBOSE <standby_db_name>;
What to look for:
Configuration Status should be SUCCESS
Verbose output shows:
Transport lag
Apply lag
Errors or warnings
This gives a clean, summarized status of the entire Data Guard setup.
Best Practice Verification Flow
This is the exact order I follow daily:
Run V$DATAGUARD_STATS → check lag
Run V$ARCHIVE_DEST_STATUS → confirm redo transport
Run V$MANAGED_STANDBY → confirm apply process
Run V$ARCHIVE_GAP → check missing logs
Run V$DATAGUARD_STATUS → check broker errors
Cross-check alert logs for detailed messages
CONCLUSION:
A Data Guard setup doesn’t fail suddenly — it gives signals long before that.
If you consistently monitor transport, apply, and gaps, you can fix issues before they turn into outages.
This checklist has helped me keep multiple Data Guard environments stable, and I hope it helps you do the same.
If you’re an Oracle DBA working with Data Guard, feel free to save this as your daily verification reference.
