Bug 27338

Bug: 27338

Impact:

Product:

GemStone/S

Versions:

6.7.2.1, 6.7.2, 6.7.1, 6.7, 6.6.5, 6.6.4, 6.6.3.3, 6.6.3.2, 6.6.3, 6.6.2, 6.6.1, 6.6, 6.5.8, 6.5.7.5, 6.5.7, 6.5.6, 6.5.5, 6.5.4, 6.5.2, 6.5.1, 6.5, 6.3.1, 6.3, 6.2.x, 6.2, 6.1.6, 6.1.5, 6.1.x, 6.0.x, 5.1.5.1, 5.1.5, 5.1.4, 5.1.3.1, 5.1.3

Platform:

All

Fixed In:

Missing tranlogs are not detected during restore

When executing "SystemRepository restoreFromCurrentLogs" to restore
tranlogs from the directory specified by the configuration parameter
STN_TRAN_LOG_DIRECTORIES, if a tranlog is missing from the middle of
the sequence, the system will not detect this and restore only up to
the missing tranlog.  If the system is then put into use via
"SystemRepository commitRestore", it will create a "fork in time"
which will result in lost data.

For example, imagine you are restoring a system that includes tranlogs
T1, T2, T3, T4, T5, and T6. Say that T3 is missing.  After committing
the restore, the system will only contain data up to T2.  Now assume
that new transactions are then committed which will go into tranlogs
T7 and T8 before the mistake is discovered.  At this point, your only
options are:

1.  Continue with the system as-is, loosing data in T3 through T6.
2.  Assuming T3 is recovered, you can restore the backup and replay
    tranlogs T1 through T6, loosing data in T7 and T8.  Since T7 and
    T8 were generated from a different "context" (T1 through T2) they
    cannot be replayed in a context that includes T3 through T6.

Workaround

Make sure during tranlog restore that the tranlog directory contains
all tranlogs needed.  Also, you should review the stone log to determine
which tranlogs were actually loaded and confirm that this is correct
before committing the restore and using the system.