9i 10g upgrade execution plan differences.

Hi all,
I am tring to find execution plan differences after I upgrade production system from 9i to 10gR2. So I have restored only needed tablespaces from my production system (9i) to a new machine and then upgraded thiat Oracle server to 10GR2. At this new server I run a script to get new execution plans of 10g. What suprises me is that query plans of 10g is different and most of new plans choose to access tables via indexes instead of full table scans stated in the original plans taken from 9i. My idea about those differences is that the optimizer takes some values for its cost formula from other system tables that I do not have in 10g server.I guess I am missing something which is not documented in upgrade book.
any idea?
Regards.

9i database is my production database and I regularly run cron jobs for missing or stale statistics on all tables. So there is no possibility to hit a problem on object level statistics. I guess that I am missing something about system level statistics which are the part of the formula (single block read time etc) for cost calculating. So I tried to use setting some statastics via dbms_stat.set_system_statistics procedure, but it did not work.
Any idea?
Regards.
ALPER ÖNEY

Similar Messages

Oracle 10g Diff in execution plan query with binding var Vs without

We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'

I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM

How can I get an execution plan for a Function in oracle 10g

Hi
I have:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I would like to know if is possible to get an EXECUTION PLAN for a FUNCTION if so, how can I get it ?
Regards

You can query the AWR data if your interesting SQL consumes enough resources.
Here is a SQL*Plus script I call MostCPUIntensiveSQLDuringInterval.sql (nice name eh?)
You'll need to know the AWR snap_id numbers for the time period of interest, then run it like this to show the top 20 SQLs during the interval:
@MostCPUIntensiveSQLDuringInterval 20The script outputs a statement to run when you are interested in looking at the plan for an interesting looking statement.
-- MostCPUintesticeSQLDuringInterval: Report on the top n SQL statements during an AWR snapshot interval.
-- The top statements are ranked by CPU usage
col inst_no format 999 heading 'RAC|Node'
col sql_id format a16 heading 'SQL_ID'
col plan_hash_value format 999999999999 heading 'Plan|hash_value'
col parsing_schema_name format a12 heading 'Parsing|Schema'
col module format a10 heading 'Module'
col pct_of_total format 999.99 heading '% Total'
col cpu_time format 999,999,999 heading 'CPU |Time (ms)'
col elapsed_time format 999,999,999 heading 'Elapsed |Time (ms)'
col lios format 9,999,999,999 heading 'Logical|Reads'
col pios format 999,999,999 heading 'Physical|Reads'
col execs format 99,999,999 heading 'Executions'
col fetches format 99,999,999 heading 'Fetches'
col sorts format 999,999 heading 'Sorts'
col parse_calls format 999,999 heading 'Parse|Calls'
col rows_processed format 999,999,999 heading 'Rows|Processed'
col iowaits format 999,999,999,999 heading 'iowaits'
set lines 195
set pages 75
PROMPT Top &&1 SQL statements during interval
SELECT diff.*
FROM (SELECT e.instance_number inst_no
 ,e.sql_id
 ,e.plan_hash_value
 ,e.parsing_schema_name
 ,substr(trim(e.module),1,10) module
 ,ratio_to_report(e.cpu_time_total - b.cpu_time_total) over (partition by 1) * 100 pct_of_total
 ,(e.cpu_time_total - b.cpu_time_total)/1000 cpu_time
 ,(e.elapsed_time_total - b.elapsed_time_total)/1000 elapsed_time
 ,e.buffer_gets_total - b.buffer_gets_total lios
 ,e.disk_reads_total - b.disk_reads_total pios
 ,e.executions_total - b.executions_total execs
 ,e.fetches_total - b.fetches_total fetches
 ,e.sorts_total - b.sorts_total sorts
 ,e.parse_calls_total - b.parse_calls_total parse_calls
 ,e.rows_processed_total - b.rows_processed_total rows_processed
-- ,e.iowait_total - b.iowait_total iowaits
-- ,e.plsexec_time_total - b.plsexec_time_total plsql_time
 FROM dba_hist_sqlstat b -- begining snap
 ,dba_hist_sqlstat e -- ending snap
 WHERE b.sql_id = e.sql_id
 AND b.dbid = e.dbid
 AND b.instance_number = e.instance_number
 and b.plan_hash_value = e.plan_hash_value
 AND b.snap_id = &LowSnapID
 AND e.snap_id = &HighSnapID
 ORDER BY e.cpu_time_total - b.cpu_time_total DESC
 ) diff
WHERE ROWNUM <=&&1
set define off
prompt to get the text of the SQL run the following:
prompt @id2sql &SQL_id
prompt .
prompt to obtain the execution plan for a session run the following:
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID'));
prompt or
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID',NULL,NULL,'ALL'));
prompt .
set define on
undefine LowSnapID
undefine HighSnapIDI guess you'll need the companion script id2sql.sql, so here it is:
set lines 190
set verify off
declare
 maxDisplayLine NUMBER := 150; --max linesize to display the SQL
 WorkingLine VARCHAR2(32000);
 CurrentLine VARCHAR2(64);
 LineBreak NUMBER;
 cursor ddl_cur is
 select sql_id
 ,sql_text
 from v$sqltext_with_newlines
 where sql_id='&1'
 order by piece
 ddlRec ddl_cur%ROWTYPE;
begin
 WorkingLine :='.';
 OPEN ddl_cur;
 LOOP
 FETCH ddl_cur INTO ddlRec;
 EXIT WHEN ddl_cur%NOTFOUND;
 IF ddl_cur%ROWCOUNT = 1 THEN
 dbms_output.put_line('.');
 dbms_output.put_line(' sql_id: '||ddlRec.sql_id);
 dbms_output.put_line('.');
 dbms_output.put_line('.');
 dbms_output.put_line('SQL Text');
 dbms_output.put_line('----------------------------------------------------------------');
 END IF;
 CurrentLine := ddlRec.sql_text;
 WHILE LENGTH(CurrentLine) > 1 LOOP
 IF INSTR(CurrentLine,CHR(10)) > 0 THEN -- if the current line has an embeded newline
 WorkingLine := WorkingLine||SUBSTR(CurrentLine,1,INSTR(CurrentLine,CHR(10))-1); -- append up to new line
 CurrentLine := SUBSTR(CurrentLine,INSTR(CurrentLine,CHR(10))+1); -- strip off up through new line character
 dbms_output.put_line(WorkingLine); -- print the WorkingLine
 WorkingLine :=''; -- reset the working line
 ELSE
 WorkingLine := WorkingLine||CurrentLine; -- append the current line
 CurrentLine :=''; -- the rest of the line has been processed
 IF LENGTH(WorkingLine) > maxDisplayLine THEN -- the line is morethan the display limit
 LineBreak := instr(substr(WorkingLine,1,maxDisplayLine),' ',-1); --find the last space before the display limit
 IF LineBreak = 0 THEN -- there is no space, so look for a comma instead
 LineBreak := substr(WorkingLine,instr(substr(WorkingLine,1,maxDisplayLine),',',-1));
 END IF;
 IF LineBreak = 0 THEN -- no space or comma, so force the line break at maxDisplayLine
 LineBreak := maxDisplayLine;
 END IF;
 dbms_output.put_line(substr(WorkingLine,1,LineBreak));
 WorkingLine:=substr(WorkingLine,LineBreak);
 END IF;
 END IF;
 END LOOP;
 --dbms_output.put(ddlRec.sql_text);
 END LOOP;
 dbms_output.put_line(WorkingLine);
 dbms_output.put_line('----------------------------------------------------------------');
 CLOSE ddl_cur;
END;
/

Very different execution plan in Oracle 10g vs. 9i

Good afternoon,
A few days ago I migrated an Oracle database 9i to 10g.
Right now I have an exact copy of the 9i instance running on another machine.
I noticed that the time for some queries take much more. For example, when comparing the execution plan for this query on the instance with Oracle 9i and Oracle 10g instance, I see that the cost in 10g is 94981765382, while in 9i is 120106.
Any idea what might be happening?
Execution Plan Oracle 9: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_9i.jpg
Execution Plan Oracle 10g: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_10g.jpg
Edited by: david_lozano_lucas on Dec 14, 2011 4:54 PM

Sorry,
Here are the details.
For Oracle 9i:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3675M| | 120K (0)| | | | | |
|* 1 | FILTER | | | | | | | | | | |
|* 2 | HASH JOIN | | 16M| 3675M| | 120K (0)| | | 03,09 | P->S | QC (RAND) |
| 3 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 (0)| | | 03,01 | S->P | HASH |
|* 4 | HASH JOIN OUTER | | 16M| 3582M| 1023M| 120K (0)| | | 03,08 | P->P | HASH |
|* 5 | HASH JOIN OUTER | | 16M| 2783M| 1041M| 102K (0)| | | 03,08 | PCWP | |
|* 6 | HASH JOIN OUTER | | 16M| 2521M| 715M| 69515 (0)| | | 03,08 | PCWP | |
| 7 | PARTITION RANGE ALL | | | | | | 1 | 14 | 03,08 | PCWP | |
| 8 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1922M| | 60988 (0)| 1 | 14 | 03,04 | P->P | HASH |
| 9 | VIEW | | 909K| 33M| | | | | 03,05 | P->P | HASH |
| 10 | SORT GROUP BY | | 909K| 19M| 62M| 1553 (0)| | | 03,05 | PCWP | |
|* 11 | HASH JOIN | | 909K| 19M| | 164 (0)| | | 03,05 | PCWP | |
|* 12 | TABLE ACCESS FULL| ORG_LOC_DM | 1131 | 6786 | | 8 (0)| | | 03,00 | S->P | HASH |
|* 13 | TABLE ACCESS FULL| INV_MOVE_SKU_LCM_DM | 909K| 13M| | 154 (0)| 60 | 60 | 03,02 | P->P | HASH |
|* 14 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 16M| 260M| | 6457 (0)| 59 | 59 | 03,06 | P->P | HASH |
| 15 | VIEW | | 1795K| 89M| | | | | 03,07 | P->P | HASH |
| 16 | SORT GROUP BY | | 1795K| 63M| 233M| 4565 (0)| | | 03,07 | PCWP | |
|* 17 | TABLE ACCESS FULL | SLS_SKU_LCM_DM | 1795K| 63M| | 599 (0)| 60 | 60 | 03,03 | P->P | HASH |
| 18 | NESTED LOOPS | | 1 | 16 | | 7 (15)| | | | | |
| 19 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 (0)| | | | | |
|* 20 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 1 (0)| | | | | |
Predicate Information (identified by operation id):
1 - filter("SYS_ALIAS_1"."DAY_IDNT"= (SELECT /*+ */ :B1 FROM "RDW91_DM"."MAINT_LOAD_DT" "Y","RDW91_DM"."TIME_DAY_DM" "X" WHERE
"X"."DAY_DT"="Y"."CURR_LOAD_DT"))
2 - access("SYS_ALIAS_1"."LOC_KEY"="G"."LOC_KEY")
4 - access("SYS_ALIAS_1"."LOC_KEY"="I"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="I"."SKU_KEY"(+))
5 - access("SYS_ALIAS_1"."LOC_KEY"="B"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="B"."SKU_KEY"(+))
6 - access("SYS_ALIAS_1"."LOC_KEY"="J"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="J"."SKU_KEY"(+))
11 - access("A"."LOC_KEY"="B"."LOC_KEY")
12 - filter("B"."LOC_TYPE_CDE"='W')
13 - filter("A"."CMTH_IDNT"=201112)
14 - filter("B"."CMTH_IDNT"(+)=201111)
17 - filter("SLS_SKU_LCM_DM"."CMTH_IDNT"=201112)
20 - access("X"."DAY_DT"="Y"."CURR_LOAD_DT")
For 10g:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3685M| | 94G| | | | | |
| 1 | FILTER | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10008 | 16M| 3685M| | 94G| | | Q1,08 | P->S | QC (RAND) |
| 4 | BUFFER SORT | | 16M| 3685M| | | | | Q1,08 | PCWP | |
| 5 | NESTED LOOPS OUTER | | 16M| 3685M| | 94G| | | Q1,08 | PCWP | |
| 6 | HASH JOIN | | 16M| 3424M| | 201K| | | Q1,08 | PCWP | |
| 7 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 8 | PX RECEIVE | | 2261 | 13566 | | 8 | | | Q1,08 | PCWP | |
| 9 | PX SEND HASH | :TQ10001 | 2261 | 13566 | | 8 | | | | S->P | HASH |
| 10 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 | | | | | |
| 11 | PX RECEIVE | | 16M| 3332M| | 201K| | | Q1,08 | PCWP | |
| 12 | PX SEND HASH | :TQ10007 | 16M| 3332M| | 201K| | | Q1,07 | P->P | HASH |
| 13 | HASH JOIN OUTER BUFFERED | | 16M| 3332M| 982M| 201K| | | Q1,07 | PCWP | |
| 14 | HASH JOIN OUTER | | 16M| 2733M| 735M| 127K| | | Q1,07 | PCWP | |
| 15 | PX RECEIVE | | 16M| 1934M| | 75785 | | | Q1,07 | PCWP | |
| 16 | PX SEND HASH | :TQ10004 | 16M| 1934M| | 75785 | | | Q1,04 | P->P | HASH |
| 17 | PX BLOCK ITERATOR | | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWC | |
| 18 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWP | |
| 19 | PX RECEIVE | | 1450K| 71M| | 3892 | | | Q1,07 | PCWP | |
| 20 | PX SEND HASH | :TQ10005 | 1450K| 71M| | 3892 | | | Q1,05 | P->P | HASH |
| 21 | VIEW | | 1450K| 71M| | 3892 | | | Q1,05 | PCWP | |
| 22 | SORT GROUP BY | | 1450K| 53M| 188M| 3892 | | | Q1,05 | PCWP | |
| 23 | PX RECEIVE | | 1450K| 53M| | 562 | | | Q1,05 | PCWP | |
| 24 | PX SEND HASH | :TQ10002 | 1450K| 53M| | 562 | | | Q1,02 | P->P | HASH |
| 25 | PX BLOCK ITERATOR | | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWC | |
| 26 | MAT_VIEW ACCESS FULL| SLS_SKU_LCM_DM | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWP | |
| 27 | PX RECEIVE | | 652K| 24M| | 1150 | | | Q1,07 | PCWP | |
| 28 | PX SEND HASH | :TQ10006 | 652K| 24M| | 1150 | | | Q1,06 | P->P | HASH |
| 29 | VIEW | | 652K| 24M| | 1150 | | | Q1,06 | PCWP | |
| 30 | SORT GROUP BY | | 652K| 14M| | 1150 | | | Q1,06 | PCWP | |
| 31 | HASH JOIN | | 652K| 14M| | 128 | | | Q1,06 | PCWP | |
| 32 | BUFFER SORT | | | | | | | | Q1,06 | PCWC | |
| 33 | PX RECEIVE | | 1131 | 6786 | | 8 | | | Q1,06 | PCWP | |
| 34 | PX SEND HASH | :TQ10000 | 1131 | 6786 | | 8 | | | | S->P | HASH |
| 35 | TABLE ACCESS FULL | ORG_LOC_DM | 1131 | 6786 | | 8 | | | | | |
| 36 | PX RECEIVE | | 652K| 10M| | 118 | | | Q1,06 | PCWP | |
| 37 | PX SEND HASH | :TQ10003 | 652K| 10M| | 118 | | | Q1,03 | P->P | HASH |
| 38 | PX BLOCK ITERATOR | | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWC | |
| 39 | MAT_VIEW ACCESS FULL| INV_MOVE_SKU_LCM_DM | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWP | |
| 40 | PARTITION RANGE SINGLE | | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 41 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 42 | NESTED LOOPS | | 1 | 16 | | 6 | | | | | |
| 43 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 | | | | | |
| 44 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 5 | | | | | |
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)

Force statement to use a given rule or execution plan

