to get a speed advantage from dbms_stats in parallel do you have to the tablespace and/or segments broken up over several mount points?
>
> From: "Jankovic, Djordje" <Djordje.Jankovic_at_attcanada.com>
> Date: 2003/06/02 Mon PM 02:34:41 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: RE: Need help
>
> I have done some test before and found out that analyze is faster than dbms_stats for smaller tables only (less than 10M) - and the difference was not that big (for example very small tables dbms_stats would do a compute instead of estimate). For large tables they are pretty much the same. And this is comparing dbms_stats working in serial mode. You can do stuff in parallel which could change the picture in dbms_stats favor.
>
> dbms_stats is more accurate (since its introduction incorrect statistics gathering was discovered for ANALYZE), it supports better granularity control (partitions, subpartitions). Using dbms_stats you can also export and import statistics: save the old statistics before the run and reuse the old statistics in case you don't like the new ones.
>
> There are a number of other advantages: treating stale tables, automatic estimate sample size, collecting histogram info only for skewed columns (at least the ones that oracle thinks are skewed). Using dbms_stats you can also collect system stats.
>
> And analyze is not depreciated in 9i.
>
> AFAIK the only things dbms_stats does not do are: finding chained/migrated rows, computing cluster statistics, and validating the structure.
>
> Djordje
>
> -----Original Message-----
> [mailto:JKmurthy_at_chn.cognizant.com]
> Sent: Monday, June 02, 2003 10:50 AM
> To: Multiple recipients of list ORACLE-L
>
>
> Hi all,
> Can anyone tell me which of the following performs better in collecting statistics of a table:
> Analyze command or
> Dbms_stats.gather_table_stats
>
> I tried my queries with both the options -- but always Analyze is out-performing the dbms_stats.
> But i read in a document that Dbms_stats performs better !!
> Besides I also read that Analyze command will be deprecated from Oracle 9i.
>
> So can anyone tell me why dbms_stats is performing poor...
> Are there any paramters that need to be set to increase the performace of dbms_stats ?
>
> Thanks in advance.
>
> Regards
> Kesh
>
>
>
>
I have
done some test before and found out that analyze is faster than dbms_stats for
smaller tables only (less than 10M) - and the difference was not that big (for
example very small tables dbms_stats would do a compute instead of
estimate). For large tables they are pretty much the same. And this
is comparing dbms_stats working in serial mode. You can do stuff in parallel
which could change the picture in dbms_stats
favor.
dbms_stats is more accurate (since its introduction incorrect statistics
gathering was discovered for ANALYZE), it supports better granularity control
(partitions, subpartitions). Using dbms_stats you can also export and
import statistics: save the old statistics before the run and reuse the old
statistics in case you don't like the new ones.
There
are a number of other advantages: treating stale tables, automatic estimate
sample size, collecting histogram info only for skewed columns (at least the
ones that oracle thinks are skewed). Using dbms_stats you can also collect
system stats.
And
analyze is not depreciated in 9i.
AFAIK
the only things dbms_stats does not do are: finding chained/migrated rows,
computing cluster statistics, and validating the structure.
Djordje
Hi
all,
Can
anyone tell me which of the following performs better in collecting statistics
of a table:
Analyze
command or
Dbms_stats.gather_table_stats
I tried my queries
with both the options -- but always Analyze is out-performing the
dbms_stats.
But i read in a
document that Dbms_stats performs better !!
Besides I also
read that Analyze command will be deprecated from Oracle
9i.
So can
anyone tell me why dbms_stats is performing poor...
Are there
any paramters that need to be set to increase the performace of dbms_stats
?
Thanks in
advance.
Regards
Kesh
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: <rgaffuri_at_cox.net
INET: rgaffuri_at_cox.net
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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 Mon Jun 02 2003 - 14:24:53 CDT
