Archive log shipping is mature, reliable and well understood, but it also creates a recovery-point gap between the latest committed transactions on the primary and the last archive log available on the standby. In many environments, that gap is measured in minutes, with a five-minute RPO commonly accepted as the norm.
That was the challenge the Dbvisit team set out to address: reducing that exposure by adding continuous redo streaming alongside the existing archive log shipping process, with the aim of delivering a true sub-second RPO.
To understand the challenges involved and how they were overcome, I spoke with Vijay, our Head of Customer Services, Oracle ACE, long-time DBA and one of the technical contributors involved in the development of Standby MultiPlatform Zero Data Loss (StandbyMP ZDL). We discussed where the traditional 5–15 minute RPO comes from, how ZDL changes the replication model, what happens during failover, and the practical limitations and infrastructure considerations DBAs need to understand.
What follows is a technical look at that conversation rather than the marketing claim: what ZDL actually does, how it works alongside StandbyMP’s existing architecture, and what DBAs should consider before using it in an Oracle Standard Edition environment. Throughout this blog, I’ve included direct quotes from my conversation with Vijay to provide his technical perspective in his own words.
StandbyMP’s traditional Oracle replication model is based on physical archive log shipping. When an archive log is generated on the primary, StandbyMP transfers it to the standby and applies it there, so the recovery point depends partly on how frequently redo is archived and then transferred.
As Vijay explains, the key point is that a transaction does not reach the standby until the relevant archive log has been generated on the primary:
“Any transaction that is happening in your production database does not go to your standby database until this archive log is generated in your primary.”
Oracle protects committed transactions on the primary by writing redo into the online redo logs. However, until that redo has been archived and the archive log transferred, those committed transactions are not yet available for standby recovery. The primary can therefore be internally consistent while the standby still has a recovery-point gap.
“These transactions are available in your primary, but there’s no way these transactions are available in your standby... the moment I bring up my standby database will be based on the last archive log that was applied.”
Depending on database activity and archive-log configuration, that gap might be ten minutes, five minutes, considerably less or more. The underlying issue is the same: the most recent committed redo can still exist only in the primary database’s online redo logs.
At commit time, Oracle’s Log Writer process writes the relevant redo from memory into the online redo logs. Once that write is complete, Oracle can acknowledge the commit. That redo can then support instance recovery on the primary if the database crashes before the modified blocks have been fully written to the datafiles.
“Once the transaction is flushed into the redo log, it becomes a consistent transaction. Oracle will guarantee this transaction will be available even if my database is crashing and it comes back up.”
From a disaster recovery perspective, though, primary-database recoverability is not the same as standby recoverability. If the latest redo has not yet become an archive log and moved to the standby, the standby cannot recover through that part of the transaction history. That is the RPO gap ZDL is designed to address.
ZDL introduces a second replication path that operates independently of archive log shipping. Rather than waiting for an online redo log to be archived, it continuously synchronises the active redo from the primary to the standby server.
“We expand that boundary by independently syncing the current online redo log members of my primary database to my standby database.”
The important distinction is that the existing archive-log workflow continues to operate as before. ZDL does not replace it or change its role as the primary physical replication mechanism. Instead, the streamed redo provides an additional recovery source if the standby needs to be activated before the latest primary redo has been archived.
In practical terms, the two processes work together:
Archive log shipping continues to keep the standby physically synchronised.
ZDL separately streams the active redo to the standby server.
The streamed redo is retained rather than continuously applied.
During activation, StandbyMP can use that redo to recover beyond the last archive log already present on the standby.
This is what narrows the recovery point from minutes to sub-second levels in suitable environments.
At first glance, replacing archive shipping with continuous streaming might sound simpler, but that is deliberately not how ZDL has been designed. Vijay describes the two paths as “complementary and not redundant”. Archive log shipping remains the established and repeatedly verified mechanism used to maintain the standby, while streamed redo provides an additional recovery layer rather than becoming the sole replication mechanism.
“The redo streaming links along with the proven archive log shipping... archive log shipping is an established, battle-tested physical replication mechanism.”
There is also a resilience benefit to keeping both paths. If redo streaming is temporarily interrupted, the archive log replication mechanism still exists. When streaming is operating normally, it provides the additional redo needed to recover closer to the point of failure. So this is not a fundamentally different standby architecture; it is an extension of the existing one.
One of the most important technical distinctions is that streamed redo is not continuously applied to the standby database. It is stored independently on the standby server.
“The streamed redo is stored on my standby database server, and it’s not applied at all at any point in time... it lands independent from your normal StandbyMP synchronisation.”
That changes during activation. If the primary becomes unavailable, StandbyMP first has the archive logs already present on the standby, then uses the additional streamed redo to recover beyond the final archived log. Put simply, streaming protects the redo at the DR site, while activation consumes that redo to extend recovery.
“Streaming keeps the data safe at the DR site. It is the activation process that ensures the database is recovered to a point in time.”
This is where the terminology matters. ZDL uses asynchronous replication; it is not a synchronous commit architecture in which the primary transaction cannot be acknowledged until the standby confirms receipt. Synchronous protection can increase protection, but it also couples primary availability to standby availability and network performance.
“With respect to ZDL... the database does not know about the synchronisation at all. We synchronise independently.”
Because the process is asynchronous, a very small amount of redo can still be in transit at the instant of an unexpected failure. The practical objective is near-real-time protection, with the redo stream generally reaching the standby within a fraction of a second in a suitably performing environment.
“The streamed redo typically reaches the standby within a second of it being generated in the primary... the unrecovered tail is sub-second.”
That is an important distinction for DBAs. A sub-second RPO from an asynchronous architecture is not the same as an unconditional synchronous zero-loss guarantee.
Sub-second RPO is an architectural capability, but what can be achieved in practice still depends on the environment around the database. Vijay highlighted three main areas to evaluate:
Redo-log sizing and log-switch behaviour are also relevant. Too many switches or poorly sized redo logs may point to an underlying Oracle configuration issue that should be addressed independently of ZDL.
For Oracle Standard Edition DBAs, an obvious question is whether a tighter RPO comes at the expense of scarce compute resources. ZDL was designed to minimise that overhead, and Vijay says the requirements are low enough that they do not create a significant performance impact on most production databases.
“The requirements are so low that it does not create any significant performance impact on most production databases.”
The replication also operates independently of the database rather than introducing a synchronous acknowledgement dependency into the transaction path. Internal testing discussed in the interview has not shown a significant performance impact, although Vijay is careful to distinguish those observations from formal independent benchmarking.
That distinction is worth keeping in mind. DBAs should validate performance in the environment where ZDL will actually run rather than assume results measured elsewhere will apply identically. For existing environments, Vijay recommends a short proof of concept to assess network, storage and workload characteristics before production rollout.
Relatively little changes in the day-to-day model. ZDL extends an existing StandbyMP architecture rather than introducing a separate disaster recovery platform, so archive log replication, DR testing, switchover and standby-management operations remain in place. The additional operational element is visibility into the redo-streaming gap.
StandbyMP exposes information including:
This gives the DBA visibility of both the traditional archive-based recovery position and whether the streamed redo is successfully closing the remaining gap. As Vijay puts it:
“Even if [the archive-log gap] is five minutes, it doesn’t matter because this five minutes will be bridged by that zero.”
The phrasing is informal, but the point is useful: archive-log lag on its own is no longer the complete picture of effective recovery exposure.
Not every database requires a sub-second RPO, and that matters when the technology is being evaluated objectively. Traditional archive log replication remains a valid design where several minutes of potential transaction loss falls within the organisation’s accepted recovery objective.
“Traditional archive-log synchronisation works perfectly for most organisations.”
ZDL becomes more significant when reconstructing or reconciling several minutes of transactions would have a material business impact. That can include:
The architectural decision should therefore start with the business recovery requirement, not simply with the availability of a new replication capability.
ZDL is primarily an RPO technology. It improves how close the recoverable standby can be to the primary at the point of failure, but it does not remove the time needed to activate a standby, redirect applications, restart dependent services or restore the wider application stack.
“RPO tells me what the data loss that I can withstand. RTO tells me how fast I can bring the database or the application back to operation.”
A database might therefore have an RPO measured in fractions of a second while the full application has an RTO measured in tens of minutes. They are separate engineering problems and should remain separate in DR planning.
The most significant technical change introduced by ZDL is not that StandbyMP has abandoned archive log shipping. It has not. What changes is the point to which an Oracle Standard Edition standby can potentially recover after an unexpected primary failure.
The archive-log boundary is no longer necessarily the final recovery boundary. By preserving recent online redo independently at the standby site and consuming it during activation, StandbyMP can extend recovery beyond the last archive log and reduce the unrecovered tail to sub-second levels in appropriately configured environments.
For DBAs, that leads to a more useful architectural question than simply asking whether “zero data loss” is possible: how much data can the business afford to lose, what would it cost to recover that data manually, and can the infrastructure support the RPO the business actually requires?
If minutes of lost transactions are acceptable, conventional archive-log replication remains entirely reasonable. Where they are not, continuous redo streaming changes what is technically achievable on Oracle Standard Edition.
For DBAs evaluating the architecture, the next useful step is to review the StandbyMP Zero Data Loss data sheet and test ZDL against a representative workload or existing StandbyMP environment. A short proof of concept can validate network latency, storage performance, redo generation behaviour and achievable recovery exposure before deployment.