Hi!
We have a statement that in our production system takes 6-7 seconds to complete. The statement comes from our enterprise application's core code and we are not able to change the statement.
When using a RULE-hint (SELECT /*+RULE*/ 0 pay_rec...........) for this statement, the execution time is down to 500 milliseconds.
My question is: Is there any way to pin a execution plan to a given statement. I have started reading about outlines, which seems promising. However, the statement is not using bind-variables, and since this is core code in an enterprise application I cannot change that either. Is it possible to use outlines with such a statement?
Additional information:
When I remove all statistics for the involved tables, the query blows away in 500 ms.
The table tran_info_types has 61 rows and is a stable table with few updates
The table ab_tran_info has 1 717 439 records and is 62 MB in size.
The table query_result has 777 015 records and is 216 MB in size. This table is constantly updated/insterted/deleted.
The query below return 0 records as there is no hits in the table query_result.
This is the statement:
SELECT /*+ALL_ROWS*/
       0 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
FROM ab_tran_info abi,
       tran_info_types ti,
       query_result qr1,
       query_result qr2
WHERE abi.tran_num = qr1.query_result
   AND abi.type_id = qr2.query_result
   AND abi.type_id = ti.type_id
   AND ti.ins_or_tran = 0
   AND qr1.unique_id = 5334549
   AND qr2.unique_id = 5334550
UNION ALL
SELECT 1 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
FROM ab_tran_info abi,
       tran_info_types ti,
       query_result qr1,
       query_result qr2
WHERE abi.tran_num = qr1.query_result
   AND abi.type_id = qr2.query_result
   AND abi.type_id = ti.type_id
   AND ti.ins_or_tran = 0
   AND qr1.unique_id = 5334551
   AND qr2.unique_id = 5334552;Here is the explain plan with statistics:
Plan
SELECT STATEMENT HINT: ALL_ROWSCost: 900 Bytes: 82 Cardinality: 2
     15 UNION-ALL
          7 NESTED LOOPS Cost: 450 Bytes: 41 Cardinality: 1
               5 NESTED LOOPS Cost: 449 Bytes: 1,787,940 Cardinality: 59,598
                    3 NESTED LOOPS Cost: 448 Bytes: 19,514,824 Cardinality: 1,027,096
                         1 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1 Cost: 1 Bytes: 155 Cardinality: 31
                         2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1 Cost: 48 Bytes: 471,450 Cardinality: 33,675
                    4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 11 Cardinality: 1
               6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 11 Cardinality: 1
          14 NESTED LOOPS Cost: 450 Bytes: 41 Cardinality: 1
               12 NESTED LOOPS Cost: 449 Bytes: 1,787,940 Cardinality: 59,598
                    10 NESTED LOOPS Cost: 448 Bytes: 19,514,824 Cardinality: 1,027,096
                         8 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1 Cost: 1 Bytes: 155 Cardinality: 31
                         9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1 Cost: 48 Bytes: 471,450 Cardinality: 33,675
                    11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 11 Cardinality: 1
               13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 11 Cardinality: 1           Here is the execution plan when I have removed all statistics (exec DBMS_STATS.DELETE_TABLE_STATS(.........,..........); )
Plan
SELECT STATEMENT HINT: ALL_ROWSCost: 12 Bytes: 3,728 Cardinality: 16
     15 UNION-ALL
          7 NESTED LOOPS Cost: 6 Bytes: 1,864 Cardinality: 8
               5 NESTED LOOPS Cost: 6 Bytes: 45,540 Cardinality: 220
                    3 NESTED LOOPS Cost: 6 Bytes: 1,145,187 Cardinality: 6,327
                         1 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2 Bytes: 104 Cardinality: 4
                         2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1 Cost: 1 Bytes: 239,785 Cardinality: 1,547
                    4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 26 Cardinality: 1
               6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 26 Cardinality: 1
          14 NESTED LOOPS Cost: 6 Bytes: 1,864 Cardinality: 8
               12 NESTED LOOPS Cost: 6 Bytes: 45,540 Cardinality: 220
                    10 NESTED LOOPS Cost: 6 Bytes: 1,145,187 Cardinality: 6,327
                         8 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2 Bytes: 104 Cardinality: 4
                         9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1 Cost: 1 Bytes: 239,785 Cardinality: 1,547
                    11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 26 Cardinality: 1
               13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2 Bytes: 26 Cardinality: 1           Our Oracle 9.2 database is set up with ALL_ROWS.
Outlines: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/outlines.htm#13091
Cursor sharing: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3696883368520

Hi!
We are on Oracle 9iR2, running on 64-bit Linux.
We are going to upgrade to Oracle 10gR2 in some months. Oracle 11g is not an option for us as our application is not certified by our vendor to run on that version.
However, our performance problems are urgent so we are looking for a solution before we upgrade as we are not able to upgrade before we have done extensive testing which takes 2-3 months.
We have more problem sql's than the one shown in this post. I am using the above SQL as a sample as I think we can solve many other slow running SQL's if we solve this one.
Is the SQL Plan management an option on Oracle 9i and/or Oracle 10g?

Performance issue after 10G upgrade.

All,
We recently upgraded to 10G (Version:10.2.0.3.0) after which the below query causing the problem. This query is written in a pl/sql package called by a Perl program. The Perl program is running forever without completion during some attempts and sometimes it is completing very fast. We did some kind of debugging and found that everytime the program is getting stucked up at this below given query and not at all proceeding from here even if we leave it for 2 - 3 days. During a successful attempt it completes in 3 - 4 hrs. This query is taking 2 explain plan as given below and it seems one of them is best and the other one is worst. Plan 2 is best and plan 1 is worst.
Is there any suggestion in fixing this and the reason why two explain plans are picking up?....Num of records on the tables is as given below...
Can you please provide me some detailed information as i'm a beginner in these performance tuning concepts?
Your help will be much appreciated..
Tables No. of records
ult_cust_master 551925
us_state_county 3223
customer 1559
turfbuilder_group2_empcnt_tmp 44K
ult_cust_sale 2430143
ucsi_item 9714371
SELECT cust.cust_num, cust.cust_name, cust.emp_count, cust.sic1,
 cust.s1_description, NVL (cust_sale.qty, 0) qty,
 NVL (cust_sale.mot_amt, 0) mot_amt,
 NVL (cust_sale.cust_amt, 0) cust_amt, cust.min_sale_dt,
 cust.max_sale_dt, cust.cust_status
