I want to understand Explain Plan

Dear Gurus,
I want learn/understand Explain Plan for query so as to tune the query.
OR I want to tune query by understanding their plan but how it help to tune query.
Could anybody give me link or material on above.
Thanking in advance
Sanjeev

If you don't want to read the Oracle documentation, then this book is excellent: Troubleshooting Oracle Performance - Christian Antognini
It does a great job of explaining execution plans.

Similar Messages

Understanding explain plan

Oracle Gurus,
I am trying to understand the below explain plan which I generated using DBMS_XPLAN. This explain plan shows 380M cost, what do "M" and "K" mean here? If anyone has any good documentation to understand explain plan, please pass on.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | INSERT STATEMENT | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
| 1 | HASH UNIQUE | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
|* 2 | FILTER | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10002 | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) |
|* 5 | HASH JOIN BUFFERED | | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | PCWP | |
| 6 | PX RECEIVE | | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 7 | PX SEND HASH | :TQ10000 | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 8 | PX BLOCK ITERATOR | | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWC | |
|* 9 | TABLE ACCESS FULL | TOP10_UL_SECTOR_LUCENT | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWP | |
| 10 | PX RECEIVE | | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10001 | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,01 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWC | |
|* 13 | TABLE ACCESS FULL | BH_UL_SECTOR_LUCENT | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWP | |
| 14 | SORT AGGREGATE | | 1 | 14 | | | | | | | |
| 15 | PARTITION RANGE ITERATOR| | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
|* 16 | INDEX SKIP SCAN | IDX2_BH_UL_SECTOR_LUCENT | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
-----------------------------------------------------------------------------------------------------------------------------------------------------

Hello,
Once again K is number of (1000) rows fetched and M is for bytes repsentation. Check this oracle doc for reading xplan
Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
Regards

Need help understanding Explain Plan from 10046 trace

Below is a query and Explain Plan from a 10046 trace shown with trcanlzr.sql.
In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
SELECT cp.cred_process_id, cp.provider_id,
       brdg_credentialing.get_appl_specialist(cp.cred_process_id,'R') specialist_name,
       brdg_cred_report_pkg.provider_name(cp.cred_process_id) provider_name,
       ctc_apptype.description appl_type_desc,
       TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)) init_received_dt,
       brdg_code_util.code_descr(brdg_credentialing.get_appl_status_cd_ctc_id(cp.cred_process_id)) appl_status_desc,
       brdg_credentialing.get_appl_prac_specialties(cp.cred_process_id,'Y') primary_specialty,
       cwh.city practice_city,
       UPPER (cwh.state) practice_state,
       TRUNC (ch.event_dt) specialist_assign_dt,
       DECODE (ctc_apptype.code,'INITPPO', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'REAPP', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'SPECCRED', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'TRANS', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
               'RECPPO', p.next_recred_dt,
               'RECAPP', p.next_recred_dt, NULL) sort_date,
               p.next_recred_dt
FROM brdg_cred_app_open_vw cp,
       brdg_cat_type_codes ctc_apptype,
       brdg_cred_work_history cwh,
       brdg_cred_history ch,
       brdg_providers p
WHERE cp.type_cd_ctc_id = ctc_apptype.cat_type_code_id
   AND ctc_apptype.category_cd = 'CRED'
   AND ctc_apptype.type_cd = 'APPTYPE'
   AND cp.cred_process_id = cwh.cred_process_id (+)
   AND cwh.primary_practice_flag (+) = 'Y'
   AND cp.cred_process_id = ch.cred_process_id
   AND ch.cred_history_id = (SELECT MAX(cred_history_id)
                               FROM brdg_cred_history
                              WHERE cred_process_id = cp.cred_process_id
                                AND event_cd_ctc_id = brdg_credentialing.get_event_ctc_id ('SEVENT','SPESTCHG'))
   AND cp.provider_id = p.provider_id (+)
   and brdg_credentialing.get_appl_specialist_id(cp.cred_process_id) = 5
ORDER BY 3 ASC, 3, 5, 12, 6
        Explain Plan Operation
