DDR Log Snooping - DDRBLOCK phase started, userthreads blocked Although user transactions are blocked while the server is in DDRBLOCK
mode, ER activity is allowed to continue. During this time, ER attempts process transactions to advance the Replay Position and remove the risk
of a log overrun.
If the database server comes close to overwriting a logical log that Enterprise Replication has not yet processed (i.e. the Current ID / Pos is close to the Replay ID / Pos), Enterprise Replication enters DDRBLOCK mode. Close is approximately determined when the Current ID / Pos is more than LTXEHWM plus the maximum logical log size ahead of the Replay ID / Pos.
Although user transactions are blocked while the server is in DDRBLOCK mode, Enterprise Replication activity is allowed to continue. During this time, Enterprise Replication attempts process transactions to advance the replay position and remove the risk of a log overrun. Enterprise Replication can usually resolve the cause of the DDRBLOCK state.
Quite some effort has been put into avoiding DDRBLOCK mode and the Current ID overwriting the Replay ID in recent releases, mostly into preventing ER consuming lots of logical log space itself.
On an ER source it is recommended to have LTXEHWM at least 30 (if not 50) above LTXHWM to allow long transactions to rollback well before reaching LTXEHWM, since ER forces SENDQ spooling at about 75% of the DDRBLOCK limit, which will cause additional logging, thus adding again to the danger of DDRBLOCK!
Recommendation change this to the following:
LTXEHWM 60 or 70 to avoid the DDRBLOCK