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#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).