HP 3000 Manuals HP 3000 Manuals
Post-Recovery Options
After a recovery has completed, there are three procedural options. The
option chosen determines the recovery procedure in the event of a
subsequent system failure. Together, the database administrator and
system manager or console operator should agree upon the best
post-recovery procedure to avoid confusion at recovery time. The options
available after recovery include:
1. Making a new database backup copy and starting a new log file from
the console with the CHANGELOG command.
In the event of a subsequent system failure, the new database
backup copy is restored and recovered against the new log file.
This option allows for a straightforward recovery procedure but
delays users from accessing the database until the new backup copy
has been generated.
2. Resuming transaction logging to the same log file using the
RESTART option without creating a new backup copy.
In the event of a subsequent system failure, the old database copy
is restored and recovered against the log file. This procedure is
the same as the original recovery, but takes longer due to the
additional log file records. Users can access the database after
the first system failure without waiting for it to be stored.
3. Initiating logging to a new log file without creating a new backup
copy.
In the event of a system failure, the old database copy is
restored and two recoveries are executed: the first using the old
log file and the second using the new log file. This procedure is
not recommended if option 2 is available.
Until a new database backup copy is generated, if you consistently
start logging to a new log file after a system failure, a total
recovery preceded by n failures requires n executions of the
recovery system.
The second and subsequent recoveries of a database against more
than one log file are not permitted unless the DBSTORE flag is
disabled. This is because the first modification reexecuted from
the first log file clears the DBSTORE flag from the database root
file. Subsequent calls to DBRECOV can only succeed by specifying
the >CONTROL NOSTORE option. Ensure that the log files are
recovered in the proper consecutive order.
NOTE For options 2 and 3, do not restart a log file before the database
has been recovered after a system failure because of the following
reasons:
* Some log records could have been lost in the system failure,
and
* The log file may not be consistent with the true state of
the database.
A recovery is necessary to bring the database and log file into
agreement before restarting the log process.