Every time that the administrator brings the database server to quiescent mode or online mode from offline mode, the database server checks to see if fast recovery is needed.
As part of shared-memory initialization, the database server checks the contents of the physical log. The physical log is empty when the database server shuts down under control. The move from online mode to quiescent mode includes a checkpoint, which flushes the physical log. Therefore, if the database server finds pages in the physical log, the database server clearly went offline under uncontrolled conditions, and fast recovery begins.
If a database uses buffered logging (as described in Buffered Transaction Logging), some logical-log records associated with committed transactions might not be written to the logical log at the time of the failure. If this occurs, fast recovery cannot restore those transactions. Fast recovery can restore only transactions with an associated COMMIT record stored in the logical log on disk. (For this reason, buffered logging represents a trade-off between performance and data vulnerability.)
For tables that do not use logging, fast recovery restores the table to its state at the time of the most recent checkpoint. All changes made to the table since the last checkpoint are lost.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]