do
not force a
query to use that particular plan.
If you want to force Oracle to use a particular plan, plan
stability is
orders of magnitude easier!
Umm, but if you look at plan stability you will see that it is
implemented as hints (and query rewrite) - typically loads of them.
A
hint
- an ordered hint would have eliminated that option as
well.
so plan stability works (in my
understanding)by generating a set of hints that limit the available
execution plans to 1 (the one you want), and ensuring that when the query you
want plan stability is issued query rewrite kicks in and sends
to change, etc.
If you want to force Oracle to use a particular plan, plan
stability is
orders of magnitude easier!
Umm, but if you look at plan stability you will see that it is
implemented as hints (and query rewrite) - typically loads of them. A
hint *does* force you to do what it says
Btw, the one good use for plan stability stored outlines are poorly
written 3rd party applications, where you can't even add a hint to code. I
these cases you can compose a good execution plan yourself and set your
statement to use it.
Tanel.
- Original Message -
To: Multiple
, there must be another problem. Any guesses?
rw
If you want to force Oracle to use a particular plan, plan stability
is orders of magnitude easier!
Only if you happen to have the licence for the 9.2 performance
tuning pack, and can use the dinky little GUI for drawing
Hi,
my question is about the same, but more general. How can i force Oracle to use my
prefered way of explain plan and not use CBO's. I mean, apart from stored outlines, it
somehow seems to complicated. I would like to say what order and join types it should
use. But, try as I might, I many
Subject: Plan stability
Hi,
my question is about the same, but more general. How can i
force Oracle to use my prefered way of explain plan and not
use CBO's. I mean, apart from stored outlines, it somehow
seems to complicated. I would like to say what order and join
types it should
to the CBO or new Oracle functionality should cause the ideal plan
to change, etc.
If you want to force Oracle to use a particular plan, plan stability is
orders of magnitude easier!
Justin Cave
Hi, list friends:
We are using partition to archive history data in our
production OLTP database. We
scan of other table, use hash join then etc. If you have
explain plain with 5 steps, why cannot I write these 5 steps together with query so
Oracle takes it for granted that this is the best way to do it?
If you want to force Oracle to use a particular plan, plan stability
is orders
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Wartiak Rastislav Sent: 2. desember 2003 08:44
To: Multiple recipients of list ORACLE-L
Subject: Plan stability
Hi,
my question is about the same, but more general. How can i
force Oracle to use my prefered way of explain plan and not
use
] [mailto:[EMAIL PROTECTED] On
Behalf Of Wartiak Rastislav
Sent: 2. desember 2003 09:39
To: Multiple recipients of list ORACLE-L
Subject: RE: Plan stability
AFAIK RBO cannot be used for partitioned tables, not talking
about the fact that RBO might not be supported in future versions
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Wartiak Rastislav Sent: 2. desember 2003 08:44
To: Multiple recipients of list ORACLE-L
Subject: Plan stability
Hi,
my question is about the same, but more general. How can i force
Oracle to use my prefered way of explain plan
ORACLE-L
Subject: RE: Plan stability
AFAIK RBO cannot be used for partitioned tables, not talking
about the fact that RBO might not be supported in future versions.
What is complicated about stored outlines? If you don't like those
you can always go back to the RBO.
Gudmundur
issues should be moot.
(b) Plan stability exists to stop execution plans from changing - so
any SQL with a plan should, by your comment above, require
it's stored outline to be put under review in case any new functionality
should be applied and the outline changed. So, again, your
The biggest problem with hints is that you cannot
specify a full set - in particular there is no effective
way to handling unnesting of subqueries.
For simple cases, you can put the tables in the
main query in the 'correct' order and use the
ORDERED hint, then name the indexes and
join
15 matches
Mail list logo