About explain plan

Hello ALL,
I have the following explain plan, can any body explain the meaning of this explain plan
SELECT * FROM
2 TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE','111'));
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
| 0 | SELECT STATEMENT | | 401 | 25263 | | 751K|
| 1 | MERGE JOIN SEMI | | 401 | 25263 | | 751K|
| 2 | SORT JOIN | | 17M| 820M| 2108M| 75297 |
| 3 | TABLE ACCESS FULL | TABLE1 | 17M| 820M| | 3520 |
|* 4 | SORT UNIQUE | | 275M| 3412M| 10G| 676K|
| 5 | VIEW | VW_NSO_1 | 275M| 3412M| | 3538 |
|* 6 | HASH JOIN | | 275M| 7874M| | 3538 |
|* 7 | TABLE ACCESS FULL| TABLE2 | 16 | 128 | | 2 |
|* 8 | TABLE ACCESS FULL| TABLE1 | 17M| 360M| | 3520 |
Predicate Information (identified by operation id):
4 - access("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
filter("TABLE1"."POSITION"="VW_NSO_1"."$nso_col_1")
6 - access("TABLE2"."VERSION_NO"="TABLE1"."VERSION_NO")
7 - filter("TABLE2"."STATIC_UPD_FLAG"='N')
8 - filter("TABLE1"."DATETIME_INSERTED">TO_DATE('0004-01-01 00:00:00',
'yyyy-mm-dd hh24:mi:ss'))
Note: cpu costing is off
26 rows selected.
SQL>

There is a section in the manual on interpreting the output of explain plan http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/ex_plan.htm#16972 Tom Kyte also discusses interpreting the plan http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:231814117467#7344298017927 (page down about halfway where he starts his book excerpt).
Rows, bytes, and temp space are the cost-based optimizer's guess about the number of rows, bytes, and temp space that will be touched (or consumed) by the operation. The cost is an internal number that has no significance to you when you're reading an explain plan-- it does have some significance when you are examining an event 10046 trace.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Similar Messages

A question about explain plan

here is my sql statement and running result:
SQL> @bind_variables_peeking_test.sql
SQL> SET ECHO OFF
SQL>
SQL> REM
SQL> REM Setup test environment
SQL> REM
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL>
SQL> DROP TABLE t;
DROP TABLE t
ERROR at line 1:
ORA-00942: table or view does not exist
SQL>
SQL> CREATE TABLE t
2 AS
3 SELECT rownum AS id
4 FROM dual
5 CONNECT BY level <= 1000;
SQL>
SQL> execute dbms_stats.gather_table_stats(ownname=>user, tabname=>'t');
SQL> SELECT count(id), count(DISTINCT id), min(id), max(id) FROM t;
COUNT(ID) COUNT(DISTINCTID) MIN(ID) MAX(ID)
1000 1000 1 1000
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM Without bind variables different execution plans are used if the value
SQL> REM used in the WHERE clause change. This is because the query optimizer
SQL> REM recognize the different selectivity of the two predicates.
SQL> REM
SQL>
SQL> SELECT count(*) FROM t WHERE id < 990;
COUNT(*)
989
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID bspfffaycy92u, child number 0
SELECT count(*) FROM t WHERE id < 990
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 990 | 2970 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<990)
SQL>
SQL> PAUSE
SQL>
SQL> SELECT count(*) FROM t WHERE id < 10;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID 4xfxt0frkj40y, child number 0
SELECT count(*) FROM t WHERE id < 10
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<10)
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM With bind variables the same execution plan is used. Depending on the
SQL> REM peeked value (10 or 990), a full table scan or an index range scan is used.
SQL> REM
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL> PAUSE
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL>
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL> explain plan for SELECT count(*) FROM t WHERE id < :id;
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 3 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 50 | 150 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<TO_NUMBER(:ID))
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM Cleanup
SQL> REM
SQL>
SQL> UNDEFINE sql_id
SQL>
SQL> DROP TABLE t;
SQL> PURGE TABLE t;
SQL>
SQL> spool off;
please noticed the last two explain plan result,one sql statement but have two result,why?

what do you mean "invalidated the previous plan"?
i gather the table statistics information once.
every time before i run the statement and explain plan, i flush share pool to make sure there are not execution plan to reused.
so i think i do not invalidated the previous plan and the two result should be same.

About EXPLAIN PLAN table

Hi,
This is just a sample query which I have executed on a recently installed Oracle ..
SQL> explain plan for
2 select * from emp
3 where job = 'CLERK';
select * from emp
ERROR at line 2:
ORA-02402: PLAN_TABLE not found
When I have requested my DBA, he said, he couldnt find this (PLAN TABLE) utility in oracle .. Please advice me, from where can I get this utility ?? And how to proceed
Regards

SQL> explain plan for select sysdate from dual
2 /
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation            | Name       | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT     |             |       |       |       |
|   1 | TABLE ACCESS FULL   | DUAL        |       |       |       |
Note: rule based optimization
9 rows selected.Cheers
Sarma.

Explain Plan

Just Question about Explain Plan.
Q- 1. Is it Possible to trace a current session query from other session without altering that session. If How can i do it. I can not do it with v$session becuase it will be different sessionid. Also i ndon't want to alter session.
Q-2 I have SQl statement gives different EXECUTION PLAN on 9R2 and 10g. Is it possible.
Can any one explain this please

