VMDSS can dramatically increase the performance of your application server, by using the Data Spaces facility found in VM/ESA. Data spaces give your application server access to vast amounts of fast storage, and uses a high performance DASD I/O system that has many advantages over the standard I/O system (IUCV *BLOCKIO).
VMDSS can also distribute data across multiple dbextents, which helps to balance the load on your system's DASD and allows the operating system to read and write data in parallel. Finally, you can monitor the performance of your DASD I/O system for individual storage pools, and control the amount of system-resource it uses.
To understand how data spaces work and why they are an improvement over existing systems, you first need to understand how VM uses its paging system to manage virtual machine storage.
Each virtual machine within a VM system has its own virtual address space (also called a primary address space) which is where you load and run programs. Because this space is virtual, the operating system does not dedicate a piece of main storage (also called real storage) to each virtual machine. You do not need to buy 16MB of main storage for each 16MB virtual machine. Instead the operating system only uses main storage for those parts of virtual storage you need right now, or are likely to need in the near future.
These parts of storage are divided into 4KB (4096 byte) blocks called pages. When a virtual machine needs a page that it has not accessed before, the operating system retrieves it from its location on DASD, and loads it into an empty page in main storage. (Before a virtual machine can use a page, it must be in main storage.)
When the operating system runs out of free pages in main storage, it moves the least recently used ("oldest") page to auxiliary storage to create a free space for a new page. While the virtual machine is still active (logged on), the page will remain in either main or auxiliary storage.
VM/ESA uses two types of auxiliary storage: system paging DASD, and optional expanded storage. If your system has expanded storage, a page will be moved there first. If expanded storage is full, the least recently used page in expanded storage is moved to system paging DASD by way of main storage. When a virtual machine needs a page that it has previously used, the operating system moves it back to main storage from expanded storage, or from system paging DASD, if it is not already in main storage.
Figure 25. Standard Virtual Machine Storage
|
This paging system accomplishes two things. First, it allows each virtual machine to use much more storage than could be accommodated in main storage alone. Second, it keeps the most recently used pages in the storage devices that are the fastest to access. (The most recently used pages are the ones most likely to be used again in the near future.) Main and expanded storage are much faster than system paging DASD, and while expanded storage can be as fast as main storage, it is effectively slower because the operating system still needs to move the page into main storage before it can use it.
In VM/ESA, a program running in a machine's primary space can dynamically create additional address spaces for data, called data spaces. Like a virtual machine's primary address space, a data space is a virtual space with its real pages in main storage, in expanded storage, and on DASD. However, unlike a primary space, you cannot run a program in a data space. Also, in VMDSS the VM paging system manages data space pages differently than virtual machine pages. This means that data spaces do not use system paging DASD. (Unmapped internal dbspaces are the exception. Refer to Unmapped Internal Dbspaces).
Figure 26. Data Spaces Storage
 |
With VMDSS, if there is no longer any free space in main or expanded storage, the operating system will simply replace an old data space page in main or expanded storage with a new page. If the old page is needed again, it is reread from its original DASD source. If the old page was modified while it was in main storage, the operating system ensures that the modified page is written back to its original DASD source before it is overwritten.
This expands a machine's effective virtual storage by providing additional addresses for data, thereby making room in the primary space for larger programs.
Before a page of data can be used by the database manager, it must be located in its data page buffers. The buffers are two areas of storage in your primary address space, which are created when you start the database manager. One area is reserved for pages from the directory disk, and the other for pages from storage pools. They are called the directory buffer pool and the local buffer pool, respectively.
When the database manager needs a page, it looks for it in its buffer pool. If it does not find it there, it uses a VM service called IUCV *BLOCKIO to read the page from DASD into a free space in its pool.
Since the buffer pools are part of a primary address space, the operating system treats them like part of the database manager code. If a buffer page is not referenced frequently, it may be moved out to expanded storage or system paging DASD by the VM paging system (for more information refer to Asynchronous Page Fault Processing).
Figure 27. Page Movement in the Standard DASD I/O System. The database manager explicitly directs the operating system to move pages to and from DASD with the IUCV *BLOCKIO instruction. Once database machine pages are in main storage, they may be moved out to either expanded storage or system paging DASD by the VM paging system.
 |
If the database manager cannot find a page in its buffer pools, it "retrieves" it from a data space and stores it in a free buffer in its pool. When this happens, the operating system actually does most of the work. If the page is already in main storage, the database manager can move it directly to the buffer pool. If the page is in expanded storage or in DASD, the operating system moves it into main storage, and then copies it into a buffer. If your processor supports Enhanced Move Page for VM, pages are moved from expanded storage directly into a buffer.
Figure 28. Page Movement with Data Spaces Support. The figure shows a page being read into main storage from DASD and then into a buffer pool. The page will be in two places in main storage until either the data space page is released or the database manager releases the buffer page (refer to Releasing Pages).
 |
