Help required regarding tunning the query mentioned

Question

HI all ,
Query mentioned below takes around 1 hr to complete . It's being used by the autoconfig kindly me in tunning it ..
QUery :
UPDATE WF_ITEM_ATTRIBUTE_VALUES WIAV SET WIAV.TEXT_VALUE = REPLACE(WIAV.TEXT_VALUE,:B1,:B2)
WHERE (WIAV.ITEM_TYPE, WIAV.NAME) = (SELECT WIA.ITEM_TYPE, WIA.NAME
FROM WF_ITEM_ATTRIBUTES WIA WHERE WIA.TYPE = 'URL'
AND WIA.ITEM_TYPE = WIAV.ITEM_TYPE
AND WIA.NAME = WIAV.NAME)
AND WIAV.TEXT_VALUE IS NOT NULL
AND INSTR(WIAV.TEXT_VALUE
, :B1) > 0
Plan :*
<pre>
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | UPDATE STATEMENT | | 453 | 14496 | 284K|
| 1 | UPDATE | WF_ITEM_ATTRIBUTE_VALUES | | | |
|* 2 | FILTER | | | | |
|* 3 | TABLE ACCESS FULL | WF_ITEM_ATTRIBUTE_VALUES | 453 | 14496 | 282K|
|* 4 | TABLE ACCESS BY INDEX ROWID| WF_ITEM_ATTRIBUTES | 1 | 33 | 2 |
|* 5 | INDEX UNIQUE SCAN | WF_ITEM_ATTRIBUTES_PK | 1 | | 1 |
Predicate Information (identified by operation id):
2 - filter(("SYS_ALIAS_2"."ITEM_TYPE","SYS_ALIAS_2"."NAME")= (SELECT /*+ */
"WIA"."ITEM_TYPE","WIA"."NAME" FROM "APPLSYS"."WF_ITEM_ATTRIBUTES" "WIA" WHERE
"WIA"."NAME"=:B1 AND "WIA"."ITEM_TYPE"=:B2 AND "WIA"."TYPE"='URL'))
3 - filter("SYS_ALIAS_2"."TEXT_VALUE" IS NOT NULL AND
INSTR("SYS_ALIAS_2"."TEXT_VALUE",:Z)>0)
4 - filter("WIA"."TYPE"='URL')
5 - access("WIA"."ITEM_TYPE"=:B1 AND "WIA"."NAME"=:B2)
</pre>
Index :*
<pre>
INDEX_NAME COLUMN_NAME
APPLSYS WF_ITEM_ATTRIBUTE_VALUES_PK 1 ITEM_TYPE
2 ITEM_KEY
3 NAME
</pre>
regds
Rahul
Edited by: RahulG on Jan 2, 2009 10:47 PM
Edited by: RahulG on Jan 2, 2009 10:48 PM

Answer 1

RahulG wrote:
HI all ,
Query mentioned below takes around 1 hr to complete . It's being used by the autoconfig kindly me in tunning it ..
A few notes:
1. Your query is using bind variables. If you're already on 9i or later (probably 9iR2 according to plan output), this statement will be subject to bind variable peeking and therefore the output of EXPLAIN PLAN is only of limited use, since the actual execution plan might be different and/or might be based on different cardinality estimates based on the actual bind values peeked at hard parse time. You can use the V$SQL_PLAN view to get the actual execution plan(s) if the statement is still cached in the shared pool, from 10g on DBMS_XPLAN.DISPLAY_CURSOR is available for that purpose.
2. The execution plan posted suggests that only 453 rows will correspond to the filter criteria (but, as mentioned in 1. is based on an unknown bind variable value when using EXPLAIN PLAN), and probably therefore the optimizer didn't unnest the subquery but runs this as recursive FILTER query potentially for each row passing the filter criteria on the driving table WF_ITEM_ATTRIBUTE_VALUES. Depending on the actual number of rows this might be inefficient, and unnesting the subquery and turning it into a join might be more appropriate. This might accomplished e.g. by providing more representative statistics to the optimizer (are the statistics up-to-date?).
Although you can't change the SQL you could try this manually by using the UNNEST hint to see if it makes any difference in the execution plan (and run time):
WHERE (WIAV.ITEM_TYPE, WIAV.NAME) = (SELECT /*+ UNNEST */ WIA.ITEM_TYPE, WIA.NAME
...3. The composite index WF_ITEM_ATTRIBUTE_VALUES_PK can only be used on the first column ITEM_TYPE for effective index access, the NAME column would have to be used as filter on all index leaf blocks that would be found using a range scan on ITEM_TYPE. This might be quite inefficient, and/or might lead to a lot of rows/blocks that need to be visited in the table using this index access path.
4. You could try to trace the execution by enabling extended SQL trace, e.g. using the (undocumented) DBMS_SUPPORT package in 9i. Running the "tkprof" utility on the generated trace file tells you the actual row source cardinalities (which can then be compared to the estimates of the optimizer) and - if the "waits" have been enabled - what your statement has waited for most.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/