Hi
The large disks you are talking about, are you meaning large as 36GB, 72GB
an so on, or are you talking about LUN-sizes?
In a shark, you can have very large LUN:s, but they will consist of a
large number of smaller SSA-based hard drives. This means that you will
not have a performance impact on the disks.
Normally performance issues on TSM / SAN has to do with having disks and
tapes on the same HBA. DB transactions is very randomly written, so if you
for example are doing migration, TSM will write to both disks and tape(DB
transactions to disk, migration from disk, migration to tape). This will
have a huge impact, as the HBA is arbitrated(which means only one write
can be done at a time). Also, doing backups and migration directly to
tape, assumes the ablility to write continous, sequential data. If you
have the DB on the same card, your clients, or the TSM server, won't be
able to stream data to the tapes, leading to poor performance.
Eliza, I'd suggest you use somekind of monitoring tool, like the Storwatch
specialist, to see throughput from/to disks and tape. I'm sure that if you
separate the disks from the tape, you will see a performance upgrade.
How many HBA:s do you have in your Shark?
Also, check to see that the logs, diskpook and database is not on the same
volumes. This will also generate bad performance.
The best practice is to have db & log on one HBA, diskpool on one HBA, and
tape drives on one or more HBA:s(depending on amount of tapes drives).
This is however recommended for large environments, with > 200 mid-size
clients.
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Exist i Stockholm AB
Propellervägen 6B
183 62 HÄGERNÄS
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Remco Post <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
2002-09-02 10:48
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: backup performance with db and log on a SAN
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
> [EMAIL PROTECTED]
>
---
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
