There are two types of storage: real and virtual.
In VM, each virtual machine has its own virtual address space, which is where you load and run programs. VSE supports multiple address spaces that can each contain several partitions.
Because these address spaces are virtual, the operating system does not dedicate a piece of main storage to each virtual machine or partition. You do not need to buy 8MB of main storage for each 8MB virtual machine or partition. 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 virtual storage are divided into 4KB (4096 byte) blocks called pages. When a virtual machine or partition needs a page that it has not accessed before, the operating system retrieves the page from its location on DASD, and loads it into an empty page in main storage. (Before a page can be used, 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.
The VM operating system 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 10. Standard Virtual Machine Storage
|
The VSE operating system only uses system paging DASD: it does not support expanded storage. When the operating system runs out of free pages in main storage, it moves the least recently used page directly to system paging DASD. When a partition needs a page that it has previously used, the operating system moves it back to main storage from system paging DASD, if it is not already in main storage.
Figure 11. Standard VSE Partition Storage
 |
This paging system accomplishes two things. First, it allows each virtual machine or partition 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.
Each time the database machine or partition (or the CICS partition) requires a page that the operating system cannot find in main storage, a page fault occurs. The entire database machine or partition, and therefore the entire database manager, must wait until the page is returned from auxiliary storage. Consider a system that requires an average of 50ms to return one page. So at 6 faults per second the database manager is idle 300 out of 1000ms, or almost one third of the time.
| Note: |
This is not true for DASD I/O. A database machine does not
wait for *BLOCKIO, nor does a database partition wait for VSAM. The
database manager will dispatch another agent (unless you are running in single
user mode) while it waits for the DASD I/O to complete. Refer to Database I/O.
This is also not true for Page Faults that occur in Data Space (when VMDSS is enabled). Only one agent must wait for this kind of Page Faults. |
The TPBAL command (VSE system control statement) specifies the number of partitions that are eligible for deactivation. Whenever the TPIN macro (refer to the IBM VSE/ESA System Macros Reference manual) is executed, the number of partitions specified by the TPBAL command will be deactivated starting with the lowest priority partition and proceeding to the highest eligible partition (excluding the partition which executed the TPIN macro). All deactivated partitions are suspended (kept idle) until the TPOUT macro is executed. This can become a severe problem if, for example, the deactivated partition is an application server or a requester that is currently holding database locks. Whenever possible, ensure that the database partition, the CICS partition, or any DB2 Server for VSE batch partitions are NOT eligible for deactivation.
A storage queue is a control structure that the database manager uses to share its virtual space between processes. Queues are created at startup for:
The database manager allocates virtual storage to the different processes as they require it (within limits). Once the storage has been allocated, it cannot be used by any other process until the owning process releases it.
Real agent queues release all but 8KB of their allocated storage at the end of a logical unit of work (LUW). Even if the real agent no longer requires the virtual storage, it may keep it until the end of its current LUW.
Virtual space may be allocated either above or below the 16MB virtual storage line (refer to Storage Above 16MB (31 Bit Addressing).) However, because certain control blocks and program structures must always reside below the 16MB line, two storage queues are created for each process. One storage queue is for blocks and structures that must always reside below the line, the other queue is for blocks and structures that may reside either below or above the line.
When an agent requests virtual storage, the database manager decides whether the blocks and structures must reside below the 16MB line or whether they can reside either above or below the line. If they must reside below the line, space is allocated in the below or B queue. If they may reside above or below the line, space is allocated in the anywhere or A queue.
When the database manager looks for address space for blocks and structures in the B queue, it looks below the 16MB line. When the database manager looks for address space for blocks and structures in the A queue, it first tries to find free space above the 16MB line. If there is none, it will try to find free space below the line. If there is no free space below the line for either the A queue or for the B queue, releasing unused packages from storage. If it can no longer release packages, you will receive an error message and the database machine or partition may abend.
While increasing the size of your virtual database machine or partition may increase your application server's capacity, it does not necessarily improve its performance. This is because the operating system has to supply enough fast real storage to make the virtual storage appear to be real storage.
However, if sufficient real storage is available, you can take advantage of additional virtual storage, by increasing:
You need to monitor the real storage and the I/O in your system. If you do not have enough main (and in VM expanded) storage to support additional virtual storage, you may dramatically increase the load on your I/O subsystem and on your processor. In extreme cases this can lead to thrashing. (The processor and I/O subsystem spend most of their resources moving pages from main to auxiliary storage and have little or no resources left for practical work.)
In VM, your database machine's address space can be larger than the old 16MB limit. In VSE, you can use a database partition larger than the old 16MB limit.
(As mentioned in Address Space Size, anytime you increase your virtual storage, you can realize significant performance improvements by using storage above 16MB, but only if you have the resources to support it.)
A saved segment is a range of pages of virtual storage you can define to hold data or reentrant code (programs), which can be shared by multiple virtual machines. For detailed information, on how to create saved segments and which DB2 Server for VM components can be loaded into them, refer to the DB2 Server for VM System Administration manual.
Loading frequently used DB2 Server for VM components in saved segments has several advantages:
For more information on saved segments, refer to the DB2 Server for VM System Administration manual.
Your internal dbspaces can use a virtual disk to improve their performance. Virtual Disk Support lets you use a data space as a virtual disk. A virtual disk is much faster than a conventional disk because it uses main storage instead of DASD. The virtual disk appears to any program or job as just another disk, only faster.
However, virtual disk storage is temporary. Anything in a virtual disk is lost whenever the VSE operating system is restarted. For this reason, DO NOT use virtual disks for anything other than internal dbspaces. These dbspaces are only used as temporary workspace, so it does not matter if their contents are lost. The storage pool containing the virtual disk must NOT be used for any permanent dbspaces.
While the use of virtual disks is limited to internal dbspaces, they can improve the performance of index creation, joins, sorts, and other operations that require temporary workspace.
Remember, as mentioned in Address Space Size, anytime you increase your use of virtual storage, you can realize significant performance improvements, but only if you have the real storage to support it.
| Note: | It is recommended that database generation be done with real minidisks only. If you decide to generate a database which uses a virtual disk, ensure that the virtual disk is used in a pool containing only internal dbspaces. |
To use a virtual disk with internal dbspaces, you must:
A detailed example of how to complete these steps appears below. For more information on virtual disks in VSE/ESA, refer to the IBM VSE/ESA Planning manual and the IBM VSE/ESA Extended Addressability manual.
| Note: | All of the following steps should be read before executing any of them. |
This will be needed if problems arise during the setup for using a virtual disk and you need to restore your database to its previous state without any virtual disk.
Modify the IPL procedure to do the following:
For example, consider a system where a 20MB virtual disk is added to a VSE system with VSIZE=75MB:
+--------------------------------------------------------------------------------+ |
·
·
·
| |009,$$A$SUPX,VSIZE=95M,VIO=576K,VPOOL=194K,LOG | |
·
·
·
| |ADD 900:906,FBAV | |
·
·
·
| |DPD VOLID=DOSRES,CYL=209,NCYL=100,TYPE=N,DSF=N | |DPD VOLID=DOSRES,CYL=398,NCYL=8,TYPE=N,DSF=N | |DPD VOLID=DOSRES,CYL=410,NCYL=29,TYPE=N,DSF=N | |
·
·
·
| |DLA NAME=AREA1,VOLID=DOSRES,CYL=60,NCYL=3,DSF=N | |SVA PSIZE=640K,SDL=300,GETVIS=768K | |/+ | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example increases the VSIZE of the VSE operating system from 75MB to 95MB. It reserves virtual addresses 900 through 906 for fixed block architecture virtual disks, and it sets aside an additional 29 cylinders of 3390 DASD on DOSRES volume starting at address 410 for system paging DASD. (108 cylinders were already being used at addresses 209, and 398. Also, there are 180 4KB pages in every 3390 cylinders. So 29 cylinders is equal to 20MB.)
Create a procedure (to be invoked as part of the background initialization JCL, for example $0JCL) that will do the following:
For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* DEFINE THE SIZE OF THE DATASPACE | |// SYSDEF DSPACE,DSIZE=20M | |* DEFINE AND INITIALIZE EACH VIRTUAL DISK | |// VDISK UNIT=900,BLKS=40320,VOLID=QPVDS1,VTOC=008 | |/* | |/+ | |
·
·
·
| +--------------------------------------------------------------------------------+
This example reserves approximately 20MB of virtual storage for virtual disks. (Remember you do not need 20MB of real storage to support 20MB of virtual storage.) The virtual disk at address 900 uses approximately 20MB of that storage (40320 512-byte blocks, with 8 512-byte blocks of that reserved for the VTOC). (The virtual disk addresses were defined in Step 2.)
| Note: | Because of the structure of a virtual disk, blocks must be allocated in multiples of 960 blocks. So instead of 2048 512-byte blocks for 1MB of storage, you can only allocate 1920 blocks. |
Define a sequential file on a real disk for use later when backing up the VSAM user catalog (defined on the next step on a virtual disk). For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* DEFINE A SEQUENTIAL FILE FOR VDISK UCAT BACKUP | |// EXEC IDCAMS,SIZE=AUTO | | DEFINE NONVSAM (NAME(VDISK1.UCAT.BKUP) - | | DEVICETYPES(3390) VOLUMES(SYSWK1)) | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example creates a backup file called VDISK1.UCAT.BKUP.
| Note: | The above JCL does not work if it is used on FBA DASD. If only FBA
DASD is used, do one of the following:
|
Define a VSAM user catalog on the virtual disk using the DEDICATE option. For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* DEFINE A VSAM USER CATALOG | |// EXEC IDCAMS,SIZE=AUTO | | DEFINE USERCATALOG ( - | | NAME (VDS1.USER.CATALOG ) - | | DEDICATE - | | VOLUME (QPVDS1)) | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example creates a VSAM user catalog called VDS1.USER.CATALOG on volume QPVDS1 and dedicates the entire volume for this VSAM user catalog. (Volume QPVDS1 was defined in Step 3.)
Define a dbextent (VSAM cluster) on the virtual disk. For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* ADD CLUSTERS FOR THE DATA BASE VIRTUAL DISK | |// DLBL VDSUC1,'VDS1.USER.CATALOG',,VSAM | |* DEFINE CLUSTERS | |// EXEC IDCAMS,SIZE=AUTO | | DEFINE CLUSTER (NAME(SQL34.DDSK8.VDSK.DB) NONINDEXED REUSE - | | CNVSZ (4096) BLOCKS(39360) VOL(QPVDS1) - | | RECSZ (4089 4089) SHR(2)) CAT(VDS1.USER.CATALOG) | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example defines a dbextent named SQL34.DDSK8.VDSK.DB in the VSAM user catalog VDS1.USER.CATALOG (The VSAM user catalog was defined in Step 5.)
Update the cataloged procedure to include a DLBL statement for the new dbextent. For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* CATALOG DATABASE DBEXTENT LABELS | |// EXEC LIBR,PARM='MSHP' | |ACCESS S=IJSYSRS.SYSLIB | |CATALOG DTLDVDSK.PROC R=Y | |* ***************** SQL/DS DBEXTENT LABELS ************** | |// DLBL TSQLUC,'TSQL.USER.CATALOG',,VSAM | |// DLBL VDSUC1,'VDS1.USER.CATALOG',,VSAM | |// DLBL BDISK,'SQL34.BDISK.DTLD.DB',,VSAM,CAT=TSQLUC | |// DLBL LOGDSK1,'SQL34.LOGDSK1.DTLD.DB',,VSAM,CAT=TSQLUC | |// DLBL DDSK1,'SQL34.DDSK1.DTLD.DB',,VSAM,CAT=TSQLUC | |
·
·
·
| |// DLBL DDSK7,'SQL34.DDSK7.DTLD.DB',,VSAM,CAT=TSQLUC | |// DLBL DDSK8,'SQL34.DDSK8.VDSK.DB',,VSAM,CAT=VDSUC1 | |/+ | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example adds a DLBL statement for DDSK8 that identifies dbextent SQL34.DDSK8.VDSK.DB. (The dbextent was created in Step 6.) DDSK7 is one of the dbextents that belonged to the original internal dbspace storage pool.
Add dbextents to the new storage pool by following instructions included in the DB2 Server for VSE System Administration manual. (Refer to "adding and deleting dbextents".)
To avoid using too much real storage, it is recommended that you include at least two dbextents in the new pool. The first must be the virtual disk. The second, should be a physical dbextent that can accommodate the overflow from the virtual disk. You can use some of the dbextents from the original pool that contained the internal dbspaces (in this example DDSK7). Make the total size of both dbextents large enough to accommodate your current internal dbspaces and make the virtual disk as large as possible without over committing real storage.
Also, ensure that you add the virtual dbextent before you add any physical dbextents. The database manager searches the dbextents for a free page in the order that they were added.
Attention: Do not accidentally place the virtual disk in an existing storage pool that contains anything other than internal dbspaces. You will lose valuable data and a full database or pool level restore will be required.
The following is an example of the ARISADD member, which specifies how procedure ARIS250D will add and delete dbextents to and from pools:
+--------------------------------------------------------------------------------+ |POOL 9 | |ADD 8 9 | |DELETE 7 | |ADD 7 9 | |ARCHIVE | +--------------------------------------------------------------------------------+
This example adds dbextent 8 (DDSK8) to storage pool 9. (DDSK8 was identified in Step 7.) Ensure that you add the virtual disk dbextent to a new storage pool (reserved only for internal dbspaces). It also removes dbextent 7 (DDSK7) from the original pool that contained the internal dbspaces. It then adds it to the new pool (pool 9) that contains the virtual disk dbextent.
Back up the VSAM user catalog defined on the virtual disk into the sequential file on a real disk. For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |// LIBDEF PHASE,SEARCH=IJSYSRS.SYSLIB | |* THIS JOB UNLOADS A VSE/VSAM CATALOG USING THE REPRO COMMAND | |// DLBL IJSYSCT,'VSAM.MASTER.CATALOG',,VSAM | |// ASSGN SYS001,DISK,VOL=SYSWK1,SHR | |// DLBL CATOUT,'VDISK1.UCAT.BKUP',999 | |// EXTENT SYS001,SYSWK1,1,0,33315,75 | |// DLBL IJSYSUC,'VDS1.USER.CATALOG', X | | ,VSAM | |// EXEC IDCAMS,SIZE=AUTO | | REPRO INFILE (IJSYSUC) - | | OUTFILE (CATOUT - | | ENVIRONMENT ( - | | BLOCKSIZE (2068) - | | RECORDFORMAT (VARBLK) - | | RECORDSIZE (516) - | | ) - | | ) | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example unloads the VSAM user catalog VDS1.USER.CATALOG to the backup file VDISK1.UCAT.BKUP. (The backup file was created in Step 4.) The backup file will be used to restore the VSAM user catalog on the virtual disk whenever the VSE system is restarted. Restoring the VSAM user catalog redefines the VSAM space and cluster previously defined on the virtual disk and sets the high used RBA to what is was before the system restart, thus allowing the database manager to successfully use it.
Invoke the application server to add only internal dbspaces into this new pool. For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |* ADD INTERNAL DBSPACES TO THE DATABASE | |// LIBDEF *,SEARCH=PRD2.SQL340 | |// EXEC PROC=DTLDVDSK | |// EXEC ARISQLDS,SIZE=AUTO,PARM='SYSMODE=S,STARTUP=S' | | INTERNAL 50 1024 9 | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
This example JCL creates 50 internal dbspaces, each of 1024 4KB pages, in storage pool 9. (Storage pool 9 was created in Step 8.)
Create conditional JCL that does the following:
For example:
+--------------------------------------------------------------------------------+ |
·
·
·
| |// DLBL IJSYSCT,'VSAM.MASTER.CATALOG',,VSAM | |// ASSGN SYS001,DISK,VOL=SYSWK1,SHR | |// DLBL VDSBKUP,'VDISK1.UCAT.BKUP' | |// EXTENT SYS001,SYSWK1,1,0 | |// DLBL IJSYSUC,'VDS1.USER.CATALOG',,VSAM | |// EXEC IDCAMS,SIZE=AUTO | | LISTCAT CAT(VDS1.USER.CATALOG) ENT(SQL34.DDSK8.VDSK.DB) ALL (1) | | IF LASTCC NE 0 THEN DO (2) | | EXPORT VDS1.USER.CATALOG DISCONNECT (3) | | DEFINE USERCATALOG ( NAME(VDS1.USER.CATALOG) - (4) | | DEDICATE VOLUME (QPVDS1)) | | IF LASTCC NE 0 THEN CANCEL JOB | | REPRO INFILE (VDSBKUP ENVIRONMENT - (5) | | (BLOCKSIZE (2068) - | | RECORDFORMAT (VARBLK) - | | RECORDSIZE (516))) - | | OUTFILE (IJSYSUC) | | IF LASTCC GT 4 THEN CANCEL JOB (6) | | END | |/* | |
·
·
·
| +--------------------------------------------------------------------------------+
Place this sample JCL in front of your current application server startup job. It checks for the existence of dbextent SQL34.DDSK8.VDSK.DB in the VSAM user catalog VDS1.USER.CATALOG. If it no longer exists, the JCL restores the VSAM user catalog from the backup created in Step 4. The application server will then start normally and will use the virtual disk for internal dbspaces.
The ADD DBEXTENT and DELETE DBEXTENT operations are not recorded in the log. Since these operations update the directory (but not the database itself), problems can be encountered if you normally archive the database and then try to restore that archive with the ADD DBEXTENT or DELETE DBEXTENT occurring in between the archive and the restore. Archiving before and after you make changes to the virtual disk will assist you if problems occur. For more information, refer to the DB2 Server for VSE System Administration manual.
Your internal dbspaces can use a virtual disk to improve their performance. Virtual Disk Support lets you use a data space as a virtual disk. A virtual disk is much faster than a conventional disk because it uses main storage instead of DASD. The virtual disk appears to any program or job as just another disk, only faster.
However, virtual disk storage is temporary. All data on a virtual disk is lost when it is detached from a user ID or when the user ID logs off. For this reason, DO NOT use virtual disk for anything other than internal dbspaces. These dbspaces are only used as temporary workspace, so it does not matter if their contents is lost. The storage pool containing the virtual disk must NOT be used for any permanent dbspaces.
While the use of a virtual disk is restricted to internal dbspaces, they can be used to improve the performance of index creations, joins, sorts, and other operations that require temporary workspace.
Remember, anytime you increase your use of virtual storage, you can realize significant performance improvements, but only if you have the real storage to support it.
| Note: | It is recommended that database generation be done with real minidisks only. If you decide to generate a database which uses a virtual disk, ensure that the virtual disk is used in a pool containing only internal dbspaces. |
To use a virtual disk with internal dbspaces, you must:
A detailed example of how to complete these steps appears below. Please read all the steps before executing any of them.
This will be needed if problems arise during the setup for using a virtual disk and you need to restore your database to its previous state without any virtual disk.
Determine the size of the virtual disk to be added. It should be large enough for most sorts, but must not be so large as to cause excessive VM paging. Define this virtual disk in the VM Directory, similar to:
MDISK 0329 FB-512 V-DISK nnnnnnnn M
For information about defining a virtual disk in a VM Directory, refer to the VM/ESA: Planning and Administration manual.
Add the virtual disk, and possibly other dbextents, to a new storage pool. For information about using the SQLADBEX EXEC, refer to the DB2 Server for VM System Administration manual.
To avoid using too much real storage, it is recommended that you include at least two dbextents in the new pool. The virtual disk must be the first dbextent in the new pool. Other dbextents should be real minidisks to accommodate the overflow from the virtual disk. You can use some of the dbextents from the pool that originally contained the internal dbspaces. Make the total size of the dbextents in the new pool large enough to accommodate your current internal dbspaces.
Also, ensure that you add the virtual dbextent before you add any real minidisks. The database manager searches the dbextents for a free page in the order they were added.
If you are also using DB2 Server DSS, you should use SEPINTDB=Y to use your internal dbspaces in a data space, instead of using a virtual disk. If you still want to use a virtual disk, you MUST update your Storage Pool Specification file to specify 'BLK' and 'SEQ' for the storage pool containing the virtual disk. VM does not allow a virtual disk to be mapped to a data space. In this case, message ARI2018E will be issued identifying the virtual disk address.
Attention: Do not accidentally place the virtual disk in an existing storage pool containing permanent dbspaces. You will lose valuable data and a full database or pool level restore will be required.
When you run the SQLADBEX EXEC, you specify the actions to be taken by answering the prompts. When you see message ARI6145D, reply 1 (yes), to view the 'dbname SQLADBEX A' file created from the prompts.
Assume you have the following set up and are changing to use a virtual disk for internal dbspaces:
| Note: | Running the SQLADBEX EXEC will cause a break in the continuity of your log archives, so a database archive should always be taken. |
After starting the SQLADBEX EXEC and entering the information at the prompts, reply 1 (yes) to message ARI6145D. This will display the 'dbname SQLADBEX A' file in XEDIT; its contents can be reviewed, modified, or both. This file specifies the sequence of actions that SQLADBEX will perform. Given our assumptions above, the file will appear as follows:
ADD 9 8 <-- add virtual disk to pool 8 DELETE 5 3 <-- delete dbextent 5 from pool 3 DELETE 6 3 <-- delete dbextent 6 from pool 3 ADD 5 8 <-- add dbextent 5 to pool 8 ADD 6 8 <-- add dbextent 6 to pool 8 ARCHIVE <-- an archive will be taken
Refer to the DB2 Server for VM System Administration manual for more details, cautions and warnings concerning the adding and deleting of dbextents.
The last step of the SQLADBEX EXEC will update the 'dbname SQLFDEF Q' file, to match dbextents that have been added, deleted, or both. The 'CP LINK' command for the virtual disk in this file must be updated; this is documented in a following step.
This step will 'move' the internal dbspaces from the old pool to the newly added pool which contains the virtual disk, by using the SQLADBSP EXEC. You may also add permanent dbspaces to the database at this time (except into the new pool) or you can simply redefine the pool where internal dbspaces will be placed. Remember, this new pool, with the virtual disk dbextent, can ONLY contain internal dbspaces. For information about using the SQLADBSP EXEC, refer to the DB2 Server for VM System Administration manual.
In this step, you will edit and modify the 'dbname SQLFDEF Q' file to change the 'CP LINK' mode for the virtual disk dbextent. This is required to allow the virtual disk to only be formatted and reserved once per IPL CMS of the database manager. If this step is not performed, the virtual disk must be formatted and reserved prior to each start up of the database manager (for example, SQLSTART).
This is done by having the virtual disk linked to the database manager virtual machine twice. When the 'dbname SQLFDEF Q' file detaches the virtual disk, the second link remains attached to the machine and the formatting of the virtual disk is not lost. This second link and the formatting is done from the database manager's PROFILE EXEC (this is set up in the next step).
Be sure you have the production minidisk (normally 'Q') accessed R/W. XEDIT the 'dbname SQLFDEF Q' file. Locate the line containing the 'CP LINK userid cuu cuu W' statement for the address ('cuu') of the virtual disk. Change the CP LINK 'MODE' character from 'W' to 'M'.
Attention: If you delete the virtual disk extent and add it again (through the SQLADBEX EXEC), you must again change the LINK Mode character from 'W' to 'M'.
In this step you will modify the database manager's PROFILE EXEC so that the virtual disk will be CMS formatted and reserved each time the database manager virtual machine IPL's CMS. In addition, a second link to the virtual disk will be set up (see the previous step).
Attention: If an error occurs such that the virtual disk is not usable, the database cannot be brought up. In this situation, you must correct the error to make the virtual disk usable, or you must replace the virtual disk with a real minidisk at the same address (and at least the same size). The replacement minidisk must be formatted and reserved, as usual, before the database is brought up.
It is recommended that a separate EXEC be created to perform the LINK, FORMAT and RESERVE commands, and that this EXEC be called from the PROFILE EXEC. You can place the following statements in your PROFILE EXEC to initialize the virtual disk for usage:
'EXEC PREPVDSK' /* Call EXEC to Prepare Virtual Disk */ If rc ¬= 0 Then Do; Say "PREPVDSK rc =" rc; Exit rc; End
| Note: | The 'If' statement above will cause the PROFILE EXEC to end if an error is returned from the PREPVDSK EXEC. This assumes that the PROFILE EXEC will eventually invoke the SQLSTART EXEC after the virtual disk has been initialized. This is done because the database cannot be started if the virtual disk is not properly initialized. You may need to tailor this processing to suit your particular operational environment. |
The following is a sample 'PREPVDSK EXEC':
/* REXX */ Trace 'O '; Address 'COMMAND' /* Use this EXEC to FORMAT and RESERVE a Virtual Disk, */ /* that is used as the FIRST Dbextent of a Storage Pool containing */ /* ONLY INTERNAL DBSPACES. */ /* */ /* ATTENTION: This process, to use a Virtual Disk, requires that the */ /* CP Link Mode letter be changed from 'W' to 'M' in the */ /* SQLFDEF file for the CP LINK command for the DATABASE */ /* Address of the Virtual Disk. */ /* */ /* This EXEC should be called from the PROFILE EXEC of the Database */ /* Virtual Machine, to prepare the Virtual Disk for use. */ /* (once per LOGON/IPL of the Database Machine) */ /* */ /* The Virtual Disk MDISK is Linked R/O with an unused address, */ /* (which is refered to below as the PERANENT ADDRESS) so that */ /* that subsequent Detaches of the normal address (refered to below */ /* as the SQLFDEF ADDRESS) by this EXEC and the SQLFDEF file will */ /* NOT lose the FORMAT/RESERVE information. */ /* */ /* The Virtual Disk MDISK is Linked again, R/W, with its SQLFDEF */ /* address, for the FORMAT/RESERVE processing. This address is then */ /* Detached. It will be Linked again later by the SQLFDEF file when */ /* the database machine runs the SQLSTART EXEC. */ /* */ /* If the R/O Link of the Virtual Disk is detached by mistake, */ /* you MUST run this EXEC before running SQLSTART again. */ /* */ /********* UPDATE THE FOLLOWING 5 VARIABLES AS APPROPRIATE: *********/ dbname = 'dbname ' /* Database Name */ pdisk = '0cuu' /* Virtual Disk PERMANENT Address */ vdisk = '0cuu' /* Virtual Disk SQLFDEF Address */ vlabel = 'DDKnn ' /* Virt Disk Label (Dbextent Number)*/ ufm = 'Z' /* Unused Filemode Letter */ z=Diagrc(8?,'CP DETACH' vdisk) /* Be sure SQLFDEF Addr is NOT Linked */ z=Diagrc(8?,'CP LINK *' vdisk pdisk 'RR') /* Get PERMANENT R/O Link */ Parse Var z cprc . ; If cprc ¬= 0 Then Exit cprc z=Diagrc(8?,'CP LINK *' vdisk vdisk 'M') /* Get SQLFDEF R/W Link */ Parse Var z cprc . ; If cprc ¬= 0 Then Exit cprc 'SET CMSTYPE HT'; 'RELEASE' ufm; 'SET CMSTYPE RT' Push vlabel Push '1' 'FORMAT' vdisk ufm '(BLKSIZE 4096 NOERASE' /* FORMAT the Vdisk */ If rc ¬= 0 Then Exit rc Push '1' 'RESERVE' dbname vlabel ufm /* RESERVE the Vdisk */ If rc ¬= 0 Then Exit rc 'SET CMSTYPE HT'; 'RELEASE' ufm; 'SET CMSTYPE RT' z=Diagrc(8?,'CP DETACH' vdisk) /* Detach the SQLFDEF address again, */ Exit 0 /* ... it will be re-Linked by SQLFDEF during SQLSTART. */
Neither the ADD DBEXTENT nor the DELETE DBEXTENT operation is recorded in the log. Since these operations update the directory (but not the database itself), problems can be encountered if you normally archive the database and then try to restore that archive with the ADD DBEXTENT or DELETE DBEXTENT occurring in between the archive and the restore. For more information about this problem, refer to the DB2 Server for VM System Administration manual. Archiving before and after you make changes to the virtual disk will assist you if problems occur.