This system has several advantages over the standard DASD I/O system, which uses the IUCV *BLOCKIO service. In the latter, each page move must be explicitly requested by the database manager, whereas here paging is done by the VM paging system. This is faster and more efficient for several reasons, including:
Refer to Deciding When to Use Data Spaces for a detailed description of each advantage.
When the database manager needs a buffer for another page, it overwrites the "oldest" unmodified page in the pool with a new page. This is referred to as releasing a page or stealing a buffer.
When the database manager needs a buffer for another page, it does so in the same way that it would with Data Spaces Support off.
When the operating system needs main or expanded storage for itself or for other virtual machines, it may release data space pages from main storage. Pages may also be released at the request of the database manager. There are several parameters you can use to control when the database manager will start releasing pages and which pages it will choose (refer to Managing Main and Expanded Storage).
While a page is in the buffer pool, the database manager may modify it. To ensure the integrity of your data, a modified page will not be released until it has been written back to DASD. 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.
Instead of writing the modified page to DASD, the database manager moves it to a data space.
Once again, the operating system does most of the work. It takes the modified page from the database manager and moves it into main or expanded storage.
If the operating system needs a main storage page that is occupied by that page, it will move it to expanded storage or to DASD before it uses the main storage page. Similarly, if it needs an expanded storage page that is occupied by a modified page, it will move the modified page to DASD by way of main storage.
At checkpoints, the database manager writes a summary status record to the log and makes sure that all modified buffer pages and status information are written to DASD. This ensures that you have a permanent record of your data on DASD.
The database manager writes all the modified pages that are still in the buffer pools to DASD. Until it is finished it cannot serve any users.
The database manager moves modified pages that are still in the buffer pools to data spaces. It then directs the operating system to save all the data space pages that were modified by the database manager to DASD. Until the operating system is finished, the database manager is forced to wait: it cannot serve any users until the checkpoint is complete.
Individual storage pools can be used with or without Data Spaces Support.
| Note: | A storage pool used only for internal dbspaces and which has a dbextent on a virtual disk cannot be used with Data Spaces Support turned on for this pool. For more information on virtual disk support for VM/ESA for internal dbpsaces, refer to Virtual Disk Support for VSE/ESA for Internal Dbspaces or Virtual Disk Support for VM/ESA for Internal Dbspaces. |
Figure 29. Storage Pools with Data Spaces Support on and off
 |
For a description of how to turn on Data Spaces Support, refer to Specifying Either Data Spaces Support or Standard DASD I/O. For information on when to use data spaces with storage pools, refer to Storage Pool.
Internal dbspaces can be used with or without Data Spaces Support.
Since internal dbspaces are assigned to a specific storage pool, you can turn Data Spaces Support on and off for them by turning support on and off for that pool. This type of Data Spaces Support is similar to the support for any other storage pool. Since the system assigns, or "maps" each data space page to a physical page in a dbextent (contained in a storage pool), it is referred to as mapped support.
VMDSS also supports unmapped internal dbspaces. Instead of mapping pages onto dbextents, VM/ESA manages them as normal virtual storage paged to VM system paging DASD (see Figure 30).
Figure 30. Unmapped and mapped internal dbspaces
 |
The internal dbspaces are still assigned to a storage pool, but they do not use any DASD in that pool. Rather they use system paging DASD. To make up for this, you must allocate more DASD to system paging. Refer to VM/ESA Paging DASD.
For a description of how to turn on Data Spaces Support for internal dbspaces, refer to Using Data Spaces with Internal Dbspaces. For information on when to use data spaces with internal dbspaces, refer to Internal Dbspaces.
You can use the directory with Data Spaces Support either on or off.
The database manager stores directory data on the directory disk (B-disk) in 512-byte blocks and reads these blocks into the directory buffers from the B-disk as necessary.
The directory uses data spaces as a storage pool would. If the database manager cannot find a block of directory data in the directory buffers, it gets the block from a data space. If the directory block is not already in main storage, the operating system locates the page on the B-disk that contains the directory block and copies it into main storage (each 4KB page contains eight 512-byte directory blocks).
Any DASD accessed through a data space must have a 4KB block size. This means that if you want to use the directory with Data Spaces Support, you must reblock the directory minidisk from 512-byte blocks to 4KB pages.
For information on how to reblock and start Data Spaces Support for the directory, refer to Using Data Spaces with the Directory. For information on when to use Data Spaces Support with the directory, refer to Directory.
Figure 31. The Database Directory with Data Spaces Support On and Off
 |
