Consider for a moment the problem of restoring a database. This is usually required
after your machine stops unexpectedly. The current state of the machine is gone.
All of the programs that were running and making changes are gone.
Drestore only has the log file as a guide to what has happened. For this reason, the entries in the log file must be accurate and make sense. This section describes some of the problems that drestore sees as fatal errors in the log file.
The first problem is when logical RMSfiles are not closed when a program ends. Any RMSfile that is opened must be closed by the program using the RMSfile. When an RMSfile is opened for writing of any sort, an entry is recorded in the log file. When the RMSfile is closed (using dclose), another entry is recorded. The database restore command uses these entries to make sure that changes to an RMS definition file only occur when the RMSfile is not opened. If the log file has mismatched opens and closes, drestore cannot restore RMS definition file changes or anything that follows for that RMSfile.
A second problem is unended transactions. If a program completes a transaction but does not record the ending marker, or if a program terminates abnormally before writing an end transaction marker, the database restore command has no recourse but to invalidate the transaction and not restore it. Any following transactions that depend on the invalidated transaction must also be invalidated and not restored. Again, the rule to follow is:
If you begin a transaction, either end it or cancel it.
If a transaction does not complete, then it is invalid. Any records that the transaction modifies must be considered invalid. Any subsequent transactions that modify those invalid records must also be considered invalid, whether the subsequent transaction completes successfully or not. This newly invalidated transaction may in turn have modified other records, which must now be considered invalid. Transactions that depend on these newly invalidated records are then invalid. This process of finding dependencies between invalid transactions and invalid records repeats until no more invalid transactions are found.
The last problem has to do with keeping the log file in sync with the backups. Think of the log file and your backups as a matched set. When a new backup is done, a new log file should be started. The C/Base programs have no way of knowing when backups are done. That leaves it to you to keep your log file in step with your backups. After you do your backups and before you restart your applications, truncate the log files to zero length with the makelog(C-1) command. This insures that the before images of your data files will match the log file images when doing restores. Do not remove the log file, as all programs that perform logging must be able to open an existing log file.
The makelog command creates a transaction log file for a database or truncates an existing log file.