Browse Prior Art Database

Eliminate Unnecessary Logging of Database Manager Index Manager Transactions

IP.com Disclosure Number: IPCOM000103710D
Original Publication Date: 1993-Jan-01
Included in the Prior Art Database: 2005-Mar-18
Document File: 4 page(s) / 164K

Publishing Venue

IBM

Related People

Sirkin, MJ: AUTHOR [+2]

Abstract

In the current implementation of Database Manager most of the logging done by Index Manager is duplication of work already done by Data Management Services (DMS). There is no need to perform this work, as it can be determined from the log records already placed in the log file by DMS.

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

Eliminate Unnecessary Logging of Database Manager Index Manager Transactions

       In the current implementation of Database Manager most of
the logging done by Index Manager is duplication of work already done
by Data Management Services (DMS).  There is no need to perform this
work, as it can be determined from the log records already placed in
the log file by DMS.

      There are several benefits to this logging scheme:

      1) Performance.  Logging is one of the slower operations
performed by Database Manager (due to the heavy I/O demand).
Currently, most of the log records placed in the log file are by
Index Manager.  Eliminating these insertions should greatly help
performance.

      2) Space.  Log records can take up a great amount of space on
disk, and eliminating them will decrease log space requirements.

      3) Average transaction size.  Users of Database Manager must be
careful to keep the size of their transactions small enough such that
one transaction does not fill up the log.  Under this scheme, many
more database operations can be done before a log will fill.  This
will aid database programmers.

      Database Manager (IBM Extended Services) uses a write-ahead
logging convention.  Each transaction is written in a log which is
stored on disk before the transaction is actually written to the
database.  In this way, if a system crashes, the database can be
restored to a consistent state when the system is restarted.

      The current design of index manager dictates that we rebuild
the indexes physically.  In other words, when an index is rebuilt
using a log (for example, during recovery), the index will be a
mirror image of the original index when the recovery is complete.
This approach is unnecessary.  All that is required for a rebuilt
index is that it have all of the correct data items in the correct
order, and that the index items point to the correct data records.

      The current scheme requires a lot of record keeping.  This
proposal is to keep indexes logically the same.  In this new scheme,
every piece of data is reliably in the index, but its physical
location does not matter.  This satisfies the above criteria.

      There is a cost associated with this new scheme.  During redo
and undo operations, Index Manager must have all operations driven by
DMS when DMS reads the row-based log records.

      It should be mentioned that not all of Index Manager's log
records can be eliminated using this scheme.  For example, the create
and delete index functions would still require a minimum of logging.
In this new scheme, however, only a start and end log record would
need to be kept for each of these operations.  All that really
matters is that the create or delete index operation started and/or
finished.  If, for example, a workstation crashes while a create
index operation is taking place, the index can be deleted.  If the
log manager sees the end of c...