This is true - but then again... raw doesn't cost
anything...
...Quick IO and cached Quick IO do :-)
I only raise the point because in these days of lvm's
(gui and/or otherwise) and "enterprise" backup
products, I often fail to see the "managment
difficulties" with raw devices.
Cheers
Connor
- Gaja Krishna Vaidyanatha <oraperfman_at_yahoo.com>
wrote: > I don't want to start a "technical religious
war"
> here. Nevertheles, I am not a great fan of "raw
> devices" especially after the advent of comparable
> I/O
> options such as Direct I/O within Oracle which
> allows
> you to keep your file system layout and yet have
> "raw
> device comparable" performance. Plus options such as
> Quick I/O and Cached Quick I/O from Veritas provide
> similar performance and "ease of maintenance and
> management".
>
> Regards,
>
> Gaja
>
>
> --- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> > So it's great that EMC is offering striping on
> the
> > hardware level that
> > should be good idea for implementing striped raw
> > device.
> >
> > -----Original Message-----
> > To: Multiple recipients of list ORACLE-L
> > Sent: 4/2/02 6:28 PM
> >
> > Hi Waleed & list,
> >
> > The issue I raised about "queuing" was within the
> > context of sequential writes to the various
> "stripe
> > units" within a striped volume. If you have a
> 4-way
> > stripe and there are 4 dirty disk blocks (1 on
> each
> > stripe unit) that needs to be written to each of
> the
> > 4
> > disks, the LVM-mid-layer should be able to get
> them
> > down to their respective disks, independent of one
> > another, not one after the other. If the dirty
> disk
> > blocks are not written independent of one another,
> > there will be no advantage of "striping" for
> writes.
> > And "pure striping" should cater to I/O
> scalability
> > for both reads and writes.
> >
> > Regards,
> >
> > Gaja
> >
> >
> >
> > --- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> > > HI Gaja & list,
> > >
> > > I am trying to find the truth here! I was told
> by
> > > the storage group that EMC
> > > has striping now and this what I'm researching.
> > >
> > > Gaja, what you described as a problem during
> > WRITES
> > > to striped EMC is a
> > > typical procedure in any striped volumes.
> > >
> > > There is a mid layer that has to map logical I/O
> > > addresses to physical disk
> > > addresses.
> > >
> > > If you are using Veritas LVM then all
> reads/writes
> > > requests will be queued
> > > to the LVM and will do exactly as you mentioned.
> > >
> > > There is a queue but the difference is big. You
> > > have a queue with many
> > > servers serving the queue requests
> simultaneously.
> > >
> > > Please check powerlink.emc.com
> > >
> > >
> > > Regards,
> > >
> > > Waleed
> > >
> > > -----Original Message-----
> > > Sent: Tuesday, April 02, 2002 12:38 PM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > > Waleed & list,
> > >
> > > To define the terms we have on hand:-
> > > A contiguous meta volume requires the hyper
> > volumes
> > > to
> > > be sequential. A non-contiguous does not require
> > the
> > > hyper volumes to be sequential.
> > >
> > > I want to reiterate again that the concept of
> > "pure
> > > striping" at the hardware level, is still not
> > there
> > > in
> > > EMC, even though you have documentation that
> > claims
> > > that you do. Let me explain.
> > >
> > > When you look at "pure striping", there are 2
> > > aspects
> > > to it :-
> > >
> > > 1) The read aspect
> > > 2) The write aspect
> > >
> > > Take an example of a 4-way striped volume. The
> > read
> > > aspect provides us the capability for all 4
> drives
> > > to
> > > independently spin and service I/O from each of
> > the
> > > drives. This the EMC device does, after the data
> > has
> > > been placed on all hypers that support a meta
> > > volume.
> > >
> > > The write aspect needs to offer the same
> > > functionality. So, if you are writing to 4
> > distinct
> > > blocks (each on 1 disk), then each drive should
> be
> > > able to write 1 block in an independent fashion.
> > >
> > > That is where, the EMC hardware striping is not
> > > complete. This is because, the 4 blocks that
> need
> > to
> > > be written to the "meta volume" with 4 hypers
> > > (regardless of whether it is contiguous or not),
> > > will
> > > happen in "sequential" fashion. Meaning, to
> write
> > 4
> > > blocks into the "striped volume", the first
> block
> > > will
> > > be written to the first hyper, followed by the
> > > second
> > > block to the second hyper and so on. As you can
> > see
> > > the blocks that need to be written are queued
> up,
> > so
> > > that they are written in a sequential fashion on
> > the
> > > underlying hypers. This can and will cause
> severe
> > > write-intensive I/O bottlenecks.
> > >
> > > Why is this implemented this way? No specific
> > > reasons,
> > > except, "that is how it is right now". It has
> been
> > > rumored that microcode 5x68 or 5x69, will do
> that.
> > > Remains to be seen.
> > >
> > > So all the EMC "striping" does right now is to
> > > alleviate the problem of read-intensive
> operations
> > > not
> > > hammering a single drive, provided the data is
> > > spread
> > > across all the underlying hypers. I am not very
> > > familiar with the Engenuity product offering,
> > hence
> > > cannot comment on that, but from what I have
> > heard,
> > > it
> > > is a software-based volume management product.
> > >
> > >
> > > Best regards,
> > >
> > > Gaja
> > >
> > > --- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM>
> wrote:
> > > >
> > > > It looks like it's available now.
> > > >
> > > > This is from: ResourcePak for Windows Version
> > 3.2
> > > > Product Guide
> > > >
> > > > "Symmetrix Microcode level 5x65 includes
> support
> > > for
> > > > concatenated
> > > > (contiguous) and striped metavolumes.
> > > > Noncontiguous metavolumes (including striped)
> > > > require EMC Enginuity(tm)
> > > > (5x66 microcode) or higher."
> > > >
> > > > Regards,
> > > >
> > > > Waleed
> > > > -----Original Message-----
> > > > To: Multiple recipients of list ORACLE-L
> > > > Sent: 4/1/02 5:38 PM
> > > >
> > > > Waleed & list,
> > > >
> > > > I researched this issue recently and found out
> > > that
> > > > the meta volume was "concatenating a bunch of
> > > hyper
> > > > volume". As you know, concatenation is NOT
> > > striping.
> > > > The hyper volumes get filled with data one
> after
> > > > another, eventually giving you the "simulation
> > of
> > > a
> > > > striped volume", when all hypers are filled
> with
> > > > data.
> > > >
> > > > I don't know about the "single-host vs.
> > > multi-host"
> > > > addressibility issue. There are plans for
> > > supporting
> > > > "true striped volumes" in microcode level 68
> or
> > > 69.
> > > > From some "reliable sources" that does not
> look
> > > like
> >
> === message truncated ===
>
>
> =====
> Gaja Krishna Vaidyanatha
> Director, Storage Management Products,
> Quest Software, Inc.
> Co-author - Oracle Performance Tuning 101
>
http://www.osborne.com/database_erp/0072131454/0072131454.shtml
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Gaja Krishna Vaidyanatha
> INET: oraperfman_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from). You may
> also send the HELP command for other information
> (like subscribing).
Connor McDonald
http://www.oracledba.co.uk (mirrored at
http://www.oradba.freeserve.co.uk)
"Some days you're the pigeon, some days you're the statue"
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: =?iso-8859-1?q?Connor=20McDonald?=
INET: hamcdc_at_yahoo.co.uk
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Thu Apr 04 2002 - 05:53:20 CST
