Product Information > JADE Synchronized Database Service (SDS) Administration Guide > Chapter 1 - Administering a JADE Synchronized Database Service (SDS) Environment > Restart Recovery

Restart Recovery

On SDS secondaries, the restart recovery mechanism ensures that integrity is re-established after restart, by applying journal updates beginning at the farthest-back Log Sequence Number (LSN), where the oldest incomplete transaction starts, and it continues through journals until all available changes have been applied (this ensures that the files are synchronized with the journals). The recovery then performs a "revert" pass, which undoes the effects of all transactions back to farthest back LSN, which ensures that the database is in a consistent state before resuming replay.

Native secondaries interrogate the DisableNativeRedintegrateOnRestart parameter and RPS secondaries interrogate the DisableRPSRedintegrateOnRestart parameter. These parameters both default to true. (These parameters can be defined in the [SyncDbService] section of the JADE initialization file.) Secondary restart recovery is disabled by default for native secondaries, and enabled by default for RPS secondaries.

To enable secondary restart recovery for native secondaries, set the value of the DisableNativeRedintegrateOnRestart parameter to false; conversely, to enable secondary restart recovery for RPS secondaries, set the value of the DisableRPSRedintegrateOnRestart parameter to false.

JADE implements an SDS secondary restart recovery audit. These journals, which have the .rlog extension, are numbered created, written, and removed the same as the normal .log journals. When a block in a file is made free, information from the block header is audited to the .rlog journal so that the "revert" pass can correctly recreate block state when reversing that free operation, going backwards undoing the effects of the transactions.

The .rlog and .log journals are structurally identical, and can be selected for dumping using the JADE Database utility (jdbutil). The .rlog journals have no operational requirements; they are created and removed as necessary by secondary replay and restart recovery.