ID   PID    Card     Rows    Cost      SearchCols /   Indexed Cols     Predicates
0:    1                       36   SELECT STATEMENT
1:    0     1       139       36    SORT ORDER BY
2:    1             139            . FILTER   [+]
3:    2     1       311       11   .. NESTED LOOPS OUTER
4:    3     1       311       10   ... NESTED LOOPS OUTER
5:    4     1       311        9   .... NESTED LOOPS
6:    5     1       311        8   ....+ NESTED LOOPS
7:    6     4        16        1   ....+. TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
8:    7     4        16        1   ....+.. INDEX RANGE SCAN CAT_TYPE_CODE_UK 2/3 [+]   [+]
9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]
10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]
11:   10     1         3        2   ....+... NESTED LOOPS
12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]
14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]
15:    5     1        11        1   ....+ TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
16:   15     1       311        1   ....+. INDEX UNIQUE SCAN CDHT_PK 1/1 [+]   [+]
17:   16     1       311            ....+.. SORT AGGREGATE
18:   17     1       526        2   ....+... TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
19:   18    23      9950        1   ....+.... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]
20:    4     1       219        1   .... TABLE ACCESS BY INDEX ROWID PROVIDERS
21:   20     1       219        1   ....+ INDEX UNIQUE SCAN PROV_PK 1/1 [+] [+]
22:    3     1       311        1   ... TABLE ACCESS BY INDEX ROWID CRED_WORK_HISTORY   [+]
23:   22     3      1057        1   .... INDEX RANGE SCAN CDWH_CDPR_FK 1/1 [+]   [+]
24:    2   172                      .. INLIST ITERATOR
25:   24     1       172        1   ... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]
26:    2     1         0        2   .. TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]
27:   26    23      2004        1   ... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]
(1) X/Y: Where X is the number of searched columns from index, which has a total of Y columns.
(2) Actual rows returned by operation (average if there were more than 1 execution).
   2 - filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES" "BRDG_CAT_TYPE_CODES" WHERE
              "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIALING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)) AND
              ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND
              "CATEGORY_CD"='APPSTAT') AND NOT EXISTS (SELECT 0 FROM "PPO"."CRED_HISTORY" "BRDG_CRED_HISTORY"
              WHERE "CRED_PROCESS_ID"=:B2 AND "EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC
   8 - access("CTC_APPTYPE"."CATEGORY_CD"='CRED' AND "CTC_APPTYPE"."TYPE_CD"='APPTYPE')
   9 - filter("BRDG_CREDENTIALING"."GET_APPL_SPECIALIST_ID"("CP"."CRED_PROCESS_ID")=5 AND
              ("CP"."INS_DT">=TO_DATE(' 2007-12-20 17:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
              "CP"."TYPE_CD_CTC_ID"<>"BRDG_CODE_UTIL"."GET_ID"('CRED','APPTYPE','RECPPO')))
10 - access("CP"."TYPE_CD_CTC_ID"="CTC_APPTYPE"."CAT_TYPE_CODE_ID")
       filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES"
              "CTC_APPTYPE","PPO"."CAT_TYPE_CODES" "CTC_TYPE" WHERE "CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1 AND
              "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE" AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
              "CTC_APPTYPE"."CATEGORY_CD"='APPTYPE'))
13 - access("CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1)
14 - access("CTC_APPTYPE"."CATEGORY_CD"='APPTYPE' AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
              "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE")
15 - filter("CP"."CRED_PROCESS_ID"="CH"."CRED_PROCESS_ID")
16 - access("CH"."CRED_HISTORY_ID"= (SELECT MAX("CRED_HISTORY_ID") FROM "PPO"."CRED_HISTORY"
              "BRDG_CRED_HISTORY" WHERE "CRED_PROCESS_ID"=:B1 AND
              "EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG')))
18 - filter("EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG'))
19 - access("CRED_PROCESS_ID"=:B1)
21 - access("CP"."PROVIDER_ID"="P"."PROVIDER_ID"(+))
22 - filter("CWH"."PRIMARY_PRACTICE_FLAG"(+)='Y')
23 - access("CP"."CRED_PROCESS_ID"="CWH"."CRED_PROCESS_ID"(+))
25 - access("CATEGORY_CD"='APPSTAT' AND ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR
              "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIAL
              ING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)))
26 - filter("EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC'))
27 - access("CRED_PROCESS_ID"=:B1)

Welcome to the forums!
user11987210 wrote:
In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]
10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]
11:   10     1         3        2   ....+... NESTED LOOPS
12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES
13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]
14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]   The NESTED LOOPS operation (ID #11) has two children, ID #12 sometimes called the driving source, and ID #14 the inner loop. ID #14 is executed once for each row returned by ID #12. The results of ID #11 are then fed to ID #10 which performs an INDEX RANGE SCAN.
Hope this helps!

Understanding explain plan output

Hi,
Version 11202.
Bellow is the output of tkprof against a statment which has cpu time = elapsed time =~3000 sec.
The statment is related to oracle EBS , but the question bellow is regarding the execution plan.
As you can see in the plan bellow most of the time is spend on the following step :
         0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)What i am trying to understand is why 2 billions rows (2059303280) has been accessed by the index IBY_PMT_INSTR_USES_ALL_N2
