RE: OFA myths was Re: BAARF

2003-09-30 Thread Jacques Kilchoer
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

RE: OFA myths was Re: BAARF

2003-09-30 Thread 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!!! Tom Mercadante Oracle Certified Professiona

RE: OFA myths was Re: BAARF

2003-09-30 Thread Jacques Kilchoer
> -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 Adminis

RE: OFA myths was Re: BAARF

2003-09-30 Thread Paul Baumgartel
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

Re: BAARF

2003-09-29 Thread Tim Gorman
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 a

RE: OFA myths was Re: BAARF

2003-09-29 Thread Cary Millsap
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

RE: BAARF

2003-09-29 Thread Cary Millsap
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: - Perfo

RE: OFA myths was Re: BAARF

2003-09-29 Thread Jacques Kilchoer
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 ass

Re: BAARF

2003-09-29 Thread Binley Lim
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

Re: BAARF

2003-09-29 Thread Tim Gorman
the table data. You've never run into that? > > > > > Tim Gorman @sagelogix.com> To: Multiple recipients of > list ORACLE-L <[EMAIL PROTECTED]> > Sent by:

RE: BAARF

2003-09-29 Thread Niall Litchfield
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

Re: BAARF

2003-09-29 Thread Tanel Poder
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 E

RE: BAARF

2003-09-29 Thread Cary Millsap
#x27;ve never run into that? Tim Gorman To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent by: cc: ml-errorsSubject: Re: BAARF

RE: BAARF

2003-09-29 Thread Hitchman, Peter
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 freque

Re: BAARF

2003-09-29 Thread Thomas Day
an To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent by: cc: ml-errors

Re: BAARF

2003-09-28 Thread Tim Gorman
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,

RE: OFA myths was Re: BAARF

2003-09-26 Thread Cary Millsap
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 wen

OFA myths was Re: BAARF

2003-09-25 Thread Steve Rospo
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

RE: BAARF

2003-09-25 Thread Matthew Zito
f list ORACLE-L > Subject: RE: BAARF > > > > And what do you suggest? > > > > > > > > I would strongly advise

RE: BAARF

2003-09-25 Thread Thomas Day
Zito" @gridapp.com>cc: Sent by: Subje

RE: BAARF

2003-09-25 Thread Matthew Zito
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 o