Thanks Chris,
I use following syntax ...
dbms_stats.gather_table_stats(
cRec.owner -- owner
,cRec.table_name -- table_name
,NULL -- partition name
,25 -- estimate pct
,FALSE -- block_sample
,NULL -- method_opt
,4 -- degree
,'DEFAULT' -- granularity
,TRUE); -- cascade
I start 5 jobs simultaneously, each has a cursor that selects owner and
tablename based on certain criteria. Looking that this, I am pretty sure, I
am collecting stats for indexes as well. I am leaving method opt to null, so
it defaults.
There is something that is going wrong ... I don't know what ... and I want
to find out ...
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
-----Original Message-----
Sent: Thursday, August 08, 2002 3:15 PM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Hi Raj,
I am assuming that you are using DBMS_STATUS.GATHER_SCHEMA_STATUS, so
perhaps you are not generating stats for the indexes. The syntax...
DBMS_STATS.GATHER_SCHEMA_STATS (
ownname VARCHAR2,
estimate_percent NUMBER DEFAULT NULL,
block_sample BOOLEAN DEFAULT FALSE,
method_opt VARCHAR2 DEFAULT 'FOR ALL COLUMNS SIZE 1',
degree NUMBER DEFAULT NULL,
granularity VARCHAR2 DEFAULT 'DEFAULT',
cascade BOOLEAN DEFAULT FALSE);
The last parameter is "cascade", which determines if stats are generated for
indexes. As you can see, the default is FALSE.
If you are using DBMS_STATS.GATHER_SCHEMA_STATS then are you setting the
cascade parameter to TRUE?
Also, if your only populating the first two parameters, then you may want to
look over all the parameters. Everyone of them may have some potential
value for your situation.
HTH
Chris
-----Original Message-----
Sent: Thursday, August 08, 2002 2:49 PM
To: Multiple recipients of list ORACLE-L
Okay ... here is the problem ...
We have our DB (8161) running in RULE mode. Due to some schema using
Context, we need to analyze a bunch of tables, but the table has optimizer
mode set to RULE.
We used to do 'exec dbms_utility.analyze_schema('<schema>,'COMPUTE');' for a
long time. Lately it doesn't finish, so I changed it to ESTIMATE. The
database and certain queries were okay, running within limits.
Then one day (my mistake), I changed the scripts to use dbms_stats to do the
analyze instead of dbms_utility.analyze_schema. This broke some of our
critical and large reports. These reports run in 20 mins, but after using
dbms_stats, it took the reports > 2.5 hours to finish.
I assume, dbms_utility.analyze_schema(), 'alter table analyze', and
dbms_stats are same and do the same thing. So, why do the reports work fine
when using the former 2 and a re dead slow when using dbms_stats ?? What is
so different in 'analyze table' and 'dbms_stats' ??
Any hints, ideas are gratefully accepted.
Thanks in advance
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
*********************************************************************This e-mail
message is confidential, intended only for the named recipient(s) above and may
contain information that is privileged, attorney work product or exempt from
disclosure under applicable law. If you have received this message in error, or are
not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000
and delete this e-mail message from your computer, Thank
you.*********************************************************************2
