I tried the following but they didn’t help:
alter session set “_optimizer_cost_based_transformation” =off;

alter session set “_gby_hash_aggregation_enabled” = FALSE;

Waiting for your reply.
Thanks,
Santosh Kumar

I have my stats package using AUTO and I have over 600 tables with 80K columns.

Any change on a production system to a global feature like stats collection could have unpredictable side-effects – so I can’t tell you whether there is any danger in stopping histogram collection on the syatem schema. You could side-step that issue by writing your own job that does “gather schema stats” on the system schema before allowing Oracle’s default stats collection to run.

The pitiful response against tablespaces and files could be related to a problem with statistics – it is possible for queries for used extents to run very inefficiently, a problem that could be exacerbated by partitioned tables with lots of partitions. If you are licenced to use the Performance Pack, you might try to capture the SQL used by OEM for these reports and see if the SQL tuning tool gives you any advice about statistics.

I know I am late to the table, we have just finally upgraded to 10g. Performance was bad until we made sure all instances had good system stats.

We have a couple of schemas which still perform badly. One is a warehousing schema which contains many partitioned tables. I am not sure why but when we gather stats manually on the affected tables (those performing badly during data loads). Performance returns to normal. It seems like the auto stats process is not gathering good stats on these tables. The script we have been using did not set METHOD_OPT so we were using the 10g default.
The second schema is an OLTP system which performs many updates to quantity columns, only a small percentage of the other attributes change. Oracle has gathered many histograms on this schema.
I would like to change the METHOD_OPT parameter to the 9i default. However, since the auto stats gathering process also gathers stats on system tables. I am concerned that changing the default METHOD_OPT will impact stats on the system tables. Is there a danger in setting ‘METHOD_OPT’ to ‘FOR ALL COLUMNS SIZE 1′ for the gathering of stats on the system tables?

We have been using all the defaults with disastrous results using OEM to view tablespaces and files. Response is pitiful against LMT (as much as 5 minutes) but great against the system tablespace which is still DMT (1 -2 seconds). This applies only to 10g databases. We still have a few 9.2.0.7 because 3rd party vendors are not ready. A TAR with oracle did not help. I gave up after more than a month of running queries and submitting trace file after trace file.

Do you have any comments on this?

Cos, I’ve seen it; it’s a good read, but a little heavy going in places. It may help some people to recognise some of the changes that have appeared in their upgrade.

Another interesting topic/article “Cost-Based Query Tranformation in Oracle” at http://portal.acm.org/citation.cfm?id=1164215&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618

Thought you might want to comment/expand on that, as a topic for a future blog post ;-)

thx,
Cos