Q and A

Asked and Answered

Divide and Conquer

How do you leverage 160 I/O channels in relationship to partitioning? Should we layout our partitions on different I/O channels?

Robert Catterall responds:

I wouldn't get down to that level. Here's the way I see it: Partitioning large tables can be an effective means of exploiting an infrastructure that provides 160 I/O channel paths to a pool of DB2 DASD volumes. Rather than try to hand-place tablespace and index partitions on specific DASD volumes, I'd prefer to let SMS perform that chore. I'd want to have all of the DASD volumes available for DB2 user data and indexes (meaning not the catalog and not the log data sets) placed into a single SMS storage group, or maybe two SMS storage groups. (At CheckFree we use one. You could use two if you want to put tables in one and indexes in another.) I'd then define one or more DB2 STOGROUPs with SMS placement of data sets specified (via VOLUMES('*') on the DB2 for OS/390 CREATE STOGROUP statement), and then associate my DB2 tablespaces and indexes with that STOGROUP or STOGROUPs. With a lot of volumes in the SMS storage group, you're likely to get a good spread across your I/O channels, with very little effort on your part as compared to the hand-placement approach.

For more information on this subject, you might want to check out the DB2 DBA column " Time to Reconsider SMS " from the Quarter 1, 2000 issue of DB2 Magazine.

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

Back to Divide and Conquer by Robert Catterall