RE: S.A.M.E

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