Oracle-L: RE: Statistics - using dbms

From: Grabowy, Chris <cgrabowy_at_fcg.com>
Date: Thu, 08 Aug 2002 12:49:34 -0800
Message-ID: <F001.004AFBC3.20020808124934@fatcity.com>

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; 'ORACLE-L_at_fatcity.com'

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: 'ORACLE-L_at_fatcity.com'; 'Rajendra.Jamadagni_at_espn.com'

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: cgrabowy_at_fcg.com

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: ListGuru_at_fatcity.com (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).

Received on Thu Aug 08 2002 - 15:49:34 CDT

RE: Statistics - using dbms_stats breaks the query