SQL> select table_name,num_rows,sample_size,last_analyzed from dba_tables where table_name='IBY_PMT_INSTR_USES_ALL';
TABLE_NAME NUM_ROWS SAMPLE_SIZE LAST_ANAL
IBY_PMT_INSTR_USES_ALL 2414470 241447 28-JAN-13
SQL> select table_name,distinct_keys,clustering_factor,num_rows,sample_size,last_analyzed from dba_indexes where index_name='IBY_PMT_INSTR_USES_ALL_N2';
TABLE_NAME DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE LAST_ANAL
IBY_PMT_INSTR_USES_ALL 304515 267170 2407170 240717 28-JAN-13The whole statment and is plan is as followed :
insert into iby_pmt_instr_uses_all (instrument_payment_use_id,payment_flow,
ext_pmt_party_id,instrument_type,instrument_id,payment_function,
order_of_preference,created_by,creation_date,last_updated_by,
last_update_date,last_update_login,object_version_number,start_date,
end_date,debit_auth_flag,debit_auth_method,debit_auth_reference,
debit_auth_begin,debit_auth_end)select iby_pmt_instr_uses_all_s.nextval ,
'FUNDS_CAPTURE' ,iep.ext_payer_id ,'BANKACCOUNT' ,eba.ext_bank_account_id ,
'CUSTOMER_PAYMENT' ,DECODE(cbi.primary_flag,'Y',1,10) ,:b0 ,SYSDATE ,:b0 ,
SYSDATE ,:b2 ,1 ,cbi.start_date ,cbi.end_date ,'' ,'' ,'' ,'' ,'' from
iby_external_payers_all iep ,hz_cust_accounts hca ,hz_cust_site_uses_all
csu ,hz_cust_acct_sites_all cas ,hz_parties hzba ,hz_relationships hzr ,
hz_code_assignments hcba ,hz_parties hzbb ,hz_organization_profiles hop ,
hz_code_assignments hcbb ,iby_ext_bank_accounts eba ,
ra_customer_banks_int_all cbi where
(((((((((((((((((((((((((((((((((((((((cbi.interface_status is null and
cbi.request_id=:b3) and UPPER(cbi.bank_name)=UPPER(hzba.party_name)) and
hzba.party_id=hop.party_id) and SYSDATE between
TRUNC(hop.effective_start_date) and NVL(TRUNC(hop.effective_end_date),
(SYSDATE+1))) and hcba.class_category='BANK_INSTITUTION_TYPE') and
hcba.class_code='BANK') and hcba.owner_table_name='HZ_PARTIES') and
hcba.owner_table_id=hzba.party_id) and cbi.bank_home_country=
hop.home_country) and hzbb.party_id=hcbb.owner_table_id) and
hcbb.owner_table_name='HZ_PARTIES') and hcbb.class_category=
'BANK_INSTITUTION_TYPE') and hcbb.class_code='BANK_BRANCH') and
nvl(hcbb.status,'A')='A') and hzbb.party_id=hzr.subject_id) and
hzba.party_id=hzr.object_id) and hzr.relationship_type='BANK_AND_BRANCH')
and hzr.relationship_code='BRANCH_OF') and hzr.status='A') and
hzr.subject_table_name='HZ_PARTIES') and hzr.subject_type='ORGANIZATION')
and hzr.object_table_name='HZ_PARTIES') and hzr.object_type='ORGANIZATION')
and UPPER(cbi.bank_branch_name)=UPPER(hzbb.party_name)) and hzbb.party_id=
eba.branch_id) and hzba.party_id=eba.bank_id) and eba.bank_account_num=
cbi.bank_account_num) and eba.currency_code=cbi.bank_account_currency_code)
and cbi.orig_system_customer_ref=hca.orig_system_reference) and
iep.cust_account_id=hca.cust_account_id) and iep.party_id=hca.party_id) and
((cbi.orig_system_address_ref is null and iep.org_id is null ) or
iep.org_id=cbi.org_id)) and ((cbi.orig_system_address_ref is null and
iep.org_type is null ) or iep.org_type='OPERATING_UNIT')) and cbi.org_id=
cas.org_id(+)) and nvl(iep.acct_site_use_id,(-1))=
decode(cbi.orig_system_address_ref,null ,(-1),csu.site_use_id)) and
cbi.orig_system_address_ref=cas.orig_system_reference(+)) and
(csu.site_use_id=(select min(site_use_id) from hz_cust_site_uses_all hcsua
where ((hcsua.cust_acct_site_id=cas.cust_acct_site_id and
hcsua.site_use_code='BILL_TO') and hcsua.status='A')) or csu.site_use_id is
null )) and cas.cust_acct_site_id=csu.cust_acct_site_id(+)) and not exists
(select 'x' from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
'CUSTOMER_PAYMENT')))
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1   3049.58    3080.23      31827   44696023       1587        1175
Fetch        0      0.00       0.00          0          0          0           0
total        2   3049.58    3080.23      31827   44696023       1587        1175
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 57 (APPS)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         0          0          0 LOAD TABLE CONVENTIONAL (cr=44696030 pr=31827 pw=0 time=2870820188 us)
      1175       1175       1175   SEQUENCE IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
      1175       1175       1175    FILTER (cr=44695960 pr=31774 pw=0 time=3270803657 us)
      1175       1175       1175     NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
      1175       1175       1175      NESTED LOOPS (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
      1175       1175       1175       NESTED LOOPS (cr=64827 pr=205 pw=0 time=2949382 us cost=245 size=423 card=1)
      1175       1175       1175        NESTED LOOPS OUTER (cr=63494 pr=205 pw=0 time=2921176 us cost=243 size=403 card=1)
      1175       1175       1175         NESTED LOOPS (cr=63377 pr=205 pw=0 time=2893312 us cost=240 size=391 card=1)
      1175       1175       1175          NESTED LOOPS (cr=61415 pr=205 pw=0 time=2850064 us cost=236 size=348 card=1)
     47434      47434      47434           NESTED LOOPS (cr=57058 pr=205 pw=0 time=2565056 us cost=234 size=328 card=1)
     41203      41203      41203            NESTED LOOPS OUTER (cr=42422 pr=0 pw=0 time=581594 us cost=230 size=296 card=1)
     41203      41203      41203             HASH JOIN (cr=1049 pr=0 pw=0 time=173751 us cost=229 size=277 card=1)
      2333       2333       2333              NESTED LOOPS (cr=1013 pr=0 pw=0 time=32850 us)
      2333       2333       2333               NESTED LOOPS (cr=825 pr=0 pw=0 time=22036 us cost=208 size=172 card=1)
       514        514        514                NESTED LOOPS (cr=691 pr=0 pw=0 time=16378 us cost=206 size=88 card=1)
       514        514        514                 NESTED LOOPS (cr=588 pr=0 pw=0 time=7190 us cost=95 size=2501 card=41)
       514        514        514                  TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=20 pr=0 pw=0 time=1716 us cost=10 size=1681 card=41)
       514        514        514                   INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_N1 (cr=7 pr=0 pw=0 time=464 us cost=4 size=0 card=164)(object id 464630)
       514        514        514                  TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=568 pr=0 pw=0 time=2797 us cost=2 size=20 card=1)
       514        514        514                   INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=54 pr=0 pw=0 time=1059 us cost=1 size=0 card=1)(object id 421661)
       514        514        514                 TABLE ACCESS BY INDEX ROWID HZ_ORGANIZATION_PROFILES (cr=103 pr=0 pw=0 time=5913 us cost=3 size=27 card=1)
       514        514        514                  INDEX RANGE SCAN BZ_HZ_ORGANIZATION_PROFILE_N1 (cr=76 pr=0 pw=0 time=2873 us cost=2 size=0 card=1)(object id 9378840)
      2333       2333       2333                INDEX RANGE SCAN HZ_RELATIONSHIPS_N2 (cr=134 pr=0 pw=0 time=3962 us cost=1 size=0 card=1)(object id 11581198)
      2333       2333       2333               TABLE ACCESS BY INDEX ROWID HZ_RELATIONSHIPS (cr=188 pr=0 pw=0 time=7476 us cost=2 size=84 card=1)
      1175       1175       1175              TABLE ACCESS FULL RA_CUSTOMER_BANKS_INT_ALL (cr=36 pr=0 pw=0 time=9479 us cost=21 size=123375 card=1175)
     41203      41203      41203             TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=41373 pr=0 pw=0 time=304952 us cost=1 size=19 card=1)
     41203      41203      41203              INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U2 (cr=170 pr=0 pw=0 time=93830 us cost=1 size=0 card=1)(object id 421730)
     47434      47434      47434            TABLE ACCESS BY INDEX ROWID IBY_EXT_BANK_ACCOUNTS (cr=14636 pr=205 pw=0 time=2375333 us cost=4 size=32 card=1)
     47434      47434      47434             INDEX RANGE SCAN IBY_EXT_BANK_ACCOUNTS_N6 (cr=3548 pr=94 pw=0 time=1112297 us cost=2 size=0 card=1)(object id 14313177)
      1175       1175       1175           TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=4357 pr=0 pw=0 time=171450 us cost=2 size=20 card=1)
      1203       1203       1203            INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=3154 pr=0 pw=0 time=107886 us cost=1 size=0 card=1)(object id 421661)
      1175       1175       1175          TABLE ACCESS BY INDEX ROWID HZ_CODE_ASSIGNMENTS (cr=1962 pr=0 pw=0 time=41107 us cost=3 size=43 card=1)
      1175       1175       1175           INDEX RANGE SCAN HZ_CODE_ASSIGNMENTS_U2 (cr=1611 pr=0 pw=0 time=25716 us cost=2 size=0 card=1)(object id 14355645)
      1175       1175       1175         TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=117 pr=0 pw=0 time=14875 us cost=3 size=12 card=1)
      1175       1175       1175          INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=86 pr=0 pw=0 time=10600 us cost=2 size=0 card=1)(object id 464289)
      1175       1175       1175        TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=1333 pr=0 pw=0 time=22634 us cost=2 size=20 card=1)
      1175       1175       1175         INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U3 (cr=158 pr=0 pw=0 time=9307 us cost=1 size=0 card=1)(object id 9438627)
      1175       1175       1175       TABLE ACCESS BY INDEX ROWID IBY_EXTERNAL_PAYERS_ALL (cr=125 pr=12 pw=0 time=131366 us cost=3 size=34 card=1)
      1175       1175       1175        INDEX RANGE SCAN IBY_EXTERNAL_PAYERS_ALL_U2 (cr=109 pr=4 pw=0 time=51266 us cost=2 size=0 card=1)(object id 14313089)
         0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
      1000       1000       1000     SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
      1000       1000       1000      TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
      1000       1000       1000       INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)

