Browse Prior Art Database

Avoid Buffer Pool Scan at Dataset Close

IP.com Disclosure Number: IPCOM000106504D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 98K

Publishing Venue

IBM

Related People

Haderle, DJ: AUTHOR [+2]

Abstract

For a database management system (DBMS) that supports a data caching facility, a buffer pool scan is normally done to purge cached data prior to closing a dataset. With a large buffer pool, the CPU overhead, which performs such scans, could be significant. This invention describes a scheme which avoids buffer pool scans to purge cached data at dataset close. In addition, it provides an option which allows cached data to remain valid across multiple open/close(s) if there is no logical reason to purge data at dataset close.

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

Avoid Buffer Pool Scan at Dataset Close

For a database management system (DBMS) that supports a data caching
facility, a buffer pool scan is normally done to purge cached data
prior to closing a dataset.  With a large buffer pool, the CPU
overhead, which performs such scans, could be significant.  This
invention describes a scheme which avoids buffer pool scans to purge
cached data at dataset close.  In addition, it provides an option
which allows cached data to remain valid across multiple
open/close(s) if there is no logical reason to purge data at dataset
close.

      A DBMS managed database dataset is normally opened at the time
that it is first being accessed by a DBMS thread/application.  Once
opened, it can be concurrently accessed by multiple DBMS threads
(concurrency control is done by database locking).  An open dataset
can be closed when it becomes not in-use (i.e., all accessing threads
have de-registered their interest to the dataset).  The dataset
de-registration is normally done at thread commit or termination
time.

      For each open dataset, the DBMS creates a Dataset Control Block
(DCB) within its control region address space.  The DBMS uses the DCB
address and the dataset page number as the unique key to perform a
buffer search (i.e., determine whether a database page is cached in
the buffer pool).  The reason for using the DCB address as part of
the search key is to minimize the amount of dataset identifying
information that need to be kept in each Buffer Control Block (BCB).
Each BCB is associated with a buffer, and it is used by the DBMS to
store buffer control information.  When a database page is cached in
a buffer, its dataset's DCB address is stored in the BCB.

      When an open dataset is closed, it is necessary for the DBMS to
ensure that the dataset's DCB address is not known to all buffers in
the buffer pool.  This is due to the fact that the corresponding DCB
is freed at dataset close.  The same DCB address could be reused for
a subsequent open of a different database dataset.  If this condition
happens, cached pages that belong to the closing dataset could be
mistakenly retrieved on behalf of another database dataset.  One way
to ensure that the closing dataset's DCB is not known to all buffers
is to perform a buffer pool scan to clear the DCB address in those
matched BCBs.  With a large buffer pool, the CPU overhead and the
response time delay for such scans could be significant.  cached data
without scanning the buffer pool.  Since the main reason for scanning
the buffer pool is to invalidate the DCB address stored in the BCBs,
this inv...