This article is a description of what can cause a DDR Block situation and some methods to configure an instance so the DDR Block situation can be avoided.
DDR Block mode causes:
ER queue data sbspace or grouper paging sbspace is full:
In this scenario, ER may stall waiting for more space to be added to these sbspaces. If space is not added promptly, ER may run into DDR Block state.
Replicating large transactions can cause DDR Block state:
Large transactions typically consume more resources in ER as well as in other components of the server like lock resources. Large transactions may cause excessive IO in ER to optimize memory usage. We do paging activity in grouper and we may spool transaction to sendq sbspace. They also consume more resources at the target server while applying -- like lock resources. Target server may need double the amount of lock resources as we may also update delete tables if you are using timestamp or stored procedure conflict resolution rule. Also some reason if target server needs to retry the large transaction -- due to lock timeout or deadlock error -- replication may still slow down due to the large transaction retry operation.
Resolving the problem
Some of the other tips to avoid DDR Block situation:
- If possible, have 24 hours worth of log space
- Avoid log file switching too often (< 30 minutes)
- Keep log files about the same size
- Keep some distance between LTXHWM/LTXEHWM (40/60)