Yoav wrote:
and not exists
(select 'x' from iby_pmt_instr_uses_all ipi where (((ipi.ext_pmt_party_id=
iep.ext_payer_id and ipi.instrument_type='BANKACCOUNT') and
ipi.instrument_id=eba.ext_bank_account_id) and ipi.payment_function=
'CUSTOMER_PAYMENT')))
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0          0          0 LOAD TABLE CONVENTIONAL (cr=44696030 pr=31827 pw=0 time=2870820188 us)
1175       1175       1175   SEQUENCE IBY_PMT_INSTR_USES_ALL_S (cr=44695967 pr=31774 pw=0 time=3270855802 us)
1175       1175       1175    FILTER (cr=44695960 pr=31774 pw=0 time=3270803657 us)
1175       1175       1175     NESTED LOOPS ANTI (cr=44695844 pr=31774 pw=0 time=3270739008 us cost=251 size=497 card=1)
1175       1175       1175      NESTED LOOPS (cr=64952 pr=217 pw=0 time=2991575 us cost=248 size=457 card=1)
0          0          0      TABLE ACCESS BY INDEX ROWID IBY_PMT_INSTR_USES_ALL (cr=44630892 pr=31557 pw=0 time=3075553107 us cost=3 size=95402360 card=2385059)
2059303280 2059303280 2059303280       INDEX RANGE SCAN IBY_PMT_INSTR_USES_ALL_N2 (cr=13320705 pr=104 pw=0 time=1459328515 us cost=2 size=0 card=8)(object id 14313388)
1000       1000       1000     SORT AGGREGATE (cr=116 pr=0 pw=0 time=39211 us)
1000       1000       1000      TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=116 pr=0 pw=0 time=27041 us cost=4 size=22 card=1)
1000       1000       1000       INDEX RANGE SCAN HZ_CUST_SITE_USES_N1 (cr=85 pr=0 pw=0 time=19027 us cost=3 size=0 card=1)(object id 464289)
You have a "not exists" subquery that the optimizer has turned into a nested loop anti join.
For each of the 1175 rows returned by the previous step Oracle does a range scan of what it thinks is the most appropriate index - the figures for cost (2) and card (8) at that line show that something has gone wrong with the optimizer's estimates, and for each of the 1175 prior rows it has acquired an average 1.7M index entries based on the index predicates, then visited the table and discarded resulting row.
It looks as if the index is a bad choice of index - you need to check the index predicates for the plan - use dbms_xplan to pull it from memory; and check your indexes to see if there is a better one that the optimizer should have chosen
Regards
Jonathan Lewis

