Bug 41882


GemStone/S 64 Bit,,,,,, 3.1, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6,, 2.4.5,,,,,,, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.4,, 2.3.1, 2.3,,,,, 2.2.5, 2.2.x, 2.2, 2.1.x, 2.0.x, 1.2.4, 1.2.x, 1.x



Recovery problems with free space

Under some circumstances, on recovery after unexpected shutdown, page demands
during recovery will be more than the space in the repository, and recovery
will fail.

The most likely scenario for this problem is when there is a large amount
of reclaim, and possibly a commit record backlog, and the system is not
able to write a checkpoint prior to shudown. If there is a large amount
of reclaim and other work done during the period of the commit record backlog,
all these records must be replayed from the tranlogs during recovery. During
the special conditions of recovery, used space cannot be freed for reuse.


Adding sufficient extent space will allow recovery to complete.

During tranlog restore, unlike during recovery, space can be reclaimed,
so restoring from backup and tranlogs will succeed.

To avoid this problem, the best way is to avoid the commit record backlog
and resulting shutdown in the first place.  Be especially careful about
commit record backlogs in the period following an MFC or other operation
that will cause a large amount of reclaim.

The default for STN_FREE_SPACE_THRESHOLD in earlier version is 1MB, which
is much too small; we suggest configuring this to be 1/1000 of the repository
size, which is the default in later versions. Depending on the rate of
page use, this larger value would be likely to allow the session holding
the CRB to be terminated, avoiding a shutdown, and increases the chance
that the checkpoint can complete.

However, note that if the repository is large, with a large amount of changes
that need to be written out as part of the checkpoint, it may take significant
time for a checkpoint to complete.  See also bug #41809.

Last updated: 1/15/14