Browse Prior Art Database

Continuous Transaction Processing with Overlapped Journals and Checkpoints

IP.com Disclosure Number: IPCOM000115645D
Original Publication Date: 1995-Jun-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 6 page(s) / 158K

Publishing Venue

IBM

Related People

Ouchi, NK: AUTHOR

Abstract

Disclosed is a mechanism that permits a transaction processing system to continue operation while taking the checkpoint of a database by overlapping the transactions that will go into one journal with accesses by transactions that will go into the new journal. The checkpoint is a pointer generation process. The mechanisms need to ensure data integrity are disclosed.

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

Continuous Transaction Processing with Overlapped Journals and Checkpoints

      Disclosed is a mechanism that permits a transaction processing
system to continue operation while taking the checkpoint of a
database by overlapping the transactions that will go into one
journal with accesses by transactions that will go into the new
journal.  The checkpoint is a pointer generation process.  The
mechanisms need to ensure data integrity are disclosed.

      Most databases provide availability by using a checkpoint, snap
shot, of the database and a running journal of all activities against
the checkpoint.  If the database fails or has to remove transactions,
the database  can be reconstructed by taking the checkpoint and then
applying the journal of transactions and "backing out" the
transactions to be removed.  The problem arises in taking the
checkpoint.  The database must be quiesced, all activity must be
suspended while the copy is made.  The 3990 TO copy and the rumored
STK functions permit rapid virtual checkpoint copies, but all
transactions must be completed and all new transactions must be
stopped until the checkpoint is completed.  Note that a transaction
may alter many data sets in the database and the database can be
accessed from several processors.  This is illustrated in Fig. 1
where transactions TA, TA' and TA" are applied to the database before
the checkpoint and are in the journal for the previous checkpoint.
Transactions TB, TB' and TB" are after the checkpoint and are in the
journal B that can be applied to the checkpoint B. Note that TA, TA'
and TA" had to complete before the checkpoint could be made and that
transaction TB, etc. cannot start until the checkpoint is complete.
The 3990 TO copy and the rumored STK function require that the
checkpoint pause cause a break in the  transaction processing.  The
mechanism described in this disclosure removes the requirement for
this break.

      Fig. 2 illustrates the basis of the disclosure.  While
transactions are processing, a virtual copy of the database is taken.
Transactions after the checkpoint, TB, TB', TB" are applied against
the copy of the database.  When all of the transactions that started
before the checkpoint complete, this image of the database and
journal form Checkpoint B against which Journal B may be applied.
Note that transactions continue to process during the entire
operation.

      The key observation is that transactions prior to the
checkpoint can alter data after the checkpoint but that transactions
after the checkpoint cannot alter data in the view used by the
transactions before the checkpoint.  This is illustrated in Fig. 3
where View A is the image seen by TA, TA', TA", etc. and View B is
the image seen by TB, TB', TB", etc.  The TAs can alter the data in
View B but TBs can change only data in View B.  However, if data are
changed by TBs, these data are invalid i...