Help me in reading/understanding Explain Plan

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
SELECT SRC2.PGM_MSTR_NBR,
                                              SRC2.PGM_TRK_NBR,
                                              SRC2.CNTL_LOCN,
                                              SRC2.PGM_NAME,
                                              SRC2.PGM_STS,
                                              SRC2.SIS_PGM_START_DATE,
                                              SRC2.SIS_PGM_END_DATE,
                                              SRC2.AWARD_TRGT,
                                              SRC2.AWARD_MAX,
                                              SRC2.COMPLNC_TYPE,
                                              SRC2.CMPNY_VNDR_LOCN,
                                              SRC2.CMPNY_VNDR_NBR,
                                              LKP3.ADDR_NAME,
                                              SRC2.INV_IND,
                                              SRC2.LAST_INV_THRU_DATE,
                                              SRC2.INV_RPT_DAY,
                                              SRC2.INV_RPT_CYCLE,
                                              SRC2.BEG_COLL_DATE,
                                              SRC2.END_COLL_DATE,
                                              SRC2.SLS_CONT_DIST,
                                              SRC2.SLS_CONT_NBR,
                                              SRC2.ORD_INV_START_DATE,
                                              SRC2.ORD_INV_END_DATE,
                                              SRC2.CMPLNC_RPT_IND,
                                              SRC2.PROD_ENTRY_LVL,
                                              SRC2.DIST_ENTRY_LVL,
                                              SRC2.CUST_ENTRY_LVL,
                                              SRC2.VNDR_ENTRY_LVL,
                                              SRC2.VNDR_CONT,
                                              SRC2.SIS_CMPNY_VNDR_NBR
                                              FROM CASADM.SBA_REB_PGM SRC2
                                              INNER JOIN(SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN FROM CASADM.ACCR_SIS_PURCH_DTL
                                                         UNION SELECT PGM_MSTR_NBR,PGM_TRK_NBR,CNTL_LOCN FROM CASADM.ACCR_SIS_EXCL_DTL)ACCR2
                                                    ON (SRC2.PGM_MSTR_NBR=ACCR2.PGM_MSTR_NBR AND SRC2.PGM_TRK_NBR=ACCR2.PGM_TRK_NBR AND SRC2.CNTL_LOCN=ACCR2.CNTL_LOCN)
                                              LEFT OUTER JOIN
                                                        CASADM.MT_CMPNY_VNDR LKP3
                                                    ON (LKP3.CMPNY_VNDR_NBR=SRC2.CMPNY_VNDR_NBR);
Record Count in each table:
select count(*) from casadm.accr_sis_purch_dtl --375,968
select count(*) from casadm.accr_sis_excl_dtl --1,988,867
select count(*) from casadm.sba_reb_pgm --526,133
select count(*) from casadm.mt_cmpny_vndr --20743
Execution Plan
Plan hash value: 1465316812
| Id | Operation                    | Name                  | Rows | Bytes |TempSpc| Cost (%CPU)| Time|
|   0 | SELECT STATEMENT             |                       |     9 | 1908 | | 26988   (2)| 00:06:18 |
|   1 | NESTED LOOPS OUTER          |                       |     9 | 1908 | | 26988   (2)| 00:06:18 |
|* 2 |   HASH JOIN                  |                       |     9 | 1656 |83M| 26979   (2)| 00:06:18|
|   3 |    TABLE ACCESS FULL         | SBA_REB_PGM           |   536K|    77M| | 2624   (2)| 00:00:37 |
|   4 |    VIEW                      |                       | 2364K|    74M| | 16424   (2)| 00:03:50 |
|   5 |     SORT UNIQUE              |                       | 2364K|    49M|72M| 16424 (86)| 00:03:50|
|   6 |      UNION-ALL               |                       |       |       ||            |          |
|   7 |       INDEX FAST FULL SCAN   | ACCR_SIS_PURCH_DTL_PK |   375K| 8077K||   871   (1)| 00:00:13 |
|   8 |       TABLE ACCESS FULL      | ACCR_SIS_EXCL_DTL     | 1988K|    41M|| 5634   (1)| 00:01:19 |
|   9 |   TABLE ACCESS BY INDEX ROWID| MT_CMPNY_VNDR         |     1 |    28 | |     1   (0)| 00:00:01 |
|* 10 |    INDEX UNIQUE SCAN         | MT_CMPNY_VNDR_PK      |     1 |       | |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"=
"ACCR2"."CNTL_LOCN")
10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")
Statistics
        102 recursive calls
          0 db block gets
      34558 consistent gets
      23241 physical reads
         88 redo size
     531258 bytes sent via SQL*Net to client
       2760 bytes received via SQL*Net from client
        361 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
       5392 rows processed

With respect to HASH JOIN it has two operands a TABLE ACCESS FULL and VIEW. Oracle joins these results together based on the following access predicate:
2 - access("SRC2"."PGM_MSTR_NBR"="ACCR2"."PGM_MSTR_NBR" AND
              "SRC2"."PGM_TRK_NBR"="ACCR2"."PGM_TRK_NBR" AND "SRC2"."CNTL_LOCN"="ACCR2"."CNTL_LOCN")The VIEW is the result of the union between the CASADM.ACCR_SIS_PURCH_DTL and CASADM.ACCR_SIS_EXCL_DTL where instead of accessing the table CASADM.ACCR_SIS_PURCH_DTL Oracle was able to acquire all the data from the index ACCR_SIS_PURCH_DTL_PK .
