Corellated update AND merge(update only)

Question

Hi ,
I have few corellated updates in my code , which i though ,i can replace with 10g new Merge update only stmt.
But to my surprise , the sql using merge is showing more cost and using full table scan.
Please find below the sql stmts. below(example). Am using Oracle 10.2.0.1
create table t1 as select * from all_objects where rownum<10000;
create table t2 as select * from t1 where rownum<10000-200;
create unique index t1_objId_ind on t1(object_id);
create unique index t2_objId_ind on t2(object_id);
--Corellated updated query
update t1 set t1.object_name= (select upper(t2.object_name) from t2 where t1.object_id=t2.object_id)
where T1.OBJECT_ID IN (SELECT t2.object_id from t2);Explan for above update stmt.
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |              |  9139 |   383K|    37   (9)| 00:00:01 |
|   1 |  UPDATE                      | T1           |       |       |            |          |
|   2 |   NESTED LOOPS               |              |  9139 |   383K|    37   (9)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | T1           |  9138 |   267K|    35   (3)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | T2_OBJID_IND |     1 |    13 |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| T2           |     1 |    30 |     2   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|*  6 |    INDEX UNIQUE SCAN         | T2_OBJID_IND |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   6 - access("T2"."OBJECT_ID"=:B1)I wanted to eliminate the corellated update , So i wrote using MERGE as below
MERGE INTO T2
USING T1
ON (t1.object_id=t2.object_id)
WHEN MATCHED THEN update
  SET T2.OBJECT_NAME=UPPER(T1.OBJECT_NAME);Explan for above MERGE stmt.
| Id  | Operation            | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | MERGE STATEMENT      |      |  9139 |   303K|       |   201    (2)| 00:00:03 |
|   1 |  MERGE               | T2   |       |       |       |            |          |
|   2 |   VIEW               |      |       |       |       |            |          |
|*  3 |    HASH JOIN         |      |  9139 |  2391K|  1256K|   201   (2)| 00:00:03 |
|   4 |     TABLE ACCESS FULL| T1   |  9138 |  1142K|       |    35   (3)| 00:00:01 |
|   5 |     TABLE ACCESS FULL| T2   |  9671 |  1322K|       |    34   (3)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   3 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")Cost is 201 , but for the corellated update the cost is 37.
Any idea , how should i re-write the MERGE stmt.?
Edited by: kumar on Jun 16, 2011 4:41 PM

Answer 1

First "cost" is just a number and you should not compare or tune to get the best "cost" in an execution plan.
What counts ist elapsed time => IO, CPU...
In 11g the "cost" for the merge is better (and also the CPU time is far off to be close to the truth!)
9799 rows updated
78ms elapsed
Plan hash value: 580992724
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |              |  9641 |   404K| 28964  (34)| 00:05:48 |
|   1 |  UPDATE                      | T1           |       |       |            |          |
|   2 |   NESTED LOOPS               |              |  9641 |   404K|    41   (3)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | T1           | 10866 |   318K|    40   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | T2_OBJID_IND |     1 |    13 |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| T2           |     1 |    30 |     2   (0)| 00:00:01 |
|*  6 |    INDEX UNIQUE SCAN         | T2_OBJID_IND |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   6 - access("T2"."OBJECT_ID"=:B1)
Note
   - dynamic sampling used for this statement (level=2)
commited
16ms elapsed
9799 rows merged
125ms elapsed
Plan hash value: 2009158753
| Id  | Operation            | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | MERGE STATEMENT      |      |  9641 |   320K|       |   251   (1)| 00:00:04 |
|   1 |  MERGE               | T2   |       |       |       |            |          |
|   2 |   VIEW               |      |       |       |       |            |          |
|*  3 |    HASH JOIN         |      |  9641 |  3088K|  1720K|   251   (1)| 00:00:04 |
|   4 |     TABLE ACCESS FULL| T2   |  9640 |  1600K|       |    39   (0)| 00:00:01 |
|   5 |     TABLE ACCESS FULL| T1   | 10866 |  1676K|       |    40   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
Note
   - dynamic sampling used for this statement (level=2)In your example, the elapsed time (thanks for the it!) is 78ms for the update and 125ms for the MERGE. (ORACLE 11g on and old PC) .
So "should you rewrite" the MERGE? No idea how. I assume you want to change from UPDATE to MERGE and see if it's worth?
Here it's not. But, your example just uses 2MB of data. And the difference from my point view is not MERGE or UPDATE it's NL against HASH join with that tiny amount of data.
So generally I use MERGE because of speed and because I have more control over the query. For updating 2MB of data, it's not worth it. For updating GBytes the stuff I worked on it was faster (and better to control).