Span database across multiple disks

[evandena]

Hi guys, first off this is TSM 5.5 on AIX.

Our main TSM guy is swamped getting other work done prior to a planned medical leave, so I'm going to try and pick up some of the TSM slack. Let me just say I'm no TSM expert, and only have an intermediate operating understanding of how it works.

I've noticed our backups and expirations taking quite a long time to finish. At one point, one expiration process had been running for a few weeks. I had to suspend backups for a day on a few occasions to let expiration catch up. Thankfully, we only rely on TSM as a secondary backup/recovery method.

I did a little digging, and found out that our database is living on one of our SAN arrays, as this was supposed to be faster than the pSeries local disk (I can't confirm this). This volume is also a destination for our daily Exchange and SQL backups, so it's getting hit pretty hard. Looking at nmon, this disk is at 100% io all the time. This appears to be the source of slow backups and expirations, or anything database intensive.

So, is there a way to span the DB across multiple disks to help the io load? Thanks for any help, and I apologize for being a noob.

 

[rgg]

Why don't you get some TSM performance tracing first before jumping down the rabbit hole? You're more than likely on the right path since it doesn't sound like your configuration follows "best practices," but there are some other factors that can cause slow expiration as well.

http://www-01.ibm.com/support/docview.wss?uid=swg21326204

 

[evandena]

Thanks.

Maybe I'll take a step back and do some number gathering. Beyond the dozens of other performance no-no's we're doing, I feel the 100% used disk is the biggest factor. By simply stopping backups, expiration probably went 20 times faster.

I'll take a good look at your link, thanks.

 

[evandena]

Just a follow up for the record.
We ended up migrating the database to a newer array and all of the problems are gone. This is the smoothest TSM has run in years.