Comments on: Analyze this! http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/ Just another Oracle weblog Wed, 22 May 2013 12:40:08 +0000 hourly 1 http://wordpress.com/ By: I Wish « Oracle Scratchpad http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-43229 Fri, 16 Dec 2011 18:32:38 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-43229 [...] chained and migrated rows counted separately in dba_tables when we run the packaged procedure. The optimizer will use information about chained or migrated rows, but the information is only collected if you use the analyze command (and even then the two [...]

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36679 Sun, 04 Jul 2010 09:31:32 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36679 Bruce,

That’s an interesting observation – unfortunately my first attempt to emulate your results on 10.2.0.3 and 9.2.0.8 failed.

I modified the test scripts from the original blog, and added code after the example with the ANALYZE command to use dbms_stats.gather_table_stats() again – which left the chain_cnt in place. The resulting execution path (and 10053 trace) showed that Oracle still considered the chain_cnt.

First observation – when you use dbms_stats the global_stats column on user_tables is set to ‘YES’, when you use analyze it is set to ‘NO’. Possibly there are some versions of Oracle where the handling of chain_cnt is dependent on that flag.

Can you give an example of the code sequence you used to produce your results.

]]> By: Bruce Zikmund http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36676 Sat, 03 Jul 2010 20:30:24 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36676 I don’t believe CHAIN_CNT is actually used by the optimizer – at least not in my experience with 9i or 10g. In the past I have encountered several tables with high migrated rows, however, CHAIN_CNT = 0 because dbms_stats() doesn’t compute CHAIN_CNT! I performed a 10053 trace on a query against this table, and then again after an ANALYLZE COMPUTE STATISTICS, and found a different costing as is mentioned above. However, after re-applying dbms_stats() after the ANALYZE, the 10053 trace costing model reverted back to the pre-ANALYZE state, even though CHAIN_CNT retained its high non-zero value. Thus a technique I often use is to run a periodic sweep through the database using ANALYZE to identify those tables with increasing CHAIN_CNT – and then, immediately follow-up with dbms_stats() so as to revert to the dbms_stats costing. This enables computation of the optimum PCTFREE while not signficantly compromising the execution plans. It is also very helpful to identify tables that need to be reorganized (e.g., ALTER TABLE xxx MOVE). It would be nice to know why dbms_stats() dropped support for CHAIN_CNT in the first place as it can be a very useful statistic.

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36478 Sat, 12 Jun 2010 14:30:19 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36478 Girish:

I’m sorry, I still don’t understand what your question is. You say: “My request is what are implications of existence of chain_cnt in stats? Will it influence to calculate index access path?”

But the article is about the effects of analyze and the chain_cnt value, and includes an example with the following comment:

“The cost of the query changed so much after the analyze that I had to put in a hint to force Oracle to use the index.”

This seems to address the question you appear to be asking.

]]> By: Girish Sharma http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36473 Fri, 11 Jun 2010 06:23:30 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36473 You are saying something very different; while i wish to request something very different. I am not saying that you have said that dbms_stats will collect more smart/worthy stats; its my opinion; assumption. My request is what are implications of existence of chain_cnt in stats? Will it influence to calculate index access path? If yes; then how? (for which you have this blog entry in reference of above OTN thread in which OP is somewhat confused regarding export/import Vs Stats of chained rows).

Best Regards
Girish Sharma

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36465 Thu, 10 Jun 2010 09:30:18 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36465 “You are highlighting …”
The previous response to Henry states explicitly what I was trying to highlight.

“most worth full statistics” I did not say that using dbms_stats means you get “nost worth full statistics”, I said that Oracle Corp. has been telling you for years to use dbms_stats and not analyze – you’re supposed to use dbms_stats() – whether or not the statistics it gives are “better” or “worse”.

“Which one is good?” The best path for a query may be one that the optimizer doesn’t find, regardless of what statistics you’ve got. The important point is that analyze and dbms_stats() generate different stats and therefore may give you different paths — either strategy could give you the better paths some of your queries and worse paths for other queries.

“no/minor impact”. The blog shows an example where the impact of changing from analyze to dbms_stats() is not minor. Consistent means “always does the same thing”, which means, amongst other things: “always makes the same mistakes”. If, for a given version of Oracle, you always use analyze, the optimizer will always make same mistakes; if you always use dbms_stats() the optimizer will make a different set of mistakes – but it will always make the same “different” set of mistakes.

]]> By: Girish Sharma http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-36459 Thu, 10 Jun 2010 03:42:41 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-36459 You are highlighting that if i change the method of statistic collection; i.e. from analyze command to dbms_stats; now optimizer is having smart and most worth full statistics, but suppose there are two execution plans; (A) With Chain_cnt (B) Without Chain_cnt; so how particular this (chain_cnt) is significantly influence for calculation of index access path?. Which one is good?
If i conclude your line “adjustment for the chain_cnt is consistent with the rest of the strategy used by the optimizer..”; so there will no/minor impact of chain_cnt, because it is consistent. Please correct me, if i am wrong.

Thanks and Regards
Girish Sharma

]]> By: Analyze This – 2 « Oracle Scratchpad http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-35973 Sat, 03 Apr 2010 10:30:59 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-35973 [...] I’ve just rediscovered another note I’ve written about the difference between dbms_stats and analyze, and the effect this [...]

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-32898 Tue, 05 May 2009 18:04:00 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-32898 Henry,

There’s certainly a strong case for saying that the adjustment for the chain_cnt is consistent with the rest of the strategy used by the optimizer in calculating indexed access paths – and possibly that’s why the code changed in 9i.

The issue I wanted to highlight, though, was that you could get significant changes in costs if you changed your stats collection method.

]]> By: Henry Poras http://jonathanlewis.wordpress.com/2009/04/30/analyze-this/#comment-32893 Mon, 04 May 2009 19:22:08 +0000 http://jonathanlewis.wordpress.com/?p=1091#comment-32893 In this case wouldn’t the analyze cost be more accurate as it takes the migrated rows into account?

Henry

]]>