RE: RE: "Never split index and data files ..."

Hi Ed and list,

Most of my bad experiences with SAME have been related to adding disk capacity, rather than its performance which is normally OK.

The first time I hit it was about 5 years ago when someone had configured the 30 4G drives as a single striped and mirrored volume 15 disks wide, and then someone else had added 2 more mirrored pairs to allow for data growth. The new disks immediately became a hot spot because they had no striping and could not support the same concurrency as the rest of the system.

My worst experience with SAME was an 800G data warehouse (noarchivelog mode) that had a requirement to fit a full cold backup into a 3 hour window. Because of the striping, the best backup performance they could get was single threaded! So their wonderful robotic tape library that could in theory backup 500G per hour was useless. As soon as there were 2 or more backup threads active the disk heads started thrashing and the tapes could not stream! To make matters worse, they had bought the disk farm concept, and there were four other unrelated applications sharing the same EMC arrays and one of those was a 24x7 emergency services thing so we could not reconfigure the disk arrays at all. It took 4 people about 3 months to work out a way to do the required reconfiguration from the Unix level in a 4-day outage window. When the time came, of course something went wrong and the whole change had to be backed out! The eventual solution was to spend several millions of dollars on a whole new bunch of hardware. Of course we did the configuration properly the next time so that there would be no disk or controller level contention between the backup threads.

@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/
@ http://www.christianity.net.au/

-----Original Message-----
Sent: Saturday, 21 April 2001 3:26
To: Multiple recipients of list ORACLE-L

Dick,

Don't take this the wrong way...it's NOT meant to be sarcastic:

You said "SAME is a great theory, but I can't and haven't seen it perform well in practice, yet."

My question to you: Have you seen it in practice at all? An actual working implementation?

For that matter; has ANYONE seen it implemented in a production environment? I'm sure it must be somewhere, but I'm curious if anyone knows where.

This is a subject that I'm really into right now...that's why I'm prodding a bit!

Thanks,

Ed Haskins
Oracle DBA
Verizon Wireless

-----Original Message-----
Sent: Friday, April 20, 2001 12:46 PM
To: Multiple recipients of list ORACLE-L

Steve,

    I heard about this SAME philosophy at the last NorthEast Oracle Users Group
meeting from a individual who works on the utilities for Oracle in the New England Development Office. Although we did not get deeply into the philosophy,
I'll agree that it is not the silver bullet, actually it can become a performance detractor. The individual who wrote the paper for Oracle (Anjo Kolk) is a LONG time Oracle person, actually wrote the core of the kernel, so I
believe he's probably writing from a purely theoretical point of view. In that
light what he's saying would be true, stripe & mirror everything and theoretically you should never have an io bottleneck. BUT, many hardware platforms don't handle mirroring very well unless your using a disk array like
EMC's. Now that handles the mirror internally so we've alleviated that problem,
but EMC likes to break their drives into 'hyper volumes' so your stripping may
or may not be across physical drives. Also your stripes can still have the bottle neck of the number of SCSI cards in the computer. In any case taking a
little time to insure that redo logs, archive logs, indexes, and data are all
REALLY spread out across devices is the only way to go. SAME is a great theory,
but I can't and haven't seen it perform well in practice, yet.

Dick Goulet

____________________Reply Separator____________________
Author: "Steve Adams" <steve.adams_at_ixora.com.au>
Date:       4/19/2001 11:25 PM

Hi All,

The author (Anjo Kolk) is an advocate of SAME (stripe and mirror everything).
The SAME philosophy is that "everything" should be striped across all the disks
available. Separating indexes from their tables is contrary to that philosophy.
I don't agree with it, but that's where he's coming from anyway.

@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/
@ http://www.christianity.net.au/

-----Original Message-----
Sent: Friday, 20 April 2001 6:56
To: Multiple recipients of list ORACLE-L

Whoaaa, I sure hope someone can, because I have never heard that before? Kev

-----Original Message-----
Ghosalkar
Sent: Thursday, April 19, 2001 4:36 PM
To: Multiple recipients of list ORACLE-L

Guys,

i was checking my statspack report on oraperf and i came across this statement.

"Never split index and data files to different sets of disks."

can anyone xplain the logic behind this.

Thanks
Mandar

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve Adams
  INET: steve.adams_at_ixora.com.au

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: dgoulet_at_vicr.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: Haskins, Ed
  INET: Ed.Haskins_at_VerizonWireless.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: Steve Adams
  INET: steve.adams_at_ixora.com.au

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