thank you smoradi and william for your response.
Sorry for Long Post
I tried to post it before also. i did not get the conculsion. This are the final results i got. So can any one Help me.
Following are the information
I have TKPROF result. can any one expalin me this what it means. Where are wait time.
I got the explain plan as unnder can any one explain me please i am still having problem solving this
can any one explain me how to improve the perfomance.
1.SS_SKU_STORE_WEEk is the biggest table around 12 million rows.
2. SS_SKU_STORE 50 thosand rows
3. ITEM 44 thousand
4.Rest all tables are small.
SQL> SELECT   /*+ index( ss_sku_store SS_SKU_ST_PK ) */
2              TO_NUMBER( ss_sku_store.sku || ss_sku_store.store_num) rowkey,
3              ss_sku_store.sku psku,
4              ' ' || INITCAP( item.descrip ) description,
5              dept_id,
6              TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) subdepartment,
7              TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) ||'.'|| TO_CHAR( class_id ) class,
8              NVL( vendor_id, -1 ),
9              NVL( buyer_num, -1),
10              NVL( TRIM(pattern_cd), -1),
11              DECODE(Color_Cd, 0, -1, NVL( Color_Cd, -1)) Color_Cd,
12              NVL( size_cd, -1),
13              -1 list_id,
14              ss_sku.sku skuattribute,
15              ss_sku_store.store_num pstore,
16              INITCAP( store.name ) location,
17              store.state,
18              NVL( INITCAP( regional_vp), :cUNASSIGNED) regional_vp,
19              NVL( INITCAP( regional_merch_mgr), :cUNASSIGNED) regional_merch_mgr,
20              NVL( INITCAP( district_mgr), :cUNASSIGNED) district_mgr,
21              NVL( INITCAP( area_mgr), :cUNASSIGNED) area_mgr,
22              NVL( sq_footage, -1),
23              SUBSTR( '000' || fashion_attribute.seq, -3, 3 ) || NVL( store.fashion_att_cd, '' ) fashion_att_cd,
24              SUBSTR( '000' || cust_profile.seq, -3, 3 ) || NVL( store.cust_type_cd, '' ) cust_type_cd,
25              NVL( section_count, -1) section_count,
26              '000' corp_vol_grp_cd,
27              0 storegroup,
28              store.store_num storeattribute,
29              0 storesort,
30              submit_status,
31              DECODE( current_user, :pUserID, shipment_schedules.check_staged_sku(ss_sku_store.sku,-1), 1) lockedflag,
32              '' aggregatedrowkey,
33              '' AttributeDescription,
34              starting_on_hand     onhand
35     FROM     cust_profile,
36              fashion_attribute,
37              ( SELECT   vendor_id,
38                         sku
39                FROM     item_vendor
40                WHERE    sku IN ( SELECT sku
41                                  FROM    ss_session_sku
42                                  WHERE   user_key = :pUserKey)
43                AND      primary_flag = :cTRUE ) primaryvendor,
44              ( SELECT   SKU,
45                         DECODE( status, 0, 0, DECODE( status, 1 ,0 ,1) ) AS submit_status
46                FROM     ( SELECT   /*+ full(ss_session_sku) use_nl(ss_session_sku,ss_sku_store_week) index(ss_sku_store_week SS_SKU_STR_WK_SKU )*/
47                                    SS_SKU_Store_Week.SKU,
48                                    MAX( NVL( ssk_week_status, 0 ) ) AS status
49                           FROM     ss_session_sku,
50                                    ss_sku_store_week
51                           WHERE    user_key              = :pUserKey
52                           AND      ss_sku_store_week.sku = ss_session_sku.sku
53                           GROUP BY ss_sku_store_week.sku )
54               ) sku_status,
55              ss_sku,
56              store,
57              ss_sku_store,
58              item
59     WHERE    sku_status.sku           = item.sku
60     AND      sku_status.sku           = ss_sku.sku
61     AND      sku_status.sku           = ss_sku_store.sku
62     AND      sku_status.sku           = primaryvendor.sku
63     AND      sku_status.sku           = sku_status.sku
64     AND      ss_sku_store.store_num   = store.store_num
65     AND      store.cust_type_cd       = cust_profile.cust_type_cd(+)
66     AND      store.fashion_att_cd     = fashion_attribute.fashion_att_cd(+)
67     ORDER BY ss_sku_store.sku,
68              ss_sku_store.store_num;
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=531 Card=3203 Bytes=948088)
   1    0 SORT (GROUP BY) (Cost=531 Card=3203 Bytes=948088)
   2    1    HASH JOIN (RIGHT OUTER) (Cost=323 Card=3203 Bytes=948088)
   3    2      TABLE ACCESS (FULL) OF 'CUST_PROFILE' (TABLE) (Cost=2 Card=16 Bytes=304)
   4    2      HASH JOIN (RIGHT OUTER) (Cost=321 Card=3203 Bytes=887231)
   5    4        TABLE ACCESS (FULL) OF 'FASHION_ATTRIBUTE' (TABLE) (Cost=2 Card=9 Bytes=162)
   6    4        HASH JOIN (Cost=318 Card=3203 Bytes=829577)
   7    6          TABLE ACCESS (FULL) OF 'STORE' (TABLE) (Cost=15 Card=1289 Bytes=105698)
   8    6          TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'SS_SKU_STORE' (TABLE) (Cost=3 Card=707 Bytes=17675)
   9    8           NESTED LOOPS (Cost=302 Card=3203 Bytes=566931)
