ADSM-L

Re: Trouble when TSM-database reaches 100Gb?

2005-09-06 09:46:39
Subject: Re: Trouble when TSM-database reaches 100Gb?
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 6 Sep 2005 09:45:48 -0400
> I would be interested in hearing what others have to say
>on this matter.  When we moved from 10k rpm SSA drives (non-RAID,
>with cache on the SSA adapter) to 15k rpm FAStT RAID5 arrays, we saw
>a world of improvement on our server.  It made a huge improvement.  I
>attribute this to a combination of faster drives (15k rpm) and
>spreading the I/O across spindles using RAID5.

We firmly believe in stripping the TSM database (and any other mostly
random access database)
across as many spindles as possible.  Like any database, you have to tune
the disk layout.

A spindle is capable of a limited number of iops.  To get more random
throughput you need
more spindles, and, you need to make sure that all the spindles are working
for you all the time.
If you have a spindles that is not constantly being used it is a wasted
resource.

I'll describe one of our TSM databases (~140gb).  It is on a Clariion
array.  I created 6 luns - one each
on the 6 raid5 raidsets defined in the Clariion.  At the AIX level I pull
these 6 luns into a volume group and
create stripped logical volumes across the luns using a 32k strip size.
The database and log volumes
setup the exact say way.  The database uses 13 raw stripped logical volumes
and the log uses 3
stripped raw logical volumes.  Yes . . . .It's a PLAID!!!!

When I changed the TSM database from what amounted to a very minimally
stripped setup to the plaid our
backup times fell from 4-5hr to 1hr.  Expiration dropped form several days
to 12hr.

We use this same setup for almost all our Oracle databases - we create
plaids.  When we setup our
big sap databases (8tb, 8tb, 4tb, 2tb), we told EMC that we were going to
create plaids.  They told us
 quite firmly that this was a mistake and not to do it.  We did it anyway.
We use Veritas Volume
Manager (hpux systems) to be able to maintain the plaid across newly added
storage space
by re-stripping existing filesystems on the fly across the new storage.
It's been 3 years now, and
EMC seems amazed that the bottleneck on our symms are the busses, not the
drives.  We seldom have
performance issues related to not enough iops.   They now not only support
what we've done, they
recommend it to others.

At a recent EMC conference they made a big point in one sessions that the
number one reason
for performance problems in any disk subsystem is hot drives.  You have to
tune your disk
subsystem to prevent this, whether the disk system is a symm, dmx,
clariion, ess/shark,
fastt, ds8k/ds6k, ssa or  jbod. A disk that is not pulling it;'s share if
the i/o load is being wasted.

Rick


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.