Re: S.A.M.E

Adding to the excellent response from Stephen, I merely have two observations to your questions.

>>why not create one huge tablespace for all my database objects????

For manageability reasons. If you have a humongous tablespace and one datafile has a block corruption, all your data has to be offline. If you need to transport a tablespace, guess how much data you are talking about. The worst is hot backup; all the files for that tablespace are in hot backup mode in essence you have placed the entire database in hot backup mode, generating gazillion amount of archived log.

In addition, you may also want to plan for the future. What if your database size grows and the current SAN has no room to grow? You perhaps decide to buy a cheaper (and slower) frame and place your "less accessed" data on that. If that data is in the same tablespace as the other data, you would have a tough time moving that out to a separate tablespace.

SAME is not the panacea; it simply makes the job of handling database layout much simpler.

The other recommendation is to test your configuration with NVRAM disabled and then enabled. With random load we saw a significant performance gain by eliminating cache in an OPS system I worked on earlier.

HTH. Arup Nanda
www.proligence.com

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Tuesday, May 13, 2003 6:20 PM

>
> 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#collateral, 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: Arup Nanda
  INET: orarup_at_hotmail.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).