10    9             HASH JOIN (Cost=287 Card=5 Bytes=760)
11   10               NESTED LOOPS (Cost=284 Card=5 Bytes=655)
12   11                 NESTED LOOPS (Cost=273 Card=5 Bytes=270)
13   12                   NESTED LOOPS (Cost=252 Card=86 Bytes=3784)
14   13                     NESTED LOOPS (Cost=17 Card=13 Bytes=468)
15   14                       SORT (UNIQUE) (Cost=1 Card=13 Bytes=130)
16   15                         INDEX (RANGE SCAN) OF 'SS_SESS_SKU_PK' (INDEX (UNIQUE)) (Cost=1 Card=13 Bytes=130)
17   14                       TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_VENDOR' (TABLE) (Cost=3 Card=1 Bytes=26)
18   17                         INDEX (RANGE SCAN) OF 'ITEM_VENDOR_ITEM_FK_IDX' (INDEX) (Cost=2 Card=1)
19   13                     PARTITION HASH (ITERATOR) (Cost=65 Card=7 Bytes=56)
20   19                       TABLE ACCESS (BY LOCAL INDEX ROWID)OF 'SS_SKU_STORE_WEEK' (TABLE) (Cost=65 Card=7 Bytes=56)
21   20                         INDEX (RANGE SCAN) OF 'SS_SKU_STR_WK_SKU' (INDEX) (Cost=14 Card=6427)
22   12                   TABLE ACCESS (FULL) OF 'SS_SESSION_SKU'(TABLE) (Cost=0 Card=1 Bytes=10)
23   11                 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (TABLE) (Cost=2 Card=1 Bytes=77)
24   23                   INDEX (UNIQUE SCAN) OF 'ITEM_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
25   10               TABLE ACCESS (FULL) OF 'SS_SKU' (TABLE) (Cost=3 Card=343 Bytes=7203)
26    9             PARTITION HASH (ITERATOR) (Cost=1 Card=211)
27   26               INDEX (RANGE SCAN) OF 'SS_SKU_ST_PK' (INDEX(UNIQUE)) (Cost=1 Card=211)
EXPLIAN PLAN AND DATA FROM TKPROF
all     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.01          0          0          0           0
Execute      2      1.35       1.30          0          0          0           0
Fetch        5      0.14       0.16          5       2497          0         111
total        9      1.49       1.49          5       2497          0         111
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 30 (MDSEADMIN)
Rows     Row Source Operation
      0 PX COORDINATOR FORCED SERIAL (cr=797 pr=2 pw=0 time=42745 us)
      0   PX SEND QC (ORDER) :TQ10005 (cr=797 pr=2 pw=0 time=42711 us)
      0    SORT ORDER BY (cr=797 pr=2 pw=0 time=42701 us)
      0     PX RECEIVE (cr=797 pr=2 pw=0 time=42627 us)
      0      PX SEND RANGE :TQ10004 (cr=797 pr=2 pw=0 time=42617 us)
      0       BUFFER SORT (cr=797 pr=2 pw=0 time=42609 us)
      0        NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42532 us)
      0         NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42520 us)
      0          NESTED LOOPS (cr=797 pr=2 pw=0 time=42510 us)
      0           NESTED LOOPS (cr=797 pr=2 pw=0 time=42502 us)
      0            NESTED LOOPS (cr=797 pr=2 pw=0 time=42495 us)
      0             NESTED LOOPS (cr=797 pr=2 pw=0 time=42488 us)
      0              HASH JOIN (cr=797 pr=2 pw=0 time=42480 us)
      1               BUFFER SORT (cr=5 pr=1 pw=0 time=13357 us)
      1                PX RECEIVE (cr=5 pr=1 pw=0 time=13300 us)
      1                 PX SEND HASH :TQ10001 (cr=5 pr=1 pw=0 time=13291 us)
      1                  TABLE ACCESS BY INDEX ROWID ITEM_VENDOR (cr=5 pr=1 pw=0 time=13280 us)
      3                   NESTED LOOPS (cr=4 pr=0 pw=0 time=423 us)
      1                    SORT UNIQUE (cr=1 pr=0 pw=0 time=189 us)
      1                     INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=86 us)(object id 25279)
      1                    INDEX RANGE SCAN ITEM_VENDOR_ITEM_FK_IDX (cr=3 pr=0 pw=0 time=53 us)(object id 24079)
      0               PX RECEIVE (cr=792 pr=1 pw=0 time=28530 us)
      0                PX SEND HASH :TQ10003 (cr=792 pr=1 pw=0 time=28524 us)
      0                 VIEW (cr=792 pr=1 pw=0 time=28517 us)
      0                  HASH GROUP BY (cr=792 pr=1 pw=0 time=28509 us)
      0                   PX RECEIVE (cr=792 pr=1 pw=0 time=28295 us)
      0                    PX SEND HASH :TQ10002 (cr=792 pr=1 pw=0 time=28290 us)
      0                     NESTED LOOPS (cr=792 pr=1 pw=0 time=28284 us)
      1                      BUFFER SORT (cr=1 pr=0 pw=0 time=139 us)
      1                       PX RECEIVE (cr=1 pr=0 pw=0 time=45 us)
      1                        PX SEND BROADCAST :TQ10000 (cr=1 pr=0 pw=0 time=40 us)
      1                         INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=34 us)(object id 25279)
      0                      PX BLOCK ITERATOR PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28136 us)
      0                       TABLE ACCESS FULL SS_SKU_STORE_WEEK PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28084 us)
      0              TABLE ACCESS BY INDEX ROWID ITEM (cr=0 pr=0 pw=0 time=0 us)
      0               INDEX UNIQUE SCAN ITEM_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24055)
      0             TABLE ACCESS BY INDEX ROWID SS_SKU (cr=0 pr=0 pw=0 time=0 us)
      0              INDEX UNIQUE SCAN SS_SKU_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25300)
      0            PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
      0             TABLE ACCESS BY LOCAL INDEX ROWID SS_SKU_STORE PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
      0              INDEX RANGE SCAN SS_SKU_ST_PK PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)(object id 25547)
      0           TABLE ACCESS BY INDEX ROWID STORE (cr=0 pr=0 pw=0 time=0 us)
      0            INDEX UNIQUE SCAN STORE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25586)
      0          TABLE ACCESS BY INDEX ROWID FASHION_ATTRIBUTE (cr=0 pr=0 pw=0 time=0 us)
      0           INDEX UNIQUE SCAN FASHION_ATTRIBUTE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24035)
      0         TABLE ACCESS BY INDEX ROWID CUST_PROFILE (cr=0 pr=0 pw=0 time=0 us)
      0          INDEX UNIQUE SCAN CUST_PROFILE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24036)
ALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       43      0.10       0.11          0          1          0           0
Execute    861      0.38       0.45        357        622         46         621
Fetch      845      0.21       0.21        128       2626          2         892
total     1749      0.69       0.78        485       3249         48        1513
Misses in library cache during parse: 21
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                      60        0.00          0.00
SQL*Net message from client                    39        0.00          0.16
db file scattered read                         82        0.01          0.05
db file sequential read                       185        0.01          0.05
log file sync                                   1        0.00          0.00
191 user SQL statements in session.
   23 internal SQL statements in session.
214 SQL statements in session.
   37 statements EXPLAINed in this session.Thank you for your help in advance
Message was edited by:
devmiral

Explain plan inside a procedure

I'm using execute immediate statement to process data. I would like to have additional information about explain plan for these statements, for example:
create or replace procedure p
is
v_stmt varchar2(4000) := 'select count(*) from dual where dummy = :1';
v_plan varchar2(4000);
begin
execute immediate v_stmt using 'X';
-- here I would like to retrieve into v_plan variable an explain plan used for v_stmt
end;
Is it possible to do? If so, how?
thank you

Just trace/tkprof the session that executes the process.
You'll have the execution plan and lots more of information:
ORACLE-BASE - SQL trace, 10046, trcsess and tkprof in Oracle
Oracle related stuff: Basic SQL statement performance diagnosis - HOW TO, step by step instructions

Explain me about cost in explain plan.

Hi All,
Please explain me about cost in explain plan.
Below is my explan plans
1. first plan showing cost is more but query is returing the result very fast (564 msecs ) --- local database.
2. second plan showing less cost but result is very slow (14 secs) .
1. local database.
PLAN_TABLE_OUTPUT
| ID | Operation                         | NAME                      | ROWS | Bytes | COST |
|   0 | SELECT STATEMENT                  |                           |    17 | 2312 |    60 |
|   1 | SORT UNIQUE                      |                           |    17 | 2312 |    59 |
|   2 |   COUNT STOPKEY                   |                           |       |       |       |
|   3 |    NESTED LOOPS                   |                           |    17 | 2312 |    58 |
|   4 |     MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS           |    17 | 1326 |    24 |
|   5 |      INDEX RANGE SCAN             | IDX_ESNG_REG_TITLE        |    21 |       |     3 |
|   6 |     TABLE ACCESS BY INDEX ROWID   | MV_EDECO_ESONGS_TERR_CTRY |     1 |    58 |     2 |
|   7 |      INDEX UNIQUE SCAN            | IDX_ESNG_TERR_ESNG_ID_1   |     1 |       |     1 |
PLAN_TABLE_OUTPUT
| ID | Operation                         | NAME                       | ROWS | Bytes | COST |
|   0 | SELECT STATEMENT                  |                            |     9 | 1260 |    34 |
|   1 | SORT UNIQUE                      |                            |     9 | 1260 |    33 |
|   2 |   COUNT STOPKEY                   |                            |       |       |       |
|   3 |    NESTED LOOPS                   |                            |     9 | 1260 |    32 |
|   4 |     MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS            |     9 |   720 |    14 |
|   5 |      INDEX RANGE SCAN             | IDX_ESNG_REG_TITLE         |    11 |       |     3 |
|   6 |     MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS_TERR_CTRY |     1 |    60 |     2 |
|   7 |      INDEX UNIQUE SCAN            | PK_EDESONGSTERCTRY_ESONGID |     1 |       |     1 |
------------------------------------------------------------------------------------------------Regards,
Rajasekhar

rajasekhar_n wrote:
Hoek, I have cross checked the results both the querys are precessing same records and returing same result *(both are using DB links).*But you said the first query was on a local database?
If you're using dblinks then it's not local is it! ?:|

Explain plan does not say anything about partition

Hello,
We have Oracle 11g database. And we have range partitioned a table. Now when I see explain plans for queries sometimes it says PARTITION RANGE ALL (when no filter), Some times PARTITION RANGE ITERATOR or PARTITION RANGE SINGLE or PARTITION RANGE JOIN FILTER etc. But sometimes it does not say any thing about partition.
Is the partition pruning being used? Since my understanding is that table is no more a monolithic sort of, but sort of table now has many tables for each partition.
So option is either scan all partition i.e display PARTITION RANGE ALL or scan some partitions, and display it in explain plan.
Am I thinking in wrong direction?
Please let me know.
Thank you,

