Introduction
Data Guard setups often appear straightforward on paper, but real-world environments have a way of exposing gaps in even the most familiar procedures.
While creating a Physical Standby Database using RMAN Active Duplicate, I completed all the standard steps and enabled managed recovery successfully. Initially, everything looked fine — but soon I noticed a behavior that clearly indicated something wasn’t right.
The root cause turned out to be a missing but critical step:
Standby Redo Logs (SRLs) were not created.
This blog walks through:
The symptoms I observed
Why missing SRLs impact Data Guard
How I identified the issue
The correct and safe fix, with commands
Lessons learned for future setups
Initial Environment
Oracle Physical Standby Database
Created using RMAN Active Duplicate
Redo transport configured
Managed recovery started
At a high level, the standby was functional — but not optimal.
Symptoms Observed
Over time, I noticed:
Redo apply lag increasing intermittently
Real-time apply not consistently active
Standby applying redo only after log switches
There was no obvious ORA- errors, which made the issue subtle and easy to overlook.
Investigation & Root Cause
The usual checks were performed:
Managed Recovery Process (MRP) status
Redo transport configuration
Archive log generation and apply
Then I verified the presence of Standby Redo Logs:
SELECT GROUP#, THREAD#, STATUS FROM V$STANDBY_LOG;
Result:
No rows were returned.
This confirmed that Standby Redo Logs were never created.
Why Standby Redo Logs Are Critical
Standby Redo Logs are required for:
Real-Time Apply
Active Data Guard
Reduced apply lag
Smooth redo handling during log switches
Without SRLs:
Redo is written only to archived logs
Apply waits for log switches
Real-time recovery is not possible
In short, Data Guard works — but not efficiently.
The Correct Fix (Step-by-Step with Commands)
Since the standby was already created and running, the fix needed to be safe and non-disruptive.
1️⃣ Stop Managed Recovery
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2️⃣ Temporarily Set Standby File Management to MANUAL
When standby_file_management is set to AUTO, Oracle does not allow manual file creation.
To add SRLs manually, this must be changed:
ALTER SYSTEM SET standby_file_management=MANUAL;
3️⃣ Add Standby Redo Log Files
Standby Redo Logs must:
Match the size of primary redo logs
Have at least one extra group per thread
Example:
ALTER DATABASE ADD STANDBY LOGFILE
(‘/u01/oradata/STBY/srl01.log’) SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE
(‘/u01/oradata/STBY/srl02.log’) SIZE 500M;
Repeat as required based on primary configuration.
4️⃣ Set Standby File Management Back to AUTO (Very Important)
After manual creation, always revert the parameter:
ALTER SYSTEM SET standby_file_management=AUTO;
Leaving it as MANUAL can cause future issues with datafile creation.
5️⃣ Restart Managed Recovery in Real-Time Apply Mode
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
Verification
Confirm that SRLs are present and in use:
SELECT GROUP#, THREAD#, STATUS FROM V$STANDBY_LOG;
Also check managed recovery status:
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
After the fix:
Redo started applying in real time
Apply lag stabilized
Standby behavior normalized
Key Lessons Learned
Data Guard can appear healthy even when critical components are missing
Standby Redo Logs are not optional
Always verify SRLs after creating a physical standby
Not every Data Guard issue requires rebuilding the standby
Safe parameter handling is essential in production environments
Best Practices Going Forward
Based on this experience, I now ensure:
Standby Redo Logs are created before enabling redo transport
SRL verification is part of the post-setup checklist
standby_file_management is changed only temporarily when needed
Real-time apply is always validated
CONCLUSION
Forgetting Standby Redo Logs didn’t break my Data Guard setup — but it silently reduced its effectiveness. Identifying and fixing this issue reinforced an important truth:
Real DBA expertise is built by understanding why something works — not just following setup steps.
I hope this real-world scenario helps other DBAs avoid the same pitfall.
