CROSS-REFERENCE
Related Applications: This application is one of four U.S. patent applications being filed simultaneously, all of which are commonly assigned, the other are:
Ser. No. 07/970,335, METHOD OF DYNAMICALLY CANCELING A DB2 THREAD, by David L. Janicek;
Ser. No. 07/970,334, METHOD OF DYNAMICALLY EXPANDING A DB2 EDM POOL, by David L. Janicek;
Ser. No. 07/970,336, METHOD OF DYNAMICALLY ADDING OR REMOVING DB2 LOGS, by Anouar Jamoussi and David L. Janicek.
Microfiche Appendix: The microfiche appendix to this specification consisting of 207 microfiche and 3 pages contains source code listings of a series of copyrighted computer program routines that are the property of the assignee of this application. Permission is granted to make copies of the appendix and its contents solely in the course of creating facsimile copies of a patent issuing on this application and for no other purpose. All other rights under copyright or similar law are reserved.
Glossary and Bibliography: A general-purpose glossary of certain terms of art and a list of potentially helpful references for further reading are set out at the end of the printed specification of this application. References are indicated in the text of the specification in conventional fashion, e.g., "[Smith]" might indicate an article by Smith. Both the glossary and the list of references are intended solely as an aid to understanding the invention and not as limiting the scope of the inventive subject matter defined in the claims.
The Problem of Fixed DB2 Buffer Pool Sizes
This invention relates to the use of database software such as the well-known DATABASE 2 database software distributed by IBM Corporation, commonly referred to colloquially in the art as "DB2." As is well known to those of ordinary skill, generally speaking DB2 operates as a subsystem in a computer system that itself is operating under the IBM MVS operating system software.
The invention particularly relates to a method for allowing DB2 users to obtain better throughput by dynamically manipulating the sizes of the buffer pools used for data input/output (I/O). More specifically, the invention relates to a method by which a user of a DB2 application can dynamically increase or decrease the amount of MVS virtual storage allocated to each of the (four) DB2 buffer pools.
FIG. 1 illustrates, in greatly simplified form, the relationship between (a) DB2, (b) an application program that makes use of DB2-provided services to read from and write to data storage, referred to as a "DB2 application," and (c) a user who communicates with the DB2 appliication via communications management software such as, e.g., the well-known IBM Virtual Terminal Access Method (VTAM) software.
The present version of DB2 defines four buffer pools, in which virtual storage space exists in 4K or 32K pages. When a table space (i.e., a data set) is defined by a DB2 application, the table space is assigned to a specific one of these four buffer pools. DB2 "opens" a given buffer pool, i.e., issues an MVS macro instruction to allocate virtual storage for the buffer pool, only on the first occasion when a DB2 application actually requests that data be read from or written to a table space associated with the buffer pool. DB2 maintains the buffer pool, keeping control of all memory allocated to the buffer pool, until all data sets using the buffer pool are closed by the associated DB2 application(s).
It has long been known that the respective sizes of the buffer pools can directly affect the performance of the DB2 application programs. As DB2's workload fluctuates during the day, and also as the non-DB2 MVS workload fluctuates, the demand on MVS's virtual storage capabilities can fluctuate as well. A buffer pool of fixed size therefore is likely to be nonoptimal at any given time.
Heretofore, "tuning" of the buffer pool size for improved performance has not been feasible as a practical matter. In DB2's present version, the size of a buffer pool can be expanded or contracted only by bringing down DB2 (i.e., terminating the execution of DB2), changing the parameters defining the size of the particular buffer pool, and bringing DB2 back up. The process of bringing DB2 down for the purpose of making parameter changes, then bringing it back up again, is sometimes referred to as "cycling" DB2. Cycling of DB2 frequently results in serious inconvenience to users of DB2 because bringing down DB2 necessarily causes an outage (i.e., unavailability) of all application programs that use DB2. Thus, data bases supported by those application programs become unavailable to users for the duration of the outage.