This section describes the operating system, virtual machines, software, virtual storage, and hardware you need to enable and operate VMDSS.
To support all of VMDSS's functions, you must:
If you are not operating in XC mode, you will not be able to use:
You will be able to use striping, and the storage pool performance counters for the standard DASD I/O system.
This section describes the virtual machines you need to enable and operate VMDSS.
The MAINT machine, or its equivalent, already exists in all VM systems. It is suggested that you use this machine to update the CP directory, although you can use any machine with write access to the database minidisks and authority to update the CP directory.
The database machine, usually called SQLMACH, owns the database minidisks. It acts as an application server, either locally or remotely, within a TSAF collection or SNA network. For more information, refer to DB2 Server for VM System Administration.
To support all VMDSS's functions, you must configure the database machine to operate in XC mode. Refer to Step 2: Update the CP Directory.
You can configure the database machine to operate in ESA mode, but you will then only be able to use a subset of VMDSS's capabilities, as described in Operating in Non-XC Mode.
To enable and operate VMDSS, you must first install DB2 Server for VM Version 7 Release 1.
This section describes the virtual storage the MAINT and SQLMACH machines needed to use VMDSS.
You do not require any additional virtual storage for the MAINT machine.
You may need to add additional virtual storage to your database machine. To calculate how much:
For example, consider a database generated with:
It is also currently using 10 data spaces for public and private dbspaces. The database machine will use an additional 171KB of virtual storage:
41×1024 = 41,984
20×1024 = 20,480
2.5×10×1024 = 25,600
20×16 = 320
256×8 = 2,048
256×8 = 2,048
+ 10240×8 = + 81,920
174,400 = 174,400 = 170.40KB &eqv. 171KB
While you do not require additional real storage (main or expanded storage) to use VMDSS, any storage you add will be used by VMDSS to help improve the performance of your database. Several facilities are included with VMDSS to help you manage how much real storage you use. For more information refer to Managing Your Working Storage Size.
This section describes how much DASD space the VM system, the MAINT machine, and the SQLMACH machine need in order to use VMDSS.
The device number for a minidisk residing on an FBA DASD must start and end on a 4K block boundary. The starting FBA block number and the ending FBA block number +1 of the minidisk must be evenly divisible by 8. Refer to the MAPMDISK information in the VM/ESA: CP Programming Services manual.
You can turn Data Spaces Support off for the Storage Pool residing on the FBA device not on a 4K block boundary by updating the storage pool specification file.
To continue using an FBA device, use DDR or use the SQLCDBEX EXEC to copy the extent to a new minidisk that is formatted on a 4K block boundary. Alternately, you can move to a non-FBA device using the SQLCDBEX EXEC. Refer to the DB2 Server for VM System Administration for details on how to use the SQLCDBEX EXEC.
Before you can use separate internal dbspaces (unmapped), you may need to allocate more DASD for VM system paging.
Attention: If VM runs out of system paging DASD, CP will abend if it does not have sufficient spool DASD to accommodate the overflow.
To calculate the maximum number of additional cylinders you need for
unmapped internal dbspaces, divide the number of pages currently in all your
internal dbspaces by the conversion ratio for your type of DASD, listed in Table 11 and round up to the nearest integer.
Table 11. Additional Paging Cylinders
|
DASD Type |
3350 |
3375 |
3380 |
3390 |
9345 |
|---|---|---|---|---|---|
|
Conversion Ratio (Blocks per Cylinder) |
120 |
96 |
150 |
180 |
150 |
For example, if you are currently using 80 internal dbspaces of 1024 pages each for your internal dbspaces, the calculation for 3380 DASD is as follows:
80*1024/150=546.133 cylinders
&eqv.547 cylinders
Thus, you may need as many as 547 additional 3380 cylinders if you want to use unmapped internal dbspaces. Remember, that the number you calculate will be the maximum you will ever need. While you may actually use far fewer cylinders on a day to day basis, you still need enough cylinders in either system paging DASD or spool DASD to accommodate your peak requirements. If you cannot supply this maximum value, you can still use mapped data spaces.
To assess your peak requirements, assign your internal dbspaces to their own storage pool and use mapped internal dbspaces, refer to Mapped Internal Dbspaces. You can then use the SHOW POOL operator command (refer to DB2 Server for VSE & VM Operation) to see how many pages your production system is really using for internal dbspaces. This will probably be much lower than your maximum calculation. You can then allocate the number of pages the database manager is really using for the internal dbspace pool to system paging DASD and start using unmapped internal dbspaces (refer to Unmapped Internal Dbspaces).
Attention: The SHOW POOL command only displays the number of pages a pool is currently using.
You must carefully monitor page usage over a relatively long period until you are confident that the database manager will not use more pages than you will allocate to system paging DASD. Also, remember to continue monitoring SHOW POOL when you start using unmapped internal dbspaces in case your requirements increase.
VMDSS requires a minimum amount of free space on the system minidisks.
The system disks are the service and production minidisks or SFS directories of the SQLMACH database machine. No additional DASD is required.
There are three types of database disks:
While there is no change to the amount of DASD you require for your log or data extent disks, the DASD you require for the directory disk may change depending on how you use VMDSS.
If you use Data Spaces Support with the directory, you must move the directory from a disk formatted with 512-byte blocks to one with 4KB blocks. Since 4KB blocks use real DASD storage more efficiently than do 512-byte blocks, you do not need as much real DASD storage.
To calculate the number of cylinders you need, multiply the number
currently in your directory disk by the conversion ratio for your type of
DASD, listed in Table 12 and round up to the nearest integer.
Table 12. Conversion from 512 byte to 4K byte blocks
|
DASD Type |
3350 |
3375 |
3380 |
3390 |
9345 |
|---|---|---|---|---|---|
|
Conversion Ratio |
0.85 |
0.63 |
0.57 |
0.51 |
0.52 |
For example, if you are currently using 34 cylinders of 3380 DASD for your directory disk, the calculation is as follows:
34&smultdot.0.57=19.38 cylinders
&eqv.20 cylinders
Thus, you will only need a 20 cylinder disk after you move to 4KB pages.
You can also move the directory from a 4KB-block disk to a 512-byte-block disk. To calculate how many cylinders you will then need, divide the number you need when the directory is in 4KB blocks by the conversion and round up to the nearest integer.
To support all of VMDSS's functions you must enable it in a ESA/390 processor within the ES/9000(R) family that supports VM/ESA in XC mode.