| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: cardinality in query plans?
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
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_at_cox.net>
> Date: 2004/03/15 Mon AM 08:50:35 EST
> To: oracle-l_at_freelists.org
> 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon Mar 15 2004 - 08:13:24 CST
 |
 |