1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

Span database across multiple disks

Discussion in 'TSM Database' started by evandena, Dec 14, 2012.

  1. evandena

    evandena New Member

    Joined:
    Mar 25, 2008
    Messages:
    42
    Likes Received:
    0
    Occupation:
    Systems Analyst
    Location:
    Madison, WI
    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.
     
  2.  
  3. rgg

    rgg Member

    Joined:
    Apr 17, 2009
    Messages:
    120
    Likes Received:
    19
    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
     
  4. evandena

    evandena New Member

    Joined:
    Mar 25, 2008
    Messages:
    42
    Likes Received:
    0
    Occupation:
    Systems Analyst
    Location:
    Madison, WI
    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.
     
  5. evandena

    evandena New Member

    Joined:
    Mar 25, 2008
    Messages:
    42
    Likes Received:
    0
    Occupation:
    Systems Analyst
    Location:
    Madison, WI
    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.
     

Share This Page