We're in the process of installing TSM 6.2 on a new system, to replace our current TSM 5.5 system which has a 250gb database. We're going to use the export-import method of migration, to eliminate the possibly long downtime of an uprgade-in-place. It was time to update the old hardware anyway. I'm counting on the database being about 350gb on TSM6 after the migration is complete. I'm at the point of allocating space for the DB2 database, which I want to do very carefully for such a big TSM system. A backup/restore to change the layout would involve unacceptable downtime.
Up until now, the conventional wisdom for the TSM6 DB2 Database went something like, "Make 4 containers, or perhaps 8. Put each on a separate LUN." It also says that you should allocate space now, at the start, for how large you think the database might eventually get. That was about all that was said, other than the obvious things like using your fastest disks, not sharing the disks/LUNs/Unix Filesystems with anything else, and other general disk performance motherhood and apple pie. This had me slicing and dicing big RAID arrays in my SAN box into lots of little LUNs. Bad idea. Then along came this recent presentation "DB2 for TSM Administrators" http://www.ibm.com/support/docview.wss?uid=swg27020613&myns=swgtiv&mynp=OCSSGSG7&mync=E which has a new recommendation to use just 1 huge container, in a big RAID5 or RAID10 array. The thing that was made clear by this presentation is that if you're using a SAN box which divides up space in such a way that a single physical disk might contain parts of more than one LUN, you're hurting performance. This is common with SAN systems such as IBM DS that let you define multiple LUNs per RAID array. With DB2 striping across containers, you could wind up striping across parts of the same physical drive, which would be very bad thrashing. I was glad that this presentation pointed this out, by simply recommending one container per RAID array, rather than one container per LUN. This makes sense. But I've got a big problem with all this. There's very little flexibility here. You have to employ too much clairvoyance, and allocate as much space initially for your database as it will ever need. Sorry, my crystal ball fails me here. Containers should be roughly the same size, and when you add one there may be hot spots and other forms of I/O imbalance. Growth can be disruptive. When some Very Important Faculty Member walks in and demands to backup 10 million files, but the database is already full, I cannot take the downtime to backup and restore the entire database just to rebalance I/O. I need to figure out how to grow it incrementally and non-disruptively - like with TSM5. So I'm thinking of going in a completely different direction. Lots of little containers. You can have as many as 128. The "TSM V6.1 Technical Guide" redbook says that DB2 uses striping across containers. So I'm thinking of using pairs of 36gb 15Krpm disks to make 36gb RAID1 (simple mirroring) arrays for small containers, and let DB2 do the striping. I'll only use as many as I need at the time. Either the SAN or AIX LVM can do the mirroring. Then if it grows, I can add more of these smaller containers as needed, one at a time. When I add containers, there will still be hot spots and an I/O imbalance, but it should be less severe and of shorter duration, because the new container will be relatively small. And it will eliminate the consideration for matching stripe sizes between the RAID box and DB2. This way I can add disks as needed, when they're actually needed, much like the TSM5 B-tree database. With 36gb containers there's a theoretical limit of 4608gb here, but I'll need to subdivide into separate instances for other reasons long before approaching that size. It says that adding a container causes some kind of a reorg which can consume resources. How bad is the performance impact of that reorg? If the newly added container is relatively small, will that reduce the resources needed for this reorg? Even if it's a large impact, I could still do it on a weekend. Is this concept of using lots of little RAID1 containers for the TSM6 DB2 database a good idea or not? Roger Deschner University of Illinois at Chicago [email protected] ==== "Research is what I'm doing when I don't know what I'm doing." ==== ========================= -- Wernher von Braun =========================
