Update SQL taking too much time.. hw to optimised?

Question

Hi,
here is the query; this is taking time more than 3hrs to execute.
UPDATE process_sub_step proc1
SET process_indicator = '0',
process_result = 'SC'
WHERE EXISTS (SELECT *
FROM link_trans link1
WHERE link1.tr_leu_id = proc1.tr_leu_id AND link1.TYPE = 'S')
AND process_substep_id = 'TR_02_03'
AND process_indicator = '2'
The above query is taking more than 3hrs to execuite ...!!!!!!!
Record count in the both table is more than 10L.
The column used in join condition has index.
Execution Plan is : -
UPDATE STATEMENT ALL_ROWSCost: 6                     
     5 UPDATE PROCESS_SUB_STEP
          4 NESTED LOOPS SEMI Cost: 6 Bytes: 23 Cardinality: 1           
               1 INDEX RANGE SCAN INDEX PROC_SSTL_COMB_IDX Cost: 3 Bytes: 16 Cardinality: 1      
               3 TABLE ACCESS BY INDEX ROWID TABLE EGR.LINK_TRANS_CONS Cost: 2 Bytes: 378 Cardinality: 54      
                    2 INDEX RANGE SCAN INDEX LTC_TYPE_IDX Cost: 1 Cardinality: 2
What approach should I take to improve the performance......!!!!
But same query if i write in select mode like below; it display result very quick -
select *
from
process_sub_step proc1
WHERE EXISTS (SELECT *
FROM link_trans link1
WHERE link1.tr_leu_id = proc1.tr_leu_id AND link1.TYPE = 'S')
AND process_substep_id = 'TR_02_03'
AND process_indicator = '2';
Thanks...

Answer 1

> here is the query; this is taking time more than 3hrs to execute.
Obviously. For every single row in the process_sub_step matching the filter criteria, a sub-select has to be executed on the link_trans table.
So if that filter criteria identified a million rows, a million exist SELECTs have to be executed. Even a unique index scan will take accumulate into a large overhead. In your case, it is an index range scan that is performed which is slower than a unique scan.
Btw, there is no joining done here - just a nested loop process. I.e. read a row at a time from process_sub_step using a loop, and in each loop iteration, run a SELECT against link_trans.
To optimise this specific SQL means having to do less I/O (process less rows):
a) selecting less rows from process_sub_step to delete
b) making the select filter on link_trans more restrictive
Neither is likely practical. Which means you need to approach this problem with another method and not an EXIST sub-select.