RE: Why "Separating Data and Indexes improves performance" is a m yth?

  • From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 23 Apr 2004 14:04:27 -0500

The one that comes to mind is a particularly nasty query from a Business
Objects (aka "B.O.") report that runs against our OLTP DB.  Did I mention
that the vendor ported the schema from VMS RMS files, so there's no
normalization (e.g. first row of description in master table, with the rest
of the description optionally in another table) or RI or PKs?

Needless to say, the BO universe is butt ugly, as are the resulting queries.
But hey, I'm only a DBA.  I guess we don't need any sort of DW/DM.  That
18-hour query can be run on weekends, or "We Can Just" throw hardware at it.


Rich

Rich Jesse                        System/Database Administrator
rich.jesse@xxxxxxxxxxxxxxxxx      QuadTech, Sussex, WI USA

Disclaimer: Here's to good friends and good times, tonite is kinda special.


> -----Original Message-----
> From: Tim Gorman [mailto:tim@xxxxxxxxxxxxx]
> Sent: Friday, April 23, 2004 1:07 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Why "Separating Data and Indexes improves 
> performance" is a
> m yth?
> 
> 
> Do you see a lot of FAST FULL scans?  Generally, when I see 
> them, they are
> the result of either:
> 
>     * SELECT COUNT(*) on table with PK (usually ad-hoc, thus rare)
>     * result of index being forced into usage due to an inappropriate
>       INDEX hint (i.e. no predicates using the index in the WHERE
>       clause)
>     * ALTER INDEX ... REBUILD (hopefully relatively rare)
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: