Raj,
(scratching my head) I haven't really thought about this (actually I dont
think, too old), but I believe NULL would be considered a "value" and
therefore the default doesn't kick in. Don't know, perhaps someone else can
confirm/deny this. If true then I would recode the procedure call to
specify the parameters with the values...OWNER=>cRec.owner. Or something
like that, my brain is getting lots of memory faults at the moment.
Otherwise, I would be studying the stats dbms_stats is generating, you know
basic stuff. Like do the tables and indexes have stats?? Or save off the
stats from dbms_stats and compare them to the stats you get from
ANALYZE_SCHEMA. Or copy the schema over, generate the stats the other way
and do some cool SQL comparing the stats.
You got to pull out your red shovel and your yellow pail and play, have some
fun.
HTH.
Chris
Crawling back into my padded cube.
-----Original Message-----
Sent: Thursday, August 08, 2002 3:20 PM
To: Grabowy, Chris; '[EMAIL PROTECTED]'
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!
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Grabowy, Chris
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
