Resource hungry query

Question

Friends
I had used the following query for an update statement:
UPDATE target_table tar
   SET (tar.flag1, tar.flag2, tar.flag3, tar.flag4, tar.flag5, tar.flag6,
        tar.flag7, tar.flag8, tar.flag9, tar.flag10, tar.flag11, tar.flag12,
        tar.flag13, tar.flag14, tar.flag15) =
          (SELECT src.flag1, src.flag2, src.flag3, src.flag4, src.flag5,
                  src.flag6, src.flag7, src.flag8, src.flag9, src.flag10,
                  src.flag11, src.flag12, src.flag13, src.flag14, src.flag15
             FROM src_table src
            WHERE src.date_col = tar.date_col AND src.cust_id = tar.cust_id)
WHERE EXISTS (
              SELECT 'x'
                FROM src_table src
               WHERE src.date_col = tar.date_cole
                     AND src.cust_id = tar.cust_id)But I got a message from our DBAs that this query is very resource hungry causing outage & job abends. When I did explain plan for this query, I got the following output:
UPDATE STATEMENT 
UPDATE  target_table
  PX COORDINATOR 
   PX SEND QC (RANDOM) :TQ10002
    HASH JOIN RIGHT SEMI BUFFERED
     PX RECEIVE 
      PX SEND HASH :TQ10000
       PX BLOCK ITERATOR
        INDEX FAST FULL SCAN src_table_index
     PX RECEIVE 
      PX SEND HASH :TQ10001
       PX BLOCK ITERATOR
        TABLE ACCESS FULL target_table
  TABLE ACCESS BY INDEX ROWID src_table
   INDEX RANGE SCAN src_table_indexNow if I change this query to the following:
UPDATE target_table tar
   SET (tar.flag1, tar.flag2, tar.flag3, tar.flag4, tar.flag5, tar.flag6,
        tar.flag7, tar.flag8, tar.flag9, tar.flag10, tar.flag11, tar.flag12,
        tar.flag13, tar.flag14, tar.flag15) =
          (SELECT src.flag1, src.flag2, src.flag3, src.flag4, src.flag5,
                  src.flag6, src.flag7, src.flag8, src.flag9, src.flag10,
                  src.flag11, src.flag12, src.flag13, src.flag14, src.flag15
             FROM src_table src
            WHERE src.date_col = tar.date_col AND src.cust_id = tar.cust_id)And then I do explain plan, I get the following results:
UPDATE STATEMENT 
UPDATE  target_table
  PX COORDINATOR 
   PX SEND QC (RANDOM) :TQ10000
    PX BLOCK ITERATOR
     TABLE ACCESS FULL target_table
  TABLE ACCESS BY INDEX ROWID src_table
   INDEX RANGE SCAN src_table_indexDoes that mean that using 'where exists' is not a good option?
Thanks

Answer 1

Tuning updates is very tricky - especially those with subquries!
You're performaing a full index scan on the source table but a full table scan on the target table. I could not tell the query cardinality from the postings, but since the parallel query option is being employed I'll assume a large amount of data is being processed.
Is the full table scan on the target table necessary? Would an index on the WHERE clause columns from the target table prevent this and use fewer system resources to perform the update?
You are also reading the source data twice, for each subquery. This may be necessary :( ; maybe Karthick's MERGE can avoid this. You're doing a full index scan against the source table, which is similar to a full table scan except you are only reading the keys from the index - better, but like a FTS you are readling all of the rows. Is this necessary?
WHERE EXISTS() is usually a good option, although not when a full table scan is performed. You need a way to avoid the FTS.
The parallel query option can do one of three things: help performance, hurt performance, or do nothing. It can help with the full table and full index scans you are doing so it may be helping. How much data are are you updating (bytes and rows)?
If you have the licence partitioned tables might help performance by partitioning both the source and target tables by the same partition key. In that case SQL can match smaller sets of data (the partitions) and run more efficiently. This might help if you are processing a lot of data - as you seem to be.
Good luck!
Edited by: riedelme on Jan 5, 2010 8:04 AM