Re: cardinality in query plans?
- From: <ryan.gaffuri@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 15 Mar 2004 9:16:57 -0500
second one has the hints. So obviously the hint is better. I'm at a loss to
explain why I need a hint.
SQL> exec runstats_pkg.rs_stop(500);
Run1 ran in 1456 hsecs
Run2 ran in 1288 hsecs
run 1 ran in 113.04% of the time
Name Run1 Run2 Diff
LATCH.simulator hash latch 898 257 -641
STAT...redo size 72,380 73,300 920
STAT...table fetch by rowid 1 6,293 6,292
STAT...buffer is pinned count 0 7,942 7,942
STAT...session logical reads 14,490 5,535 -8,955
STAT...consistent gets 13,945 4,982 -8,963
STAT...no work - consistent re 13,897 4,927 -8,970
STAT...buffer is not pinned co 13,858 4,812 -9,046
STAT...table scan blocks gotte 13,856 168 -13,688
LATCH.cache buffers chains 30,587 12,668 -17,919
STAT...session uga memory max 0 27,592 27,592
STAT...table scan rows gotten 870,888 130 -870,758
Run1 latches total versus runs -- difference and pct
Run1 Run2 Diff Pct
33,803 14,975 -18,828 225.73%
PL/SQL procedure successfully completed.
I'm learning the 10053 trace now. I'm real curious about the cardinality issue
from my last email.
>
> From: <ryan.gaffuri@xxxxxxx>
> Date: 2004/03/15 Mon AM 08:50:35 EST
> To: oracle-l@xxxxxxxxxxxxx
> Subject: cardinality in query plans?
>
> I'm doing a two table join and both tables are analyzed. Oracle is
> incorrectly choosing a full tables scan over an index search(I tested it,
> index search has 1/4 the logical I/Os).
>
> When I see the cardinality for the full tablescan I see 262,000. However,
> when I do a count(*) of the table or check num_rows in dba_tables I see
> 870,000 records. I'm assuming this is why Oracle is choosing the full table
> scan.
>
> table is analyzed as follows:
>
> exec dbms_stats.gather_table_stats(cascade=>true).
>
> this interesting part is that when I use bind variables Oracle chooses the
> proper plan. Any ideas?
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
