Browse Prior Art Database

Concurrent Recover Index

IP.com Disclosure Number: IPCOM000101675D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 3 page(s) / 123K

Publishing Venue

IBM

Related People

Bonner, CR: AUTHOR [+3]

Abstract

This article describes how to allow multiple recover index utility jobs to run concurrently on the same table space. The overall method is to: 1) scan the table space data; and 2) extract the keys from the table on which the index is defined; and then 3) rebuild the index from the keys which were extracted from the data.

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

Concurrent Recover Index

       This article describes how to allow multiple recover
index utility jobs to run concurrently on the same table space. The
overall method is to:  1) scan the table space data; and 2) extract
the keys from the table on which the index is defined; and then 3)
rebuild the index from the keys which were extracted from the data.

      Currently only one recover index utility at a time is allowed
to run on the same table space, because the table space is locked
exclusive by the utility.  Since the table space is only read by the
util- ity, it is not necessary to lock it exclusive for utility
usage.  The reason that it is locked exclusive is to restrict
Structured Query Language (SQL) operations from using an index that
is being recovered by the utility and therefore inconsistent.  That
is, the table space lock is used to cover both the table space and
all of its indexes. However, the same table space lock acquired by
one recover index utility also prevents any other utilities from
running concurrently on the same table space, including other recover
index utilities.

      To allow multiple recover index utilities to read the same
table space concurrently, while still restricting SQL operations from
using the table space, the following technical disclosure is made:
1.   Utility-Utility serialization.
      The utility serialization process is illustrated in the figure.
The utility serialization process performs a check for starting a
utility against any currently active utilities upon an object.  If
they are incompatible the starting utility is not allowed to
continue.  Currently two recover index utilities running on the same
table space are incompatible.  To resolve this, the utility
compatibility table is changed to allow a recover index utility to
continue if one or more recover index utilities are active on the
same table space.
      The utility serialization process also sets the utility in
process (UTIP) state in the data base allocation control table (DBA
table) for the table space.  Once set, the UTIP state in the DBA
table has the effect of restricting SQL operations from using the
table space and any of its indexes.  A use count is kept for UTIP, so
that it will remain set until the last recover index utility is done
with the table space.

      2.   SQL-Utility serialization.
     The SQL serialization process is illustrated in the figure.
Serialization with SQL is dependent upon whether SQL or the recover
index utility begins processing the table space first.
      If a recover index utility is active first and SQL attempts to
access the table space, the UTIP state in the DBA table will stop the
SQL operation and will result in an error message "resource
unavailable".
     ...