The only thing to do that makes sense is to back up all your data, erase the boot drive, reinstall and update the OS, then restore only your documents from backup and reinstall your third-party software from known-good copies.
Sadly, this is not practical at the current time. She is away from home, in a place with modem-speed internet access, without access to install media or her backups (which are on a hard drive at home.) I was able to operate on her machine by sshing in, and I did the best I could to remove the crap. The rest will have to wait until she gets back.
Here is something I found by googling:
http://nnrpanel.com/offlineAU.htm
Thank you, I will try them. I doubt they will know anything (since there are no Mac instructions on that page) but maybe they can at least send me to the US center. I have tried the US Nielsen Ratings contact form, three times now, but it appears that either they don't read it or they don't respond to it. It also has a maximum message size of about 250 characters.
I wonder if it may be related to one of those make money at home - be a secret shopper - review products at your leaisure and make a ton of moneydeals.
I would tend to doubt it, if only because they are clearly quite effective (or nobody would be running those ads) and yet nobody has reported this anywhere else that I can find.
I'm going to send some emails and see if I can find someone who knows something.

Question about running explain plan

I tried to run explain plan for a simple query, just to familiarize myself with how to do it. (I have another query that's taking a long time, and I've never run explain plan before). I got an error, googled it, and discovered I had to run the file at @%ORACLE_HOME%\rdbms\admin\utlxplan.sql first, to create the Plan_Table. Well, I tried to run that file and I get the error that I don't have priveleges on the tablespace. This really doesn't surprise me, as my access is read-only. Is there any way around this? I don't know a whole lot about databases, so forgive me if these following questions are dumb, but...
1) is that file basically trying to create a table (called Plan_Table) within the schema I'm in (the only schema I have access to)?
2) can my company's DBA run that file for me to create the Plan_Table?

What version of the database are you on?
You can get run-time execution plans from V$SQL_PLAN. You will need permission to read the V$ views. First find your query in V$SQL_PLAN (you can do a text search; putting a comment in like '--my_query' can help), then join to V$SQL_PLAN to find the query plan that that query used - join by the ADDRESS and HASH_VALUE columns.
Otherwise, see if you can get insert/update/delete access on just that one table when your DBA creates it
Good luck.

About generating an EXPLAIN plan

What is its use?

Hi
Good inputs. Hovewer explain plan is not only used by CBO but for RBO (Rule Based Optimizer), too.
SQL> explain plan for
2 select /*+ RULE */
3 *
4 from dba_objects;
Explained.
SQL> select * from table (dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation                      | Name        | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT               |              |       |       |       |
|   1 | VIEW                          | DBA_OBJECTS |       |       |       |
|   2 |   UNION-ALL                    |              |       |       |       |
|* 3 |    FILTER                      |              |       |       |       |
|   4 |     TABLE ACCESS BY INDEX ROWID| OBJ$         |       |       |       |
|   5 |      NESTED LOOPS              |              |       |       |       |
|   6 |       TABLE ACCESS FULL        | USER$        |       |       |       |
|* 7 |       INDEX RANGE SCAN         | I_OBJ2       |       |       |       |
|* 8 |     TABLE ACCESS BY INDEX ROWID| IND$         |       |       |       |
|* 9 |      INDEX UNIQUE SCAN         | I_IND1       |       |       |       |
| 10 |    TABLE ACCESS BY INDEX ROWID | LINK$        |       |       |       |
| 11 |     NESTED LOOPS               |              |       |       |       |
| 12 |      TABLE ACCESS FULL         | USER$        |       |       |       |
|* 13 |      INDEX RANGE SCAN          | I_LINK1      |       |       |       |
Predicate Information (identified by operation id):
   3 - filter("SYS_ALIAS_1"."TYPE#"<>1 AND "SYS_ALIAS_1"."TYPE#"<>10 OR
              "SYS_ALIAS_1"."TYPE#"=1 AND (SELECT 1 FROM "SYS"."IND$" "I" WHERE
              "I"."OBJ#"=:B1 AND ("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR
              "I"."TYPE#"=4 OR "I"."TYPE#"=6 OR "I"."TYPE#"=7 OR "I"."TYPE#"=9))=1)
   7 - access("SYS_ALIAS_1"."OWNER#"="U"."USER#" AND "SYS_ALIAS_1"."LINKNAME"
              IS NULL)
       filter("SYS_ALIAS_1"."LINKNAME" IS NULL AND
              "SYS_ALIAS_1"."NAME"<>'_default_auditing_options_' AND
              "SYS_ALIAS_1"."NAME"<>'_NEXT_OBJECT')
   8 - filter("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4
              OR "I"."TYPE#"=6 OR "I"."TYPE#"=7 OR "I"."TYPE#"=9)
   9 - access("I"."OBJ#"=:B1)
13 - access("L"."OWNER#"="U"."USER#")
Note: rule based optimization
38 rows selected.
SQL> Bye, Aron

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
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/

Filter(NULL IS NOT NULL) in Explain Plan ??

Hi All,
Can someone please explain what this explain plan statement means? I see a filter(NULL IS NOT NULL) as the first statement - could not figure out why it came up so from googling.
My Query Used:
EXPLAIN PLAN FOR
MERGE INTO summary_bysrccd
USING
(SELECT LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS SUMMARY_DATE,
os.acctnum,
ol.sourcecode AS sourcecode,
ol.sourcename AS sourcename,
count(1) cnt_articleview
FROM article_views os , master_sourcecode ol
where os.sourcecode = ol.sourcecode
AND os.acctnum IS NOT NULL
AND ol.sourcecode IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
     AND (
          ('INCR' = 'FULL'
          AND (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS')
          AND   os.entry_CreatedDate BETWEEN TO_DATE('22-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('28-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
          OR ('INCR' = 'FULL'
          AND os.entry_createddate BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS') )
group by LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))),
os.acctnum,ol.sourcecode,ol.sourcename) mrg_query
ON (ods_av_summary_bysrccd.acctnum = mrg_query.acctnum AND
ods_av_summary_bysrccd.summary_date=mrg_query.summary_date AND
ods_av_summary_bysrccd.sourcecode=mrg_query.sourcecode)
WHEN NOT MATCHED THEN
INSERT (SUMMARY_date,ACCTNUM,SOURCECODE,SOURCENAME,CNT_ARTICLEVIEW,ENTRY_LASTUPDATEDDATE)
VALUES(mrg_query.summary_date,mrg_query.acctnum,mrg_query.sourcecode,mrg_query.sourcename,
mrg_query.cnt_articleview,sysdate)
WHEN MATCHED THEN
UPDATE SET ods_av_summary_bysrccd.cnt_articleview=
CASE WHEN NVL('INCR','INCR') = 'FULL' THEN mrg_query.cnt_articleview
ELSE ods_av_summary_bysrccd.cnt_articleview+mrg_query.cnt_articleview
END,
ods_av_summary_bysrccd.entry_lastupdateddate=sysdate;My Explain Plan:
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 268591246
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | MERGE STATEMENT                           |                           |     1 |   456 |       |     3   (0)| 00:00:01 |       |       |
|   1 | MERGE                                    | ODS_AV_SUMMARY_BYSRCCD    |       |       |       |            |          |       |       |
|   2 |   VIEW                                    |                           |       |       |       |            |          |       |       |
|   3 |    NESTED LOOPS OUTER                     |                           |     1 |   417 |       |     3   (0)| 00:00:01 |       |       |
|   4 |     VIEW                                  |                           |     1 |   360 |       |     5 (100)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                        |                           |     1 |    73 |   595M|            |          |       |       |
PLAN_TABLE_OUTPUT
|* 6 |       FILTER                              |                           |       |       |       |            |          |       |       |
|* 7 |        HASH JOIN                          |                           | 6975K|   485M| 3944K| 17594   (1)| 00:03:32 |       |       |
|   8 |         TABLE ACCESS FULL                 | ODS_MASTER_SOURCECODE     | 84021 | 2953K|       |   273   (1)| 00:00:04 |       |       |
|* 9 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ODS_ARTICLE_VIEWS         | 7007K|   247M|       |   826   (0)| 00:00:10 |    33 |    33 |
|* 10 |          INDEX FULL SCAN                  | IDX_AV_ACCTNUM            |    25M|       |       |    26   (0)| 00:00:01 |       |       |
| 11 |     TABLE ACCESS BY GLOBAL INDEX ROWID    | ODS_AV_SUMMARY_BYSRCCD    |     1 |    57 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 12 |      INDEX UNIQUE SCAN                    | ODS_AV_SUMMARY_BYSRCCD_PK |     1 |       |       |     2   (0)| 00:00:01 |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   6 - filter(NULL IS NOT NULL)
   7 - access("OS"."SOURCECODE"="OL"."SOURCECODE")
   9 - filter("OS"."REQUESTDATETIME" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-08-23 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-08-27 23:59:59', 'syyyy-mm-dd hh24:mi:ss') AND UPPER("OS"."SUCCESS_IND")='S')
10 - filter("OS"."ACCTNUM" IS NOT NULL)
12 - access("ODS_AV_SUMMARY_BYSRCCD"."SUMMARY_DATE"(+)=INTERNAL_FUNCTION("MRG_QUERY"."SUMMARY_DATE") AND
              "ODS_AV_SUMMARY_BYSRCCD"."ACCTNUM"(+)="MRG_QUERY"."ACCTNUM" AND "ODS_AV_SUMMARY_BYSRCCD"."SOURCECODE"(+)="MRG_QUERY"."SOURCECODE")
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement

Hi Toon,
Thanks for the quick resolution. I went back and verified the table's colunm details and it has a NOT NULL constraint.
Regards,
Chaitanya
P.S: Is it ok if I ask you for some help regarding a production issue I have been encountering since 15 days but haev no clear resolution yet about what/why is the reason (the said issue is neither uniform nor regular - its affecting some modules and happening on some days - i shall give the full details if you are willing to have a look) - i shall start a new post or email you directly - yur convenience.

How to improve the query performance or tune query from Explain Plan

Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
     8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
          5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
               2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
                    1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
                    3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
          7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
               6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
     10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
          12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
               11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
          14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
               13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
     21 FILTER
          16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
          20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
               18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
                    17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
     23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
          42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
               38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
                    34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
                         30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
                              26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                   25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                        24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                              29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                   28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                        27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                         33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                              32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                                   31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
                    37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
                         36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
                              35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
               41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
                    40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
                         39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
          44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
               43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
          1 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        243 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
       SID
       310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
     VALUE
       163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID        CHILD_NUMBER
04mpgrzhsv72w            0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like   (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
PM:     PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
          REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
            : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

"Explain Plan" in Oracle SQL Developer is greyed out

Hi all,
I know this is not the right place to post this, but I have look around and do not know where to post question about Oracle SQL Developer - I presume this tool is also discussed here in this forum.
My question is very simple (I presume):
1. I installed Oracle SQL Developer 3.0.04.
2. I added a new DB connection to a DB hosted in one of my servers in the LAN.
3. However, when I am writing some SQL queries, I intend to use the "Explain Plan" feature, but it is being greyed out (disabled).
4. How can I enable it back?

Hello,
{forum:id=260}
Regards
Marcus

Explain plan: "Select statement"

Hi,
I'm using the explain plan command to retrieve information about query execution. In particular I want to estimate query execution time.
Let's consider the following example:
"| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |"
"| 0 | SELECT STATEMENT | | 4775 | 484K| 98886 (1)| 00:19:47 |"
"| 1 | HASH GROUP BY | | 4775 | 484K| 98886 (1)| 00:19:47 |"
"|* 2 | MAT_VIEW ACCESS FULL| Materialized_view1 | 4775 | 484K| 98884 (1)| 00:19:47 |"
In the calculation of total execution time should i consider the "select statement" operation?
The total execution time can be calculated like this: Time(Select statement) + Time(hash group by) + Time(access full)=19.47*3=58.41. Is it right?
Thanks

No, the expected time is 00:19:47. No time is expected to be spent in steps 0 and 1.

Exactly how bad is this explain plan?

Hi,
I'm on Oracle 9i - 9.2.0.6.0.
First, please excuse my question, I'm not that good at reading explain plans.
I have this explain plan:
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)|
|   0 | SELECT STATEMENT                          |                            | 70057 |    20M|       |   114K (12)|
|* 1 | FILTER                                   |                            |       |       |       |            |
|   2 |   TABLE ACCESS FULL                       | DUAL                       |    82 |       |       |     3 (34)|
|* 3 |   INDEX RANGE SCAN                        | CHANGELOG_1                |     1 |    44 |       | 2217   (3)|
|   4 | NESTED LOOPS OUTER                       |                            | 70057 |    20M|       |   114K (12)|
|   5 |   NESTED LOOPS OUTER                      |                            | 67062 |    18M|       |   113K (11)|
|   6 |    NESTED LOOPS OUTER                     |                            | 64194 |    16M|       |   111K (10)|
|   7 |     NESTED LOOPS OUTER                    |                            | 61450 |    14M|       |   110K (9)|
|   8 |      NESTED LOOPS OUTER                   |                            | 58823 |    13M|       |   109K (8)|
|   9 |       NESTED LOOPS OUTER                  |                            | 56308 |    12M|       |   107K (6)|
| 10 |        NESTED LOOPS OUTER                 |                            | 53900 |    11M|       |   106K (5)|
| 11 |         NESTED LOOPS OUTER                |                            | 51596 |    10M|       |   105K (4)|
| 12 |          NESTED LOOPS OUTER               |                            | 49390 | 9212K|       |   104K (3)|
| 13 |           NESTED LOOPS OUTER              |                            | 47278 | 8310K|       |   102K (2)|
|* 14 |            HASH JOIN                      |                            | 31639 | 5067K| 4576K| 7331 (13)|
|* 15 |             HASH JOIN                     |                            | 31639 | 4202K| 1936K| 1372   (9)|
| 16 |              TABLE ACCESS FULL            | COMPANY                    | 76111 | 1040K|       |   335 (15)|
|* 17 |              HASH JOIN                    |                            | 31649 | 3770K|       |   933   (7)|
| 18 |               TABLE ACCESS FULL           | AGREEMENT                  |   149 | 3129 |       |     3 (34)|
|* 19 |               HASH JOIN                   |                            | 31649 | 3121K|       |   928   (6)|
| 20 |                TABLE ACCESS FULL          | CONCRETEAGREEMENT          | 34172 |   333K|       |    55 (24)|
|* 21 |                TABLE ACCESS BY INDEX ROWID| SPECIFICATION              | 31649 | 2812K|       |   866   (4)|
|* 22 |                 INDEX RANGE SCAN          | SPECIFICATION_DATE         | 37437 |       |       |   143   (5)|
| 23 |             TABLE ACCESS FULL             | PERSON                     | 1786K|    47M|       | 4584 (11)|
|* 24 |            TABLE ACCESS BY INDEX ROWID    | INFORMATION                |     1 |    16 |       |     4 (25)|
|* 25 |             INDEX RANGE SCAN              | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 26 |           TABLE ACCESS BY INDEX ROWID     | INFORMATION                |     1 |    11 |       |            |
|* 27 |            INDEX RANGE SCAN               | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 28 |          TABLE ACCESS BY INDEX ROWID      | INFORMATION                |     1 |    14 |       |            |
|* 29 |           INDEX RANGE SCAN                | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 30 |         TABLE ACCESS BY INDEX ROWID       | INFORMATION                |     1 |    14 |       |            |
|* 31 |          INDEX RANGE SCAN                 | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 32 |        TABLE ACCESS BY INDEX ROWID        | INFORMATION                |     1 |    11 |       |            |
|* 33 |         INDEX RANGE SCAN                  | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 34 |       TABLE ACCESS BY INDEX ROWID         | INFORMATION                |     1 |    13 |       |            |
|* 35 |        INDEX RANGE SCAN                   | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 36 |      TABLE ACCESS BY INDEX ROWID          | INFORMATION                |     1 |    12 |       |            |
|* 37 |       INDEX RANGE SCAN                    | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 38 |     TABLE ACCESS BY INDEX ROWID           | INFORMATION                |     1 |    15 |       |            |
|* 39 |      INDEX RANGE SCAN                     | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 40 |    TABLE ACCESS BY INDEX ROWID            | INFORMATION                |     1 |    17 |       |            |
|* 41 |     INDEX RANGE SCAN                      | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
|* 42 |   TABLE ACCESS BY INDEX ROWID             | INFORMATION                |     1 |    17 |       |            |
|* 43 |    INDEX RANGE SCAN                       | INFORMATION_SPECIFICATION |     2 |       |       |     3 (34)|
---------------------------------------------------------------------------------------------------------------------                     I can see that there are some FULL TABLE SCAN, but this may be OK. What worries me is the combination with numerous NESTED LOOPS.
A CTAS for approx 500.000 records out of 14.000.000 runs in about 180 mins. This is too much. My guess is that it should/could be brought down to something like 20 min.
For completeness, the query in question:
SELECT *
FROM stik_spec_inf_v
WHERE spdate >= to_date('15-03-2008', 'dd-mm-yyyy')
   AND spdate < to_date('15-04-2008', 'dd-mm-yyyy');Wher eview is created as
CREATE OR REPLACE FORCE VIEW stik_spec_inf_v
AS
   SELECT CAST(1 AS NUMBER(3)) dataversion
         ,sp.ID AS spid
         ,sp."DATE" AS spdate
         ,sp.valuedate
         ,sp.amount
         ,sp.amountcode
         ,sp.periodstart
         ,sp.periodend
         ,sp.ambcode
         ,sp.state AS spstate
         ,sp."TYPE" AS sptype
         ,sp.respitedate
         ,sp.stopcode
         ,sp.validcode
         ,sp.person
         ,sp.company
         ,sp.concreteagreement
         ,sp.reconciliation
         ,sp.partialscheme
         ,(SELECT 1
             FROM dual
            WHERE EXISTS(
                     SELECT 1
                       FROM changelog
                      WHERE targetclass = 'com.csc.jpay.voucher.Specification'
                        AND targetid = sp.ID)) spchanged
         ,i1.startdate AS daekgagedato
         ,i1.amount AS daekgage
         ,i2.startdate AS prmgagedato
         ,i2.amount AS prmgage
         ,i3.employerpercent
         ,i3.employeepercent
         ,i3.voluntarypercent
         ,i5.salaryperiod
         ,i6.groupcontractcode
         ,i7.workinghourspercent
         ,i9.startdate AS hiringdate
         ,i10.startdate AS resignationdate
         ,i21.policenumber
         ,ix."TYPE" AS leavecode
         ,ix.startdate AS leavestartdate
         ,ix.enddate AS leaveenddate
         ,pe.cpr
         ,pe.ksdid
         ,co.opkr_number
         ,a.NAME AS agreement_name
     FROM SPECIFICATION sp
         ,information i1
         ,information i2
         ,information i3
         ,information i5
         ,information i6
         ,information i7
         ,information i9
         ,information i10
         ,information i21
         ,information ix
         ,person pe
         ,company co
         ,concreteagreement ca
         ,agreement a
    WHERE 1 = 1
      AND i1.SPECIFICATION(+) = sp.ID
      AND i1."TYPE"(+) = 1
      AND i2.SPECIFICATION(+) = sp.ID
      AND i2."TYPE"(+) = 2
      AND i3.SPECIFICATION(+) = sp.ID
      AND i3."TYPE"(+) = 3
      AND i5.SPECIFICATION(+) = sp.ID
      AND i5."TYPE"(+) = 5
      AND i6.SPECIFICATION(+) = sp.ID
      AND i6."TYPE"(+) = 6
      AND i7.SPECIFICATION(+) = sp.ID
      AND i7."TYPE"(+) = 7
      AND i9.SPECIFICATION(+) = sp.ID
      AND i9."TYPE"(+) = 9
      AND i10.SPECIFICATION(+) = sp.ID
      AND i10."TYPE"(+) = 10
      AND i21.SPECIFICATION(+) = sp.ID
      AND i21."TYPE"(+) = 21
      AND ix.SPECIFICATION(+) = sp.ID
      AND ix."TYPE"(+) > 10
      AND ix."TYPE"(+) < 21
      AND pe.ID = sp.person
      AND co.ID = sp.company
      AND ca.ID = sp.concreteagreement
      AND a.ID = ca.agreement;Please excuse my lengthy post. I still hope for some valuable input.
Thanks
Peter

Hi,
I have tried with an in-line view as John suggested. This give a FULL TABLE SCAN on information.
SELECT /*+ RULE */ * FROM (
    SELECT sp.id spid, sp."DATE" spdate
     FROM (SELECT   SPECIFICATION
                   ,max(decode("TYPE", 1, startdate)) daekgagedato
                   ,max(decode("TYPE", 1, amount)) daekgage
                   ,max(decode("TYPE", 2, startdate)) prmgagedato
                   ,max(decode("TYPE", 2, amount)) prmgage
                   ,max(decode("TYPE", 3, employerpercent)) employerpercent
                   ,max(decode("TYPE", 3, employeepercent)) employeepercent
                   ,max(decode("TYPE", 3, voluntarypercent)) voluntarypercent
                   ,max(decode("TYPE", 5, salaryperiod)) salaryperiod
                   ,max(decode("TYPE", 6, groupcontractcode)) groupcontractcode
                   ,max(decode("TYPE", 7, workinghourspercent)) workinghourspercent
                   ,max(decode("TYPE", 9, startdate)) hiringdate
                   ,max(decode("TYPE", 10, startdate)) resignationdate
                   ,max(decode("TYPE", 21, policenumber)) policenumber
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, "TYPE"))) leavecode
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, startdate))) leavestartdate
                   ,max(decode(sign("TYPE" - 10),1, decode(sign("TYPE" - 21), -1, enddate))) leaveenddate
               FROM information
              WHERE TYPE BETWEEN 1 AND 21
           GROUP BY SPECIFICATION) i
         ,SPECIFICATION sp
    WHERE 1 = 1
      AND sp.ID = i.SPECIFICATION)
WHERE spid = 1Any ideas on how to get around that?
Regards
Peter

About explain plan

Similar Messages

Maybe you are looking for