DB2 Server for VSE & VM: Performance Tuning Handbook


Appendix C. Why is the TARGETWS Value Frequently Exceeded?

To understand why the TARGETWS value is exceeded by the amount of real storage actually used by the database when it is using DB2 Data Space Support (known as VMDSS), let's look at how TARGETWS operates and how VM/ESA manages real storage.

First, remember that CP controls real storage. However, VMDSS can influence how CP manages the real storage that DSS uses (by the TARGETWS value, REFPAGE macro, and RELPAGE macro).

Second, VMDSS does not remember all of the pages that are or have been in real storage. This is partly a trade off--if VMDSS remembered everything, a lot of CPU time would be spent keeping track. In addition, it is not possible for VMDSS to actually know everything that is in real storage. For example, VMDSS does not know what CP does for the database machine. CP may be stealing away pages before VMDSS can release them. This is usually not a problem, and can reduce the database's storage usage.

There is another CP effect that is frequently overlooked. When VMDSS references a data space page that is not in real storage, CP brings in that page from DASD, and may also bring in other pages in a block. In some cases, these are extra pages that the database expects will be needed and has told CP to block together using the REFPAGE macro. However, CP may bring in extra pages based on its own estimation of previous page usage. In both of these cases, VMDSS does not know if CP brought in extra pages or not. Even if the database gives CP some REFPAGE information, CP uses the current system load to decide if it will bring in extra pages or not, and if so, how many.

What this really means is that VMDSS does not know exactly what real storage is being used for which data space pages at any moment in time.

Third, VMDSS has only one method of reducing the usage of real storage--releasing pages using the RELPAGE macro. The RELPAGE macro notifies CP that a specific data space page (or range of pages) is no longer needed and that CP can immediately reuse the real storage frame that currently holds that virtual data space page (assuming CP has not already stolen that page frame). Also, remember that VMDSS uses RELPAGE at specific points when using data space pages.

Most important, is when a data space page is moved from the data space into a database local buffer. Once the page's contents are copied into the local buffer, it can be released. This implies that a page is NOT released unless it is moved into a local buffer. Also (ignoring the extra complications caused by the Working Storage Residency Priorities), page releasing also only occurs when the TARGETWS setting is exceeded.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]