The TABLE ACCESS FULL is exactly what says a full table access of SBA_REB_PGM.
The NESTED LOOPS OUTER has two operands like the HASH JOIN. The way this works is that for each result returned by the HASH JOIN operation it accesses the index MT_CMPNY_VNDR_PK and then the table MT_CMPNY_VNDR based on the following access predicate:
10 - access("LKP3"."CMPNY_VNDR_NBR"(+)="SRC2"."CMPNY_VNDR_NBR")It'd probably be worthwhile for you to review the following paper by Christian Antognini Interpreting Execution Plans as well.

Explain Plan understand technique & Query optimizing check list

Hello gurus,
Can some body help me with doc available or your experience to tell on how to understand Explain Plan & Query optimizing check list.
Thanks..

That's correct,
But unfortunately the institute is pretty far from home.. and travelling time will be high..
I am a working man..
Please suggest if some good book or link.
Thanks.

Understanding of Explain plan

Hi all,
Could you please provide me any article on how to read and understand the complete explain plan by step by step?
I am not much familiar with expalin paln.
Wolud be appreciated your help !!
Regards,
Vissu...
Edited by: vissu on Aug 10, 2010 2:13 AM

[ | http://www.lmgtfy.com/?q=Understanding+explain+plans+in+oracle+10g]
[| http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm]

Question regarding using of Explain Plan

Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
I am using Oracle 9i as back end .
Please tell me how can i use feature of Explain Plan Feature for the below query.
SELECT * FROM emp WHERE empno = 7369
Thanks in advance.

[email protected] wrote:
Hi. I'm new with Oracle Queries so I have a little obstacles about understanding. I want to learn how to use Explain Plan feature from Oracle
I am using Oracle 9i as back end .
Please tell me how can i use feature of Explain Plan Feature for the below query.
SELECT * FROM emp WHERE empno = 7369
Kiran,
Firstly , before anything else, I would suggest to change your handle to anything else and remove the email id from it. Its not good to have the id displayed in any public forum.
About the question, unfortunately, its not that easy to answer. To understand explain plan and how to use it, you need to understand that algorithm/mechanism, whatever you feel like saying, that generates it. Because, explain plan is just the outcome of that mechanism, a final product, its the result of some inputs given by you in the form of your query, predicates, joins and their types and that all bring up the explain plan. Explain plan is basically the constitution of some steps which are used /fixed by optimizer to run the query. I would suggest that you read this page from cover to cover to understand some of the steps and their meanings which are shown to you in the plan. I am giving 10g link as this is a more better version of optimizer than the previous ones and I would suggest you to do experiments on 10g only.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i21299
And I would suggest that you collect these following books and start reading them. I haven't yet found any thing better than these books.
[Cost Based Oracle Fundamentals (Jonathan Lewis)|http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Experts-Voice/dp/1590596366]
[Troubleshooting Oracle Performance(Christian Antognini )|http://www.amazon.com/Troubleshooting-Oracle-Performance-Christian-Antognini/dp/1590599179/ref=sr_1_1?ie=UTF8&s=books&qid=1240078634&sr=1-1]
[Effectuve Oracle By Design(Tom Kyte)|http://www.amazon.com/Effective-Oracle-Design-Osborne-ORACLE/dp/0072230657/ref=sr_1_1?ie=UTF8&s=books&qid=1240078698&sr=1-1]
It would be real long journey before the mazes of optimizer and explain would be clear so make sure you have patience as well.
HTH
Aman....

Running explain plan on a prepared statement

I'm using IBatis to run queries against an Oracle database. IBatis runs the queries as prepared statements. I want to run explain plan on the prepared statements.
I already have a shim -- a proxy java.sql.Connection object -- that takes the SQL used to create a prepared statement (e.g., "select a, b, c from table d where c = ?"), returns a proxy java.sql.PreparedStatement, and then on the PreparedStatement's execute(), interpolates the bound parameters into the SQL statement, and runs Explain Plan on that (e.g, preparedStatement.setInt(5) is called, followed by preparedStatement.execute(), which results in my proxy running "explain plan for select a, b, c from table d where c = 5;")
Using Spring configuration, I can transparently insert the shim and get explain plans for all queries run through that Connection.
The problem is this: I'm explaining the plan for the SQL with the bound parameters, not necessarily the SQL run for the prepared statement.
Assume that in the above example, there exists an index on column c in table d, and that 5% of d's rows have the value 1, 15% have the value 2, and 80% have the value 3.
For "select a, b, c from table d where c = 1", Oracle will use the index. But for "select a, b, c from table d where c = 3", Oracle will do a full table scan.
What I want to know is what Oracle will do for "select a, b, c from table d where c = ?" when "?" is an unknown, arbitrary value subsequently bound to 1 or to 3.
As I understand it, the query plan for a prepared statement is done once, when the prepared statement is created. At execute time (as I understand it), the query plan is not reformulated based on the actual bound values (though partition pruning is recalculated).
So how can I find out what query plan is actually be used for prepred statement?
Thanks.

I already have a shim -- a proxy java.sql.Connection object -- that takes the SQL used to create a prepared statement I believe explain plan is part of PL/SQL rather than external to it.
As such you can pass it via a prepared statement. It is just a matter of getting the syntax correct. And of course collecting the result.
The syntax is going to be be something like the following. You would use it just like you use the existing sql.
begin
select ... from ... where c = ?;
endThe result might be returned a result sets (plural). If so you would need to code appropriately for that.

Explain plan--Object not found error

Hi All,
I want to use 'explain plan' to optimise the query.
How do i see the explain plan in toad.
when i say
explain plan set statement_id='XX' for select stmt;
select * from explain plan
where statement_id='XX';
iam geeting object not found
what parameters i need to set up before using explain plan
Please give me details.
Please suggest.
Thanks.

This should have been in TOAD Forum :-)).. Anyway,
You need to set the plan table name in view->Options->Oracle. If the specified plan table doesnt exist, create the plan table

Explain plan for running query

Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
Shareef

912856 wrote:
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
ShareefYOu can also use dbms_xplain to generate plan used in v$sql. like for example
SQL>SELECT SQL_ID, CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select * from em%';
SQL_ID CHILD_NUMBER
6kd5fkqdjb8fu 0
SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('6kd5fkqdjb8fu',0,'ALLSTATS'));If you need the actual tuntime statistics used by sql statement then you need to put hint /*+ gather_plan_statistics */ in sql ststement, something like
select /*+ gather_plan_statistics */ * from emp;
and then generate the explain plan for this
Have a look
http://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

