DDR Log Snooping - DDRBLOCK phase started

Technote (FAQ)


Question

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.

Cause

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.

Answer

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!

EXAMPLE :
LTXHWM 40
LTXEHWM 50

Recommendation change this to the following:

LTXHWM 40
LTXEHWM 60 or 70 to avoid the DDRBLOCK

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Informix Servers

Software version:

11.5, 11.7, 12.1

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:

1641776

Modified date:

2013-06-24

Translate my page

Machine Translation

Content navigation