No wars! I also agree there are good products out there.
But the question will be: can these products offer striping for Oracle
OPS/RAC?

Using EMC striping would allow this, I believe!

note: I'm not working for EMC

Regards,

Waleed

 Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the company

-----Original Message-----
Sent: Wednesday, April 03, 2002 12:41 PM
To: Multiple recipients of list ORACLE-L


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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Khedr, Waleed
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to