Browse Prior Art Database

Use of File Creation Log Sequence Number during Database System Restart

IP.com Disclosure Number: IPCOM000110016D
Original Publication Date: 1992-Oct-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 2 page(s) / 81K

Publishing Venue

IBM

Related People

Ballard, DJ: AUTHOR [+2]

Abstract

As described in "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging" by Mohan, et. al., OS/2* Database Manager uses a two-pass database restart method (redo, undo), skipping an analysis pass. Since one function of an analysis pass is to remove from processing log records belonging to files subsequently returned to the operating system, one must provide such a function in a two-pass method. This disclosure shows how the use of a File Creation Log Sequence Number (LSN) provides such a function.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Use of File Creation Log Sequence Number during Database System Restart

       As described in "ARIES: A Transaction Recovery Method
Supporting Fine-Granularity Locking and Partial Rollbacks Using
Write-Ahead Logging" by Mohan, et. al., OS/2* Database Manager uses a
two-pass database restart method (redo, undo), skipping an analysis
pass.  Since one function of an analysis pass is to remove from
processing log records belonging to files subsequently returned to
the operating system, one must provide such a function in a two-pass
method.  This disclosure shows how the use of a File Creation Log
Sequence Number (LSN) provides such a function.

      Throughout the lifetime of a table, log records are written
reflecting updates made to that table.  When the table is dropped (or
replaced, in the case of a reorg, or truncated, in the case of an
import/replace), those log records are no longer valid, and should be
discarded in the event of a database restart.  Also, since it is
possible after a table is dropped for its operating system file to
later be reused for a different table, it must be ensured that a
given log record actually applies to the current version (if any) of
the file it references.  Data integrity errors can occur otherwise.

      During redo, for page-oriented log records such as INSERT
RECORD, the solution is straightforward.  For these types of log
records, the information required to determine if the log record
should be applied to the page can be determined directly from the
affected page.  There are various states the page can be in:
-    The page exists, is initialized and lsnLogRecord<=lsnPage.  For
this case, the log record has already been applied to the page.  It
is possible in this case that the log record actually applies to an
earlier version of this file, but the LSN comparison is still valid
and produces the desired results.
-    The page exists, is initialized and lsnLogRecord>lsnPage.  For
this cas...