
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-memoryinitialization.TheactionsthatOnLinetakesasitimplements
fast recovery can be summarized in four steps:
1. Returnalldiskpagestotheirconditionat 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 recordin the logicallog 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 isreturned to a consistent state: all committed
transactions are restored and all uncommitted transactions are rolled back.
Fast Recovery and Logging
If adatabase uses buffered logging, some logical logrecords associated with
committed transactions might not be written to the logical log at the time of
thefailure.If this occurs, fastrecoveryisunableto restorethosetransactions.
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.
Comentarios a estos manuales