This section describes the advantages of using Data Spaces Support over the standard DASD I/O system, and when to use Data Spaces Support with:
The paging system in Data Spaces Support can be much faster and more efficient than the standard DASD I/O system.
The data spaces act like a large DASD cache, keeping the most recently used data in the fastest storage. While this is similar to using a large pool of buffers or DASD caching, there are significant advantages to using Data Spaces Support over these two methods. (Refer to DB2 Server for VM System Administration for more information on buffer pools.)
Some of the advantages are:
These are described in turn below.
There is a series of internal processes between when the database manager requests a page from DASD, and when the operating system transfers it to main storage. This series is shorter when you use Data Spaces Support than when you use the standard DASD I/O system.
Since the operating system treats the buffers like part of the database manager code, it may page them out to system paging DASD if it needs main storage. Whenever the database manager needs a piece of code (or a buffer) that has been moved to paging DASD, it and all its users must wait for that page to return from DASD.
With Data Spaces Support, you can use a smaller pool of local buffers, decreasing the chance of a buffer being paged out. If a page fault occurs in a data space (the operating system cannot find the page in main or expanded storage) the database manager can proceed with other users and return to the original user when the fault has been resolved.
When you use striping, the database system tries to keep related data pages physically close together on DASD. (It allocates pages in groups of 16.) Thus, when the operating system needs to retrieve related pages from DASD, there is a good chance that the pages will be located together. The operating system can then read in a whole series of pages with one I/O operation, which improves the performance of your system.
Striping also spreads these groups of 16 pages across all the dbextents in a storage pool. If the dbextents are on separate physical devices, the operating system can read several groups of pages at the same time (asynchronously). This improves blocking and prefetching (see below), and helps you balance the load between DASD packs.
When you use the Data Spaces Support, the operating system tracks the way you access pages. It records which pages you have used together (in a block) and the order in which you use them. Then, when the database manager requests a page from a data space, if the page is on DASD, CP will start retrieving (prefetching) other pages in the same block in the order you previously followed. Since DASD I/O can proceed in parallel (because of striping), this effectively places pages in main storage before the database manager needs them.
In some cases, the database manager will pass information to the operating system about how it expects to use pages. The operating system uses this information to modify its own reference pattern and thereby further improve prefetching.
You can dynamically manage how the database manager uses main and expanded storage:
With Data Spaces Support, the database manager can write modified pages back to DASD (refer to Modifying Pages ) "more" asynchronously than without it.
If the database manager needs a buffer occupied by a modified page, it first writes the page to DASD, then loads the buffer with a new page.
When it does this, it puts the current agent into an I/O Wait State until the write is complete. Since the database manager continues to service agents that are not in wait states, this process is asynchronous between agents.
When the database manager writes a modified page to a data space, the current agent is not put into a wait state. The operating system ensures that the page is eventually written to DASD (before the next checkpoint) without stopping the current agent. This process is asynchronous within an agent and therefore more asynchronous than without Data Spaces Support.
We suggest that you turn Data Spaces Support on for all your storage pools. Even without adding main or expanded storage to facilitate caching, you should see performance improve due to the advantages of shorter path length, striping, blocking, and prefetching.
If you want the additional benefit of caching, you should first consider the cost in main and expanded storage. Whenever you use Data Spaces Support, the operating system will use main and expanded storage to cache any data the database manager uses. If the database manager needs this data again, the operating system can retrieve it quickly. However, if the cached data is not used very often, it may be swapped out of main or expanded storage before it is referenced again. If this happens, you are using main or expanded storage to cache pages without receiving any of the benefit. Thus, if the main and expanded storage in your system is limited, you should only use caching for your most active pools.
(You can effectively turn caching off for a particular storage pool without turning Data Spaces Support off, by using working storage residence priority "1". Refer to Choosing Storage Residence Priorities.)
You can improve the performance of your database by using unmapped internal dbspaces. We suggest that you do so unless you do not have enough VM paging DASD (refer to VM/ESA Paging DASD).
Unmapped internal dbspaces have the following advantages over mapped ones:
If you want to manage your internal dbspaces the same way you manage all your other dbspaces, you may want to use mapped internal dbspaces. If you place your internal dbspaces in a separate storage pool, you can turn Data Spaces Support on or off, and set a working storage residence priority for them.
For information on how to customize your database for internal dbspaces, refer to Using Data Spaces with Internal Dbspaces.
We suggest that you use Data Spaces Support with the directory. However, you may choose not to if you need to switch your database machine between XC mode and ESA mode.
Every time you switch to a processor or operating system that does not support XC mode (for example a backup system) you must reblock the directory disk. (Refer to Reblocking the Database Directory.)
For information on how to customize a database to use Data Spaces Support with the directory, refer to Using Data Spaces with the Directory.