==> In article <[EMAIL PROTECTED]>, Gordon Woodward <[EMAIL PROTECTED]> writes:
> Before I upgrade our TSM server to v5.2 (seems to be taking forever to do > due to small outage windows) I want to reorganise our database volumes so they > are a little more efficient. Is there any recommended maximum number of > database volumes a TSM database should have? Ours is spread across about 20 > different volumes of varying sizes, not the best makeup I am sure, hence why I > want to re-arrange it before hand. I'd say that your maxima would be ruled by other factors, such as some of those to which you allude: size &c. Best recommendation: try to keep your volumes on a 1:1 basis with your physical spindles. It's the best possible way to convey to TSM what the architecture of your underyling disk is. There'll be places where this breaks down. Huge disks is one place; You'll want multiple volumes just because you don't want to constrain the threads of execution operating on your DB. disk aggregation NAS devices (e.g. Shark) are another: you're so far from the physical abstraction there that you can forget much of the conventional wisdom of how to keep your DB safe. For example, you might not be nuts to ride without DB copies if you're using shark space. But for simple count-of-volumes, not really any limit. I've had as many as .. 34? 32, and four logvols. Two drawers of 9G SSA. - Allen S. Rout
