CBO changed path

From: Baker, Barbara <bakerb_at_rockymountainnews.com>
Date: Fri, 14 Sep 2001 08:51:38 -0700
Message-ID: <F001.0038EB22.20010914083023@fatcity.com>

!! Please do not post Off Topic to this List !!

We have had 2 querys go wacko on us. Both are cursors in a large
(5000 line) pl/sql package. This interface package runs daily.
The cursor execution below ran in less than 30 seconds on Tues; ran 2 hrs 15 minutes Wed. (yikes!) We had the same problem with a similar cursor 2 weeks ago.

I've fixed the query by adding more selectivity to the where clause. Here's the real mystery. I pulled the 3 tables from this join from the production box (E4500 Solaris 2.6, Oracle 8.0.5) to our smaller test box. Small test box is running identical stuff (solaris 2.6, Oracle 8.0.5). The query still runs in under 30 seconds on small test box. I dumped all the init parameters (SELECT NAME, VALUE FROM V$PARAMETER) from both databases, then did a diff in the output files. No significant differences that I can see.

I'm wondering why the query still runs ok on the test box, but went wacko on the "real" system.

These 3 tables are small (invrows 95,062 rows 21 megs; sub_ad 5,993 rows, 20 megs; sub_pub 45,553 rows 30 megs). All 3 tables have identical indexes on both boxes; all 3 have been analyzed on both boxes. All 3 tables have index on column adno. optimizer is choose on both instances.

Sorry this is so long. I'd appreciate any insights. Thx!!!

Barb

select
i.adno,
<more stuff>
from invrows i,

        sub_ad a,
        sub_pub p
WHERE   A.RUNNO=860      and   I.ROWTYPE=4
  and   I.ADNO=A.ADNO    and   I.VNO=A.VNO
  and   i.adno=p.adno    and   i.pubno=p.pubno
  and   a.vno=p.vno      and   A.VNO=1

and a.startdate > a.rdate
and a.enddate = to_date(a.cus4name,'mm/dd/rrrr') and to_char(a.rdate,'mm/dd/rrrr') = to_char(p.mdate,'mm/dd/rrrr')

autotrace from production (BAD!!)

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=313) 1 0 NESTED LOOPS (Cost=1 Card=1 Bytes=313)

   2    1     NESTED LOOPS (Cost=56 Card=7 Bytes=1267)
   3    2       TABLE ACCESS (FULL) OF 'SUB_AD' (Cost=10 Card=1 Bytes=133)
   4    2       TABLE ACCESS (FULL) OF 'SUB_PUB' (Cost=46 Card=5820
Bytes=279360)
   5    1     TABLE ACCESS (BY INDEX ROWID) OF 'INVROWS' (Cost=1 Card=6791
Bytes=896412)
   6    5       INDEX (RANGE SCAN) OF 'I_INVR1' (NON-UNIQUE) (Cost=1

Card=6791)

autotrace from test box (Good!)

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=313) 1 0 NESTED LOOPS (Cost=1 Card=1 Bytes=313)

   2    1     NESTED LOOPS (Cost=1 Card=1 Bytes=265)
   3    2       TABLE ACCESS (FULL) OF 'SUB_AD' (Cost=11 Card=1 Bytes=133)
   4    2       TABLE ACCESS (BY INDEX ROWID) OF 'INVROWS' (Cost=1 Card=6906
Bytes=911592)
   5    4         INDEX (RANGE SCAN) OF 'I_INVR1' (NON-UNIQUE) (Cost=1
Card=6906)
   6    1     TABLE ACCESS (BY INDEX ROWID) OF 'SUB_PUB' (Cost=1 Card=6911
Bytes=331728)
   7    6       INDEX (UNIQUE SCAN) OF 'I_SUBPUB1' (UNIQUE)



_______________________________

tkprof from production (BAD!!)
(The tkprof shows 129,696,658 rows returned for sub_pub when the
entire table is only 45,000 rows.)

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ----------

Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.01 0.01 0 0 0 0
Fetch 7 8139.09 8153.17 907 56669565 8361 102
------- ------ -------- ---------- ---------- ---------- ----------

total 9 8139.11 8153.19 907 56669565 8361 102

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 618 (AMAX)

Rows Execution Plan

-------  ---------------------------------------------------
      0  SELECT STATEMENT   GOAL: CHOOSE

102 NESTED LOOPS
54193272 NESTED LOOPS

   5993     TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'SUB_AD'
129696658     TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'SUB_PUB'
  27213    TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF 'INVROWS'
155138410     INDEX   GOAL: ANALYZED (RANGE SCAN) OF 'I_INVR1' (NON-UNIQUE)

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Baker, Barbara
  INET: bakerb_at_rockymountainnews.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 Fri Sep 14 2001 - 10:51:38 CDT

CBO changed path - why??