-
When media recovery is required, the image-copied version of the entity
is reloaded and then a redo scan is initiated starting from the media
recovery redo point.
-
During the redo scan, all the log records related to the entity being
recovered are processed and the corresponding updates are applied,
unless the information in the image copy checkpoint record's
dirty_pages list or the LSN on the page makes it unnecessary.
-
Unlike during restart redo, if a log record refers to a page that is not in
the dirty_pages list and the log record's LSN is > the LSN of the
begin_chkpt log record of the image copy checkpoint, then that page must
be accessed and its LSN compared to the log record's LSN to check if the
update must be redone.
-
Once the end of the log is reached, if there are any in-progress
transactions, then those transactions that had made changes to the entity
are undone.
-
Page-oriented logging provides recovery independence amongst objects.
Since in ARIES, every database page's update is logged separately, even
if an arbitrary database page is damaged in the nonvolatile storage and
the page needs recovery, the recovery can be accomplished easily by
extracting an earlier copy of that page from an image copy and rolling
forward that version of the page using the log.
-
Individual pages of the database may be corrupted not only because of
media problems, but also because of an abnormal process termination
while the process is actively making changes to a page in the buffer pool
and before the process gets a chance to write a log record describing the
changes.
-
Writing CLRs for media recovery is a very good idea even if the system is
supporting only page locking.
