Browse Prior Art Database

One-Pass Contraction Technique for Database Bufferpool

IP.com Disclosure Number: IPCOM000107278D
Original Publication Date: 1992-Feb-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Related People

Hu, MH: AUTHOR [+4]

Abstract

A technique is disclosed which can be used by a database system to efficiently manage the dynamic contraction of a bufferpool. With the on-line capability to alter bufferpool size, a database manager can adjust the size of the bufferpool to achieve maximum performance based on the database transaction requirements. The technique described here allows bufferpool contraction to take place in an efficient, predictable manner.

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

One-Pass Contraction Technique for Database Bufferpool

       A technique is disclosed which can be used by a database
system to efficiently manage the dynamic contraction of a bufferpool.
With the on-line capability to alter bufferpool size, a database
manager can adjust the size of the bufferpool to achieve maximum
performance based on the database transaction requirements.  The
technique described here allows bufferpool contraction to take place
in an efficient, predictable manner.

      In previous implementations, the contraction process merely
marked buffers as needing to be deleted.  It was then left up to the
mainline processes to perform the actual freeing up of these buffers
as they were encountered in the normal course of operations.  This
caused the contraction process to take a potentially indefinite
amount of time, especially on a lightly loaded system.  Also, there
was a negative performance impact on the processes which ended up
doing the actual freeing up of the buffer resources, due not only to
the extra work involved but also to the required serialization
between concurrent processes.

      This technique is primarily intended for use in the contraction
of a "secondary" bufferpool, which is an extension of the "primary"
bufferpool.  The secondary pool resides in volatile storage, which
can potentially be stolen by the operating system at any time.  Thus,
only clean data is stored there, and it is only accessible by the
database system's buffer manager.  A buffer in the secondary pool is
"active", i.e., non-stealable, only for the length of time it takes
to move its contents to or from the...