We're here to help!

Does Dbvisit Standby have a concept similar to Data Guard Protection Modes such as Maximum Availability, Maximum Protection & Maximum Performance?

Not per se. A decision must be made on the maximum time that the standby database may be behind the primary database. This is a business decision, but certain factors play a key role. These are:

• Speed of the network.
• Activity on the database.
• Speed of the disks.
• Compression method chosen and CPU power to compress and uncompress archive log files.

A good recommended time frame is to schedule Dbvisit Standby every 5-10 minutes on both the primary and standby servers. For example:

On source, crontab scheduled in case of version 7 and if daemon is not used if its version 8:

# Dbvisit - Standby Database Technology from Dbvisit Software Limited
00,10,20,30,40,50 * * * * /usr/dbvisit/standby/dbvisit PROD >>/dev/null 2>&1

On target/standby, crontab scheduled in case of version 7 and if daemon is not used if its version 8:

# Dbvisit - Standby Database Technology from Dbvisit Software Limited 
 05,15,25,35,45,55 * * * * /usr/dbvisit/standby/dbvisit PROD >>/dev/null 2>&1

It is a common requirement (or service level agreement) that a standby database be kept less than n minutes behind its associated primary. More accurately, the requirement is normally a specification of the amount of the data that is allowed to be lost in the event of a disaster on the primary.

This generally means careful consideration of redo log sizes, or some scheduled task to archive the current log file at regular intervals. From Oracle 9i forward a new init parameter was introduced to automate this. From the Oracle documentation:

Setting the ARCHIVE_LAG_TARGET Initialization Parameter When you set the ARCHIVE_LAG_TARGET initialization parameter, you cause Oracle to examine an instance's current online redo log periodically. If the following conditions are met the instance will switch the log:

• The current log was created prior to n seconds ago, and the estimated archival time for the current log is m seconds (proportional to the number of redo blocks used in the current log), where n + m exceeds the value of the ARCHIVE_LAG_TARGET initialization parameter.
• The current log contains redo records.

  In an Oracle Real Application Clusters environment, the instance also kicks other threads into switching and archiving logs if they are falling behind. This can be particularly useful when one instance in the cluster is more idle than the other instances (as when you are running a 2-node primary/secondary configuration of Oracle Real Application Clusters).

Initialization parameter ARCHIVE_LAG_TARGET specifies the target of how many seconds of redo the standby could lose in the event of a primary shutdown or crash. It also provides an upper limit of how long (in the number of seconds) the current log of the primary database can span. Because the estimated archival time is also considered, this is not the exact log switch time. The following initialization parameter setting sets the log switch interval to 30 minutes (a typical value).

ARCHIVE_LAG_TARGET = 180

Donna Zehl December 15, 2015 10:16