RE: Stripe and Mirror Everything - The "S.A.M.E. Method"

Well yeah... the footnotes says it's copyrighted by VERITAS but it only seems to be available on technet. I searched the VERITAS website and couldn't find the paper. Seems curious.

Steve Orr

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Scott.Shafer_at_dcpds.cpms.osd.mil
Sent: Friday, January 12, 2001 10:52 AM
To: Multiple recipients of list ORACLE-L Subject: RE: Stripe and Mirror Everything - The "S.A.M.E. Method"

Look for the signature on that paper. Does it perchance say "Marketing Department" anywhere?
;-)

--Scott

> -----Original Message-----
> From: Steve Orr [SMTP:sorr_at_arzoo.com]
> Sent: Friday, January 12, 2001 12:01 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Stripe and Mirror Everything - The "S.A.M.E. Method"
>
> Here's the url for a white paper titled "Configuring the Oracle Database
> with VERITAS Software and EMC Storage for Optimal Scalability,
> Manageability, and Performance" on Technet:
>
> http://technet.oracle.com/deploy/availability/pdf/ora_cbook1.pdf
>
> The conclusion of the paper is something like "just put everything on
> RAID0+1 and don't worry about file contention by using the 'SAME' method."
> SAME is an acronym for "stripe and mirror everything." They compare the
> old
> "traditional method" of segregating redo logs, RBS, temp, data, index, and
> system tablespaces/datafiles to the SAME method with everything residing
> on
> one large array. They give benchmarks to show that the SAME method
> actually
> performs better.
>
> Any feedback or criticism of this paper? Does it really reflect the way we
> should configure very large databases? Their test database was 50G.
>
> I'm curious about the validity of the benchmarks. It seems their
> implementation of the "traditional method" is half hearted. The only files
> they separate are the redo logs. What if they kept the same array as in
> test
> case 2 and duplexed the redo logs on drives outside the array? What if
> they
> went further and implemented physical drive separation with three volumes:
> one for data; one for indexes; and one for system, RBS, and temp
> tablespaces? What if they had a 500G database? Another curious observation
> is that db_block_size was only 4K on a Solaris E3000.
>
> The paper says, "Today, most Oracle DBAs do not configure an Oracle
> database
> and storage based on the SAME method because that is not how they were
> trained to implement Oracle and storage." It goes on to say, "...with the
> right storage software and hardware solution, we recommend that Oracle
> DBAs
> consider the new SAME approach." Hmmm... are they trying to tell us old
> DBAs
> to keep up with the technology?
>
>
> All opinions, humble and otherwise, are earnestly requested.
>
> Steve Orr
> The curious DBA.
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Steve Orr
> INET: sorr_at_arzoo.com
>
> 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: 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.com
--
Author:
  INET: Scott.Shafer_at_dcpds.cpms.osd.mil

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: 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