We're here to help!

Description

You are able to modify the behavior of dbvisit standby daemon by several variables in DDC file:

DMN_DBVISIT_INTERVAL
DMN_MONITOR_INTERVAL
LOGSWITCH

These 4 are the most important. Variables above are for primary site, there are same variables for standby, they just have "_DR" added to their name (except for LOGSWITCH which is not valid for standby).

So now, how does this work? If you are using dbvctl daemon it is important to realize, that daemon does actually 2 tasks on you server. Each task has its own timer, although daemon itself is single process.

1) Monitor

Once daemon process is started, it will start checking for new archivelogs. The interval for these checks is actually value of DMN_MONITOR_INTERVAL. The default value is 5, so by default daemon will check each 5 seconds if there is new archlog.

For each check, daemon will utilize database connection. Once new archlog is found in database, dbvctl process for sending / applying it is triggered.

2) Dbvctl schedule

Independent on the monitor schedule, daemon will run dbvctl command for sending / applying logs in the intervals specified by DMN_DBVISIT_INTERVAL / DMN_DBVISIT_INTERVAL_DR (specified again in seconds).

This action behaves as usual dbvctl -d command and as such, it has high dependency on another DDC parameter:

LOGSWITCH

Which determines, whether logswitch will occur on the source database when dbvctl is run. Possible values for LOGSWITCH are: Y, N, I. The complete description of LOGSWITCH parameter can be found here:

 

https://dbvisit.atlassian.net/wiki/display/DS8QSG/Dbvisit+Standby+Configuration+(DDC)+-+Reference

 

When we would set parameter DMN_DBVISIT_INTERVAL to "600" and LOGSWITCH would be set to "Y" it would mean, that we would force a log switch on the primary database each 10 minutes (similar to setting database parameter archive_lag_target).

 

 

It is very important to tune and setup the timing for dbvisit daemon properly. For Dbvisit Standby solution, the only thing which determines the amount of lost transactions (data) when DR event strikes, is the frequency of the archive log switch and their shipping frequency to standby site.

 

When using settings mentioned above, you are able to setup reasonable interval for log switching and shipping for your standby solution.

 

 

You have OLTP database with constant load. Before installing standby solution, you can observe around 2-3 log switches per hour. New business requirements demand, that standby solution is used and the permitted data loss is 10 minutes.

 

With Dbvisit Standby, you can use following settings:

DMN_DBVISIT_INTERVAL=600
DMN_MONITOR_INTERVAL=0
LOGSWITCH=Y

With such settings, daemon would run dbvctl -d with forcing a logswitch and send that particular log to the standby database each 10 minutes. We would disable the daemon monitor (DMN_MONITOR_INTERVAL=0) - there is no need to run it as we know, that in 99% of cases there will not be any new archivelog before the next run of daemon dbvctl and it would be waste of resources to keep the monitor checking.

 

 

You have OLAP (Warehouse) database with inconsistent log switch frequency (during day almost no transactions, during night lot of them due to data refresh jobs from source OLTP database). 

 

We can use following settings:

DMN_DBVISIT_INTERVAL=600
DMN_MONITOR_INTERVAL=60
LOGSWITCH=Y

The resulting behavior with these settings is, that monitor will run each minute and if there is new archlog, it will send it to standby. This is useful for the nightly batch jobs, as the log switch frequency will for sure increase and there might be more log switches in 10 minutes.

 

Independently, dbvctl -d will be run each 10 minutes forcing a logswitch and sending the logfile to standby - this will help us during the day when the transaction load is almost none and we will still keep our standby in-sync.

 

 

Now you can perhaps have an idea about setting dbvctl to be run each minute with logswitch to have almost no data loss at all. We definitely do not recommend this, as logswitch and sending archlog to standby consumes really a lot of system resources at one time.

 

If you have for example also compression enabled, you have to consider, that file needs to be packed, sent, unpacked and applied within one minute - this can be very tight timeframe.

 

Oracle states, that healthy database logswitch frequency is about once per 15-20 minutes. Sometimes for standby solution, this interval can be unacceptable for business. So it is perfectly fine to go for 10 minutes interval. If you have well tuned, monitored, healthy and resource rich environment, you can perhaps even go for 5 minutes. But going for anything less is not advisable.