[This is preliminary documentation and subject to change.]
The RSM database handles an additional inconsistency problem. It is possible that a system failure can cause an incomplete write operation of the RSM data file. This occurs when some sectors are written to disk and some are not at the time of the system failure. This causes the RSM data file to be inconsistent within itself. The lost data might not be available in the data file or in the journal, since it includes records that might have been moved due to space allocation and so forth. Also, the RSM database cannot determine which data might be lost. To prevent inconsistency in this case, RSM uses a data file replica (NTMSDATA.BAK). The database keeps the replica up to date using a slow update of all modified data file clusters. It does not do immediate updates, because it this would increase the latency of a database commit operation. However, it synchronizes subsequent updates to the database with the completion of the slow update of the replica. Therefore, either the data file or the replica is consistent at all times. The database determines which is consistent by comparing the incarnation number to the index file's incarnation number. This is possible since the incarnation number of the index file is flushed to disk after the successful completion of the data file and index file update flush. This ensures that the data file and index file is on disk prior to rolling the incarnation number of the index file, indicating a completed update.
The database recovers using the replica as follows: