My pleasure Tim. How nice of you to say so....really
I could do this once a week and never repay the value
I get from the list.
|| -----Original Message-----
|| From: Tim Sawmiller [mailto:[EMAIL PROTECTED]]
|| Sent: Tuesday, April 24, 2001 1:27 PM
|| To: Multiple recipients of list ORACLE-L
|| Subject: RE: HYPER VOLUMES - RE: "Never split index and data
|| files ..."
||
||
|| Thank you for the very informative and detailed explanation.
||
|| >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
|| || 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" <[EMAIL PROTECTED]>
|| || 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" <[EMAIL PROTECTED]>
|| || 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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
|| ||
|| || 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
||
|| 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
||
|| 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
