I had also such an experience. I was at a customer who had a 250 (!) GB TSM
DB allocated on 8x34GB LUNs of a DMX box. Obviously the LUNs where part of RAID
groups in the DMX that were shared with other applications (in this case, a
production Oracle DB). While the access was random, things went fairly well,
but when we needed more of the DB (expiration and especially dbbackup) things
would go crazy. Full Dbbckups took in excess of 5 hours, and we saw plenty of
"hot disks" during the process.
I wasn't a big fan of "striping all" myself, bu I decided to give it a try.
The customer's storage admin told me simply "It won't work", but I went on.
I deleted the TSM DB and created eight striped RLVs, each of them using 4
8,5GB "pieces" of each LUN. The RLVs had 32k stripe size (So the average 256k
dbbackup IO would be satisfied using all four disks) and were allocated in a
sort of round-robin way (first RLV from disks 1-2-3-4, second RLV from disks
2-3-4-5 and so on).
To cut it short, db backups are now made in 1h40m. And they have now time to
do expirations and storage pool backups.
Hope this helps,
Paul
-----Original Message-----
From: ADSM: Dist Stor Manager on behalf of Richard Rhodes
Sent: Tue 1/24/06 18:26
To: ADSM-L AT VM.MARIST DOT EDU
Cc:
Subject: Re: DB & LOG Volume layout - new
I don't think you will ever get a definitive answer. There are too many
ways to setup a disk
system, and different people have different philosophies.
For example, here's what we do . . . . kind of radical, so hang on . . .
For our Oracle databases (random I/O type transactions) we've moved
from
the standard "everything
on it's own spindle" to where now we cross stripe - use disk stripping
(stripped meta vols on symm/dmx
and raid5 luns on clariion), then, stripe across that at the OS level.
It
gives a complete
uniform workload across your spindles for RANDOM access jobs. EMC is
amazed at how well
our DMX's and symms perform on our SAP systems. They told us NOT to do
this . . . .now they
really like the idea . . .as does Oracle.
I have TSM setup the same way - It uses raid5 luns in Clariion storage -
one lun from each raidset, so
I've got a part of all spindles in the clariion, then, I have stripped
AIX
logical volumes (32k) across
all the Clariion luns. From what I can see, it flies!!!! Yes, other
applications are on those
raidsets . . . that's life with 140gb disk drives.
My storage pools are on a different disk subsystem and are NOT cross
stripped, since their
access is mostly sequential.
In general for just about ANY system we set storage up for, we stripe as
far and wide as possible.
A disk drive in an expensive disk subsystem that isn't doing many I/O's
is
a waste of money, and,
a lun confined to one or a couple spindles is not guaranteed bandwidth,
but
rather a
guaranteed bandwidth limit.
So, there you have it . . . another way to set it up.
Lloyd Dieter
<ldieter@ROCHESTE
R.RR.COM>
To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor
cc
Manager"
<[email protected]
Subject
.EDU> Re: DB & LOG Volume layout - new
01/24/2006 02:48
PM
Please respond to
[email protected]
om
I've been watching this thread with interest, as some of the posts
contradicted what I thought I knew.
Using nmon, I've watched a couple of systems (AIX, TSM 5.2) running
expiration and DBbackups that have the DB vols set up according to the
"one volume per spindle" premise that appeared to have spotty "hot"
disks,
that is the I/O was not distributed evenly across the different volumes.
One drive would have a lot of I/O, then another, etc.
I've always striped them, in hardware if it was available, and using LVM
if it was not. This gave fairly even I/O, but I admit that doesn't mean
that it was the fastest method.
I'd love to have a definitive answer here, because I've heard it both
ways, and when I've asked support, they didn't seem to know.
I'd like someone "piled higher & deeper" to give a conclusive
answer...anyone?
-Lloyd
On Tue, 24 Jan 2006 14:28:55 -0500
"Allen S. Rout" <asr AT UFL DOT EDU> wrote thusly:
> >> On Tue, 24 Jan 2006 15:43:57 +0100, Dirk Kastens
> ><Dirk.Kastens AT UNI-OSNABRUECK DOT DE> said:
>
> > How do you get the occupancy of a database volume? With Q DBVOL I
only
> > see the available space (size of the formatted volume) and the
> > allocated space (what is assigned to the database). In my case both
> > are the same for all volumes.
>
> OK, I'll just blush there. What I was describing was incorrect. I've
> got a little space unallocated on all of my databases, for a rainy
> day, and that appearance is similar to what I was describing.
>
> I still think Paul is right, though. If I wave my hands really hard,
> will that convince you? Or do I need a Ph.D.?
>
>
> - Allen S. Rout
-----------------------------------------
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.
|