Understanding the COST column of an explain plan

Hello,
I executed the following query, and obtained the corresponding explain plan:
select * from isis.clas_rost where cour_off_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS               2     10     1540
TABLE ACCESS BY INDEX ROWID     ISIS     CLAS_ROST     2     10     1540
INDEX RANGE SCAN     ISIS     CLAS_ROST_N2     1 10
I don't understand how these cost values add up. What is the significance of the cost in each row of the explain plan output?
By comparison, here is another plan output for the following query:
select * from isis.clas_rost where clas_rost_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS               1     1     154
TABLE ACCESS BY INDEX ROWID     ISIS     CLAS_ROST     1     1     154
INDEX UNIQUE SCAN     ISIS     CLAS_ROST_U1     1 1
Thanks!

For the most part, you probably want to ignore the cost column. The cardinality column is generally what you want to pay attention to.
Ideally, the cost column is Oracle's estimate of the amount of work that will be required to execute a query. It is a unitless value that attempts to combine the cost of I/O and CPU (depending on the Oracle version and whether CPU costing is enabled) and to scale physical and logical I/O appropriately). As a unitless number, it doesn't really relate to something "real" like the expected number of buffer gets. It is also determined in part by initialization parameters,session settings, system statistics, etc. that may artificially increase or decrease the cost of certain operations.
Beyond that, however, cost is problematic because it is only as accurate as the optimizer's estimates. If the optimizer's estimates are accurate, that implies that the cost is reasonably representative (in the sense that a query with a cost of 200 will run in less time than a query with a cost of 20000). But if you're looking at a query plan, it's generally because you believe there may be a problem which means that you are inherently suspicious that some of the optimizer's estimates are incorrect. If that's the case, you should generally distrust the cost.
Justin

Understanding CBO decisions, explain plan instability

Hi,
I have a situation where the explain plan for a SELECT statement changes
and performance takes a turn for the worse. The statement in question
executes well and has the desired explain plan but after an insertion
having a new eventtype ID the explain plan changes (doing lots of IO)
and remains bad until the SGA is flushed.
I would really like to know how to figure out how the CBO makes its
decisions and why it changes its mind over a 2min period. Any pointers
to get me started would be greatly appreciated.
Table has columns C_ID, R_ID, EVENTTYPE, ...
Regular indexes on (R_ID,C_ID) and EVENTTYPE.
The SELECT runs well as long as the compound index is used first
and runs poorly once a new EVENTTYPE is introduced (there are
approx 10 event types and a new one is being introduced) and its
index consulted first.
Thansk,
Darren

Delayed block cleanout really confused me. I don't see how
the details of block updates, SCNs and what is on disk relates
to explain plans and a SQL statement that changes from
performing well using the intended index to poorly using an index
on a column having low cardinality.
The SQL is actually quite trivial and a merely a lookup on this
single table.
SELECT * FROM table
WHERE c_id = :1 and r_id = :2 and eventtype = :3
Most of the time Oracle uses the intended index (r_id, c_id) and
performs well. As long as both columns are used in the condition
I don't think that ordering of them is an issue.
If the CBO uses stats which get updated nightly after sufficient
changes to the table then how can a statement change its execution
plans (for the same user) following a addition of a row having a
new EVENTTYPE value over a 2min period.
That is the reason that I want to see/understand what the CBO
is doing.
It turns out that adding a new index (C_ID, R_ID, EVENTTYPE) was
the bandaid needed to fix the problem but I'd like to get rid of
it if its not needed.
I'll look at these posts and try to get the differing plans back.
At this point I'll need to drop the new index and break the app
again and might receive some resistance to that.
Thanks for your input,
Darren

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

Understand the output of explain plan

