Filter
Top Products
4-40 IBM Informix OnLine Database Server Administrator’s Guide
Fast Recovery and Logging
The aim of fast recovery is to return OnLine to a consistent state as part of
shared-memory initialization. The actions that OnLine takes as it implements
fast recovery can be summarized in four steps:
1. Return all disk pages to their condition at the time of the most-recent
checkpoint using the data in the physical log. (See Figure 4-4 on
page 4-41.)
2. Locate the most-recent checkpoint record in the logical log files. (See
Figure 4-5 on page 4-42.)
3. Roll forward all logical log records written after the most-recent
checkpoint record. (See Figure 4-6 on page 4-43.)
4. Roll back transactions that do not have an associated COMMIT
(commit work) record. (See Figure 4-7 on page 4-44.)
The result is that OnLine data is returned to a consistent state: all committed
transactions are restored and all uncommitted transactions are rolled back.
Fast Recovery and Logging
If a database uses buffered 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 is unable to restore those transactions.
Fast recovery can only restore transactions with an associated COMMIT
(commit work) record stored in the logical log or on disk. (This is why
buffered logging represents a trade-off between performance and data
vulnerability.)
For databases that do not use logging, fast recovery restores the database to
its state at the time of the most-recent checkpoint. All changes made to the
database since the last checkpoint are lost.