If unchecked, VMDSS may ask for large amounts of main and expanded storage from the operating system. If it gets it, your database machine may be very fast but other virtual machines in the system may perform poorly.
The operating system always maintains control of its main and expanded storage, and will limit how much your database machine can use. If your machine tries to use more storage than is available, the operating system will release some of your pages (or pages from other virtual machines) from main or expanded storage to make room for the new ones.
Instead of waiting for the operating system to release pages, you can instruct the database manager to do so before your machine reaches its storage limits. Pages to be released will be selected based on the parameters you set. You can also limit the number of modified pages in main and expanded storage to improve checkpoint processing.
The four primary parameters provided are:
The target working storage size parameter controls the amount of main and expanded storage that your database machine uses. When the amount of storage reaches this target, the database manager will start to release certain data space pages immediately after they have been copied into the buffer pools.
While you may exceed this target, the database manager will try to keep you at or below it if possible. (Of course, you may never reach it if the operating system is heavily loaded.)
You can set this parameter at start up time, or dynamically while the database manager is running.
For information on how to change this parameter, refer to the DB2 Server for VSE & VM Operation manual. For information on how to choose a value for it, refer to Choosing the Target Working Storage Size.
The database manager decides which data space pages to release based on the working storage residency priority of each pool.
Priorities range from a value of 1 where all pages are released, to a value of 5 where none are. The priorities in between allow a page to be released depending on whether your current working storage size is above or below your target, and whether the page is an index or a data page.
For information on how to change storage priorities, refer to Specifying Storage Residence Priorities. For information on how to choose a storage priority, refer to Choosing Storage Residence Priorities.
The checkpoint interval controls the duration between database checkpoints. At a checkpoint, the database manager makes sure that all the modified pages in main and expanded storage are written to DASD. (Refer to Checkpoints.) If there are many modified pages, it can take a long time to complete the checkpoint, and until it is complete the database manager cannot serve any users.
For information on how to change the checkpoint interval, refer to DB2 Server for VSE & VM Operation. For information on how to choose a value for it, refer to Choosing the Checkpoint Interval.
To make checkpoint processing faster, you can limit the number of modified pages in main and expanded storage by setting the save interval. When the number of modified pages in a data space exceeds this parameter, the database manager directs the operating system to save all the modified pages in that data space to DASD. Unlike the save that occurs during checkpoint, the database manager can continue to service users while this is being done.
For information on how to change the save interval, refer to the DB2 Server for VSE & VM Operation manual. For information on how to choose a value for it, refer to Choosing the Save Interval.
VMDSS will attempt to evenly distribute, or "stripe", your data across all the dbextents in a storage pool.
Figure 32. A storage pool with striping switched on and off. The figure shows 48 4KB pages written to DASD with striping on and off.
 |
The database manager allocates pages in a storage pool in sequence, usually allocating all the pages in one dbextent before using the next dbextent.
The database manager allocates 16 pages in sequence on each dbextent in the storage pool. The operating system can then read and write the pages to and from DASD in parallel. This may significantly improve DASD performance, depending on how you configure your controllers, channels, and DASD. The optimal configuration would include several dbextents in the storage pool, each on a separate channel, controller, and physical storage device.
For a description of how to use striping, refer to Turning Striping On and Off. For information on how to decide when to use it, refer to Using Striping.
Several counters are available that can help you monitor the performance of the DASD I/O systems. Each storage pool has its own set of four counters. There is also a set of four counters for unmapped internal dbspaces, and a set for the directory. These counters are different depending on whether a particular component is using data spaces. (Unmapped internal dbspaces always use them.)
For more information refer to the DB2 Server for VSE & VM Operation manual. For information on performance measurements in general, refer to Chapter 2, Measuring Performance.
You will need to design the structure of your database so that you can control it effectively.
Figure 33. Planning for Critical Tables
 |
We suggest in DB2 Server for VM System Administration that you have one table per dbspace. Also, you may want to assign only one dbspace to each storage pool because many of the VMDSS configuration options are grouped by storage pool: for example, you can turn Data Spaces Support and striping on and off for a particular storage pool, set residence priorities by storage pool, and display counters by storage pool. By associating one table per storage pool, you can determine how a specific table will use the VMDSS functions.
However, you should not do this for every table in your database. If you have several tables that you always access together, place each one in a dbspace and assign all the dbspaces to one storage pool. Only special tables where performance and control are critical should have their own storage pool.
When you start the database manager, you can choose whether it will map data space pages to physical pages, physical mapping, or virtual pages, logical mapping (see below). The type of mapping you choose will apply to all the storage pools in the database that are using Data Spaces Support.
For a description of how to set the type of mapping, refer to the DB2 Server for VSE & VM Operation manual. For more information on how to choose one type, refer to Choosing Logical or Physical Mapping.
Figure 34. Logical and Physical Mapping
 |
This associates (maps) each logical page in a dbspace to a data space page. Since the logical pages are mapped onto a data space in the order they appear in the dbspace, a contiguous set of pages in a data space will correspond to a contiguous series of pages in a dbspace. This is the default and recommended mapping for most applications.
This maps each physical page in a dbextent to a data space page. Since the physical pages are mapped onto a data space in the order they appear on DASD, a contiguous series of pages in a data space will correspond to a contiguous series in physical storage.
Although VMDSS does not support application servers running in VSE, VSE users can access a VMDSS database in VM/ESA through guest sharing. The database manager runs in one virtual machine, while the VSE users run under a VSE guest system in another virtual machine. Since VMDSS only affects the database manager, VSE guest sharing users will benefit from the same performance improvements as VM users.
For more information on VSE guest sharing refer to the DB2 Server for VM Program Directory.