I am trying to understand the output of explain plan. I have 2 plans below and don't understand it completely.
In below SQL I would expect optimizer to fetch "ROWNUM < 500" first and then do the outer join. But below explain plan doesn't list it as No. 1. So I don't really understand how to intepret the sequence from the explain plan:
select TASK0_.TASK_ID from
( select TASK0_.TASK_ID from
( select task0_.task_id from task task0_) TASK0_ where ROWNUM < 500 ) TASK0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_transmission_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
PLAN_TABLE_OUTPUT
Plan hash value: 707970537
| Id | Operation                    | Name                     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                          |   499 | 19461 | 1042   (6)| 00:00:13 |
|* 1 | HASH JOIN OUTER             |                          |   499 | 19461 | 1042   (6)| 00:00:13 |
|* 2 |   HASH JOIN OUTER            |                          |   499 | 16966 |   757   (6)| 00:00:10 |
|   3 |    NESTED LOOPS OUTER        |                          |   499 | 14471 |   589   (4)| 00:00:08 |
|   4 |     NESTED LOOPS OUTER       |                          |   499 | 12475 |   588   (4)| 00:00:08 |
|   5 |      NESTED LOOPS OUTER      |                          |   499 | 10479 |   588   (4)| 00:00:08 |
|   6 |       NESTED LOOPS OUTER     |                          |   499 | 8982 |   588   (4)| 00:00:08 |
|   7 |        VIEW                  |                          |   499 | 2495 |   588   (4)| 00:00:08 |
|* 8 |         COUNT STOPKEY        |                          |       |       |            |          |
|   9 |          INDEX FAST FULL SCAN| PK_TASK                  |   697K| 3403K|   588   (4)| 00:00:08 |
|* 10 |        INDEX UNIQUE SCAN     | PK_r_TRANSMISSION |     1 |    13 |     0   (0)| 00:00:01 |
|* 11 |       INDEX UNIQUE SCAN      | PK_b_a_TASK          |     1 |     3 |     0   (0)| 00:00:01 |
|* 12 |      INDEX UNIQUE SCAN       | PK_s_ERROR_TASK     |     1 |     4 |     0   (0)| 00:00:01 |
|* 13 |     INDEX UNIQUE SCAN        | PK_i_TASK    |     1 |     4 |     0   (0)| 00:00:01 |
| 14 |    INDEX FAST FULL SCAN      | PK_o_TASK           |   347K| 1695K|   161   (6)| 00:00:02 |
| 15 |   INDEX FAST FULL SCAN       | PK_f_MESSAGE        |   392K| 1917K|   276   (4)| 00:00:04 |
Predicate Information (identified by operation id):
   1 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))
   2 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
   8 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
In below SQL I expect rownum to be applied at the end but it gets applied first:
select * from ( select TASK0_.TASK_ID from ( select task0_.task_id from task task0_
left outer join f_message_task task0_1_ on task0_.task_id=task0_1_.task_id
left outer join b_a_task task0_2_ on task0_.task_id=task0_2_.task_id
left outer join i_task task0_3_ on task0_.task_id=task0_3_.task_id
left outer join o_task task0_4_ on task0_.task_id=task0_4_.task_id
left outer join r_t_task task0_5_ on task0_.task_id=task0_5_.task_id
left outer join s_error_task task0_6_ on task0_.task_id=task0_6_.task_id
) TASK0_ where ROWNUM < 500 ) TASK0_;
PLAN_TABLE_OUTPUT
Plan hash value: 673345378
| Id | Operation                    | Name                     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                          |   499 | 6487 |   507   (1)| 00:00:07 |
|   1 | VIEW                        |                          |   499 | 6487 |   507   (1)| 00:00:07 |
|* 2 |   COUNT STOPKEY              |                          |       |       |            |          |
|   3 |    NESTED LOOPS OUTER        |                          |   501 | 19539 |   507   (1)| 00:00:07 |
|   4 |     NESTED LOOPS OUTER       |                          |   501 | 17034 |     5 (20)| 00:00:01 |
|   5 |      NESTED LOOPS OUTER      |                          |   501 | 15030 |     5 (20)| 00:00:01 |
|   6 |       NESTED LOOPS OUTER     |                          |   501 | 13026 |     5 (20)| 00:00:01 |
|   7 |        NESTED LOOPS OUTER    |                          |   501 | 11523 |     5 (20)| 00:00:01 |
|   8 |         NESTED LOOPS OUTER   |                          |   501 | 5010 |     5 (20)| 00:00:01 |
|   9 |          INDEX FAST FULL SCAN| PK_TASK                  |   499 | 2495 |     2   (0)| 00:00:01 |
|* 10 |          INDEX UNIQUE SCAN   | PK_o_TASK           |     1 |     5 |     1   (0)| 00:00:01 |
|* 11 |         INDEX UNIQUE SCAN    | PK_r_T |     1 |    13 |     0   (0)| 00:00:01 |
|* 12 |        INDEX UNIQUE SCAN     | PK_b_a_TASK          |     1 |     3 |     0   (0)| 00:00:01 |
|* 13 |       INDEX UNIQUE SCAN      | PK_s_ERROR_TASK     |     1 |     4 |     0   (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN       | PK_i_TASK    |     1 |     4 |     0   (0)| 00:00:01 |
|* 15 |     INDEX UNIQUE SCAN        | PK_f_MESSAGE        |     1 |     5 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(ROWNUM<500)
10 - access("TASK0_"."TASK_ID"="TASK0_4_"."TASK_ID"(+))
11 - access("TASK0_"."TASK_ID"="TASK0_5_"."TASK_ID"(+))
12 - access("TASK0_"."TASK_ID"="TASK0_2_"."TASK_ID"(+))
13 - access("TASK0_"."TASK_ID"="TASK0_6_"."TASK_ID"(+))
14 - access("TASK0_"."TASK_ID"="TASK0_3_"."TASK_ID"(+))
15 - access("TASK0_"."TASK_ID"="TASK0_1_"."TASK_ID"(+))Edited by: user628400 on Feb 20, 2009 12:14 PM
Edited by: user628400 on Feb 20, 2009 12:15 PM

Please read the FAQ: http://forums.oracle.com/forums/help.jspa
And learn how to post code and explain plans using the tags.

I want to understand Explain Plan

Similar Messages

Maybe you are looking for