Comments on: The Sin of Band-Aids

By: Robert

Robert — Mon, 18 Aug 2008 21:25:58 +0000

I hav run into this same issue in bith 9i & 10g. A plan will suddenly change for the worse when one or more tables changes by a few percent. My solution in 10g has been to run statistics at a very high (50% to 100%) sample rate. This has given me pretty good results so far. The 9i version of the database got along fine with 10% sample rates.

By: Yue

Yue — Thu, 24 Jul 2008 19:16:58 +0000

Have you encountered such situation?

the A and the B provide different plan hash values even at the same time?

A.
select sql_id, plan_hash_value, users_opening,hash_value, child_number
from v$sql
where sql_id=’4c9k39a1skd9m’
/

SQL_ID PLAN_HASH_VALUE USERS_OPENING HASH_VALUE CHILD_NUMBER
————- ————— ————- ———- ————
4c9k39a1skd9m 814482344 0 2206807347 0
B.
SELECT * FROM TABLE(dbms_xplan.display_awr(‘4c9k39a1skd9m’))
Plan hash value: 1130938188

In my actual production DB, I found that these two produced different plans and the users were experiencing A and not the B which is a better plan. It seems that the B way is less reliable than A.

By: Donald K. Burleson

Donald K. Burleson — Sat, 21 Jun 2008 15:03:30 +0000

Hi Steve,

Great note, very true of the real world.

Also, let’s not forget to mention that system statistics (dbms_stats.gather_system_stats) can also improve execution plans in very much the same way as optimizer_index_cost_adj.