ADSM-L

Re: DB & LOG Volume layout - new

2006-01-24 15:31:49
Subject: Re: DB & LOG Volume layout - new
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 Jan 2006 15:26:27 -0500
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.

<Prev in Thread] Current Thread [Next in Thread>