Bug 44265

Bug: 44265

Impact:

Product:

GemStone/S 64 Bit

Versions:

3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1.X, 3.0.1, 3.0, 3.0.X, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.6, 2.4.4.5, 2.4.4.4, 2.4.X, 2.3.1.6, 2.3.X, 2.2.6.5, 2.2.5.4, 2.2.X, 2.x

Platform:

Fixed In:

3.3

Hot and warm standby subject to delay for large reclaim operations

Replaying of transaction logs may be delayed if a large reclaim occurs and required OOPs are in late in the page ordering.

A hot or warm standby system replays transaction logs from a primary stone, in sequence, including operations such as reclaims.  If there is a large reclaim in the primary stone, this reclaim must also be replayed in the standby, in order to reclaim the OOPs.  If these OOPs are reused and referenced in later transaction logs, the reclaim of these objects on the standby system must complete. This may take some time, during which time the standby will not be up to date.  While most such delays are short, for large reclaims on large systems this may cause a period in which the standby is not up to date.

Workaround

Ensure that reclaims complete as quickly as possible.  More frequent, smaller reclaims, such as by running MFC more frequently, will complete more quickly. If you have throttled reclaim on the primary, this will also cause reclaim to be throttled and slower on the standby system, since changes in GC configuration are transmitted to the standby along with application changes.