Introduction

What is Dbvisit Standby?

Dbvisit Standby automates the synchronisation of a hot standby database at a remote or local location. A standby database is like having an online hot backup of your database instantly available 24x7. There is no need to restore in the event of a disaster (which is very time consuming), as there is instant data recovery and database recovery. It is possible to switch over to the standby database in a matter of minutes to allow business continuity in an emergency. No other software is required to replicate the primary database onto a separate standby server. 
An overview of Dbvisit Standby is presented in figure 1.

Figure 1

The 3 core functions provided by Dbvisit Standby is Log Extraction, Transport and Log Apply which are described in section below

An overview of Dbvisit Standby architecture is presented in the figure 2 below:

Figure 2

From the diagram above we can summarize the core functionality of Dbvisit Standby as a 3-step process:

Log Extraction

Dbvisit Standby will extract the primary database archive logs from the database archive destination.  The following steps form part of the log extraction process:

• The latest archive logs will be extracted to be shipped to the standby
• A log switch will be performed if no new logs were generated since the last run
• Logs will be compressed if the compression option is selected
• If configured, Dbvisit Standby can also manage the archive logs on the primary server; example purge logs older than specified time

Transport

The second step in the process will be to copy these extracted archive logs to the standby site.  This transfer process is initiated from the primary server and the transfer process is secure.  The following steps form part of the log transfer process:

• The latest archive logs will be transferred using the Dbvisit Network (Dbvnet) or SSH (Unix Only)
• The connection between the primary and standby site is encrypted and secure
• Archive logs will be transferred in compressed format if required
• Checksum values are generated to ensure logs are transferred successfully

Log Apply

The third step in the process is where Dbvisit Standby applies the transferred archive logs to the standby database.  The following steps form part of the log apply process:

• On the Standby Server, Dbvisit Standby will pickup the transferred archive logs and apply them to the standby database
• If configured, Dbvisit Standby can also manage the archive logs on the standby server; example purge logs older than specified time

Data Protection and Data Loss considerations when using Dbvisit Standby

There are two important parts to take into account when using Dbvisit Standby.  The Oracle Database archive logs are used to keep the standby database up to date via the Oracle supplied recovery mechanism.  The standby database can only be updated using archived redo logs and, on static systems, this may require the forcing of log switches or archiving of current redo logs to ensure that the archived logs are available to keep the standby database up to date.  The process of sending and applying logs is fully automated as mentioned above.

The second important concept to understand is that Dbvisit Standby is schedule based - meaning that to allow for archive logs to be copied to the standby database and applied, schedules must be enabled.  

With the Dbvisit Standby versions, up to version 7, scheduling must be configured on the primary server to send archive logs to the standby database.  On the standby database server scheduling must be configured to apply logs to the standby database.

Schedule mechanisms can be Unix CRON schedules, or the Windows Task Schedular.  Dbvisit Standby also provides an alternative scheduling method built into the Web Based Interface.

When Scheduling Dbvisit Standby on the primary server, Dbvisit Standby can be configured to ship only newly created archive logs that have been generated by this database, or it can be configured to force a "log switch" to ensure there is a newly created archive log if one is not already created.  

Due to the nature of using Archive logs and schedules, during activation (failover) of a standby database, zero data loss cannot be guaranteed. If the schedules are configured on a regular basis, near zero data loss can be achieved, but not 100% zero data loss.  If the schedule is set to every 5 minutes, then potentially there could be a difference of 5minutes between the primary and standby database.  

For more details on scheduling please see this section: Dbvisit Standby Scheduling