Browse Prior Art Database

Circular Database LOG With Allocation and Deallocation

IP.com Disclosure Number: IPCOM000099271D
Original Publication Date: 1990-Jan-01
Included in the Prior Art Database: 2005-Mar-14
Document File: 6 page(s) / 239K

Publishing Venue

IBM

Related People

Fichtner, LG: AUTHOR

Abstract

Disclosed is a method to implement a circular Log using the OS/2* file system with dynamic and deallocation of file space as required by the against the database. The design detailed herein been implemented in the Database Manager for OS/2 Edition 1.2.

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

Circular Database LOG With Allocation and Deallocation

       Disclosed is a method to implement a circular Log using
the OS/2* file system with dynamic and deallocation of file space as
required by the against the database.  The design detailed herein
been implemented in the Database Manager for OS/2 Edition 1.2.

      The concepts detailed in this article could also be to any type
of logging or queuing of data elements
        the data elements are written to disk
        sequentially,
        the oldest data elements are discarded based on
        some criteria,
        the maximum amount of disk space required is
        large,
        the difference between the maximum and minimum
        amount of disk space required is significant, and
        the current amount of disk space required varies
        between the minimum and maximum over time.

      A Database Management System requires a Log to assure the
consistency and of a database.  All changes made to a are first
recorded in the Database Log the actual changes are made to any of
the tables.  The Database Log is used to undo changes made to a
database by an aborted during normal system operation.  The Log is
also used if a system failure the recovery of a database.  When a is
restarted after a system failure, the Log is used to undo the changes
made to database by uncompleted transactions and to that the changes
made by committed are recorded in the database tables.

      In the first two releases of the OS/2 Database (OS/2 Extended
Edition 1.0 and 1.1), the Log was implemented as a linear log file.
log records are written to a single linear in a sequential manner.
Since the OS/2 file only allows file space to be added to the of a
file, the Database Log is extended in a fashion (up to a database
configuration when additional file space is required. the maximum
size of the Database Log is all update activity against the database
be quiesced since no log records may be to the Database Log for
additional updates.

      Whenever all update activity against a database the Database
Manager assures that the database on disk are updated and then
truncates the Database back to its primary allocation size.  The log
records in Database Log are no longer needed so the Database Log is
to an empty state.

      This article describes why a linear Database Log design not
adequate for the third release of OS/2 Extended and details a unique
and novel feature of the new Database Log design.

      The linear Database Log design that is implemented in first two
releases of OS/2 Extended Edition has a drawback in a high
transaction rate environment continuously overlapping transactions.
The Database Log guaranteed to grow to its maximum size which
requires all update activity against the database be quiesced. means
that periodically all transactions currently the database must either
prematurel...