DB2 and DFSMS

Storage Group requirements

DB2 data is usually very well behaved, in that it grows very slowly, with no real unexpected peaks & troughs. The good news is that this means that you can easily run your main DB2 database pools at 90%+.
In theory, DB2 works best if all the user databases are combined into one big pool. SMS then spreads the data over several disks, and irons out (more or less) DASD hotspots. In practice, this will never work, of course. It is always a good idea to keep production data well segregated from development, and probably also best to keep Acceptance Test data in its own pool too.
On top of that, you will always get an odd file or two which really needs tip top performance, and won't get it if they are contending with all the other DB2 databases. These are best segregated into their own pool.
A very active DB2 tablespace can suffer due to UCB queuing. If you have an RVA2, or EMC hypervolumes, then this can be fixed by splitting the tablespace over several volumes. This isn't as easy as it sounds, as you cannot allocate a DB2 database without secondary extents. This means that if, say you allocate a file with 200 cyls primary and 200 cyls secondary, and specify that it can go onto 20 volumes, then it will initially grab a 200 cylinder allocation. When that 200 cylinders fills up, it will not switch to a new volume, it will simply add a secondary extent of 200 cylinders on the same volume. The only way you can guarantee to get the dataset to go multi-volume, is to allocate it on disks which only have 200 cylinders free. So you need to define a special storage pool, which contains a few 200 cylinder hypervolumes (+room for the VVS and VTOC and index).

If you are using an RVA2, then you will probably need to allocate filler datasets, to leave just sufficient space for a single database extent on each volume. That forces the database to use multiple volumes.

The advent of PAV (parallel access volumes see the ESS PAV section ) changes this, as it is possible to have several, highly active data sets on a volume without performance problems. The operating system can then schedule several IO operations to the volume concurrently. Dynamic PAV is best for this, as it will switch aliases from quiet volumes to busy volumes.
Other problem areas are the BSDS & Active logs, which need to be segregated, preferably on different DASD subsystems. These are best put into a separate DB2 system pool, and placed using GSPACE.

So the Storage Pool requirements then are:

• system pool (or pools). You may need two pools, one for the recovery logs, and one for the systems datasets. Some people put tables in one pool and indexes in another to boost performance
• normal production databases
• development databases
• possibly, acceptance test databases
• high performance, or 'difficult' databases.

Converting DB2 data to SMS

Before conversion, make sure you have the correct management classes in place, have worked out a suitable storage pool plan and your ACS routines are coded to deal with DB2 data. There are two ways to convert DB2 data to SMS. If you can afford it, set up new, empty SMS pools and move the data into it. If you can't afford the space, then you have to convert in place.

Convert by Migration

This is probably the easiest way to convert if you don't have too many databases. You need to have enough spare disks available to allocate empty pools to convert into, and enough system downtime to do the moves. These are two good reasons not to use Convert by Migration for large amounts of data. You can move the data using storage utilities like DFDSS or SAMS, but this is one good opportunity to let your DBAs do the work for you using their own reorg

There is another advantage of using DBA utilities, they will reorganise the databases internally, and re-optimise the access paths through them. So all the databases are now under SMS, and have just been performance tuned! That makes your SMS systems look good.

Convert in place

This is probably the only practical way to convert hundreds of gigabytes of databases. It is best beforehand, if the DBAs convert the DB2 stogroups to SMS storagegroup equivalents, and make all allocations non specific '*'s. If DBAs want to place

I'd suggest that you practice this on a small subset of the data. What you want is a discreet application that the DBAs have isolated on a small number of disks, say about 8. That conversion will give everyone the confidence to do the rest. If all your databases are single volume then its easy!, Just use DFSMSDSS CONVERTV or equivalent, volume by volume. If you have multi-volume databases, then all the volumes on which a database exist, have to be converted in the same job. If you have a loads of multi-volume, then you really need to convert all the volumes in one DFDSS statement. This is not as bad as it sounds, I've seen 600GB converted in 90 mins.

DB2 multi-volume allocation

The way DB2 handles multi-volume allocations can be a bit confusing to storage administrators. You cannot define the DB2 files using IDCAMS with a volume(* * *) statement, and you cannot use a dataclass with multi-volume capability. The DB2 file definition is an SQL statement

 CREATE STOGROUP name
        VOLUMES(*)

The files will then be potentially allocated on all the volumes in the SMS storage group, or up to 59 volumes, whichever is smaller. If you look at a VSAM cluster component with an IDCAMS LISTCAT, you will NOT see any candidate volumes. This is because, when DB2 wants to extend a dataset, and the file is full, it issues ALTER ADDVOLUMES to the file until it adds enough candidates for all the volumes in to pool, or up to 59 in total. Once it has successfully allocated another volume, it then issues ALTER REMOVEVOLUMES to delete all the candidates that it has not used.
Do not override this by adding volumes yourself. If the file ends up with more than 59 volumes in total, then the ALTER REMOVEVOLUMES will fail, and DB2 will stop the table. The only way out of this is to use REMOVEVOLUMES yourself to clear out the candidates.

DB2 UDB for Windows, Unix and Linux has two types of tablespaces called SMS (System Managed Space) and DMS (Database Managed Space). SMS in that context is not the same as SMS, or DFSMS discussed here.

back to top

By entering and using this site, you accept the conditions and limitations of use