Out of date stats can easily be a problem. It’s imperative to the the query optimizer accurate information, so I’d recommend you collect stats that are representative.

Your friends sound like they insist on fighting symptoms rather than addressing root cause. If the distribution being chosen is broadcast, then the cardinality estimate is low. Whether or not that is accurate is a different discussion. Histograms are really not all that useful for OLTP systems that use bind variables as they don’t really mix well. On one hand you want to reuse plans for queries/cursors, but then with a histogram you are basically saying – I want different plans for different values. See how those two don’t mix? Simply put, histograms will matter where there is data skew – and that is quite common in data warehouses.

If you want to convince your DBA friends just have them refresh the stats. If they are so sure it won’t matter, then they should have no objection to proving it. :)

But my DBA friends insist in using PQ_DISTRIBUTE() hints to force (hash,hash) distribution to avoid (broadcast, none) distribution. They strongly believe that HISTOGRAMS are more useful for OLTP systems, they do not matter in DW. I have witnessed quite some DW performance issues in 10g because of lacking of histograms or using wrong histograms, but how can I convince those DBAs to at least refresh the histograms for certain columns?

Thank you and I think that dissecting execution plans would make a great blog post. I shall add that to my list of ideas. Thanks again.

Wow you certainly are a great teacher .
was wondering if that dissection would be an item of your next blog under the heading troubleshooting bad execution plans by dissecting the joins one step at a time.

excellent piece of advise by the way.

regards
Hrishy

You can cancel a query and still call dbms_xplan.display_cursor(format=>’allstats last’), and it will display the actual rows it returned thus far for the row sources that have been executed thus far, but I’m not certain this will be of much use. I would liken it to trying to find out how many rows a query returns without actually running the query. A database does not know how many rows will be returned until there are no more rows to be fetched.

What I would recommend in your case is to break the query into bite size chunks. Start with single table predicates and validate the estimates are reasonable. Then start with a 2 table join, validating the cardinality again. Add one more table, and validate again. Keep doing this until you find the join where the cardinality estimates go wrong.

Hope that helps.

I notice that the gather_plan_statistics hint that you use to have look at the actual and estimated cardinality requires that the sql run to completion and only then the call to the dbms_xplan.display_cursor is made .

If my query takes an hour or so and i am one of those impatient types would it be possible for me to do a control +C on the query and then make a call to the dbms_xplan.display_cursor to reveal the estimated and actual cardinalities .(don’t have accesses to oracle at the moment so i am not able to verify this)or is their any other method

regards
Hrishy