Re: rebuilding indexes - sure to cause a ruckus

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_at_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_at_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_at_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_at_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_at_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).