There are all sorts of little changes (and bugs) that appear in point releases; but it’s possible that the calculated cardinality from line 21 (which will end up in line 18) is very much smaller than one, even thought it has to be reported as one. Then (very small * 508K) can come to one. Simple rounding can cause some confusion. This is only a guess, of course; you might be able to confirm it by looking at the 10053 trace.

I extracted an execution plan from AWR, and am a bit puzzled on reading the following bit:

------------------------------------------------------------------------------------
| Id  | Operation                        | Name       | Rows  | Bytes | Cost (%CPU)|
------------------------------------------------------------------------------------
|  17 |             MERGE JOIN CARTESIAN |            |     1 |    62 | 10837   (2)|
|  18 |              NESTED LOOPS        |            |     1 |    44 |   249   (1)|
|  19 |               FAST DUAL          |            |     1 |       |     2   (0)|
|  20 |               PARTITION RANGE ALL|            |     1 |    44 |   247   (1)|
|  21 |                TABLE ACCESS FULL | TBL_BONUSES|     1 |    44 |   247   (1)|
|  22 |              BUFFER SORT         |            |   508K|  8940K| 10590   (2)|
|  23 |               TABLE ACCESS FULL  | TBL_PLAYERS|   508K|  8940K| 10588   (2)|

It’s a cartesian join and so the estimated cardinality here should be 1*508K = 508K. But it is showing up as 1!!

Is this a bug or is there something else going on?

Version is 10.2.0.5 EE

Many thanks.

select count(1) from
( select ’2010-08-02′ as data_desc,
t2.lev,
count(1)
from dn_coinlog_his t1,
dn_character_mes1 t2
where t2.area_id = t1.area_id
and t2.character_id = t1.characterid
and t2.data_desc = t1.data_desc
and t1.data_desc = ’2010-08-02′
group by t2.lev);

However, it did NOT use transtive closure to generate execution plan with “partition range single”.
I traced it with 10053 and found it passed the CBQT validity, however, Oracle did NOT rewrite it
with t1.data_desc = ’2010-08-02′ and t2.data_desc =’2010-08-02′.

Below is abstract from 10053 event.

Predicate Information:

**************************
Predicate Move-Around (PM)
**************************
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks passed for afg5yjfy225db.
Query block (0x2a973e5398) before join elimination:
SQL:******* UNPARSED QUERY IS *******
SELECT ’2010-08-02′ “DATA_DESC”,”T2″.”LEV” “LEV”,COUNT(1) “COUNT(1)” FROM “DI_USER”.”DN_COINLOG_HIS” “T1″,”DI_USER”.”DN_CHARACTER_MES1″ “T2″
WHERE “T2″.”AREA_ID”=”T1″.”AREA_ID”
AND “T2″.”CHARACTER_ID”=”T1″.”CHARACTERID”
AND “T2″.”DATA_DESC”=”T1″.”DATA_DESC”
AND “T1″.”DATA_DESC”=’2010-08-02′
GROUP BY “T2″.”LEV”
Query block (0x2a973e5398) unchanged

Could you show me why Oracle rewrite it with PM, sometime it not?
By the way, I have wrote you about this issue with trace file. Sorry for disturb you again.

Thank you again for your time,
Amao

I will do that when we get CMJs in memory next time and will use “+peeked_binds” option with display_cursor.

Thank you again for your time,
Ajith

This seems a little unlikely because you still get bind variable peeking that results (bugs excepted) in optimization against known constants. I suppose it’s possible that you could get more Cartesian Merge Joins on SIMILAR than you would on FORCED because the former allows re-optimization in various circumstances – so you get through more plans.

You may be getting CMJs because the estimated cardinality of the driving table is much less than one. It the estimate is correct then the CMJ is reasonable – if the estimate is wrong then the query will take longer than expected. When you find a CMJ in memory, use the “peeked_binds” option in dbms_xplan.display_cursor ( http://optimizermagic.blogspot.com/2008/02/displaying-and-reading-execution-plans.html ) to see if you can find the bind variables and reproduce the plan using constants.

If the cursor_sharing parameter is set to SIMILAR at the instance level, do you think that it can cause Cartesian merge join for many queries? I see a lot of Cartesian joins in one such database(11G – 11.1.0.7.0). I am investigating on the root cause. If it is not the reason, what else can lead to Cartesian joins? Most of the time, the query executes fast (using nested loop join), but at times it takes a long time to execute (using Cartesian merge join).

Thanks,
Ajith

You might consider using the opt_param() hint to set _optimizer_mjc_enabled to false for the duration of the query – but it’s probably an unsupported method (unless you get approval through an SR to Oracle).

The cardinality of 1 MIGHT be a side effect of the “in subquery” applying a selectivity of 5% to the target of the “IN” so a cardinality hint that scales up the single table cardinality of the target table by a factor of 20 (or more) might help – but it’s hard to say without a detailed investigation of the query, and the cardinality hint is a little subtle in anything other than very trivial cases.

Is it possible that you’re seeing a bug which I thought I’d described somewhere on the blog but can’t find at present … there are cases in 10g where the cardinality of a query with subquery is ALWAYS 1 thanks to an error in a bug-fix relating to when the normal 5% selectivity is applied. If this bug appears as the last step of a query then it doesn’t really matter, but if it appears as the last step of a non-mergeable inline view then it can have a huge impact. A workaround that may apply is to put a push_subq hint into the subquery in the inline view.

select …
where col1 in ()

The inline view can range from 1 to 50 results and the performance is terrible with a few dozen results in the inline view. The optimizer is estimating only 1 row from the inline view.

Setting the parameter, _optimizer_mjc_enabled to false forces a NESTED LOOP instead of the CMJ.

I tried with setting the CARDINALITY and DYNAMIC_SAMPLING hint, but neither one of these prevented the CMJ and still showed an estimation of 1.

Would there be anything else possible to preclude the CMJ from occurring other than setting the hidden parameter?

Read note 30 – where I point out that we don’t scan the whole hash data set for each row in the parent set.

Think of a hash table as a large set of buckets (and I mean water carrying buckets) arranged in a large square pattern – say 64 buckets in an 8 by 8 square.

To use the hash table you have some piece of arithmetic which says: if I want the number 1,436 it will be in the bucket in row 3 column 8; if I want the number 9,132 it will be in the bucket in row 8 column 2. (That’s all that a “hash function” does.)

So if you have a number I know where to look for a match. And Oracle tries to use a lot of buckets in a very big square – so there aren’t many “wrong” rows in a bucket when you look in it.

As from your last comment regarding probing for hash table. Can you please explain more about what do you mean by cell. As, general understanding is each row for parent table scans whole hash data which is there in memory or temp tablespace for child table. Please correct me if i am wrong on above sentence. Also, can you please give some more information.