Mark,
The obvious redundant indexes are the ones the n columns of which happen to be, and
in the same order, the nth first columns of another index. There is not much which can
be said besides. First of all, I would question your definition of redundant as
never used by Oracle. Some indexes
There is also the issue of keeping an index that is
not used in any explain plan, but is required to
prevent a foreign key locking problem.
hth
connor
--- Stephane Faroult [EMAIL PROTECTED] wrote:
Mark,
The obvious redundant indexes are the ones the n
columns of which happen to be, and
Cary,
I assume that using stored outlines will achieve No 2 in your list. Would
that not be an easier approach?
If you altered the system to have CREATE_STORED_OUTLINES=true and ran for a
period when all scripts are likely to be run, say a month so that all
month-end processing was completed,
We assessed this and discarded the option, and now I can't remember why
(I'll get back to you after I ask Jeff Holt, who did the study). At
best, using stored outlines is a replacement only for steps 2 and 4. The
really hard part is step 1.
Cary Millsap
Hotsos Enterprises, Ltd.
Step 6 should be fun -
It is possible to come up with code where plan A is
better than plan B in low concurrency systems,
but plan B is better than plan A in high concurrency
systems.
Similarly, plan X is better than plan Y if no updates are
taking place concurrently, and plan Y is better than
Mark,
The way we do it is by what you might call extreme brute force:
1. Capture all SQL from the applications (not just the stuff you've run
in the past month, but the stuff you'll run in the future too, like
period-end close processes, and so on).
2. Generate execution plans in production for
