Re: dbms_stats
From: Bradd Piontek <piontekdd_at_gmail.com>
Date: Wed, 3 Jun 2009 06:44:08 -0500
Message-ID: <e9569ef30906030444h4907562dx5b668e62e5c65106_at_mail.gmail.com>
I'd also rerun the dbms_stats call with 'cascade=true'. Leaping to the conclusion that analyze is better than dbms_stats using a couple queries and providing no metrics other then elapsed time isn't very good proof.
Date: Wed, 3 Jun 2009 06:44:08 -0500
Message-ID: <e9569ef30906030444h4907562dx5b668e62e5c65106_at_mail.gmail.com>
I'd also rerun the dbms_stats call with 'cascade=true'. Leaping to the conclusion that analyze is better than dbms_stats using a couple queries and providing no metrics other then elapsed time isn't very good proof.
Bradd
On 6/3/09, jaromir nemec <jaromir_at_db-nemec.com> wrote:
> Hi,
>
>>
>> so from my test , i show analyze is better than DBMS_STATS..... Any
>> other ideas plz
>
> This shows first of all that the second test runs better then the first one.
> This could be a result of caching.
>
> I'd suggest:
>
> 1) run the selects with autotrace on to see if you have different
> execution plans
>
> 2) repeat the runs to see the ratio of logical and physical I/O (also
> visible in autotrace output)
>
> HTH
>
> Jaromir
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- Sent from my mobile device Bradd Piontek "Next to doing a good job yourself, the greatest joy is in having someone else do a first-class job under your direction." -- William Feather -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 03 2009 - 06:44:08 CDT