Re:HYPER VOLUMES - RE: "Never split index and data files ...

From: <dgoulet_at_vicr.com>
Date: Tue, 24 Apr 2001 06:40:14 -0700
Message-ID: <F001.002F03CF.20010424054023@fatcity.com>

Ed,

Now your down into portions of the system where I'm out of it. In our case hyper volumes are defined by EMC and changing those 'bin' files is out of my league.

Dick Goulet

____________________Reply Separator____________________
Author: Ed.Haskins_at_VerizonWireless.com
Date:       4/23/2001 8:00 PM

Dick,

Thanks!

SAME also suggests using the "outer half" of each disk for data storage...as I/O performance is increased due to the natural circular shape of the platter. My question...how do you specify which sections of each disk are utilized? From what I've been able to read, I'm guessing that "hyper volumes" could be used for this?? I'm not sure...haven't had the opportunity to play with this yet. Anyone have an answer for this?

Ed Haskins
Oracle DBA
Verizon Wireless

-----Original Message-----
Sent: Friday, April 20, 2001 5:04 PM
To: Haskins; Ed; Multiple recipients of list ORACLE-L

ED,

Damn good question! No I won't take it as sarcastic at all.

Now to your point: We had to implement this particular strategy about 4 years ago due to the vendor we bought a disk array from (IPL). They were somewhat ahead of the curve here. Simple theory, they configured the 30GB array
as one very large disk drive with all of the disks striped and mirrored. Simply
put the SAME principle. Problem, there was only one SCSI channel into the array, OOPS, bottle neck par excellence! Again not too far in the recent past
we did a similar thing with some EMC disk, but this time we used 4 SCSI cables
with EMC's Power Path software. OH FUDGE, the 4 hyper volumes were all on the
same spindle, Damn, bottle neck par excellence again.

So as you can see, it makes a wonderful theory, but I haven't seen the pudding, yet. Still trying!

Dick Goulet

____________________Reply Separator____________________
Author: "Haskins; Ed" <Ed.Haskins_at_VerizonWireless.com>
Date:       4/20/2001 9:25 AM

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

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------