FROM (SELECT DISTINCT ucm.cust_num, f.cust_name cust_name,
 NVL (te.tet_emp_count, 0) emp_count, b.min_sale_dt,
 b.max_sale_dt, f.cust_status, sc1.sic1,
 sc1.s1_description
 FROM ult_cust_master ucm,
 us_state_county u,
 customer f,
 (SELECT div_cd, ctry_cd, cust_num,
 MIN (ucs_dt) min_sale_dt,
 MAX (ucs_dt) max_sale_dt
 FROM ult_cust_sale
 WHERE div_cd = :b4
 AND ctry_cd = :b3
 AND rec_status = 'A'
 GROUP BY div_cd, ctry_cd, cust_num) b,
 sic1 sc1,
 (SELECT tet_code, tet_vm_code, tet_type,
 tet_emp_count
 FROM turfbuilder_group2_empcnt_tmp
 WHERE tet_type = 'D') te
 WHERE f.div_cd = ucm.div_cd
 AND f.ctry_cd = ucm.ctry_cd
 AND f.cust_num = ucm.cust_num
 AND b.div_cd = ucm.div_cd
 AND b.ctry_cd = ucm.ctry_cd
 AND b.cust_num = ucm.cust_num
 AND te.tet_code(+) = ucm.cust_num
 AND te.tet_vm_code = sc1.sic1
 AND f.div_cd = :b4
 AND f.ctry_cd = :b3
 AND ucm.ucm_stcnty_fips_cd = u.usc_st_cnty_cd
 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI')
 AND ucm.rec_status = 'A'
 AND u.rec_status = 'A'
 AND sc1.rec_status = 'A'
 AND f.cust_imp21_dealer_fg = 'Y'
 AND NVL (f.cust_test_dealer_fg, 'N') <> 'Y') cust,
 (SELECT c.cust_num cust_num, sc2.sic1,
 SUM (DECODE (a.ucsii_unit_fg,
 'Y', a.ucsii_qty * 1,
 a.ucsii_qty * 0
 ) qty,
 SUM (a.ucsii_qty * a.ucsii_mot_unit_pr) mot_amt,
 SUM (a.ucsii_qty * a.ucsii_ult_unit_pr) cust_amt
 FROM ucsi_item a,
 ult_cust_sale b,
 ult_cust_master c,
 sic2 sc2,
 us_state_county u
 WHERE a.div_cd = b.div_cd
 AND a.ctry_cd = b.ctry_cd
 AND a.cust_num = b.cust_num
 AND a.ucm_mailbox_num = b.ucm_mailbox_num
 AND a.ucm_seq = b.ucm_seq
 AND a.ucs_seq = b.ucs_seq
 AND c.div_cd = b.div_cd
 AND c.ctry_cd = b.ctry_cd
 AND c.cust_num = b.cust_num
 AND c.ucm_mailbox_num = b.ucm_mailbox_num
 AND c.ucm_seq = b.ucm_seq
 AND SUBSTR (c.ucm_sic_cd, 1, 2) = sc2.sic2
 AND c.ucm_stcnty_fips_cd = u.usc_st_cnty_cd
 AND a.ucsii_in_apmr_fg = 'Y'
 AND a.ucsii_audit_data_cd = 'G'
 AND a.ucsii_contract_id IN
 ('BRANDED',
 'CTR',
 'WARIS',
 'RADIUS',
 'BRNDCONV',
 'BRNDTRNK'
 AND ( (a.ucsii_unit_fg = 'Y')
 OR (a.ucsii_unit_fg = 'N' AND a.ucsii_item_num LIKE '%.%')
 AND c.div_cd = :b4
 AND c.ctry_cd = :b3
 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI')
 AND u.rec_status = 'A'
 AND c.rec_status = 'A'
 AND a.rec_status = 'A'
 AND sc2.rec_status = 'A'
 AND b.ua_cd = 'ENDCUST'
 AND b.rec_status = 'A'
 AND b.ucs_dt BETWEEN TO_DATE (:b2, 'dd mon yyyy')
 AND TO_DATE (:b1, 'dd mon yyyy')
 GROUP BY c.cust_num, sc2.sic1) cust_sale
WHERE cust.cust_num = cust_sale.cust_num(+) AND cust.sic1 = cust_sale.sic1(+)------------------------------------------------------------------------------------------------------------------------
{color:blue}
Execution Plan – 1:
Plan hash value: 2237978112
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 643 (100)| |
|* 1 | HASH JOIN OUTER | | 1 | 175 | 643 (2)| 00:00:08 |
| 2 | VIEW | | 1 | 118 | 74 (5)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 310 | 74 (5)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 310 | 74 (5)| 00:00:01 |
|* 5 | FILTER | | | | | |
| 6 | NESTED LOOPS | | 1 | 310 | 73 (3)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 278 | 70 (2)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 187 | 69 (2)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 148 | 68 (2)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 100 | 52 (2)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 1 | 52 | 51 (2)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| SIC1 | 1 | 48 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | SYS_C001278 | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 517 | 24816 | 16 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XIF9ULT_CUST_MASTER | 505 | | 1 (0)| 00:00:01 |
|* 16 | TABLE ACCESS BY INDEX ROWID | US_STATE_COUNTY | 1 | 39 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | XPKSTATE_COUNTY | 1 | | 1 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 91 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | XPKCUSTOMER | 1 | | 1 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 13514 | 422K| 2 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 57 | 569 (2)| 00:00:07 |
| 22 | HASH GROUP BY | | 1 | 209 | 569 (2)| 00:00:07 |
|* 23 | FILTER | | | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | 1 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 209 | 568 (1)| 00:00:07 |
| 26 | NESTED LOOPS | | 1 | 135 | 567 (1)| 00:00:07 |
|* 27 | HASH JOIN | | 1491 | 110K| 118 (3)| 00:00:02 |
|* 28 | TABLE ACCESS FULL | SIC2 | 83 | 996 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 186 | 9858 | 13 (0)| 00:00:01 |
| 30 | NESTED LOOPS | | 1500 | 96000 | 115 (2)| 00:00:02 |
|* 31 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | 9 (12)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | TEST | 186 | | 1 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1 | 59 | 1 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1 | | 1 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
5 - filter((:B3=:B3 AND :B4=:B4))
11 - filter("TET_TYPE"='D')
12 - filter("SC1"."REC_STATUS"='A')
13 - access("TET_VM_CODE"="SC1"."SIC1")
14 - filter("UCM"."REC_STATUS"='A')
15 - access("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND "TET_CODE"="UCM"."CUST_NUM")
filter(("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3))
16 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
17 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD")
18 - filter(("F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
19 - access("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3 AND "F"."CUST_NUM"="UCM"."CUST_NUM")
filter(("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3))
20 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "CUST_NUM"="UCM"."CUST_NUM" AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
23 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
24 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G'
AND "A"."REC_STATUS"='A'))
27 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
28 - filter("SC2"."REC_STATUS"='A')
31 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
32 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
33 - filter(("B"."UA_CD"='ENDCUST' AND "C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM"))
34 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_SEQ"="B"."UCM_SEQ" AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND
"B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter("B"."REC_STATUS"='A')
35 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
{color}
{color:green}
Execution Plan – 2:
Plan hash value: 2023039777
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | | 3341 (100)| |
|* 1 | HASH JOIN RIGHT OUTER | | 12967 | 2216K| | 3341 (5)| 00:00:41 |
| 2 | VIEW | | 1 | 57 | | 607 (6)| 00:00:08 |
| 3 | HASH GROUP BY | | 1 | 209 | | 607 (6)| 00:00:08 |
|* 4 | FILTER | | | | | | |
|* 5 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | | 1 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 209 | | 606 (6)| 00:00:08 |
| 7 | NESTED LOOPS | | 1 | 135 | | 605 (6)| 00:00:08 |
|* 8 | HASH JOIN | | 1 | 123 | | 604 (6)| 00:00:08 |
|* 9 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_SALE | 1214 | 71626 | | 455 (7)| 00:00:06 |
|* 10 | INDEX SKIP SCAN | XIE1ULT_CUST_SALE | 1 | | | 455 (7)| 00:00:06 |
| 11 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_MASTER | 245 | 12985 | | 17 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1971 | 123K| | 148 (2)| 00:00:02 |
|* 13 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | | 9 (12)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | SIC2 | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKSIC2 | 1 | | | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | | 1 (0)| 00:00:01 |
| 18 | VIEW | | 12967 | 1494K| | 2732 (5)| 00:00:33 |
| 19 | HASH UNIQUE | | 12967 | 3254K| 6936K| 2732 (5)| 00:00:33 |
|* 20 | HASH JOIN | | 12967 | 3254K| | 1998 (6)| 00:00:24 |
| 21 | VIEW | | 410 | 16400 | | 1781 (5)| 00:00:22 |
| 22 | HASH GROUP BY | | 410 | 13120 | | 1781 (5)| 00:00:22 |
|* 23 | FILTER | | | | | | |
|* 24 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1963K| 59M| | 1781 (5)| 00:00:22 |
|* 25 | HASH JOIN | | 4792 | 1015K| | 215 (7)| 00:00:03 |
|* 26 | TABLE ACCESS FULL | SIC1 | 11 | 528 | | 2 (0)| 00:00:01 |
|* 27 | HASH JOIN | | 4792 | 790K| | 212 (6)| 00:00:03 |
|* 28 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1003 | 79237 | | 4 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | XIF317CUSTOMER | 1371 | | | 1 (0)| 00:00:01 |
|* 30 | HASH JOIN | | 4794 | 421K| | 207 (6)| 00:00:03 |
| 31 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245 | 8820 | | 17 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 1971 | 136K| | 148 (2)| 00:00:02 |
|* 33 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 280 | | 9 (12)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 35 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 8914 | 165K| | 58 (14)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
4 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
5 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G' AND
"A"."REC_STATUS"='A'))
8 - access("C"."DIV_CD"="B"."DIV_CD" AND "C"."CTRY_CD"="B"."CTRY_CD" AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "C"."UCM_SEQ"="B"."UCM_SEQ")
9 - filter("B"."UA_CD"='ENDCUST')
10 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND
"B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter(("B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd
mon yyyy')))
13 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
14 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
15 - filter("SC2"."REC_STATUS"='A')
16 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
17 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
20 - access("B"."DIV_CD"="UCM"."DIV_CD" AND "B"."CTRY_CD"="UCM"."CTRY_CD" AND "B"."CUST_NUM"="UCM"."CUST_NUM")
23 - filter((:B3=:B3 AND :B4=:B4))
24 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
25 - access("TET_VM_CODE"="SC1"."SIC1")
26 - filter("SC1"."REC_STATUS"='A')
27 - access("F"."DIV_CD"="UCM"."DIV_CD" AND "F"."CTRY_CD"="UCM"."CTRY_CD" AND "F"."CUST_NUM"="UCM"."CUST_NUM")
28 - filter(("F"."DIV_CD"=:B4 AND "F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
29 - access("F"."CTRY_CD"=:B3)
30 - access("TET_CODE"="UCM"."CUST_NUM")
33 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
34 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND
"UCM"."REC_STATUS"='A')
35 - filter("TET_TYPE"='D')
{color}
Edited by: user3030284 on Oct 28, 2008 9:42 PM


{size:12}
All,


We recently upgraded to 10G (Version:10.2.0.3.0) after which the below query causing the problem. This query is written in a pl/sql package called by a Perl program. The Perl program is running forever without completion during some attempts and sometimes it is completing very fast. We did some kind of debugging and found that everytime the program is getting stucked up at this below given query and not at all proceeding from here even if we leave it for 2 - 3 days. During a successful attempt it completes in 3 - 4 hrs. This query is taking 2 explain plan as given below and it seems one of them is best and the other one is worst. Plan 2 is best and plan 1 is worst.
Is there any suggestion in fixing this and the reason why two explain plans are picking up?....Num of records on the tables is as given below...
Can you please provide me some detailed information as i'm a beginner in these performance tuning concepts?
Your help will be much appreciated..


Tables No. of records
ult_cust_master 551925
us_state_county 3223
customer 1559
turfbuilder_group2_empcnt_tmp 44K
ult_cust_sale 2430143
ucsi_item 9714371
{size}


 /* Formatted on 2007/09/30 20:37 (Formatter Plus v4.8.5) */ SELECT cust.cust_num, cust.cust_name, cust.emp_count, cust.sic1, cust.s1_description, NVL (cust_sale.qty, 0) qty, NVL (cust_sale.mot_amt, 0) mot_amt, NVL (cust_sale.cust_amt, 0) cust_amt, cust.min_sale_dt, cust.max_sale_dt, cust.cust_status FROM (SELECT DISTINCT ucm.cust_num, f.cust_name cust_name, NVL (te.tet_emp_count, 0) emp_count, b.min_sale_dt, b.max_sale_dt, f.cust_status, sc1.sic1, sc1.s1_description FROM ult_cust_master ucm, us_state_county u, customer f, (SELECT div_cd, ctry_cd, cust_num, MIN (ucs_dt) min_sale_dt, MAX (ucs_dt) max_sale_dt FROM ult_cust_sale WHERE div_cd = :b4 AND ctry_cd = :b3 AND rec_status = 'A' GROUP BY div_cd, ctry_cd, cust_num) b, sic1 sc1, (SELECT tet_code, tet_vm_code, tet_type, tet_emp_count FROM turfbuilder_group2_empcnt_tmp WHERE tet_type = 'D') te WHERE f.div_cd = ucm.div_cd AND f.ctry_cd = ucm.ctry_cd AND f.cust_num = ucm.cust_num AND b.div_cd = ucm.div_cd AND b.ctry_cd = ucm.ctry_cd AND b.cust_num = ucm.cust_num AND te.tet_code(+) = ucm.cust_num AND te.tet_vm_code = sc1.sic1 AND f.div_cd = :b4 AND f.ctry_cd = :b3 AND ucm.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND ucm.rec_status = 'A' AND u.rec_status = 'A' AND sc1.rec_status = 'A' AND f.cust_imp21_dealer_fg = 'Y' AND NVL (f.cust_test_dealer_fg, 'N') <> 'Y') cust, (SELECT c.cust_num cust_num, sc2.sic1, SUM (DECODE (a.ucsii_unit_fg, 'Y', a.ucsii_qty * 1, a.ucsii_qty * 0 ) ) qty, SUM (a.ucsii_qty * a.ucsii_mot_unit_pr) mot_amt, SUM (a.ucsii_qty * a.ucsii_ult_unit_pr) cust_amt FROM ucsi_item a, ult_cust_sale b, ult_cust_master c, sic2 sc2, us_state_county u WHERE a.div_cd = b.div_cd AND a.ctry_cd = b.ctry_cd AND a.cust_num = b.cust_num AND a.ucm_mailbox_num = b.ucm_mailbox_num AND a.ucm_seq = b.ucm_seq AND a.ucs_seq = b.ucs_seq AND c.div_cd = b.div_cd AND c.ctry_cd = b.ctry_cd AND c.cust_num = b.cust_num AND c.ucm_mailbox_num = b.ucm_mailbox_num AND c.ucm_seq = b.ucm_seq AND SUBSTR (c.ucm_sic_cd, 1, 2) = sc2.sic2 AND c.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND a.ucsii_in_apmr_fg = 'Y' AND a.ucsii_audit_data_cd = 'G' AND a.ucsii_contract_id IN ('BRANDED', 'CTR', 'WARIS', 'RADIUS', 'BRNDCONV', 'BRNDTRNK' ) AND ( (a.ucsii_unit_fg = 'Y') OR (a.ucsii_unit_fg = 'N' AND a.ucsii_item_num LIKE '%.%') ) AND c.div_cd = :b4 AND c.ctry_cd = :b3 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND u.rec_status = 'A' AND c.rec_status = 'A' AND a.rec_status = 'A' AND sc2.rec_status = 'A' AND b.ua_cd = 'ENDCUST' AND b.rec_status = 'A' AND b.ucs_dt BETWEEN TO_DATE (:b2, 'dd mon yyyy') AND TO_DATE (:b1, 'dd mon yyyy') GROUP BY c.cust_num, sc2.sic1) cust_sale WHERE cust.cust_num = cust_sale.cust_num(+) AND cust.sic1 = cust_sale.sic1(+) 


{color:green}


Explain Plan -- 1:


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 643 (100)| |
|* 1 | HASH JOIN OUTER | | 1 | 175 | 643 (2)| 00:00:08 |
| 2 | VIEW | | 1 | 118 | 74 (5)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 310 | 74 (5)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 310 | 74 (5)| 00:00:01 |
|* 5 | FILTER | | | | | |
| 6 | NESTED LOOPS | | 1 | 310 | 73 (3)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 278 | 70 (2)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 187 | 69 (2)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 148 | 68 (2)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 100 | 52 (2)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 1 | 52 | 51 (2)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID| SIC1 | 1 | 48 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | SYS_C001278 | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 517 | 24816 | 16 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | XIF9ULT_CUST_MASTER | 505 | | 1 (0)| 00:00:01 |
|* 16 | TABLE ACCESS BY INDEX ROWID | US_STATE_COUNTY | 1 | 39 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | XPKSTATE_COUNTY | 1 | | 1 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 91 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | XPKCUSTOMER | 1 | | 1 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 13514 | 422K| 2 (0)| 00:00:01 |
| 21 | VIEW | | 1 | 57 | 569 (2)| 00:00:07 |
| 22 | HASH GROUP BY | | 1 | 209 | 569 (2)| 00:00:07 |
|* 23 | FILTER | | | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | 1 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 209 | 568 (1)| 00:00:07 |
| 26 | NESTED LOOPS | | 1 | 135 | 567 (1)| 00:00:07 |
|* 27 | HASH JOIN | | 1491 | 110K| 118 (3)| 00:00:02 |
|* 28 | TABLE ACCESS FULL | SIC2 | 83 | 996 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 186 | 9858 | 13 (0)| 00:00:01 |
| 30 | NESTED LOOPS | | 1500 | 96000 | 115 (2)| 00:00:02 |
|* 31 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | 9 (12)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | TEST | 186 | | 1 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1 | 59 | 1 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1 | | 1 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
5 - filter((:B3=:B3 AND :B4=:B4))
11 - filter("TET_TYPE"='D')
12 - filter("SC1"."REC_STATUS"='A')
13 - access("TET_VM_CODE"="SC1"."SIC1")
14 - filter("UCM"."REC_STATUS"='A')
15 - access("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND "TET_CODE"="UCM"."CUST_NUM")
filter(("UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3))
16 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
17 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD")
18 - filter(("F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
19 - access("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3 AND "F"."CUST_NUM"="UCM"."CUST_NUM")
filter(("F"."DIV_CD"=:B4 AND "F"."CTRY_CD"=:B3))
20 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "CUST_NUM"="UCM"."CUST_NUM" AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
23 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
24 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G'
AND "A"."REC_STATUS"='A'))
27 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
28 - filter("SC2"."REC_STATUS"='A')
31 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND
"U"."REC_STATUS"='A'))
32 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
33 - filter(("B"."UA_CD"='ENDCUST' AND "C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM"))
34 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_SEQ"="B"."UCM_SEQ" AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND
"B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter("B"."REC_STATUS"='A')
35 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")


{color}


{color:blue}


Explain Plan -- 2:


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | | 3341 (100)| |
|* 1 | HASH JOIN RIGHT OUTER | | 12967 | 2216K| | 3341 (5)| 00:00:41 |
| 2 | VIEW | | 1 | 57 | | 607 (6)| 00:00:08 |
| 3 | HASH GROUP BY | | 1 | 209 | | 607 (6)| 00:00:08 |
|* 4 | FILTER | | | | | | |
|* 5 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1 | 74 | | 1 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 209 | | 606 (6)| 00:00:08 |
| 7 | NESTED LOOPS | | 1 | 135 | | 605 (6)| 00:00:08 |
|* 8 | HASH JOIN | | 1 | 123 | | 604 (6)| 00:00:08 |
|* 9 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_SALE | 1214 | 71626 | | 455 (7)| 00:00:06 |
|* 10 | INDEX SKIP SCAN | XIE1ULT_CUST_SALE | 1 | | | 455 (7)| 00:00:06 |
| 11 | TABLE ACCESS BY INDEX ROWID| ULT_CUST_MASTER | 245 | 12985 | | 17 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1971 | 123K| | 148 (2)| 00:00:02 |
|* 13 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 88 | | 9 (12)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | SIC2 | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKSIC2 | 1 | | | 1 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | | 1 (0)| 00:00:01 |
| 18 | VIEW | | 12967 | 1494K| | 2732 (5)| 00:00:33 |
| 19 | HASH UNIQUE | | 12967 | 3254K| 6936K| 2732 (5)| 00:00:33 |
|* 20 | HASH JOIN | | 12967 | 3254K| | 1998 (6)| 00:00:24 |
| 21 | VIEW | | 410 | 16400 | | 1781 (5)| 00:00:22 |
| 22 | HASH GROUP BY | | 410 | 13120 | | 1781 (5)| 00:00:22 |
|* 23 | FILTER | | | | | | |
|* 24 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1963K| 59M| | 1781 (5)| 00:00:22 |
|* 25 | HASH JOIN | | 4792 | 1015K| | 215 (7)| 00:00:03 |
|* 26 | TABLE ACCESS FULL | SIC1 | 11 | 528 | | 2 (0)| 00:00:01 |
|* 27 | HASH JOIN | | 4792 | 790K| | 212 (6)| 00:00:03 |
|* 28 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1003 | 79237 | | 4 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | XIF317CUSTOMER | 1371 | | | 1 (0)| 00:00:01 |
|* 30 | HASH JOIN | | 4794 | 421K| | 207 (6)| 00:00:03 |
| 31 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245 | 8820 | | 17 (0)| 00:00:01 |
| 32 | NESTED LOOPS | | 1971 | 136K| | 148 (2)| 00:00:02 |
|* 33 | TABLE ACCESS FULL | US_STATE_COUNTY | 8 | 280 | | 9 (12)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | TEST | 245 | | | 1 (0)| 00:00:01 |
|* 35 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 8914 | 165K| | 58 (14)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("CUST"."CUST_NUM"="CUST_SALE"."CUST_NUM" AND "CUST"."SIC1"="CUST_SALE"."SIC1")
4 - filter(TO_DATE(:B2,'dd mon yyyy')<=TO_DATE(:B1,'dd mon yyyy'))
5 - filter((("A"."UCSII_UNIT_FG"='Y' OR ("A"."UCSII_ITEM_NUM" LIKE '%.%' AND "A"."UCSII_UNIT_FG"='N')) AND
"A"."UCSII_IN_APMR_FG"='Y' AND INTERNAL_FUNCTION("A"."UCSII_CONTRACT_ID") AND "A"."UCSII_AUDIT_DATA_CD"='G' AND
"A"."REC_STATUS"='A'))
8 - access("C"."DIV_CD"="B"."DIV_CD" AND "C"."CTRY_CD"="B"."CTRY_CD" AND "C"."CUST_NUM"="B"."CUST_NUM" AND
"C"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "C"."UCM_SEQ"="B"."UCM_SEQ")
9 - filter("B"."UA_CD"='ENDCUST')
10 - access("B"."DIV_CD"=:B4 AND "B"."CTRY_CD"=:B3 AND "B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND
"B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd mon yyyy'))
filter(("B"."UCS_DT">=TO_DATE(:B2,'dd mon yyyy') AND "B"."REC_STATUS"='A' AND "B"."UCS_DT"<=TO_DATE(:B1,'dd
mon yyyy')))
13 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
14 - access("C"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "C"."DIV_CD"=:B4 AND "C"."CTRY_CD"=:B3 AND
"C"."REC_STATUS"='A')
15 - filter("SC2"."REC_STATUS"='A')
16 - access("SC2"."SIC2"=SUBSTR("C"."UCM_SIC_CD",1,2))
17 - access("A"."DIV_CD"=:B4 AND "A"."CTRY_CD"=:B3 AND "A"."CUST_NUM"="B"."CUST_NUM" AND
"A"."UCM_MAILBOX_NUM"="B"."UCM_MAILBOX_NUM" AND "A"."UCM_SEQ"="B"."UCM_SEQ" AND "A"."UCS_SEQ"="B"."UCS_SEQ")
20 - access("B"."DIV_CD"="UCM"."DIV_CD" AND "B"."CTRY_CD"="UCM"."CTRY_CD" AND "B"."CUST_NUM"="UCM"."CUST_NUM")
23 - filter((:B3=:B3 AND :B4=:B4))
24 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A')
filter(("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A'))
25 - access("TET_VM_CODE"="SC1"."SIC1")
26 - filter("SC1"."REC_STATUS"='A')
27 - access("F"."DIV_CD"="UCM"."DIV_CD" AND "F"."CTRY_CD"="UCM"."CTRY_CD" AND "F"."CUST_NUM"="UCM"."CUST_NUM")
28 - filter(("F"."DIV_CD"=:B4 AND "F"."CUST_IMP21_DEALER_FG"='Y' AND NVL("F"."CUST_TEST_DEALER_FG",'N')<>'Y'))
29 - access("F"."CTRY_CD"=:B3)
30 - access("TET_CODE"="UCM"."CUST_NUM")
33 - filter((UPPER("U"."USC_STATE_ABBREV")<>'PR' AND UPPER("U"."USC_STATE_ABBREV")<>'VI' AND "U"."REC_STATUS"='A'))
34 - access("UCM"."UCM_STCNTY_FIPS_CD"="U"."USC_ST_CNTY_CD" AND "UCM"."DIV_CD"=:B4 AND "UCM"."CTRY_CD"=:B3 AND
"UCM"."REC_STATUS"='A')
35 - filter("TET_TYPE"='D')


{color}

Performance of subselect and innerjoins after 10g upgrade

Short Text
Long runtime exist clause in subselect
Long Text
We have started experience very long runtimes after installing Oracle
10g with the following program:
RVV50R10C
There are many different variants stored for this program. After the
Oracle upgrade the variant named: HEP_DRSHP_COMM will not run to
completion. We have observed the following about the job that makes it
unique from the other variants. It is using the Department field in
the selection. When the job started the following SQL statement can be
identified by using SM51 and displaying the jobs details:
SELECT
FROM
"VEPVG" T_00
WHERE
T_00 . "MANDT" = :A0 AND T_00 . "VSTEL" IN
( :A1 , :A2 , :A3 , :A4 , :A5 ) AND T_00 . "LEDAT"
BETWEEN :A6 AND :A7 AND NOT ( T_00 . "LIFSP" BETWEEN :A8 AND :A9 )
AND EXISTS ( SELECT * FROM
"VBKD" T_100 WHERE T_100 . "MANDT" = :A10 AND T_100 . "VBELN" =
T_00 . "VBELN" AND T_100 .
"ABTNR" = :A11 )
The subselect to VBKD is the source of the problem. If an execution
plan is ran against the statement the Oracle explain will show the
following:
Execution Plan
SELECT STATEMENT ( Estimated Costs = 2 , Estimated #Rows = 1 )
7 FILTER
6 NESTED LOOPS SEMI
( Estim. Costs = 2 , Estim. #Rows = 1 )
Estim. CPU-Costs = 14,773 Estim. IO-Costs = 2
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID VEPVG
( Estim. Costs = 1 , Estim. #Rows = 1 )
Estim. CPU-Costs = 11,460 Estim. IO-Costs = 1
1 INDEX RANGE SCAN VEPVG~0
( Estim. Costs = 1 , Estim. #Rows = 2 )
Search Columns: 3
Estim. CPU-Costs = 8,351 Estim. IO-Costs = 1
5 TABLE ACCESS BY INDEX ROWID VBKD
Estim. CPU-Costs = 3,313 Estim. IO-Costs = 0
4 INDEX RANGE SCAN VBKD~LOC
Search Columns: 1
Estim. CPU-Costs = 1,504 Estim. IO-Costs = 0
The use of the VBKD~LOC index is causing the poor performance. You can
review our jobs HEP_1101_DAILY, EP_1101_HOMED, HEP_1114_DAILY,
HEP_3114_DAILY which previous to the upgrade their runtime were all
less than 10 mins. These jobs fail to complete.
I would like to also ask about OSS NOTE 841280
This note does not apply to 10g but its description seems very
relevant. Would you recommend setting the parameter alwayssemi_join
= off in this release of Oracle. Is there some other setting? The
execution plan should reflect that VBKD~0 is selected.

Are the clients using JInitiator or their local JRE?

Migrate execution plan

I have 2 Oracle instances with nearly identical sets of objects -- one for development and one for production use. I am about to deploy some upgraded functionality from development to production and I have spent hours optimizing application SQL statements with Enterprise Manager's SQL Tuner and it has found several optimized execution plans that make a significant difference in performance. Is there a way to migrate these optimized execution plans from development to production when I deploy the rest of my application upgrade or will I need to again spend time running things through the SQL Tuner on production?
Thanks for your help.

I think you can export and import the histogram statistics of that schema or tables (DBMS_STATS.EXPORT_SCHEMA_STATS or DBMS_STATS.EXPORT_TABLE_STATS) from your development to production.
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#sthref7903
Optimizing SQL Statements
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/part4.htm
Exporting and Importing Statistics
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41854

Effect of RLS policy (VPD) on execution plan of a query

Hi
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Regards,
Amardeep Sidhu

Amardeep Sidhu wrote:
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

How to get rid of 'BITMAP CONVERSION' in Execution Plan.

Hi I am using oracle 10g.
I am getting the path of execution of the query something as below. I have posted some part of it not all.
I want to get rid of this 'BITMAP CONVERSION' Section of the path, is there any hint for the same in oracle?
| 56 |      TABLE ACCESS BY INDEX ROWID      | XMVL_ONLINE_VIEW_BASE         | 7274 | 1662K|       | 3320 (21)| 00:00:17 |
| 57 |       BITMAP CONVERSION TO ROWIDS     |                               |       |       |       |            |          |
| 58 |        BITMAP AND                     |                               |       |       |       |            |          |
| 59 |         BITMAP OR                     |                               |       |       |       |            |          |
| 60 |          BITMAP CONVERSION FROM ROWIDS|                               |       |       |       |            |          |
| 61 |           SORT ORDER BY               |                               |       |       |       |            |          |
| 62 |            INDEX RANGE SCAN           | IDX_XMVLONLINEVIEW_BCOMPANYPK |       |       |       |     4 (50)| 00:00:01 |
| 63 |          BITMAP CONVERSION FROM ROWIDS|                               |       |       |       |            |          |
| 64 |           SORT ORDER BY               |                               |       |       | 3608K|            |          |
| 65 |            INDEX RANGE SCAN           | IDX_XMVLONLINEVIEW_BCOMPANYPK |       |       |       |     4 (50)| 00:00:01 |
| 66 |         BITMAP CONVERSION FROM ROWIDS |                               |       |       |       |            |          |
| 67 |          SORT ORDER BY                |                               |       |       | 3288K|            |          |
| 68 |           INDEX RANGE SCAN            | IDX_XMVLVIEW_UPPERVENDORNAME |       |       |       |    59 (45)| 00:00:01 |

Mark,
Please check below link :
http://www.orafaq.com/node/1420
In the above link there is a query :
EXPLAIN PLAN FOR
SELECT *
FROM ef_actl_expns
WHERE lbcr_sk IN (
SELECT lbcr_sk
FROM ed_lbr_cst_role
WHERE lbr_actv_typ_cd = 'A'
If it is ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS' then there is "BITMAP CONVERSION TO ROWIDS" in the execution plan, but if it is ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' then there is no "BITMAP CONVERSION" in the plan. So, can we suggest to OP to go for ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' ?
But yes, as you stated that what is 4 digit of Oracle version is also mising in the above link. I am just asking that is it good to go with ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' please ? Because generally in the execution plan "BITMAP CONVERSION" happens for star transformation so, I think below link may also be interest to OP :
http://docs.oracle.com/cd/B19306_01/server.102/b14223/schemas.htm
Regards
Girish Sharma

Upgrade from Planning 9.2.0.2 to 9.3.1 or 11.1

We are currently on Sytem 9.2.0.2 and are looking to upgrade to 9.3.1 or 11. Does anybody know where I can go to get some information on the difference between 9.3 & 11. Any specific things I should look out for with regards to an upgrade to either version. I wouldn't look to do an upgrade until early 2009 and by then there would probably be a 11.1.2. Any info would be much appreciated. Regards John

Hi,
You can find all the Version 11 documentation at :- http://download.oracle.com/docs/cd/E12825_01/index.htm
There are a number documents outlining the new features or you could have a look at the blog I wrote on looking at the new features of Planning V11 :- http://john-goodwin.blogspot.com/2008/07/planning-11-new-features.html
In theory you can upgrade from Planning 9.2 to 9.3.1 or 11, I must admit when it comes to planning I prefer to do a fresh install of planning and then migrate the planning apps.
Cheers
John
http://john-goodwin.blogspot.com/

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Multiple Executions Plans for the same SQL statement

Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.
Below is the awrsqrpt's output for your reference.
WORKLOAD REPOSITORY SQL Report
Snapshot Period Summary
DB Name         DB Id    Instance     Inst Num Release     RAC Host
TESTDB          2157605839 TESTDB1               1 10.2.0.3.0 YES testhost1
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:     32541 11-Oct-08 21:00:13       248     141.1
End Snap:     32542 11-Oct-08 21:15:06       245     143.4
   Elapsed:               14.88 (mins)
   DB Time:               12.18 (mins)
SQL Summary                            DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
                Elapsed
   SQL Id      Time (ms)
51szt7b736bmg     25,131
Module: SQL*Plus
UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL,
0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE
TEST_BATCH_DT = (:B1 )
SQL ID: 51szt7b736bmg                  DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> 1st Capture and Last Capture Snap IDs
   refer to Snapshot IDs witin the snapshot range
-> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC...
    Plan Hash           Total Elapsed                 1st Capture   Last Capture
#   Value                    Time(ms)    Executions       Snap ID        Snap ID
1   2960830398                 25,131             1         32542          32542
2   3834848140                      0             0         32542          32542
Plan 1(PHV: 2960830398)
Plan Statistics                        DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                            25,131       25,130.7     3.4
CPU Time (ms)                                23,270       23,270.2     3.9
Executions                                        1            N/A     N/A
Buffer Gets                               2,626,166    2,626,166.0    14.6
Disk Reads                                      305          305.0     0.3
Parse Calls                                       1            1.0     0.0
Rows                                        371,735      371,735.0     N/A
User I/O Wait Time (ms)                         564            N/A     N/A
Cluster Wait Time (ms)                            0            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        0            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     2            N/A     N/A
Sharable Mem(KB)                                 26            N/A     N/A
Execution Plan
| Id | Operation                    | Name            | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |                 |       |       | 1110 (100)|          |
|   1 | UPDATE                      | TEST            |       |       |            |          |
|   2 |   TABLE ACCESS FULL          | TEST            |   116K| 2740K| 1110   (2)| 00:00:14 |
|   3 |   TABLE ACCESS BY INDEX ROWID| ACCT            |     1 |    26 |     5   (0)| 00:00:01 |
|   4 |    INDEX RANGE SCAN          | ACCT_DT_ACC_IDX |     1 |       |     4   (0)| 00:00:01 |
Plan 2(PHV: 3834848140)
Plan Statistics                        DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                                 0            N/A     0.0
CPU Time (ms)                                     0            N/A     0.0
Executions                                        0            N/A     N/A
Buffer Gets                                       0            N/A     0.0
Disk Reads                                        0            N/A     0.0
Parse Calls                                       0            N/A     0.0
Rows                                              0            N/A     N/A
User I/O Wait Time (ms)                           0            N/A     N/A
Cluster Wait Time (ms)                            0            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        0            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     2            N/A     N/A
Sharable Mem(KB)                                 26            N/A     N/A
Execution Plan
| Id | Operation                    | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |              |       |       |     2 (100)|          |
|   1 | UPDATE                      | TEST         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| TEST         |     1 |    28 |     2   (0)| 00:00:01 |
|   3 |    INDEX RANGE SCAN          | TEST_DT_IND |     1 |       |     1   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| ACCT         |     1 |    26 |     4   (0)| 00:00:01 |
|   5 |    INDEX RANGE SCAN          | INDX_ACCT_DT |     1 |       |     3   (0)| 00:00:01 |
Full SQL Text
SQL ID       SQL Text
51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) +
              NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB
             RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )Your input is highly appreciated.
Thanks for taking your time in answering my question.
Regards

Oracle Lover3 wrote:
Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.If you're using bind variables and you've histograms on your columns which can be created by default in 10g due to the "SIZE AUTO" default "method_opt" parameter of DBMS_STATS.GATHER__STATS it is quite normal that you get different execution plans for the same SQL statement. Depending on the values passed when the statement is hard parsed (this feature is called "bind variable peeking" and enabled by default since 9i) an execution plan is determined and re-used for all further executions of the same "shared" SQL statement.
If now your statement ages out of the shared pool or is invalidated due to some DDL or statistics gathering activity it will be re-parsed and again the values passed in that particular moment will determine the execution plan. If you have skewed data distribution and a histogram in place that reflects that skewness you might get different execution plans depending on the actual values used.
Since this "flip-flop" behaviour can sometimes be counter-productive if you're unlucky and the values used to hard parse the statement leading to a plan that is unsuitable for the majority of values used afterwards, 11g introduced the "adaptive" cursor sharing that attempts to detect such a situation and can automatically re-evaluate the execution plan of the statement.
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/

NEW FEATURE:AUTOTRACE IN SQL*PLUS 3.3(EXECUTION PLAN)

제품 : SQL*PLUS
작성날짜 : 2003-10-07
NEW FEATURE:AUTOTRACE IN SQL*PLUS 3.3
======================================
Autotrace는 SQL*Plus 3.3부터 지원하는 New feature로서 기존에는 init.ora에
SQL_TRACE=TRUE를 setting 후 얻어진 trace file을 TKPROF란 utility를
이용하여 SQL 문의 수행 경로, 각종 통계 정보를 얻었다.
그러나, SQL*Plus 3.3부터는 이것을 간단히 처리할 수 있는 방법을 제공한다.
1. SQL*Plus를 실행하여 scott user로 접속한 후, plan table을 생성한다.
#sqlplus scott/tiger
SQL>@$ORACLE_HOME/rdbms/admin/utlxplan
2. 다음에 sys user에서 PLUSTRACE란 ROLE을 만든다.
SVRMGR>connect internal;
SVRMGR>create role plustrace;
SVRMGR>grant select on v_$sesstat to plustrace;
SVRMGR>grant select on v_$statname to plustrace;
SVRMGR>grant select on v_$session to plustrace;
SVRMGR>grant plustrace to dba with admin option;
SVRMGR>grant plustrace to scott;
비고) 위의 grant 문은 client에 SQL*Plus 3.3이 install되어 있는 경우
C:ORAWIN95\PLUS33\PLUSTRCE.SQL이라는 script에 기록되어 있다.
다음과 같이 실행해 주면 된다.
1> connect sys/manager
2> @$ORACLE_HOME/sqlplus/admin/plustrce.sql
3> grant plustrace to scott;
3. 다음에는 scott user로 connect하여 작업한다.
#sqlplus scott/tiger
SQL>set autotrace on
SQL>select * from emp;
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'EMP'
Statistics
389 recursive calls
5 db block gets
53 consistent gets
12 physical reads
0 redo size
1049 bytes sent via SQL*Net to client
239 bytes received via SQL*Net from client
4 SQL*Net round-trips to/from client
0 sorts (memory)
0 sorts (disk)
13 rows processed
4. 참고로 set autotrace에는 여러가지 option을 부여해 작업할 수도 있다.
예)set autotrace on => Explain plan and statistics.
set autotrace on explain => Explain plan only.
set autotrace traceonly => select된 결과는 빼고 trace만 display
시킴.
set autotrace on statistics=> sql statement execution statistics.
5. 서버 버젼과 상관없다.
Server가 7.2 version 이하일지라도 clinet에 SQL*Plus 3.3이 install되어
있으면 client에서 sqlplus 3.3을 구동시켜 server에 접속하여 위와 같이
작업하면 무리없이 작업이 가능하다.
Reference Documents
<Note:43214.1>

Hi Roman,
I don't have an Oracle 9.2 database readily available, but it works fine on 10g XE. Please note 3.1 is not certified with 9i:
http://www.oracle.com/technetwork/developer-tools/sql-developer/certification-096745.html
Regards,
Gary
SQL Developer Team

Problem with execution plan

I'm having a problem where a sql suddenly takes several minutes to execute. This is a sequel that runs every day in production and executes fine, but suddenly it takes several minutes to finish. Websphere is set to time out after 2 minutes, it then executes a rollback command.
We think that this happends after the statistics job running in Oracle has been executed and the execution plan has been updated. It looks like the database connections created from websphere uses the old execution plan. Running the same sql from sqlplus takes only a few seconds, while from the application server it takes over 2 minutes (makes websphere time out)
We are running websphere 6.1, Oracle 10g. The questions...
After the statistics job has been executed, is the library cache flushed? and all sessions that was created will use the new execution plan? (does not look like it).
How do we force the application server to use the right execution plan - or Oracle is probably more correct to ask.

The answer to your questions can be..
1.After the statistics job has been executed, is the library cache flushed? and all sessions that was created will use the new execution plan? (does not look like it).
When the statistics for object are collected, any cached execution plan referencing it will get invalidated.
2. How do we force the application server to use the right execution plan - or Oracle is probably more correct to ask.
You can make use of Stored Outlines.

9i 10g upgrade execution plan differences.

Similar Messages

Maybe you are looking for