RE: S.A.M.E

I think the single 0+1 set makes sense when you have a "limited" number of spindles (how's that for being vague?) and you have no idea how the I/O is going to get distributed by the time all the database changes and application changes that were never in the original plan go in. (Do you mean that actually happens?! DUH!) The way it gets done here -- and this isn't anything over which I have much control -- is that the heavy duty, hard hit (or crappy written) applications get put on storage array(s) (SANS if you like to use more high tech terminology). If a file system is getting hammered and data files can't be moved for whatever reason, then additional controllers and spindles can be mapped to that file system to compensate. But that approach works only if you have the cash to throw the necessary hardware at the problem.

If you are in a situation where you have, say 10 spindles, and that's all you get buddy ol' pal, then making two 5-drive stripes and mirroring them to form a single file system seems like a good approach to me.

> -----Original Message-----
> From: Rajesh.Rao_at_jpmchase.com [mailto:Rajesh.Rao_at_jpmchase.com]
> Sent: Tuesday, May 13, 2003 5:21 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: S.A.M.E
>
>
>
> Thanks for sharing your experiences, Stephen. I have tried to
> gather as
> much information on this as possible. Could not find any real time
> experiences, or benchmarks of implementing SAME. Theres a
> white paper out
> there at
> http://technet.oracle.com/deploy/availability/listing.htm#coll
> ateral, with
> some statistical data, but that test seems to have been
> carried out with 8
> client connections.
>
> SAME's being touted as the panacea for all your I/O problems.
> And I feel it
> is. But after reading the paper, I also feel, why not create one huge
> tablespace for all my database objects???? OFA is no longer a
> consideration????
>
> SAME advices you to stripe everything across all the disk
> drives, and hopes
> that the sequential I/O's, should be alleviated by a huge
> NVRAM Cache, and
> by making Oracle perform I/Os in chunks of 1 Mb, and setting
> the stripe
> width to 1 Mb.
>
> We are laying out the development environment for a 9i RAC
> installation (so
> raw volumes), with EMC symmetrix storage 30x9Gb and a 32 Gb
> NVRAM cache.
> Heavy random I/O loads expected.
>
> Odd numbered Redo Logs ( Mirror)
> Even numbered Redo Logs ( Mirror)
> Archive Logs ( 2 way stripe + mirror )
> System, RBS and TEMP files ( 4 way stripe + mirror )
> Data and Index files. ( 8 way stripe + mirror )
>
> Testing will be done to see if it can scale to production volumes.
>
> Thanks
> Raj
>
>
>
>
> Stephen Lee
>
> <Stephen.Lee_at_D To: Multiple
> recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> TAG.Com> cc:
>
> Sent by: Subject: RE:
> S.A.M.E
> root_at_fatcity.c
>
> om
>
>
>
>
>
> 05/13/2003
>
> 11:41 AM
>
> Please respond
>
> to ORACLE-L
>
>
>
>
>
>
>
>
>
>
> I don't know if it has been debated here. There was a post I
> did a while
> back about my experience with it. In my case, I did it
> because, at the
> time, I was a sys admin in a shop with no Oracle DBA, and I
> didn't have the
> time or inclination to mess with a complex file system setup
> for an Oracle
> database. So I put the Oracle binaries and all data files on
> one big 0+1
> file system made up of two 30-drive stripes (60 drives total for the
> mathematically challenged) across 10 wide scsi controllers (6
> drives per
> controller for the mathematically challenged) using Solstice
> Disk Suite
> (4.1
> iirc). No storage arrays were used. This was all JBOD, so
> there was quite
> a collection of cables connected to the box.
>
> It worked fine. But, in this case, I think the I/O capacity
> was so far
> above what the box could ever use that I was guaranteed
> success. The box
> was a Sparc 4000 with only six 250 Mhz CPU's (iirc).
>
> Besides the simplicity of dealing with one large file system, another
> motivating factor was cost: At the time, using JBOD allowed
> me to purchase
> approximately three times the storage (i.e. ->spindles<-) as
> what I could
> get using even the lowest priced, Plain Jane storage arrays.
> My philosophy
> was something like: For the money I have, I can get a golden,
> teflon lined
> pipe one foot in diameter; or I can get a big, nasty concrete
> pipe three
> feet in diameter. Now which will give me the greater flow
> rate (if the
> analogy is correct)?
>
> Since this was to be a test system, at some point in the
> future its role
> would probably change; so using a bunch of JBOD, consisting
> of the 6-drive
> JBOD boxes Sun had at the time, gave me the option of moving
> those JBOD
> boxes around to other systems as testing requirements
> changed. When the
> test database, which was a copy of the production database,
> was benchmarked
> with the application, it ran at three times the rate of the production
> database which was on 10 250 Mhz CPU's of an E10K using an
> EMC tower. Keep
> in mind that, in those days, storage array caches were MUCH
> smaller, and
> EMC
> was doing stripe with parity (called "RAID-S").
>
> I have asked some people experienced in storage management
> about this when
> I
> have encountered them. I've gotten a lot of opinions, but only one of
> these
> people had actually conducted a real live experiment with a real live
> database; and ON HIS PARTICULAR SYSTEM, AT THAT TIME
> (hardware changes!!),
> he got better performance using the "traditional" approach of using
> multiple
> file systems. I think the people who would truly know this
> stuff would be
> the those who set boxes up for TMPC/D benchmark testing. I
> don't think
> they
> use "SAME"; but those systems rarely represent a "typical"
> customer system.
>
> I would be curious to see how an approach somewhere in
> between "SAME" and
> "traditional" works, where you attempt to put I/O of a
> particular nature on
> different RAID sets. For example, data files -- ALL data
> files -- on one
> set; alternate redo log groups on two sets, since these
> alternate between
> write (when logging) and read (when archiving); and have
> archived logs on
> another set. One problem with that alternating redo is that
> the groups
> don't always get used in the order they were created.
>
> There, I have just provided you some stuff to further muddy
> the water. If
> you have any URL's to published REAL test results, I would be most
> interested.
>
> > -----Original Message-----
> >
> > Have been trying to understand S.A,M.E. I am sure this must
> > have have been
> > debated earlier on this list. How do I access and search the
> > archives for
> > it?
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Stephen Lee
> INET: Stephen.Lee_at_DTAG.Com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>
>
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author:
> INET: Rajesh.Rao_at_jpmchase.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephen Lee
  INET: Stephen.Lee_at_DTAG.Com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).