ZDL Requirements
For enabling ZDL it is necessary to fulfill prerequisites listed in this page. Most prerequisites are related and linked to each other.
Not complying to Requirements listed here can have negative effect(s) on existing production database and/or improper ZDL functionality.
1. Network
You must consider and be aware that network Bandwidth and response time may change during the day for example due to batch jobs, backups etc …
1.1 Bandwidth
ZDL replication needs additional network bandwidth on top of existing archivelog synchronization. Total network bandwidth needed for archivelog and ZDL synchronization is two times of your peak archivelog generation rate on the primary database. To identify current archivelog generation rate, you can run following SQL:
select to_char(trunc(l.first_time,'hh24'),'yyyy-mm-dd hh24:mi') date_time
, count(l.recid) archivelog_count
, round(sum(l.blocks*l.block_size)/1024 /1024) MB
from v$archived_log l
where l.first_time > sysdate-14
group by to_char(trunc(l.first_time,'hh24'),'yyyy-mm-dd hh24:mi') order by date_time desc;This will give you an hourly archivelog generation rate for past 2 weeks (column “MB”).
To determine needed network bandwidth to standby host, you need to take the peak MB/hour result and multiply it by 2. This will be the total network bandwidth needed for ZDL replication.
If your network cannot provide sufficient bandwidth, you will experience ZDL interruptions. Archivelog synchronization is prioritized over ZDL and if there are any issues with ZDL replication, it will be automatically shut down. After the interruption, ZDL will need to be manually enabled again.
1.2 Response time and stability
Network response time should be around or less than 50 ms. Network needs to be without frequent interruptions. ZDL has built-in mechanism for recovering from short time interruptions (shorter than 1 minute). Any longer interruption can result in ZDL re-initialization, which in turn means a fresh copy of all redo members to standby server. Depending on your network bandwith and redo member size, this can mean tens of minutes util ZDL re-initializes after interruption, reducing the RPO.
2. Primary Redo Log Configuration
Primary Database redo log size, switch rate, location and naming convention play an extremely important role for ZDL replication.
2.1 Redo log disk subsystem
Since ZDL produces some additonal overhead, it is necessary and required that primary redo log files are placed on either high-performance SSD or NVME disk drives. Running ZDL feature on primary redo located on slow disks may result in additional performance issues for your production database.
2.2 Redo log switch rate
Determine your redo log switch rate by running on primary database:
select to_char(trunc(l.first_time,'hh24'),'yyyy-mm-dd hh24:mi') date_time
, count(l.recid) archivelog_count
, round(sum(l.blocks*l.block_size)/1024 /1024) MB
from v$archived_log l
where l.first_time > sysdate-14
group by to_char(trunc(l.first_time,'hh24'),'yyyy-mm-dd hh24:mi') order by date_time desc;Column “ARCHIVELOG_COUNT” shows the number of logswitches per hour. The recommended maximum rate is up to 10 logswitches per hour (can be up to 20 redo switches per hour in peaks). If your logswitch rate is higher, you should increase your redo member size accordingly.
For example, if your redo log switch rate is 40 per hour and your redo member size is 500M, you should increase the redo member size to 2GB to reduce the log switch rate to 10 per hour. The exact size and log switch rate after resize can vary, you should always try to increase in small increments and observe the impact.
ZDL Does NOT replace archivelog synchronization. Dbvisit will still need to perform regular logswitches for minimizing RPO and transferring archivelogs to standby database
2.3 Redo log member size and group count
ZDL needs to be initialized from time to time (for example after dbvagentmanager restart). In such situations, redo member from each redo group will need to be copied to standby. For example, if database has 3 groups with 1GB member size:
SQL> select group#, bytes/1024/1024 from v$log;
GROUP# BYTES/1024/1024
---------- ----------------
1 1024
2 1024
3 1024Then each time ZDL initializes, it will need to copy 3GB to standby host. This can take some time depending on your network bandwidth. Our recommendation is that the initializationn should not exceed 10 minutes (due to reduced RPO during the initialization).
Following the example above, if we have 3 groups and 1GB redo member in each and network between primary and standby is 100Mbit/s then the time needed to initialization would be:
[3] (three redo groups) * [1024] (single redo member size) : [100 / 8] (conversion of Mbit/s to MBytes/s) = 245,76 seconds
This example result is satisfactory, around 4 minutes for ZDL initialization is perfectly fine.
You must consider and be aware that network Bandwidth may change during the day for example due to high load, batch jobs, backups etc …
You will need to balance redo log size and redo log switch rate to achieve result which would be optimal for you.
2.4 Redo log member location on ASM
Dbvisit can use only primary redo log member(s) which is located on the filesystem. If your primary database and online redo members are on ASM, you will need to have at least one redo log member from each group to be located on local xfs or ext4 filesystem. Follow this guide to create a separate redo log member for each group on filesystem:
3. Primary Database Performance
This section is a recommendation only. You can deploy ZDL on any environment and any production database, you will however need to acknowledge the performance overhead consequences.
ZDL has an additional overhead on primary database for the “log file sync” wait event. Before implementing ZDL, it is suggested to evaluate your current production database performance and determine your current “log file sync” wait event level.
It is not recommended to implement ZDL on production databases which already have sub-optimal performance due to “log file sync” wait event or any other wait event (wait time is greater than execution time).
For determining the current “log file sync” wait event performance and we recommend to setup and run statspack reports as per My Oracle Support KB:
Statistics Package (STATSPACK) Guide KB152019
The statspack reports should be scheduled in 30mins - 1 hour intervals and should cover busiest periods of the day. In these peaks, the production database log file sync wait event Average Wait should be below 10 ms and it’s %total call time should be less than 35%.
Example top 5 Timed Events from statspack report on test OLTP database during busy period:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
log file sync 645,878 4,708 11 55.1
CPU time 3,698 43.3
SQL*Net message to client 710,550 27 0 .3
library cache: mutex X 4,157 25 6 .3
enq: TX - row lock contention 4,421 20 5 .2We can see the average wait time for log file sync is 11ms and database spent over 55% time on this wait event. In this specific example case, implementing ZDL could result in decreasing database performance even more and / or in ZDL synchronization interruptions. This result interpretation is that it would not be recommended to implement ZDL synchronization for this production database.
Statspack results can vary depending on database workload type (OLTP, Reporting ..). If you are not sure how to interpret statspack results, contact Dbvisit Support and provide them with statspack reports.
4. OS Requirements
ZDL relies heavily on OS time when keeping the redo log synchronization alive and it’s now even more important than before to ensure primary and standby databases host times are in perfect sync. Because of this, we highly recommend to run ntpd or chronyd daemons on Linunx systems to ensure proper time synchronization.
5. Dbvisit ZDL License
ZDL is the only feature in Dbvisit StandbyMP product which requires a separate license on top of the usual Dbvisit StandbyMP license. ZDL can be used only if this extra license is purchased. Whether your license is ZDL enabled, can be checked at any time in dbvcontrol dashboard ACTIONS pane for existing configuration:
There is clear indication if ZDL option is included in the license.
It is also possible to see whether ZDL option is enabled when creating DDC for the first time (Create Configuration File (DDC) ) :
same goes for dbvctl or dbvcli: