| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Thank you for the very informative and detailed explanation.
>>> MohanR_at_STARS-SMI.com 04/24/01 12:51PM >>> Oops, I guess I was just too obtuse and brief. Sorry 'bout that!
Here is an amplification and correction of what I sent another lister who contacted me offline.
Folks, please feel free to correct and amend if you know more/better.
thanks!
Ross
#################################################################################
Zone-Based Recording, or "ZBR" refers to the increase in the number of
sectors per
track within a given annular ring ( or "zone" ) on a disk. Why is this done?
Since a disk spins at constant angular velocity, the *linear* velocity under
the
R/W heads increases as the head moves from the spindle to the outer rim (
"track 0").
In OLD disks, there was no ZBR, so "sectors per track" was CONSTANT, and
streaming
data rate was constant across the disk. In current disks, the disk is
divided by
hardware manufacturers into cylindrical rings or "zones" in which the
"sector per
track" is constant. However, the closer the zone is to Track 0, the greater
the
number of sectors per track. A denser way of saying this is that the areal
information
density is roughly stepwise constant across the disk. This makes better use
of magnetic
real estate, but requires changes in the drive electronics ( which has to
map a
zone-dependent number of sectors per track now ) and their speed ( linear
speed at
Track 0 can be 10x that near the spindle, and the streaming data rate is
correspondingly
higher).
What is the upshot for databases?
Well, for STREAMING I/O...full table scans, index range scans, and the like,
putting data
on the OUTSIDE of the disk is better -- the throughput is fastest there.
For random, small "OLTP" I/O there is a slight preference for the middle or
inner parts
of the disks. Why? Because access time ( once you have the head's attention
) is a combination
of seek ( find the track ) and latency ( wait for the sectors to spin under
the stationary
head ) times. Track-to-track seek times are constant across the disk, but
under random I/O
you are more likely to *need* to seek when near the spindle. Access times
increase linearly
from the spindle out. So, for "OLTP" hits, time-averaged seek times DECREASE
from the spindle
out, and access times INCREASE from the spindle out, making a "sweet spot"
for OLTP near
roughly near the center of the disk.
The kicker is....this stuff used to matter enormously. Now, with the advent
of larger
and smarter on disk cache...controller cache....higher disk speeds...smaller
disk form
factors...all of these pure disk geometry considerations take less and less
precedence in tuning.
Having said that, if I was streaming video from my DB, or doing pure
long-haul OLAP/DSS work, and
needed every last scrap of juice out of the lemon, i'd stay near the outside
of the disks.
Contrariwise, if i were doing pure, random, small transaction OLTP, i'd put
data and index
near the spindle and middle, and the TEMP, ROLL, and log files near the
outsides.
As for filesystem and disk optimizations in general, the smarter OSes under
stand which files
are sequentially and frequently accessed, and put these near track 0. Those
less frequently used
may be stored near the spindle.
'nuff said!
|| -----Original Message-----
|| From: Mark Leith [mailto:mark_at_cool-tools.co.uk]
|| Sent: Tuesday, April 24, 2001 10:36 AM
|| To: Multiple recipients of list ORACLE-L
|| Subject: RE: HYPER VOLUMES - RE: "Never split index and data
|| files ..."
||
||
|| Care to elaborate on ZBR for those of us with enquiring
|| minds and absolutely
|| no idea what you are on about :)
||
|| Cheers
||
|| Mark
||
|| -----Original Message-----
|| Sent: Tuesday, April 24, 2001 01:56
|| To: Multiple recipients of list ORACLE-L
||
||
|| Ed,
||
|| Ever since ZBR, the need to use the outside of the disk ( to
|| reduce seeks ) is significantly reduced.
||
|| Ross
||
|| -----Original Message-----
|| To: Multiple recipients of list ORACLE-L
|| Sent: 4/24/2001 12:00 AM
||
|| 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
|| --------------------------------------------------------------------
|| 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:
|| 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: Mohan, Ross
|| INET: MohanR_at_STARS-SMI.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: Mark Leith
|| INET: mark_at_cool-tools.co.uk
||
|| 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: Mohan, Ross INET: MohanR_at_STARS-SMI.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: Tim Sawmiller INET: sawmillert_at_state.mi.us 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).Received on Tue Apr 24 2001 - 12:20:56 CDT
 |
 |