Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Log Record Method to Reduce Risk of Overflowing Database Log during Rollback

IP.com Disclosure Number: IPCOM000106836D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 123K

Publishing Venue

IBM

Related People

Bezviner, DE: AUTHOR [+3]

Abstract

Disclosed is a method for reducing the amount of log space required by index node splits and node deletions that occur during Rollback, thereby reducing the chance of Rollback failure due to a "log full" condition.

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

Log Record Method to Reduce Risk of Overflowing Database Log during Rollback

      Disclosed is a method for reducing the amount of log space
required by index node splits and node deletions that occur during
Rollback, thereby reducing the chance of Rollback failure due to a
"log full" condition.

      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.  Compensation log records are written during the undo
pass.  In order to guarantee rollback of transactions, some log space
is reserved for these compensation log records.

      Sometimes an index structure must be modified during an undo
pass.  Log records for this are very large, up to 4000+ bytes each.
There is no way to predict how many times an index structure will
need to be modified, so there is no way to guarantee that enough log
space is reserved for these log records.  If the log becomes full,
the rollback will fail and the database must be temporarily shut down
and recovered.

      To provide context for the disclosed method, it will be
necessary to briefly explain the processing of Index Structure
Modifications (ISM's) which occur during Undo by Database Manager*
before discussing this disclosed method.  For example, an ISM is a
node split or node deletion.

      Since ISM's are not actually undoing an operation (they modify
the index structure so that some index operation can be undone), the
ISM's log records are written using forward log records.
Furthermore, these log records are written from forward log space,
just as normal log records, since they are unpredictable and no log
space is reserved for them in advance.  Also, space is reserved for
compensation records in exactly the same manner as forward log
records written during forward processing.  Thus, they can be undone.

      Log records for an ISM, and the log record for the Undo
operation that caused the ISM, are written within a Backout-free
Interval; that is, once the interval completes, no log records within
the interval will ever be undone.  These log records will be undone,
however, if the backout free interval did not complete successfully
(the Undo operation is also logged with a forward log record).  The
backout free interval containing the ISM and Undo log record is ended
with an End Backout-free Interval log record.  This End Backout-free
Interval log record, when written during Undo, has the same back
pointers as a Compensation log Record (CLR).  Thus, the entire
Backout-free Interval is, in effect, a CLR.

      If a Logfull condition occurs when attempting to write a log
record for an ISM, the log file is extended, even past its configured
limits, if necessary, to make room for the log record.  It may not be
possible to extend the log file enough, due...