Q and A

Asked and Answered

We are already at the 2G limit for the DBM1 address space and our machine is only an R95. Do you really have the same need to separate data sets by volume as much with the new DASD technologies?

Robert Catterall responds:

In your note, you state that "we are already at the 2G limit for the DBM1 address space and our machine is only an R95." This statement implies a belief that a "bigger" (in other words, more MIPS) server will require more DBM1 virtual storage. Actually, DBM1 virtual storage consumption is not directly related to the size of the server on which DB2 is running, although a bigger machine could conceivably support a larger workload with more concurrent threads, and that would increase virtual storage consumption. A good way to relieve pressure on DBM1 virtual storage is to move a good chunk of your bufferpool space to hiperpools. Additionally, if you are using dynamic statement caching, you should consider using a data space for the EDM pool elements associated with cached prepared SQL statements. These steps could perhaps free up enough DBM1 virtual storage to allow you to define more data sets (partitions) that will hold compressed data (you will have freed up space that could be used to hold compression dictionaries).

Do you need to separate DB2 data sets by volume in order to achieve good DASD I/O performance? Not directly. That is to say, you don't have to hand place data sets on volumes to achieve good performance if you are using current-generation disk technology. When you partition tablespaces, you increase the count of data sets; and, if you have defined a lot of volumes in your disk subsystem, even system-managed data set placement is likely to result in pretty good data set spreading and separation. It's largely a matter of your I/O rate to DASD. With a high enough rate, partitioning can improve performance by reducing contention within the disk subsystem.

See a complete archive of reader/author Q&As .

Back to Divide and Conquer by Robert Catterall