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 -----------------------------------------------------------------