Re: HYPER VOLUMES - RE: "Never split index and data files ..."
You got the good oil from Ross on that. They actually record more data on the outer surfaces! In a nutshell, that's what ZBR is all about. Darn things keep changing more and more, that's what makes this business so interesting. :-) Cheers Nuno Souto [EMAIL PROTECTED] http://www.users.bigpond.net.au/the_Den - Original Message - seeks that keep running in and out of the disk. Or, have things changed since started in this business, so many years ago? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Nuno Souto 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).
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Tim, The outside track contains more data. Think of it this way: there is "X" bits per square cm of disk real estate. a "track" is constant thickness, but steadily increasing circumference, so the area of the track -- and therefore the data storable there -- increases. -- Ross || -Original Message- || From: Tim Sawmiller [mailto:[EMAIL PROTECTED]] || Sent: Tuesday, April 24, 2001 1:05 PM || To: Multiple recipients of list ORACLE-L || Subject: Re: HYPER VOLUMES - RE: "Never split index and data || files ..." || || || Ok, enlighten me...an outside track holds the same amount of || data as an inside track does, right? -- 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).
RE: OT RE: HYPER VOLUMES - RE: "Never split index and data files
Zoe Baird Returns -Original Message- Sent: Tuesday, April 24, 2001 1:37 PM To: Multiple recipients of list ORACLE-L Zymurgy Beats Recidivism? || -Original Message- || From: Boivin, Patrice J [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] || Sent: Tuesday, April 24, 2001 11:51 AM || To: Multiple recipients of list ORACLE-L || Subject: RE: HYPER VOLUMES - RE: "Never split index and data || files ..." || || || Zebra Boisterous Rout || Zebra Blues Routine || || Hmm it's hard to come up with meaninful acronyms, usually || it's easier... || || : ) || || Patrice Boivin || Systems Analyst (Oracle Certified DBA) || || || || -Original Message- || From: Mark Leith [SMTP:[EMAIL PROTECTED]] || Sent: Tuesday, April 24, 2001 11:35 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 || || || -- || Please see the official ORACLE-L FAQ: http://www.orafaq.com <http://www.orafaq.com> || -- || Author: Boivin, Patrice J || 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: Henry Poras 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).
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Zealous Bumf Router? -Original Message- Patrice J Sent: Tuesday, April 24, 2001 04:51 To: Multiple recipients of list ORACLE-L Zebra Boisterous Rout Zebra Blues Routine Hmm it's hard to come up with meaninful acronyms, usually it's easier... : ) Patrice Boivin Systems Analyst (Oracle Certified DBA) -Original Message- From: Mark Leith [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 24, 2001 11:35 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 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boivin, Patrice J 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).
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
My pleasure Tim. How nice of you to say soreally 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 isthis stuff used to matter enormously. Now, || with the advent || of larger || and smarter on disk cache...controller cachehigher 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 ||
OT RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Title: OT RE: HYPER VOLUMES - RE: "Never split index and data files ..." Zymurgy Beats Recidivism? || -Original Message- || From: Boivin, Patrice J [mailto:[EMAIL PROTECTED]] || Sent: Tuesday, April 24, 2001 11:51 AM || To: Multiple recipients of list ORACLE-L || Subject: RE: HYPER VOLUMES - RE: "Never split index and data || files ..." || || || Zebra Boisterous Rout || Zebra Blues Routine || || Hmm it's hard to come up with meaninful acronyms, usually || it's easier... || || : ) || || Patrice Boivin || Systems Analyst (Oracle Certified DBA) || || || || -Original Message- || From: Mark Leith [SMTP:[EMAIL PROTECTED]] || Sent: Tuesday, April 24, 2001 11:35 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 || || || -- || Please see the official ORACLE-L FAQ: http://www.orafaq.com || -- || Author: Boivin, Patrice J || 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). ||
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 isthis stuff used to matter enormously. Now, with the advent of larger and smarter on disk cache...controller cachehigher 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 sarcasti
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Here's some info I was able to dig up! Ed Haskins Oracle DBA Verizon Wireless Zoned Bit Recording One way that capacity and speed have been improved on hard disks over time is by improving the utilization of the larger, outer tracks of the disk. The first hard disks were rather primitive affairs and their controllers couldn't handle complicated arrangements that changed between tracks. As a result, every track had the same number of sectors. The standard for the first hard disks was 17 sectors per track. Of course, the tracks are concentric circles, and the ones on the outside of the platter are much larger than the ones on the inside--typically double the circumference or more. Since there is a constraint on how tight the inner circles can be packed with bits, they were packed as tight as was practically possible given the state of technology, and then the outer circles were set to use the same number of sectors by reducing their bit density. This means that the outer tracks were greatly underutilized, because in theory they could hold many more sectors given the same linear bit density limitations. To eliminate this wasted space, modern hard disks employ a technique called zoned bit recording (ZBR), also sometimes called multiple zone recording or even just zone recording. With this technique, tracks are grouped into zones based on their distance from the center of the disk, and each zone is assigned a number of sectors per track. As you move from the innermost part of the disk to the outer edge, you move through different zones, each containing more sectors per track than the one before. This allows for more efficient use of the larger tracks on the outside of the disk. More (http://www.pcguide.com/ref/hdd/geom/tracksZBR-c.html) -- Placing Data at the Beginning of ZBR Disks Data is most quickly transferred when it is located at the beginning of zone-based recording (ZBR) disks. Placing data at the beginning of these disks improves the bandwidth for sequential data transfers. --- Disk geometry refers to how sectors and tracks are organized for each cylinder in a disk drive. The UFS organizes itself to use disk geometry efficiently. If slices in a concatenated metadevice have different disk geometries, DiskSuite uses the geometry of the first slice. This fact may decrease the UFS file system efficiency. Note - Disk geometry differences do not matter with disks that use Zone Bit Recording (ZBR), because the amount of data on any given cylinder varies with the distance from the spindle. Most disks now use ZBR. Use Outer Disk Cylinders First Because of the Zone Bit Recording (ZBR) technology used by Sun, outer cylinders tend to outperform inner cylinders. The outer cylinders are cylinders 0, 1, and 3, as opposed to 4, 5, 6, and 7. CAUTION: Remember, don't use cylinder 2, the overlap cylinder, because it retains the total size of the disk. Some programs are baffled when this cylinder gets changed. -Original Message- Sent: Tuesday, April 24, 2001 10:51 AM To: Multiple recipients of list ORACLE-L - Original Message - > Ever since ZBR, the need to use the outside of the disk ( to > reduce seeks ) is significantly reduced. > PMFJI. The reason for using the outside of the disk is the increased linear velocity there re the heads. Larger circle, same angular velocity, larger linear velocity. Which means you get faster read data transfer rate. Nothing at all to do with reducing seeks. What you end up with is less rotational latency and significantly faster (up to 30% best case) data transfer speed from the silver to the disk cache. From there on to the disk controller and the buffers, it's all the same. This was explained to me by a guy that works on firmware for Seagate. He sent me the best "disk speed measure" program I've ever seen! Cheers Nuno Souto [EMAIL PROTECTED] http://www.users.bigpond.net.au/the_Den -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Nuno Souto 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
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
Zebra Boisterous Rout Zebra Blues Routine Hmm it's hard to come up with meaninful acronyms, usually it's easier... : ) Patrice Boivin Systems Analyst (Oracle Certified DBA) -Original Message- From: Mark Leith [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 24, 2001 11:35 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 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boivin, Patrice J 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).
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
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 isthis stuff used to matter enormously. Now, with the advent of larger and smarter on disk cache...controller cachehigher 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 v
Re: HYPER VOLUMES - RE: "Never split index and data files ..."
Ok, enlighten me...an outside track holds the same amount of data as an inside track does, right? The bits are just physically crammed close together on the inside tracks. That being the case, the actual read/write rate would be the same on outside tracks as on inside tracks. So all you really have to deal with is arm seeks that keep running in and out of the disk. Or, have things changed since started in this business, so many years ago? >>> [EMAIL PROTECTED] 04/24/01 10:51AM >>> - Original Message - > Ever since ZBR, the need to use the outside of the disk ( to > reduce seeks ) is significantly reduced. > PMFJI. The reason for using the outside of the disk is the increased linear velocity there re the heads. Larger circle, same angular velocity, larger linear velocity. Which means you get faster read data transfer rate. Nothing at all to do with reducing seeks. What you end up with is less rotational latency and significantly faster (up to 30% best case) data transfer speed from the silver to the disk cache. From there on to the disk controller and the buffers, it's all the same. This was explained to me by a guy that works on firmware for Seagate. He sent me the best "disk speed measure" program I've ever seen! Cheers Nuno Souto [EMAIL PROTECTED] http://www.users.bigpond.net.au/the_Den -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Nuno Souto 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).
Re: HYPER VOLUMES - RE: "Never split index and data files ..."
- Original Message - > Ever since ZBR, the need to use the outside of the disk ( to > reduce seeks ) is significantly reduced. > PMFJI. The reason for using the outside of the disk is the increased linear velocity there re the heads. Larger circle, same angular velocity, larger linear velocity. Which means you get faster read data transfer rate. Nothing at all to do with reducing seeks. What you end up with is less rotational latency and significantly faster (up to 30% best case) data transfer speed from the silver to the disk cache. From there on to the disk controller and the buffers, it's all the same. This was explained to me by a guy that works on firmware for Seagate. He sent me the best "disk speed measure" program I've ever seen! Cheers Nuno Souto [EMAIL PROTECTED] http://www.users.bigpond.net.au/the_Den -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Nuno Souto 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).
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
Re:HYPER VOLUMES - RE: "Never split index and data files ...
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: [EMAIL PROTECTED] 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" <[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 -- Autho
RE: HYPER VOLUMES - RE: "Never split index and data files ..."
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-505
HYPER VOLUMES - RE: "Never split index and data files ..."
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
RE: RE: "Never split index and data files ..."
Steve, Thanks for sharing your experiences! Quick question: In the end, once the new hardware was purchased and properly setup, how was the performance of the DB and backup? Were you able to meet the requirement of the 3 hour backup window? Ed Haskins Oracle DBA Verizon Wireless -Original Message- Sent: Friday, April 20, 2001 7:32 PM To: Haskins, Ed; Multiple recipients of list ORACLE-L 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" <[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 -Orig
RE: RE: "Never split index and data files ..."
Steve, Thanks, I stand corrected. Before your post, it was all the same to me. I have personally never "bought in" to the Sun striping ideology. It has always seemed pre-cooked to best support what I consider to be weak I/O hw on vendor side. - Ross -Original Message- To: Multiple recipients of list ORACLE-L Sent: 4/20/2001 10:30 PM Hi Ross, The first principle of SAME is "Stripe all files across all disks ..." It is those two "all"s that are definitive. What you did was intelligent broad striping with selective I/O separation. That's not "semi-SAME"; it's contra-SAME. The only thinking that SAME allows for is putting "hot" data like redo logs on the outside of the disks (if you can). SAME is all about sex appeal with almost no brain power. I would not even flirt with it, let alone consider a long-term relationship. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ @ http://www.christianity.net.au/ -Original Message- Sent: Saturday, 21 April 2001 4:22 To: Multiple recipients of list ORACLE-L I forgot to mention: We assiduously separated table from index...across controller and channel...and we separated "hot" and "cold" data tspaces as well. There's nothing like having enough disk and I.O. :) <==> -Original Message- <==> From: Mohan, Ross <==> Sent: Friday, April 20, 2001 1:17 PM <==> To: '[EMAIL PROTECTED]' <==> Subject: RE: RE: "Never split index and data files ..." <==> <==> <==> Long ago in a galaxy, far far away, I did <==> a semi-SAME thing on a Sequent box. Everything -- 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: 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: 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).
RE: RE: "Never split index and data files ..."
Hi Ross, The first principle of SAME is "Stripe all files across all disks ..." It is those two "all"s that are definitive. What you did was intelligent broad striping with selective I/O separation. That's not "semi-SAME"; it's contra-SAME. The only thinking that SAME allows for is putting "hot" data like redo logs on the outside of the disks (if you can). SAME is all about sex appeal with almost no brain power. I would not even flirt with it, let alone consider a long-term relationship. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ @ http://www.christianity.net.au/ -Original Message- Sent: Saturday, 21 April 2001 4:22 To: Multiple recipients of list ORACLE-L I forgot to mention: We assiduously separated table from index...across controller and channel...and we separated "hot" and "cold" data tspaces as well. There's nothing like having enough disk and I.O. :) <==> -Original Message- <==> From: Mohan, Ross <==> Sent: Friday, April 20, 2001 1:17 PM <==> To: '[EMAIL PROTECTED]' <==> Subject: RE: RE: "Never split index and data files ..." <==> <==> <==> Long ago in a galaxy, far far away, I did <==> a semi-SAME thing on a Sequent box. Everything -- 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: 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).
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" <[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
Re:RE: RE: "Never split index and data files ..."
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 y
RE: RE: "Never split index and data files ..."
Title: RE: RE: "Never split index and data files ..." Long ago in a galaxy, far far away, I did a semi-SAME thing on a Sequent box. Everything but logsfour controllers, each with full four-channel fastwide SCSI. Software raid0+1 (not 1+0). Stripe width 128Kblocks, 64Kbytes. Worked like a charm. Sun came in to "blow away" the two generation old box and layout sometime later. (E5500 flavor, probably A5000 class controllers ) It still doesn't work as well. - Ross btw, we did PQO on this box ( 10 CPU, 90/133 MHz pentiums -- yes, you read that right ) and it was like something out of a dreamoracle 723 then 734. So sweet. <==> -Original Message- <==> From: Haskins, Ed [mailto:[EMAIL PROTECTED]] <==> Sent: Friday, April 20, 2001 1:26 PM <==> To: Multiple recipients of list ORACLE-L <==> Subject: RE: RE: "Never split index and data files ..." <==> <==> <==> 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.n
RE: RE: "Never split index and data files ..."
I forgot to mention: We assiduously separated table from index...across controller and channel...and we separated "hot" and "cold" data tspaces as well. There's nothing like having enough disk and I.O. :) <==> -Original Message- <==> From: Mohan, Ross <==> Sent: Friday, April 20, 2001 1:17 PM <==> To: '[EMAIL PROTECTED]' <==> Subject: RE: RE: "Never split index and data files ..." <==> <==> <==> Long ago in a galaxy, far far away, I did <==> a semi-SAME thing on a Sequent box. Everything -- 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).
RE: "Never split index and data files ..."
It seems to me this is a debate about whether to separate tables from
indexes at the hardware (RAID stripe) level, vs. doing it by placing them in
different tablespaces, with the tablespaces located on separate devices.
Either way the indexes and the tables should not be on the same physical
device, is this correct?
Now we can wonder - is Oracle faster at doing I/O when we are accessing
indexes and tables in two separate tablespaces, or would the hardware RAID
be faster when accessing stripes containing multiple physical devices.
Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
Systems Admin & Operations | Admin. et Exploit. des systèmes
Technology Services| Services technologiques
Informatics Branch | Direction de l'informatique
Maritimes Region, DFO | Région des Maritimes, MPO
E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-Original Message-
From: Steve Adams [SMTP:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 10:42 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: "Never split index and data files ..."
Hi Allan,
Thanks for that reference. It is a much better treatment than the
Oracle paper
on the matter. The Oracle paper says "Stripe all files across all
disks using a
one megabyte stripe width". The Sun paper stops short of saying "all
... all"
which is a very significant difference. It says "As an extreme one
could take
every disk in the system, and stripe each table over every disk. In
practice, it
is more practical to break up all the disks into a few pools". It
also says,
"The database layout practice of keeping data and index separate is
still
useful, but using it for a first-order layout rule is a mistake."
This is
consistent with what I recommend in the series of tips on disk
configuration on
the Ixora web site.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/
@ http://www.christianity.net.au/
-Original Message-
Sent: Friday, 20 April 2001 21:20
To: Multiple recipients of list ORACLE-L
There is also an article on Wide Thin Disk Striping at Sun Blue
prints
http://www.sun.com/software/solutions/blueprints/1000/layout.pdf
which expands on this philosophy.
Allan
>From: "Steve Adams" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>Subject: RE: "Never split index and data files ..."
>Date: Thu, 19 Apr 2001 23:25:25 -0800
>
>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
RE: RE: "Never split index and data files ..."
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).
RE: "Never split index and data files ..."
Hi Allan, Thanks for that reference. It is a much better treatment than the Oracle paper on the matter. The Oracle paper says "Stripe all files across all disks using a one megabyte stripe width". The Sun paper stops short of saying "all ... all" which is a very significant difference. It says "As an extreme one could take every disk in the system, and stripe each table over every disk. In practice, it is more practical to break up all the disks into a few pools". It also says, "The database layout practice of keeping data and index separate is still useful, but using it for a first-order layout rule is a mistake." This is consistent with what I recommend in the series of tips on disk configuration on the Ixora web site. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ @ http://www.christianity.net.au/ -Original Message- Sent: Friday, 20 April 2001 21:20 To: Multiple recipients of list ORACLE-L There is also an article on Wide Thin Disk Striping at Sun Blue prints http://www.sun.com/software/solutions/blueprints/1000/layout.pdf which expands on this philosophy. Allan >From: "Steve Adams" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: "Never split index and data files ..." >Date: Thu, 19 Apr 2001 23:25:25 -0800 > >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).
RE: "Never split index and data files ..."
There is also an article on Wide Thin Disk Striping at Sun Blue prints http://www.sun.com/software/solutions/blueprints/1000/layout.pdf which expands on this philosophy. Allan >From: "Steve Adams" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: "Never split index and data files ..." >Date: Thu, 19 Apr 2001 23:25:25 -0800 > >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). _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Allan Robertson 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).
RE: "Never split index and data files ..."
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).
