The first warning often appears during a DR drill. Redo transport is healthy, managed recovery is running, and the standby looks ready. Then Data Guard Broker reports insufficient standby redo logs, or apply lag starts rising after an online redo log resize even though the network has no visible problem.
This is why I do not validate standby redo logs only by checking whether rows exist in V$STANDBY_LOG. The count must be correct for every redo thread, the sizes must match the primary redo layout, RFS must actually be using them, and the same preparation should exist on the current primary for the next role transition.
There is another misconception worth clearing up early. Standby redo logs improve how received redo is stored and applied. They do not convert asynchronous transport into a guaranteed zero-data-loss service. Protection mode, transport progress and apply progress are three different parts of the Data Guard path.
The discussion below focuses mainly on physical standby databases and the checks that matter in production: real-time apply, the required SRL count, RAC thread coverage, role readiness, storage pressure and the lag patterns that expose a broken receive path.
What a Standby Redo Log Changes
An online redo log belongs to the database while it is operating in the primary role. A standby redo log, or SRL, is a receiving structure. On a physical standby, the remote file server process, RFS, receives redo from the source database and writes it into the current SRL.
The managed recovery process can read that SRL while it is still being filled. This is real-time apply. Recovery does not need to wait for the current redo sequence to complete and become an archived redo log before applying it to the standby datafiles.
From Oracle Database 12.1 onward, the old USING CURRENT LOGFILE clause is deprecated and is no longer needed to start real-time apply. Starting managed recovery normally enables real-time apply when the standby is in ARCHIVELOG mode and usable SRLs are available.
If RFS cannot obtain a suitable SRL, Oracle can write received redo directly to a standby archived redo log. That does not mean modern ASYNC transport simply waits for the next primary log switch before sending redo. The visible penalty is usually on the apply side: recovery falls back to the completed archived-log path instead of applying the current stream from an SRL.
In monitoring, this can produce a saw-tooth pattern. Transport lag remains low, apply lag grows during the current sequence, and then falls after the sequence is completed and applied. When I see that pattern, I verify real-time apply and SRL usage before blaming network bandwidth or increasing apply parallelism.
Protection Mode Is Not the Same as Apply Mode
SRLs, synchronous transport and zero data loss are often discussed as though they are one feature. They are related, but each controls a different stage.
| Production question | Main control |
|---|---|
| Does the primary wait before acknowledging a commit? | Protection mode and SYNC or ASYNC transport |
| Must the remote side acknowledge after writing to storage? | AFFIRM or NOAFFIRM |
| Can recovery apply the current incoming sequence? | A usable SRL and real-time apply |
| How much received redo is still unapplied? | Standby CPU, datafile I/O and apply capacity |
Maximum Availability and Maximum Protection depend on synchronous transport to an eligible standby and require SRLs. Maximum Performance normally uses ASYNC transport. In ASYNC mode, a primary transaction can commit before its redo reaches durable storage at the standby.
A well-performing ASYNC configuration may show only a small exposure window, but SRLs do not make that window disappear. They protect and expose redo that has reached the destination. They cannot protect redo that was still buffered or in transit when the primary site was lost.
Storage latency also matters differently by mode. With SYNC AFFIRM, the primary commit path includes the remote durable write, so network latency and SRL write latency can affect application response time. With ASYNC transport, slow receiver storage may not delay every foreground commit, but sustained backpressure can increase transport lag and widen the RPO exposure.
The SRL Count Rule: ORL Groups Plus One
Required formula for every source redo thread:
SRL groups = primary online redo log groups + 1
An equal number of online and standby redo log groups is not sufficient. Oracle requires at least one more SRL group than the online redo log count for each source thread. The additional group gives RFS another target while the previous SRL is being archived and made reusable.
- A single-instance primary with three online redo groups needs at least four SRL groups.
- A two-instance RAC primary with three online groups in each thread needs four SRLs for thread 1 and four for thread 2.
- The same thread coverage is required even if the standby RAC cluster runs fewer instances. The receiver must support every redo thread at the source.
- If completed SRLs cannot be archived quickly enough during heavy switching, more than the minimum may be required.
Size the SRLs from V$LOG.BYTES. Each SRL must be at least as large as the largest source online redo log, and the cleanest operational layout is to keep the online and standby redo logs the same size. I prefer to use the exact byte value in the DDL instead of manually converting it to an approximate MB or GB value.
If the primary online redo groups have mixed sizes, standardize that layout first. In RAC, assign every SRL to its intended thread and place the files on shared storage. Leaving groups at thread 0 may allow runtime assignment in some configurations, but explicit thread ownership is easier to validate and follows current Oracle guidance.
Why SRLs Should Exist on the Primary Too
A standby redo log is not used while the database is operating in the primary role. That sometimes leads teams to create SRLs only on the current standby. The design works until the first role transition.
After a switchover, the old primary becomes the new redo receiver. If its SRLs were created in advance, it can immediately receive redo through the correct path. If they are missing, the DBA has additional work to perform and the configuration is not fully ready in the reverse direction.
Production best practice: Create the complete SRL layout on both the primary and standby databases before a switchover.
Pre-created SRLs do not make Oracle's internal role-conversion step execute faster. They make the overall switchover cleaner and immediately role-ready because no post-switch SRL creation is required. Data Guard Broker validates SRLs on both sides before a role transition, and SRLs are required on the primary when Fast-Start Failover is enabled.
Build and Inspect the SRL Layout
Keep the discovery and creation statements together in the runbook. Run the online redo queries on the source database and review V$STANDBY_LOG on every database that may receive redo.
-- Primary: online redo count and exact size by thread
SELECT thread#, group#, bytes,
ROUND(bytes / 1024 / 1024) AS size_mb,
members, status
FROM v$log
ORDER BY thread#, group#;
SELECT thread#, COUNT(*) AS online_groups,
MIN(bytes) AS min_bytes,
MAX(bytes) AS max_bytes FROM v$log GROUP BY thread# ORDER BY thread#;
-- Run on each role-capable database SELECT thread#, group#, bytes,
ROUND(bytes / 1024 / 1024) AS size_mb,
status, archived, sequence# FROM v$standby_log ORDER BY thread#, group#;
-- Example: four 2 GB SRLs for thread 1 on ASM ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 ('+DATA') SIZE 2147483648; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 ('+DATA') SIZE 2147483648; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 ('+DATA') SIZE 2147483648; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 ('+DATA') SIZE 2147483648;
-- Physical standby, Oracle 12.1 and later ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Choose group numbers that do not collide with online redo groups or existing SRLs. Repeat the DDL for every source thread. Adding new groups is normally straightforward, but dropping or resizing old groups needs a controlled change. Never drop the group currently receiving redo. Confirm that it is safely reusable before running ALTER DATABASE DROP STANDBY LOGFILE GROUP group_number.
SRL storage must sustain the peak redo rate. A slow or inaccessible disk group can create receiver backpressure even when the network is healthy. If SRLs are multiplexed, place the members in separate failure domains; two members on the same vulnerable file system provide little additional protection.
How to prove That RFS Is Using the SRLs
A clean configuration query is only the first layer. Runtime validation should cover RFS, recovery mode, lag freshness, archive health and broker readiness.
-- Standby: RFS and managed recovery activity
SELECT name, role, action, client_role,
thread#, sequence#, group#
FROM v$dataguard_process
ORDER BY name, thread#, sequence#;
-- Standby: lag value and metric freshness SELECT name, value, unit, time_computed, datum_time FROM v$dataguard_stats WHERE name IN ('transport lag', 'apply lag', 'apply finish time') ORDER BY name;
-- Primary: remote destination and SRL use SELECT dest_id, status, type, database_mode,
recovery_mode, srl, error FROM v$archive_dest_status WHERE type IN ('PHYSICAL', 'LOGICAL', 'FAR SYNC');
-- Data Guard Broker
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE VERBOSE 'STBYDB';
DGMGRL> VALIDATE DATABASE VERBOSE 'STBYDB';
For new monitoring, use V$DATAGUARD_PROCESS instead of building around V$MANAGED_STANDBY, which has been deprecated since Oracle Database 12.2.
Always read DATUM_TIME with the lag value. A transport lag of zero is not reassuring if DATUM_TIME stopped changing ten minutes ago. The last computed metric is stale because the standby is no longer receiving fresh data.
One ACTIVE SRL for a receiving thread is normal. Use ARCHIVED, SEQUENCE#, process activity and the alert log to understand whether it is currently being written or has completed and is waiting for archival. Do not clear or drop a group simply because its status is ACTIVE.
When RFS Is Not Using an SRL
- Compare the primary ORL byte size with the receiver SRL byte size.
- Count SRL groups by thread, not only as a database total.
- Verify that every source RAC thread is represented.
- Check the SRL members, ASM disk groups or file-system paths.
- Check the local archive destination and fast recovery area.
- Review the standby alert log around the affected sequence.
A full FRA can look like an SRL shortage because completed groups cannot be archived and reused. Adding more SRLs may postpone the symptom, but it does not fix the archive destination.
Once RFS is writing to the expected group, separate transport lag from apply lag. Rising transport lag points toward the send-and-receive path, network capacity, destination errors, authentication or receiver I/O. Low transport lag with rising apply lag points toward MRP, standby CPU, datafile I/O, hot blocks or the redo workload. SRLs remove the wait for a completed log; they do not make an underpowered standby faster.
Oracle SRLs Compared With PostgreSQL WAL Reception
PostgreSQL does not have an object that a DBA creates as a direct equivalent of an Oracle SRL group. The receiver-side stages are still useful to compare.
| Oracle Data Guard | PostgreSQL physical replication |
|---|---|
| Redo transport processes send redo | WAL sender streams WAL |
| RFS receives redo | WAL receiver receives WAL |
| Current redo is persisted in an SRL | Received WAL is persisted under pg_wal |
| MRP applies redo | Startup process replays WAL |
| Archived redo can resolve gaps | WAL archive and restore_command can supply missing segments |
The commit settings are comparable only at a high level. PostgreSQL synchronous_commit = remote_write waits until the standby operating system has written the WAL, while remote_apply waits until replay. Waiting for replay gives a stronger visibility point but can add significant commit latency. These settings should not be presented as exact equivalents of Oracle protection modes.
-- PostgreSQL primary
SELECT application_name, client_addr, state, sync_state,
write_lag, flush_lag, replay_lag,
pg_size_pretty(
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)
) AS replay_gap
FROM pg_stat_replication;
-- PostgreSQL standby SELECT status, sender_host, latest_end_lsn,
last_msg_send_time, last_msg_receipt_time FROM pg_stat_wal_receiver;
SELECT now() - pg_last_xact_replay_timestamp() AS replay_delay;
The time-based replay query is useful, but it is not an exact RPO measurement. It can return NULL before any transaction has been replayed, and an idle database can make a time delay look larger than the actual byte gap. As with Oracle, position, time and metric freshness should be read together.
Mini Case Study: Apply Lag After a Redo Resize
Problem
A busy RAC database had its online redo logs increased from 1 GB to 4 GB to reduce excessive switching during batch processing. Transport lag remained low, but apply lag grew through every sequence and dropped after the next log switch. The first assumption was that MRP could not keep up.
Root cause
Only the primary ORLs had been changed. The standby still had 1 GB SRLs. RFS could not use those smaller groups for the 4 GB incoming sequence and used the standby archived redo path. The alert log and an exact comparison between V$LOG and V$STANDBY_LOG exposed the mismatch.
Fix we made
New 4 GB SRLs were added for every RAC thread, using one more group per thread than the online redo count. The same layout was created on the primary for its future standby role. The old groups were removed only after they were no longer active. RFS resumed writing to the current SRL, and the saw-tooth apply lag disappeared.
The operational lesson was simple: every online redo log change needs a Data Guard log-layout review. Redo sizing is not a primary-only activity.
Lessons From the Field
Most SRL problems are configuration drift, not an Oracle defect. A DBA resizes online redo, adds a RAC thread, rebuilds a standby or moves storage and forgets to repeat the SRL review on every role-capable database.
A small scheduled control is valuable here. Compare ORL and SRL counts per thread, exact byte sizes, member status and database role across the configuration. That check is more useful than discovering the mismatch during the next DR exercise.
The FRA and local archive destination belong in the same monitoring story. A completed SRL must be archived before it can be reused. Destination errors and space pressure can therefore surface as an apparent SRL availability problem.
Finally, test the design in both directions. Broker validation is useful, but a controlled switchover proves the services, transport path, redo reception, apply behavior and ability to switch back. High availability is a tested behavior, not only a correct set of control-file records.
Quick Takeaways
- SRLs allow recovery to apply the current incoming sequence without waiting for a completed archived log.
- Every source thread requires at least one more SRL group than its primary online redo log groups.
- Match the SRL size to the primary redo layout and assign RAC threads explicitly.
- SRLs do not turn ASYNC transport into guaranteed zero data loss.
- Create the complete SRL layout on both primary and standby before a role transition.
- Validate actual RFS use, recovery mode, lag freshness, archive health and broker readiness.
- Low transport lag with high apply lag normally points to the standby apply path.
Conclusion
Standby redo logs sit directly between redo transport and recovery. When they are correctly sized, assigned and available, RFS can write the incoming stream to an SRL and MRP can apply it without waiting for a completed archived log. This reduces apply latency and leaves less recovery work during a role transition.
The boundaries are equally important. SRLs do not change ASYNC transport into a zero-data-loss design, repair a slow standby or compensate for a full FRA. Protection mode determines when the primary can acknowledge a commit. Transport health shows what reached the standby. Apply capacity determines how quickly the standby datafiles catch up.
For a single-instance database, use the primary ORL count plus one and verify the exact size. For RAC, apply the same formula separately to every source thread. Create the full layout on every database that may become a redo receiver, including the current primary.
Add this to the next Data Guard review: compare online and standby redo layouts across every member and check both current and future roles. Repeat the review after a redo resize, RAC topology change, standby rebuild or storage migration. Then validate the runtime path. Confirm RFS activity, real-time recovery mode, fresh lag timestamps, archive health and broker readiness before a DR test has to find the gap for you.
Frequently Asked Questions
Are SRLs mandatory on the current primary database?
SRLs are not used while the database remains in the primary role. Oracle recommends keeping them on the primary so it is immediately ready to receive redo after a switchover or failover. Broker-managed role transitions validate them on both sides, and Fast-Start Failover requires them on the primary.
How many SRL groups are required?
Calculate the count separately for each source redo thread. The required baseline is the number of primary online redo log groups in that thread plus one. If thread 1 has three ORL groups, it needs at least four SRL groups.
Do SRLs guarantee zero data loss with ASYNC transport?
No. SRLs persist redo that has reached the standby. ASYNC commits can complete before the redo arrives, so the RPO still depends on transport progress and the exact failure sequence.
Can an SRL simply be larger than the online redo log?
An SRL must not be smaller than the largest source online redo log. For a clean and predictable layout, use matching sizes rather than treating a larger file as the normal standard.
Is an ACTIVE SRL a problem?
Usually not. One active group for a receiving thread is expected. Investigate when completed groups cannot be archived or reused, no group is available for the next sequence, or the alert log reports an SRL error.
What Have You Seen in Production?
Have you seen a Data Guard configuration where transport looked healthy but SRL drift caused delayed apply or a switchover warning? Was it exposed by a redo resize, RAC thread change, FRA issue, broker validation or an actual DR test? Share the check that helped you find it.
Official References
- Oracle Database 19c Data Guard - Redo Transport Services
Official guidance for managing standby redo logs, sizing, the per-thread ORL plus one requirement, RFS behavior and archived redo fallback. - Oracle Database 19c Data Guard Broker - Managing Configuration Members
Official guidance for configuring SRLs on primary and standby databases, preparing for switchovers and failovers, and Fast-Start Failover requirements.
