RE: OFA myths was Re: BAARF
Personally I never use DBCA. The manual installation scripts that I've carried over from my 8.0 days for Windows and HP-UX still work (with minor modifications) for 9.2. Well, I lie. When I first install a new Oracle version I use DBCA to create a database just to see what some of the new options are. > -Original Message- > Mercadante, Thomas F > > and the first thing that I do is to delete the INDX > tablespace!!! As well > as dropping the ORD* users, SCOTT, Tim, Tammy-Fae, Jim Bob > and all the other > crappy stuff that auytomatically gets installed. > > I try and get it back to the original 8.0 install!!! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
and the first thing that I do is to delete the INDX tablespace!!! As well as dropping the ORD* users, SCOTT, Tim, Tammy-Fae, Jim Bob and all the other crappy stuff that auytomatically gets installed. I try and get it back to the original 8.0 install!!! Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, September 30, 2003 4:25 PM To: Multiple recipients of list ORACLE-L > -Original Message- > Paul Baumgartel > > Loney didn't write OFA, and methinks he was taking liberties with it. Perhaps. However I notice that DBCA in Oracle 9.2 creates a tablespace called INDX. http://download-west.oracle.com/docs/html/A97297_01/appg_ofa.htm#sthref807 Oracle9i Administrator's Reference Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris Part No. A97297-01 Appendix G Optimal Flexible Architecture ... Separate Segments With Different Requirements Separate groups of segments with different lifespans, I/O request demands, and backup frequencies across different tablespaces. Table G-5 describes the special tablespaces that the Database Configuration Assistant creates for each Oracle database. ... Table G-5 Special Tablespaces ... INDX - Index associated with data in the USERS tablespace USERS - Miscellaneous user segments ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Mercadante, Thomas F INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
> -Original Message- > Paul Baumgartel > > Loney didn't write OFA, and methinks he was taking liberties with it. Perhaps. However I notice that DBCA in Oracle 9.2 creates a tablespace called INDX. http://download-west.oracle.com/docs/html/A97297_01/appg_ofa.htm#sthref807 Oracle9i Administrator's Reference Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris Part No. A97297-01 Appendix G Optimal Flexible Architecture ... Separate Segments With Different Requirements Separate groups of segments with different lifespans, I/O request demands, and backup frequencies across different tablespaces. Table G-5 describes the special tablespaces that the Database Configuration Assistant creates for each Oracle database. ... Table G-5 Special Tablespaces ... INDX - Index associated with data in the USERS tablespace USERS - Miscellaneous user segments ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
Loney didn't write OFA, and methinks he was taking liberties with it. --- Jacques Kilchoer <[EMAIL PROTECTED]> wrote: > Not commenting on the accuracy of the information, but Kevin Loney, > in the Oracle8 DBA Handbook (1998), says the following (Chapter 3 > Logical Database Layouts), in a section entitled "The Optimal > Flexible Architecture (OFA)" > "Index segments should not be stored in the same tablespace as their > associated tables, since they have a great deal of concurreint I/O > during both manipulation and queries. Index segments are also subject > to fragmentation due to improper sizing or unpredicted table growth. > Isolating the application indexes to a separate tablespace greatly > reduces the administrative efforts involved in defragmenting either > the DATA or the INDEXES tablespace." > > From reading his book, I always thought that OFA implied the > separation of tables and indexes. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of > > Steve Rospo > > Sent: jeudi, 25. septembre 2003 15:10 > > > > I'd like to get rid of the myth that OFA really states all > > that much about > > what goes in what tablespace etc. I've got a copy of the > > Cary's OFA paper > > entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept > 24, > > 1995. (Happy belated birthday OFA!) At the end of paper > > there's a summary > > of the requirements and the recommendations that make up OFA. > > The CLOSEST > > the OFA comes to specifying table/index separation are > > > > "#7 Separate groups of segments with different lifespans, I/O > request > > demands, and backup frequencies among different tablespaces." > > > > -or maybe- > > > > "#11 *IF* [emphasis mine] you can afford enough hardware > > that: 1) You can > > guarantee that each disk drive will contain database files > > from exactly > > one application and 2) You can dedicate sufficiently many > > drives to each > > database to ensure that there will be no I/O bottleneck." > > > > The document itself says, "The OFA Standard is a set of > configuration > > guidelines that will give you faster, more reliable Oracle > > database that > > require less work to maintain." So every time I read that someone > is > > putting redo here, index tablespaces here, and temp > > tablespaces there in > > order to be "OFA compliant" I kinda shrug. Obviously it's > > all a good idea > > to separate this stuff but it's not absolutely required for > OFA-ness. > > Essentially, OFA is just a very good way of separating Oracle > > code from > > Oracle data to make administration *much* easier. I'm sure before > OFA > > there were plenty of places that had everything under > > $ORACLE_HOME/dbs and > > no naming standard for datafiles. Ugh! > > > > Now if we could only find this "Cary V. Millsap, Oracle > Corporation" > > character so he could explain himself. ;-) '95 was a > > loong time ago. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jacques Kilchoer > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > 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). __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Paul Baumgartel INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
I agree, though I'm not sure if it is because indexes are more susceptible to corruption. My guess is that given 50-50 odds, sometimes you get lucky. Mixing tables and indexes together gives you 0% odds of losing data... :-) Well, to add another couple of pennies worth... In my very first gig as a DBA ten years ago, we were faced with a 7.0.15 database that was doubling in size every few months. Management had already decided to scrap the system and migrate to another, so they refused to buy more storage even though it was production. Long story short, we were forced to unmirror the RAID-1 volumes underneath the index tablespaces and use the freed-up plexes to create new volumes for table tablespaces. Indexes are ancillary structures and ultimately expendable; tables are *data*... on 9/29/03 7:09 AM, Hitchman, Peter at [EMAIL PROTECTED] wrote: > Hi, > To add my two pennies worth. By design I create physical database lqyouts > that seperate indexes and tables by tablespace for ease of management, > unless the database is real small. My experience over the years with Oracle, > has been the object corruptions in the database have occurred more frequenty > with indexes than tables, and when it happens its good just to be able to > scrap the index tablespaces datafiles and start again. > > Regards > > Pete > > -Original Message- > Sent: 29 September 2003 02:45 > To: Multiple recipients of list ORACLE-L > > > Thomas, > > Please pardon me, but you are off-target in your criticisms of OFA. > > It has never advocated separating tables from indexes for performance > purposes. Ironically, your email starts to touch on the real reason for > separating them (i.e. different types of I/O, different recovery > requirements, etc). Tables and indexes do belong in different tablespaces, > but not for reasons of performance. > > Cary first designed and implemented OFA in the early 90s and formalized it > into a paper in 1995. Quite frankly, it is a brilliant set of rules of how > Oracle-based systems should be structured, and a breath of fresh air from > the simplistic way that Oracle installers laid things out at the time. It > took several years for Oracle Development to see the light and become > OFA-compliant, and not a moment too soon either. Just imagine if everything > were still installed into a single directory tree under ORACLE_HOME? All > of things you mention here have nothing to do with OFA. > > Please read the paper. > > Hope this helps... > > -Tim > > P.S.By the way, multiple block sizes are not intended for performance > optimization; they merely enable transportable tablespaces between > databases with different block sizes. > > > on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > >> >> I would love to have a definitive site that I could send all RAID-F >> advocates to where it would be laid out clearly, unambiguously, and >> definitively what storage types should be used for what purpose. >> >> Redo logs on RAID 0 with Oracle duplexing (y/n)? >> Rollback (or undo) ditto? >> Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? >> Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper >> than 1+0 and you won't have the write penalty) >> >> While we're at it could we blow up the OFA myth? Since you're tablespaces >> are on datafiles that are on logical volumns that are on physical devices >> which may contain one or many actual disks, does it really make sense to >> worry (from a performance standpoint) about separating tables and indexes >> into different tablespaces? >> >> We have killed the "everything in one extent" myth haven't we? > Everybody's >> comfortable with tables that have 100's of extents? >> >> And while we're at it, could we include the Oracle 9 multiple blocksizes >> and how to use them. The best that I've seen is indexes in big blocks, >> tables in small blocks --- uh, oh, time to separate tables and indexes. >> >> Maybe we will never get rid of the OFA myth. >> >> Just venting. >> >> Tired of arguing in front of management with Oracle certified DBAs that >> RAID 5 is not good, OFA is unnecessary, and uniform extents is the only > way >> to go. Looking for a big stick to catch their attention with. >> -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
Oh man... now I see the problem. Well, IMHO, Kevin's advice is the right advice for the wrong reasons. It's not the OFA. Thanks, Jacques, for pointing that out. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details... -Original Message- Jacques Kilchoer Sent: Monday, September 29, 2003 6:15 PM To: Multiple recipients of list ORACLE-L Not commenting on the accuracy of the information, but Kevin Loney, in the Oracle8 DBA Handbook (1998), says the following (Chapter 3 Logical Database Layouts), in a section entitled "The Optimal Flexible Architecture (OFA)" "Index segments should not be stored in the same tablespace as their associated tables, since they have a great deal of concurreint I/O during both manipulation and queries. Index segments are also subject to fragmentation due to improper sizing or unpredicted table growth. Isolating the application indexes to a separate tablespace greatly reduces the administrative efforts involved in defragmenting either the DATA or the INDEXES tablespace." >From reading his book, I always thought that OFA implied the separation of tables and indexes. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Steve Rospo > Sent: jeudi, 25. septembre 2003 15:10 > > I'd like to get rid of the myth that OFA really states all > that much about > what goes in what tablespace etc. I've got a copy of the > Cary's OFA paper > entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept 24, > 1995. (Happy belated birthday OFA!) At the end of paper > there's a summary > of the requirements and the recommendations that make up OFA. > The CLOSEST > the OFA comes to specifying table/index separation are > > "#7 Separate groups of segments with different lifespans, I/O request > demands, and backup frequencies among different tablespaces." > > -or maybe- > > "#11 *IF* [emphasis mine] you can afford enough hardware > that: 1) You can > guarantee that each disk drive will contain database files > from exactly > one application and 2) You can dedicate sufficiently many > drives to each > database to ensure that there will be no I/O bottleneck." > > The document itself says, "The OFA Standard is a set of configuration > guidelines that will give you faster, more reliable Oracle > database that > require less work to maintain." So every time I read that someone is > putting redo here, index tablespaces here, and temp > tablespaces there in > order to be "OFA compliant" I kinda shrug. Obviously it's > all a good idea > to separate this stuff but it's not absolutely required for OFA-ness. > Essentially, OFA is just a very good way of separating Oracle > code from > Oracle data to make administration *much* easier. I'm sure before OFA > there were plenty of places that had everything under > $ORACLE_HOME/dbs and > no naming standard for datafiles. Ugh! > > Now if we could only find this "Cary V. Millsap, Oracle Corporation" > character so he could explain himself. ;-) '95 was a > loong time ago. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Niall, I think you've specified the right test. However, whether to separate indexes from data is an easier argument. All it takes is one of potentially dozens of reasons, and isolating becomes the right idea. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details... -Original Message- Niall Litchfield Sent: Monday, September 29, 2003 4:35 PM To: Multiple recipients of list ORACLE-L Cary writes > It *is* a good idea to separate index data from heap data > into different tablespaces. But the reason isn't solely to > eliminate I/O competition. Even if I/O competition isn't an > issue for you (and the OFA Standard doesn't say that it will > be), then it's *still* a good idea to separate your index > data from your heap data, for reasons including: > > * Index segments have different backup and recovery > requirements than their corresponding heap segments. For > example, as Peter mentioned, if you have an index block > corruption event, then it's convenient to just offline, kill, > and rebuild an index tablespace. If the indexes and data are > mixed up in a single tablespace, this is not an option. Another > example: If you construct your backup schedule to make media > recovery time a constant, then you probably don't need to > back up your indexes on the same schedule as you back up your > heaps. But unless they're in different tablespaces, this > isn't an option either. Hmmm maybe I'm going to start having to rethink some stuff, when you and Howard agree and I disagree it seems likely I'm being dense. My concern goes Indexes are largely built for one of two reasons A) to make performance acceptable. B) to enforce constraints. In a media recovery situation, recovering but with unacceptable performance or locking issues probably doesn't really constitute recovery. Now If it can be shown that trashing the index tablespace and rebuilding is generally faster than restoring datafiles and applying logs I might be more convinced but at the moment I'm not so sure. So is this garbage Or not.? Niall -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Niall Litchfield INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
Not commenting on the accuracy of the information, but Kevin Loney, in the Oracle8 DBA Handbook (1998), says the following (Chapter 3 Logical Database Layouts), in a section entitled "The Optimal Flexible Architecture (OFA)" "Index segments should not be stored in the same tablespace as their associated tables, since they have a great deal of concurreint I/O during both manipulation and queries. Index segments are also subject to fragmentation due to improper sizing or unpredicted table growth. Isolating the application indexes to a separate tablespace greatly reduces the administrative efforts involved in defragmenting either the DATA or the INDEXES tablespace." >From reading his book, I always thought that OFA implied the separation of tables and >indexes. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Steve Rospo > Sent: jeudi, 25. septembre 2003 15:10 > > I'd like to get rid of the myth that OFA really states all > that much about > what goes in what tablespace etc. I've got a copy of the > Cary's OFA paper > entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept 24, > 1995. (Happy belated birthday OFA!) At the end of paper > there's a summary > of the requirements and the recommendations that make up OFA. > The CLOSEST > the OFA comes to specifying table/index separation are > > "#7 Separate groups of segments with different lifespans, I/O request > demands, and backup frequencies among different tablespaces." > > -or maybe- > > "#11 *IF* [emphasis mine] you can afford enough hardware > that: 1) You can > guarantee that each disk drive will contain database files > from exactly > one application and 2) You can dedicate sufficiently many > drives to each > database to ensure that there will be no I/O bottleneck." > > The document itself says, "The OFA Standard is a set of configuration > guidelines that will give you faster, more reliable Oracle > database that > require less work to maintain." So every time I read that someone is > putting redo here, index tablespaces here, and temp > tablespaces there in > order to be "OFA compliant" I kinda shrug. Obviously it's > all a good idea > to separate this stuff but it's not absolutely required for OFA-ness. > Essentially, OFA is just a very good way of separating Oracle > code from > Oracle data to make administration *much* easier. I'm sure before OFA > there were plenty of places that had everything under > $ORACLE_HOME/dbs and > no naming standard for datafiles. Ugh! > > Now if we could only find this "Cary V. Millsap, Oracle Corporation" > character so he could explain himself. ;-) '95 was a > loong time ago. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Havent' you heard about the theory of relativity? 1 - ideal - full recovery with indexes 2 - relatively less than ideal - having to rebuild indexes It doesn't mean you should aim for 2, but you sure want to keep 2 as an option. If you don't have separate index tablespaces, you are simply limiting your options. In a recovery situation you want all the options you can get! > Indexes are largely built for one of two reasons > > A) to make performance acceptable. > B) to enforce constraints. > > In a media recovery situation, recovering but with unacceptable > performance or locking issues probably doesn't really constitute > recovery. Now If it can be shown that trashing the index tablespace and > rebuilding is generally faster than restoring datafiles and applying > logs I might be more convinced but at the moment I'm not so sure. So is > this garbage Or not.? > > Niall -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Binley Lim INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Oh, plenty of times. Just never heard it referred to as "OFA". on 9/29/03 7:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > My struggle is not with the directory layout OFA. > > It is with the "mythical" OFA that every DBA that I have talked to knows > all about. Where ORACLE says that if you are a good and competent DBA you > will separate your table data and your index data into two separate > tablespaces so that one disk head can be reading index entries while > another disk head is reading the table data. You've never run into that? > > > > > Tim Gorman @sagelogix.com> To: Multiple recipients of > list ORACLE-L <[EMAIL PROTECTED]> > Sent by: cc: > ml-errorsSubject: Re: BAARF > > > 09/28/2003 09:44 > PM > Please respond > to ORACLE-L > > > > > > > Thomas, > > Please pardon me, but you are off-target in your criticisms of OFA. > > It has never advocated separating tables from indexes for performance > purposes. Ironically, your email starts to touch on the real reason for > separating them (i.e. different types of I/O, different recovery > requirements, etc). Tables and indexes do belong in different tablespaces, > but not for reasons of performance. > > Cary first designed and implemented OFA in the early 90s and formalized it > into a paper in 1995. Quite frankly, it is a brilliant set of rules of how > Oracle-based systems should be structured, and a breath of fresh air from > the simplistic way that Oracle installers laid things out at the time. It > took several years for Oracle Development to see the light and become > OFA-compliant, and not a moment too soon either. Just imagine if > everything > were still installed into a single directory tree under ORACLE_HOME? All > of things you mention here have nothing to do with OFA. > > Please read the paper. > > Hope this helps... > > -Tim > > P.S.By the way, multiple block sizes are not intended for performance > optimization; they merely enable transportable tablespaces between > databases with different block sizes. > > > on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > >> >> I would love to have a definitive site that I could send all RAID-F >> advocates to where it would be laid out clearly, unambiguously, and >> definitively what storage types should be used for what purpose. >> >> Redo logs on RAID 0 with Oracle duplexing (y/n)? >> Rollback (or undo) ditto? >> Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? >> Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper >> than 1+0 and you won't have the write penalty) >> >> While we're at it could we blow up the OFA myth? Since you're > tablespaces >> are on datafiles that are on logical volumns that are on physical devices >> which may contain one or many actual disks, does it really make sense to >> worry (from a performance standpoint) about separating tables and indexes >> into different tablespaces? >> >> We have killed the "everything in one extent" myth haven't we? > Everybody's >> comfortable with tables that have 100's of extents? >> >> And while we're at it, could we include the Oracle 9 multiple blocksizes >> and how to use them. The best that I've seen is indexes in big blocks, >> tables in small blocks --- uh, oh, time to separate tables and indexes. >> >> Maybe we will never get rid of the OFA myth. >> >> Just venting. >> >> Tired of arguing in front of management with Oracle certified DBAs that >> RAID 5 is not good, OFA is unnecessary, and uniform extents is the only > way >> to go. Looking for a big stick to catch their attention with. >> > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Tim Gorman > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > 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 > (
RE: BAARF
Cary writes > It *is* a good idea to separate index data from heap data > into different tablespaces. But the reason isn't solely to > eliminate I/O competition. Even if I/O competition isn't an > issue for you (and the OFA Standard doesn't say that it will > be), then it's *still* a good idea to separate your index > data from your heap data, for reasons including: > > * Index segments have different backup and recovery > requirements than their corresponding heap segments. For > example, as Peter mentioned, if you have an index block > corruption event, then it's convenient to just offline, kill, > and rebuild an index tablespace. If the indexes and data are > mixed up in a single tablespace, this is not an option. Another > example: If you construct your backup schedule to make media > recovery time a constant, then you probably don't need to > back up your indexes on the same schedule as you back up your > heaps. But unless they're in different tablespaces, this > isn't an option either. Hmmm maybe I'm going to start having to rethink some stuff, when you and Howard agree and I disagree it seems likely I'm being dense. My concern goes Indexes are largely built for one of two reasons A) to make performance acceptable. B) to enforce constraints. In a media recovery situation, recovering but with unacceptable performance or locking issues probably doesn't really constitute recovery. Now If it can be shown that trashing the index tablespace and rebuilding is generally faster than restoring datafiles and applying logs I might be more convinced but at the moment I'm not so sure. So is this garbage Or not.? Niall -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Niall Litchfield INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Hi! > * Index segments have different backup and recovery requirements than > their corresponding heap segments. For example, as Peter mentioned, if > you have an index block corruption event, then it's convenient to just > offline, kill, and rebuild an index tablespace. If the indexes and data Even though I agree with your point, I couldn't resist commenting that it is not too convenient to rebuild a billion row index... See you at Hotsos Symposium next year ;) Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Thomas, It *is* a good idea to separate index data from heap data into different tablespaces. But the reason isn't solely to eliminate I/O competition. Even if I/O competition isn't an issue for you (and the OFA Standard doesn't say that it will be), then it's *still* a good idea to separate your index data from your heap data, for reasons including: * Index segments have different backup and recovery requirements than their corresponding heap segments. For example, as Peter mentioned, if you have an index block corruption event, then it's convenient to just offline, kill, and rebuild an index tablespace. If the indexes and data are mixed up in a single tablespace, this is not an option. Another example: If you construct your backup schedule to make media recovery time a constant, then you probably don't need to back up your indexes on the same schedule as you back up your heaps. But unless they're in different tablespaces, this isn't an option either. * Index segments are usually smaller than their corresponding heap segments. Using separate tablespaces allows you to use a smaller extent size to conserve disk storage capacity. I don't think I ever wrote that you need to put indexes and their corresponding tables/clusters on separate disks, but you do need to be *able* to do that if your I/O rates indicate that you should. For the original OFA Standard definition, please see section 3 of the document called "The OFA Standard--Oracle for Open Systems," and section 5 of "Configuring Oracle Server for VLDB," both available for free at www.hotsos.com. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details... -Original Message- Thomas Day Sent: Monday, September 29, 2003 9:05 AM To: Multiple recipients of list ORACLE-L My struggle is not with the directory layout OFA. It is with the "mythical" OFA that every DBA that I have talked to knows all about. Where ORACLE says that if you are a good and competent DBA you will separate your table data and your index data into two separate tablespaces so that one disk head can be reading index entries while another disk head is reading the table data. You've never run into that? Tim Gorman To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent by: cc: ml-errorsSubject: Re: BAARF 09/28/2003 09:44 PM Please respond to ORACLE-L Thomas, Please pardon me, but you are off-target in your criticisms of OFA. It has never advocated separating tables from indexes for performance purposes. Ironically, your email starts to touch on the real reason for separating them (i.e. different types of I/O, different recovery requirements, etc). Tables and indexes do belong in different tablespaces, but not for reasons of performance. Cary first designed and implemented OFA in the early 90s and formalized it into a paper in 1995. Quite frankly, it is a brilliant set of rules of how Oracle-based systems should be structured, and a breath of fresh air from the simplistic way that Oracle installers laid things out at the time. It took several years for Oracle Development to see the light and become OFA-compliant, and not a moment too soon either. Just imagine if everything were still installed into a single directory tree under ORACLE_HOME? All of things you mention here have nothing to do with OFA. Please read the paper. Hope this helps... -Tim P.S.By the way, multiple block sizes are not intended for performance optimization; they merely enable transportable tablespaces between databases with different block sizes. on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > I would love to have a definitive site that I could send all RAID-F > advocates to where it would be laid out clearly, unambiguously, and > definitively what storage types should be used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? > Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper > than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different table
RE: BAARF
Hi, To add my two pennies worth. By design I create physical database lqyouts that seperate indexes and tables by tablespace for ease of management, unless the database is real small. My experience over the years with Oracle, has been the object corruptions in the database have occurred more frequenty with indexes than tables, and when it happens its good just to be able to scrap the index tablespaces datafiles and start again. Regards Pete -Original Message- Sent: 29 September 2003 02:45 To: Multiple recipients of list ORACLE-L Thomas, Please pardon me, but you are off-target in your criticisms of OFA. It has never advocated separating tables from indexes for performance purposes. Ironically, your email starts to touch on the real reason for separating them (i.e. different types of I/O, different recovery requirements, etc). Tables and indexes do belong in different tablespaces, but not for reasons of performance. Cary first designed and implemented OFA in the early 90s and formalized it into a paper in 1995. Quite frankly, it is a brilliant set of rules of how Oracle-based systems should be structured, and a breath of fresh air from the simplistic way that Oracle installers laid things out at the time. It took several years for Oracle Development to see the light and become OFA-compliant, and not a moment too soon either. Just imagine if everything were still installed into a single directory tree under ORACLE_HOME? All of things you mention here have nothing to do with OFA. Please read the paper. Hope this helps... -Tim P.S.By the way, multiple block sizes are not intended for performance optimization; they merely enable transportable tablespaces between databases with different block sizes. on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > I would love to have a definitive site that I could send all RAID-F > advocates to where it would be laid out clearly, unambiguously, and > definitively what storage types should be used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? > Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper > than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different tablespaces? > > We have killed the "everything in one extent" myth haven't we? Everybody's > comfortable with tables that have 100's of extents? > > And while we're at it, could we include the Oracle 9 multiple blocksizes > and how to use them. The best that I've seen is indexes in big blocks, > tables in small blocks --- uh, oh, time to separate tables and indexes. > > Maybe we will never get rid of the OFA myth. > > Just venting. > > Tired of arguing in front of management with Oracle certified DBAs that > RAID 5 is not good, OFA is unnecessary, and uniform extents is the only way > to go. Looking for a big stick to catch their attention with. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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). __ The information contained in this email is confidential and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. Thomson Scientific will accept no responsibility or liability in respect to this email other than to the addressee. If you have received this communication in error, please notify us immediately via email: [EMAIL PROTECTED] __ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Hitchman, Peter INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing li
Re: BAARF
My struggle is not with the directory layout OFA. It is with the "mythical" OFA that every DBA that I have talked to knows all about. Where ORACLE says that if you are a good and competent DBA you will separate your table data and your index data into two separate tablespaces so that one disk head can be reading index entries while another disk head is reading the table data. You've never run into that? Tim Gorman To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent by: cc: ml-errors Subject: Re: BAARF 09/28/2003 09:44 PM Please respond to ORACLE-L Thomas, Please pardon me, but you are off-target in your criticisms of OFA. It has never advocated separating tables from indexes for performance purposes. Ironically, your email starts to touch on the real reason for separating them (i.e. different types of I/O, different recovery requirements, etc). Tables and indexes do belong in different tablespaces, but not for reasons of performance. Cary first designed and implemented OFA in the early 90s and formalized it into a paper in 1995. Quite frankly, it is a brilliant set of rules of how Oracle-based systems should be structured, and a breath of fresh air from the simplistic way that Oracle installers laid things out at the time. It took several years for Oracle Development to see the light and become OFA-compliant, and not a moment too soon either. Just imagine if everything were still installed into a single directory tree under ORACLE_HOME? All of things you mention here have nothing to do with OFA. Please read the paper. Hope this helps... -Tim P.S.By the way, multiple block sizes are not intended for performance optimization; they merely enable transportable tablespaces between databases with different block sizes. on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > I would love to have a definitive site that I could send all RAID-F > advocates to where it would be laid out clearly, unambiguously, and > definitively what storage types should be used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? > Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper > than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different tablespaces? > > We have killed the "everything in one extent" myth haven't we? Everybody's > comfortable with tables that have 100's of extents? > > And while we're at it, could we include the Oracle 9 multiple blocksizes > and how to use them. The best that I've seen is indexes in big blocks, > tables in small blocks --- uh, oh, time to separate tables and indexes. > > Maybe we will never get rid of the OFA myth. > > Just venting. > > Tired of arguing in front of management with Oracle certified DBAs that > RAID 5 is not good, OFA is unnecessary, and uniform extents is the only way > to go. Looking for a big stick to catch their attention with. > -- Please see the
Re: BAARF
Thomas, Please pardon me, but you are off-target in your criticisms of OFA. It has never advocated separating tables from indexes for performance purposes. Ironically, your email starts to touch on the real reason for separating them (i.e. different types of I/O, different recovery requirements, etc). Tables and indexes do belong in different tablespaces, but not for reasons of performance. Cary first designed and implemented OFA in the early 90s and formalized it into a paper in 1995. Quite frankly, it is a brilliant set of rules of how Oracle-based systems should be structured, and a breath of fresh air from the simplistic way that Oracle installers laid things out at the time. It took several years for Oracle Development to see the light and become OFA-compliant, and not a moment too soon either. Just imagine if everything were still installed into a single directory tree under ORACLE_HOME? All of things you mention here have nothing to do with OFA. Please read the paper. Hope this helps... -Tim P.S.By the way, multiple block sizes are not intended for performance optimization; they merely enable transportable tablespaces between databases with different block sizes. on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > I would love to have a definitive site that I could send all RAID-F > advocates to where it would be laid out clearly, unambiguously, and > definitively what storage types should be used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? > Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper > than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different tablespaces? > > We have killed the "everything in one extent" myth haven't we? Everybody's > comfortable with tables that have 100's of extents? > > And while we're at it, could we include the Oracle 9 multiple blocksizes > and how to use them. The best that I've seen is indexes in big blocks, > tables in small blocks --- uh, oh, time to separate tables and indexes. > > Maybe we will never get rid of the OFA myth. > > Just venting. > > Tired of arguing in front of management with Oracle certified DBAs that > RAID 5 is not good, OFA is unnecessary, and uniform extents is the only way > to go. Looking for a big stick to catch their attention with. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: OFA myths was Re: BAARF
Steve, Thank you. I am grateful that someone else shrugs too. I still get a lot of feedback about the OFA. Almost every conference I go to, someone forgives me for writing the OFA Standard. And I leave not knowing for sure where things went wrong. A few weeks ago, one of the Oracle-L threads went down the trail of how the OFA requires that you separate index and heap segments on different disks. Bracing myself for embarrassment, I actually took the time to go back and read the OFA Standard document again, and much to my relief, I had not written that. (I did say that they should be stored in separate tablespaces, and I still believe that the reasons I proposed for that recommendation are legitimate. But where tablespaces should go on disk is a function of your specific operational metrics, not somebody's standards document.) There have been a lot of "OFA" documents published by various parties since my OFA document. I haven't read them all. Best I can figure is that some of these authors have been more strict in their interpretation of what I had tried to say. I tried to be *very* careful in my specification so that the document wouldn't become irrelevant with technology changes. I of course wouldn't have predicted all the technology changes that have occurred since 1995, but I phrased things as carefully as I could to allow for changes. For example, I never said you have to name mount points "/u[0-9][0-9]". I offered that as a good "OFA compliant" solution, but the OFA requirement for mount point naming is very open-ended: "Name all mount points that will hold site-specific data to match the pattern /pm, where p is a strong constant chosen not to misrepresent the contents of any mount point, and m is a unique fixed-length key that distinguishes one mount point from another." Granted, this doesn't provide for people naming their mount points after planets or Muppets or mountain peaks, but I still believe that it's a good idea to choose mount point names from a domain that can be unambiguously identified with a simple regular expression. And so on... Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details... -Original Message- Steve Rospo Sent: Thursday, September 25, 2003 5:10 PM To: Multiple recipients of list ORACLE-L I'd like to get rid of the myth that OFA really states all that much about what goes in what tablespace etc. I've got a copy of the Cary's OFA paper entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept 24, 1995. (Happy belated birthday OFA!) At the end of paper there's a summary of the requirements and the recommendations that make up OFA. The CLOSEST the OFA comes to specifying table/index separation are "#7 Separate groups of segments with different lifespans, I/O request demands, and backup frequencies among different tablespaces." -or maybe- "#11 *IF* [emphasis mine] you can afford enough hardware that: 1) You can guarantee that each disk drive will contain database files from exactly one application and 2) You can dedicate sufficiently many drives to each database to ensure that there will be no I/O bottleneck." The document itself says, "The OFA Standard is a set of configuration guidelines that will give you faster, more reliable Oracle database that require less work to maintain." So every time I read that someone is putting redo here, index tablespaces here, and temp tablespaces there in order to be "OFA compliant" I kinda shrug. Obviously it's all a good idea to separate this stuff but it's not absolutely required for OFA-ness. Essentially, OFA is just a very good way of separating Oracle code from Oracle data to make administration *much* easier. I'm sure before OFA there were plenty of places that had everything under $ORACLE_HOME/dbs and no naming standard for datafiles. Ugh! Now if we could only find this "Cary V. Millsap, Oracle Corporation" character so he could explain himself. ;-) '95 was a loong time ago. S- On Thu, 25 Sep 2003, Thomas Day wrote: [snip] > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different tablespaces? [snip] > Maybe we will never get rid of the OFA myth. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Rospo INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT
OFA myths was Re: BAARF
I'd like to get rid of the myth that OFA really states all that much about what goes in what tablespace etc. I've got a copy of the Cary's OFA paper entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept 24, 1995. (Happy belated birthday OFA!) At the end of paper there's a summary of the requirements and the recommendations that make up OFA. The CLOSEST the OFA comes to specifying table/index separation are "#7 Separate groups of segments with different lifespans, I/O request demands, and backup frequencies among different tablespaces." -or maybe- "#11 *IF* [emphasis mine] you can afford enough hardware that: 1) You can guarantee that each disk drive will contain database files from exactly one application and 2) You can dedicate sufficiently many drives to each database to ensure that there will be no I/O bottleneck." The document itself says, "The OFA Standard is a set of configuration guidelines that will give you faster, more reliable Oracle database that require less work to maintain." So every time I read that someone is putting redo here, index tablespaces here, and temp tablespaces there in order to be "OFA compliant" I kinda shrug. Obviously it's all a good idea to separate this stuff but it's not absolutely required for OFA-ness. Essentially, OFA is just a very good way of separating Oracle code from Oracle data to make administration *much* easier. I'm sure before OFA there were plenty of places that had everything under $ORACLE_HOME/dbs and no naming standard for datafiles. Ugh! Now if we could only find this "Cary V. Millsap, Oracle Corporation" character so he could explain himself. ;-) '95 was a loong time ago. S- On Thu, 25 Sep 2003, Thomas Day wrote: [snip] > While we're at it could we blow up the OFA myth? Since you're tablespaces > are on datafiles that are on logical volumns that are on physical devices > which may contain one or many actual disks, does it really make sense to > worry (from a performance standpoint) about separating tables and indexes > into different tablespaces? [snip] > Maybe we will never get rid of the OFA myth. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Rospo INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: BAARF
Put your redo logs on mirrored disks. If you've got a big array with lots of write cache, you don't even necessarily have to bother with striping across multiple disks. If you do want that, create a 0+1 plex across your disks and run it like that. Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Thomas Day > Sent: Thursday, September 25, 2003 3:20 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: BAARF > > > > And what do you suggest? > > > > > > > > I would strongly advise against redo logs on RAID-0 with > oracle duplexing. Different operating systems respond more or > less gracefully to the vanishing of a storage device (which > is the normal behavior of a failed disk on a RAID-0 set on a > HW array). There's too many variables possible to list out > the scenarios, but I would definitely definitely test failing > a RAID-0 set under load before I would go live with redo logs > on raid-0. > > Thanks, > Matt > > -- > Matthew Zito > GridApp Systems > Email: [EMAIL PROTECTED] > Cell: 646-220-3551 > Phone: 212-358-8211 x 359 > http://www.gridapp.com > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf > > Of Thomas Day > > Sent: Thursday, September 25, 2003 2:05 PM > > To: Multiple recipients of list ORACLE-L > > Subject: BAARF > > > > > > > > I would love to have a definitive site that I could send all RAID-F > > advocates to where it would be laid out clearly, unambiguously, and > > definitively what storage types should be used for what purpose. > > > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > > Rollback (or undo) ditto? > > Write intensive tablespaces on RAID 1+0 (or should that be > > 0+1)? Read intensive tablespaces on RAID ? (I guess 5 is OK > > since it's cheaper than 1+0 and you won't have the write penalty) > > > > While we're at it could we blow up the OFA myth? Since you're > > tablespaces are on datafiles that are on logical volumns > that are on > > physical devices which may contain one or many actual > disks, does it > > really make sense to worry (from a performance standpoint) about > > separating tables and indexes into different tablespaces? > > > > We have killed the "everything in one extent" myth haven't we? > > Everybody's comfortable with tables that have 100's of extents? > > > > And while we're at it, could we include the Oracle 9 multiple > > blocksizes and how to use them. The best that I've seen is > indexes in > > big blocks, tables in small blocks --- uh, oh, time to > separate tables > > and indexes. > > > > Maybe we will never get rid of the OFA myth. > > > > Just venting. > > > > Tired of arguing in front of management with Oracle certified DBAs > > that RAID 5 is not good, OFA is unnecessary, and uniform extents is > > the only way to go. Looking for a big stick to catch their > attention > > with. > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Thomas Day > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > > San Diego, California-- Mailing list and web > hosting services > > > - > > 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.net > -- > Author: Matthew Zito > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXA
RE: BAARF
And what do you suggest? "Matthew Zito" @gridapp.com>cc: Sent by: Subject: RE: BAARF ml-errors 09/25/2003 02:29 PM Please respond to ORACLE-L I would strongly advise against redo logs on RAID-0 with oracle duplexing. Different operating systems respond more or less gracefully to the vanishing of a storage device (which is the normal behavior of a failed disk on a RAID-0 set on a HW array). There's too many variables possible to list out the scenarios, but I would definitely definitely test failing a RAID-0 set under load before I would go live with redo logs on raid-0. Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Thomas Day > Sent: Thursday, September 25, 2003 2:05 PM > To: Multiple recipients of list ORACLE-L > Subject: BAARF > > > > I would love to have a definitive site that I could send all > RAID-F advocates to where it would be laid out clearly, > unambiguously, and definitively what storage types should be > used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be > 0+1)? Read intensive tablespaces on RAID ? (I guess 5 is OK > since it's cheaper than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since > you're tablespaces are on datafiles that are on logical > volumns that are on physical devices which may contain one or > many actual disks, does it really make sense to worry (from a > performance standpoint) about separating tables and indexes > into different tablespaces? > > We have killed the "everything in one extent" myth haven't > we? Everybody's comfortable with tables that have 100's of extents? > > And while we're at it, could we include the Oracle 9 multiple > blocksizes and how to use them. The best that I've seen is > indexes in big blocks, tables in small blocks --- uh, oh, > time to separate tables and indexes. > > Maybe we will never get rid of the OFA myth. > > Just venting. > > Tired of arguing in front of management with Oracle certified > DBAs that RAID 5 is not good, OFA is unnecessary, and uniform > extents is the only way to go. Looking for a big stick to > catch their attention with. > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Thomas Day > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > 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
RE: BAARF
I would strongly advise against redo logs on RAID-0 with oracle duplexing. Different operating systems respond more or less gracefully to the vanishing of a storage device (which is the normal behavior of a failed disk on a RAID-0 set on a HW array). There's too many variables possible to list out the scenarios, but I would definitely definitely test failing a RAID-0 set under load before I would go live with redo logs on raid-0. Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Thomas Day > Sent: Thursday, September 25, 2003 2:05 PM > To: Multiple recipients of list ORACLE-L > Subject: BAARF > > > > I would love to have a definitive site that I could send all > RAID-F advocates to where it would be laid out clearly, > unambiguously, and definitively what storage types should be > used for what purpose. > > Redo logs on RAID 0 with Oracle duplexing (y/n)? > Rollback (or undo) ditto? > Write intensive tablespaces on RAID 1+0 (or should that be > 0+1)? Read intensive tablespaces on RAID ? (I guess 5 is OK > since it's cheaper than 1+0 and you won't have the write penalty) > > While we're at it could we blow up the OFA myth? Since > you're tablespaces are on datafiles that are on logical > volumns that are on physical devices which may contain one or > many actual disks, does it really make sense to worry (from a > performance standpoint) about separating tables and indexes > into different tablespaces? > > We have killed the "everything in one extent" myth haven't > we? Everybody's comfortable with tables that have 100's of extents? > > And while we're at it, could we include the Oracle 9 multiple > blocksizes and how to use them. The best that I've seen is > indexes in big blocks, tables in small blocks --- uh, oh, > time to separate tables and indexes. > > Maybe we will never get rid of the OFA myth. > > Just venting. > > Tired of arguing in front of management with Oracle certified > DBAs that RAID 5 is not good, OFA is unnecessary, and uniform > extents is the only way to go. Looking for a big stick to > catch their attention with. > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Thomas Day > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > 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.net -- Author: Matthew Zito INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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).
