==> On Fri, 1 Jul 2005 07:37:44 -0300, Paul van Dongen <[EMAIL PROTECTED]> said:
> I was called to examine a TSM server in order to make some suggestions to > improve performance. Upon arrival, I found out a not-so-standard > configuration: > TSM 5.1.6.4 on HP-UX 11 > DB: 208 GB split on 208(!) volumes of 1GB each spread on 4 LUNs on an EMC box > (95% in use) > Log: 10 volumes of 1GB each, all on the same EMC LUN > Diskpool: 101 volumes of 1GB each, all on the same EMC LUN [...] > I am trying to talk to the admin of this server to upgrade to 5.2 or 5.3 and > to review their disk config, but would like to hear from you if someone has > been trough something alike, and of course the line of action that was taken. I'd bet that your client admin went all the way through the "multiple TSM volumes for IO parallelism" and out the other side. My suggestion would be to make the DB volumes something like 10 times as big. The log is written serially, don't worry so much about lots of cylynders for it. But I don't know that 4 hours is all that evil a time for a 200-some GB DB backup. 200 GB in 4 hours is something like 14MB/s; That might be "perfectly tuned LTO 1"... Or it might be "slightly damaged 3590" or it might be "3592 with a millstone around its' neck"... One way I moved my DB backup bottleneck was to start backing up databases to a remote TSM server. This let me toss data straight to disk, and also add under-the-covers copies of the DB backups. If you were to do something like that, you might find that the bottleneck is really in your tape architecture. The nice thing is, you can set up some other TSM server, define the devclass on your ailing box, and run a snapshot without even fiddling with your current production DB backup streams. - Allen S. Rout
