ADSM-L

Re: backup performance with db and log on a SAN

2002-09-03 08:51:32
Subject: Re: backup performance with db and log on a SAN
From: Remco Post <r.post AT SARA DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 2 Sep 2002 10:48:35 +0200
On zaterdag, augustus 31, 2002, at 05:18 , Eliza Lau wrote:

I recently moved the 36G TSM database and 10G log from attached SCSI
disk
drives to a SAN. Backing the db now takes twice as long as it used to
(from 40 minutes to 90 minutes).  The old
attached disk drives are non-RAID and TSM mirrored.  The SAN drives are
RAID-5 and TSM mirrored.  I know I have to pay a penalty for writing to
RAID-5.  But considering the massive cache of the SAN it should not be
too bad.  In fact, performance of client backups hasn't suffered.

However, the day after the move, I noticed that backup db ran for twice
as long.  It just doesn't make sense it will take a 100% performance hit
from reading from RAID-5 disks.  Our performance guys looked at the sar
data and didn't find any bottlenecks, no excessive iowait, paging, etc.
The solution is to move the db and log
back to where they were.  But now management says: "We purchased this
very expensive 2T IBM SAN and you are saying that you can't use it."
Meanwhile, our Oracle people happily report that they are seeing
the performance of their applications enjoy a 10% increase.

Has anyone put their db and log on a SAN and what is your experience?

Yes we have. SAN is very bad for database performance. We used it as a
temp storage space while we were reorganizing the ssa disks on our TSM
server. The reason SAN attached storage gives poor performance is the
size of the disks. You now have just a few large disks for your
database, while in the past you probably had a few more smaller disks to
hold the same amount of data. Disk seek times have not kept pace with
disk size, so while the disks are a lot bigger, they take about the same
amount of time to find a block of data. Since almost each database read
access requires a seek, more spindles give more bandwith and this better
performance. Even worse in raid5, since now all disks must have read the
block of data before the raid5 controller can return anything.

Raid5 will give you another performance hit, especially if you have a
write-trough cache (or no cache at all) and not a write back cache.

You probably want to look into the cache-hit ratio on the raid5
controller, and see how you could improve that. Other than that, I still
feel jbod is the way to go for databases. More spindles are more
better... ;)

I have called it in to Tivoli support but has yet to get a callback.
Has anyone noticed that support is now very non-responsive?




server; AIX 4.3.3,  TSM 4.2.1.15

Thanks,
Eliza Lau
Virginia Tech Computing Center
1700 Pratt Drive
Blacksburg, VA 24060
lau AT vt DOT edu

---
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167
PGP keys at http://home.sara.nl/~remco/keys.asc

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams