Message-ID: <F001.005D9B56.20031212133934@fatcity.com>
Date: Fri, 12 Dec 2003 13:39:34 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sender: ml-errors@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: Mladen Gogala <mladen@wangtrading.com>
Subject: Re: rebuilding indexes - sure to cause a ruckus
Organization: Fat City Network Services, San Diego, California
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Can we, please,  change terminology and use the term "log file" 
instead of "log member". I distinctly remember backup & recovery 
class in NYC when a guy with a heavy accent popped the following
question:
         "Can I recover the database if I lose my member?"

It was the time after lunch while we were all drinking sodas
in the lobby. I distinctly remember the feeling of diet coke
coming out of my nostrils. It wasn't pleasant.

On 12/12/2003 04:19:33 PM, Denny Koovakattu wrote:
> 
>   If it's from Oracle, I would believe it, i.e., I would believe 
> somebody did actually say that ;) But it does not make it right. Now 
> only if management knew/believed that.
> 
> Some more from Oracle,
> 
> - Oracle writes to one log member and then the other. So you need both 
> log members for recovery. Volunteered to help us use 
> _allow_resetlogs_corruption when we had one intact log member. (Took a 
> lot of effort not to tell him to read the concepts manual. Was from a 
> Sev1 problem that happened a few years ago.)
> 
> -  Increasing hit ratio, OS swap size to 3 times the OS memory and 
> improving data proximity in an index (never really understood this one) 
> among other bizarre ones  to improve performance. This from an Oracle 
> consultant who was called onsite by "Development Management" because we 
> claimed the real reason was because the application was committing after 
> every record to avoid locking issues on a table generating sequences, 
> not to mention running 48 batch jobs on a 8CPU box with all of them 
> committing after every record and using the table to generate keys (Cary 
> would love this one) ;) They wanted to find "other reasons" and he 
> conveniently ignored the real problem.
> 
> BTW, I personally don't like having a zillion extents for an object 
> (more so when you have multiple "DBA Replacement Tools" querying 
> dba_extents constantly and showing flashing red lights) and would expect 
> the development team NOT to give me a deer in the headlights look when 
> asked for table sizing info. Response most often heard is "Why do you 
> need that. Oracle will be able to take care of it or can't Oracle take 
> care of it or some variation thereof " What I really want to say is if 
> you don't have any idea about your data, then please don't write any 
> SQL. That should take care of most performance issues.
> 
> Barbara Baker wrote:
> 
> >You probably think you're joking.
> >Unfortunately . . .
> >
> >We've been fighting with Oracle for several months
> >about SEVERE performance degradation on an OpenVMS
> >application after we upgraded the database to 8.1.7.4
> >
> >One of Oracle's recommendations taken directly from
> >our TAR just 2 weeks ago:
> >
> >o Ensure tables and indexes have as few extents as
> >possible.
> >
> >sigh...
> >
> >Barb
> >
> >
> >--- "Bobak, Mark" <Mark.Bobak@il.proquest.com> wrote:
> >  
> >
> >>I think this subject has been done to death.  We
> >>should talk about less contentious issues such as:
> >>
> >> - The buffer cache hit ratio, your friend in expert
> >>Oracle tuning!
> >> - Rebuild your tables regularly to reduce the
> >>number of extents and improve performance!
> >> - Disk access is at least 10,000x slower than
> >>memory, to tune your database, eliminate physical
> >>I/O!
> >>
> >>Anyone else got and good ones? ;-)
> >>
> >>-Mark
> >>
> >>    
> >>
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Denny Koovakattu
>   INET: groups@koovakattu.com
> 
> 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: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> 

Mladen Gogala
Oracle DBA
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mladen Gogala
  INET: mladen@wangtrading.com

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: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).