Understanding explain plan

Hi gurus

I try to explain the plan and referring to the link that http://docs.oracle.com/database/121/TGSQL/tgsql_interp.htm#TGSQL277understand/learn, see below for more details:

1st step

EXPLAIN PLAN

SET statement_id = "ex_plan1" FOR

SELECT phone_number

Employees

WHERE phone_number AS 650% ';

step 2

SELECT PLAN_TABLE_OUTPUT

TABLE (DBMS_XPLAN. DISPLAY (NULL, 'ex_plan1', 'BASIC'));

Output

PLAN_TABLE_OUTPUT

Hash value of plan: 1445457117

---------------------------------------

| ID | Operation | Name |

---------------------------------------

|   0 | SELECT STATEMENT |           |

|   1.  TABLE ACCESS FULL | EMPLOYEES |

---------------------------------------

If you have watched the plan explained above then in operation, he leads shows TABLE ACCESS FULL.

Let's see now another for we explain with other data, see below

Step 3

EXPLAIN PLAN

SET statement_id = "ex_plan2" FOR

SELECT last_name

Employees

WHERE name LIKE '% Pe;

Step 4

SELECT PLAN_TABLE_OUTPUT

TABLE (DBMS_XPLAN. DISPLAY (NULL, 'ex_plan2', 'BASIC'));

Output

PLAN_TABLE_OUTPUT

Hash value of plan: 3085132068

----------------------------------------

| ID | Operation | Name |

----------------------------------------

|   0 | SELECT STATEMENT |             |

|   1.  INDEX RANGE SCAN | EMP_NAME_IX |

----------------------------------------

First Question:
When I run the sql below:

SELECT phone_number

Employees

WHERE phone_number AS 650% ';

so why does it display FULL TABLE ACCESS

on the other hand, when I have executed under SQL:

SELECT last_name

Employees

WHERE name LIKE '% Pe;

so why it shows INDEX RANGE SCAN even the two queries by using like operator.

2nd question

In step 4 in the section operation, what is the meaning of the INDEX RANGE SCAN?

3rd issue

In step 4, under the name of topic, what is the meaning of EMP_NAME_IX?

Thanks in advance

Concerning

Shu


All this would be in the documentation.

The second query uses a different plan because there was a clue on last_name.

Index range scan is exactly what it sounds like - it scans the index to find the appropriate values

emp_name_ix is the name of the index that it scans.

Tags: Database

Similar Questions

  • Need help with understanding explain plan

    Hi all

    I'm trying to understand the subject of the explain Plan, and while I was reading a document and from there I found one of the query that is below:

    Query

    SELECT A.customer_name,

    Count (distinct b.invoice_id) 'open invoices. "

    Count (c.invoice_id) "open invoice".

    Clients has,

    b invoices,

    c invoices_items

    WHERE b.invoice_status = 'OPEN'

    AND A.customer_id = b.customer_id

    AND c.invoice_id (+) = b.invoice_id

    A.customer_name GROUP

    Explain Plan

    See attached file...

    explain_plan.JPG

    I appreciate if someone explain this attached plan really explain in detail for my purpose of learning. Thanks in advance

    Concerning

    Muzz

    I'm trying to understand the subject of the explain Plan

    Excellent!

    I suggest you just started reading the book of Maria Colgan white "Explain the explain Plan".

    http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

    This white paper examines the different lines, you will see in a plan and what they mean.

  • Understanding explain plan output

    Hello
    Version 11202.
    Below is the output from tkprof against a statement that time cpu = time elapsed = ~ 3000 s.
    The statement is related to oracle EBS, but the bellows of the question is in what regards the execution plan.
    As you can see in the bellows of diet most of the time is to take the next 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'm trying to understand is why lines 2b (2059303280) has been consulted by 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-13
    The entire statement and plan is as follows:
    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 subquery "does not exist" that the optimizer turned in a nested loop join anti.

    For each of the 1175 lines returned by the previous step that oracle did a scan of interval it considers the most appropriate index - numbers cost (2) and map (8) at this show of line shot something went wrong with the optimizer, and estimates for each of the prior lines 1175, he gained an average 1.7 M entries index based on the predicates of the index then went to the table and put at the disposal of the resulting line.

    It seems that if the index is a bad choice of index - you need to check the predicates of index for the plan - dbms_xplan allows you to remove it from memory; and check your clues to whether there is a better one than the optimizer should have chosen

    Concerning
    Jonathan Lewis

  • Unable to understand the Plan to explain

    Hi gurus

    I'm trying to understand some basics of explain plan and get a hard time, I was reading the book tuning performance and incapable of understanding explain plan for the following query:

    Example query

    EXPLAIN PLAN FOR

    SELECT *.

    WCP

    WHERE THERE IS NOT (SELECT 0

    OF THE Department

    WHERE dept.dname = 'SALES' AND dept.deptno = emp.deptno)

    AND NOT EXISTS (SELECT 0

    Bonus OF

    WHERE bonus.ename = emp.ename);

    -------------------

    Select * from table (dbms_xplan.display);

    ---------------

    Output

    Hash value of plan: 734347697

    -----------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    -----------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |       |     5.   290.     7 (15) | 00:00:01 |

    |*  1 |  HASH ANTI JOIN |       |     5.   290.     7 (15) | 00:00:01 |

    |*  2 |   HASH ANTI JOIN |       |     5.   255.     5 (20) | 00:00:01 |

    |   3.    TABLE ACCESS FULL | EMP |    14.   532.     2 (0) | 00:00:01 |

    |*  4 |    TABLE ACCESS FULL | DEPT |     1.    13.     2 (0) | 00:00:01 |

    |   5.   TABLE ACCESS FULL | BONUS |     1.     7.     2 (0) | 00:00:01 |

    -----------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - access("BONUS".") ENAME "=" EMP ". ("' ENAME ')

    2 - access("DEPT".") DEPTNO "=" EMP ". ("' DEPTNO ')

    4 - filter("DEPT".") DNAME "= 'SALES')

    -------------------------

    Grateful if someone help out me. Thank you

    In addition, I really appreciate if someone proposes a simple tutorial to explain plan. Thanks again

    Concerning

    Shu

    Hi Shuumail,

    Here is the tutorial http://allthingsoracle.com/execution-plans-part-1-finding-plans/

  • explain plan for the same query diff

    Hi experts,

    Please, help me understand explain the plan.  I have tow Server (server and two server). The server are same table, even the type of database, even version Oracle (gr 11 (2), same operating system (linux Redhat 5.5) and same table and index.

    but when I explain the plan for the same query on the two server. I got diff--diff to explain the plan. reason it has different, according to my understanding, it should be same. explain please, I share the explain plan and lower indices for the two server.

    Server a

    SQL > col COLUMN_NAME format a20

    SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

    INDEX_NAME COLUMN_NAME POSITION_COLONNE

    ------------------------------ -------------------- ---------------

    DATE_IND1_S LOANDATETIME 1

    IND_MSI_LN_LNS1_S MSISDN 1

    IND_MSI_LN_LNS1_S LOANDATETIME 2

    IND_MSI_LN_LNS1_S LOANSTATUS 3

    LAST_INDEX L_INDX_MSISDN_S 1

    MSISDN L_INDX_MSISDN_S 2

    SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

    2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

    3 union

    4. Select 'Local' ind_type, index_name, nom_partition, status

    5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

    6 order of 1,2,3;

    IND_TYPE INDEX_NAME NOM_PARTITION STATUS

    -------- ------------------------------ ------------------------------ --------

    Global DATE_IND1_S VALID

    Global IND_MSI_LN_LNS1_S VALID

    Global L_INDX_MSISDN_S VALID

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

    He explained.

    SQL > SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 3659874059

    ------------------------------------------------------------------------------------------------------------------

    | ID | Operation | Name                       | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

    ------------------------------------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |       |       |

    |*  1 |  FILTER |                            |       |       |            |          |       |       |

    |   2.   PARTITION LIST ALL |                            |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

    |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1448K |    58 M | 21973 (2) | 00:04:24 |     1.    11.

    ------------------------------------------------------------------------------------------------------------------

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    3 - filter("LOANTYPE"=1 AND "LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

    16 selected lines.

    Second server

    SQL > select index_name, column_name, position_colonne from user_ind_columns where table_name = 'LOAN_RUNNING_DETAILS_SOUTH"of order 1.

    INDEX_NAME COLUMN_NAME POSITION_COLONNE

    ------------------------------ -------------------- ---------------

    DATE_IND1_S LOANDATETIME 1

    IND_MSI_LN_LNS1_S MSISDN 1

    IND_MSI_LN_LNS1_S LOANDATETIME 2

    IND_MSI_LN_LNS1_S LOANSTATUS 3

    LAST_INDEX L_INDX_MSISDN_S 1

    MSISDN L_INDX_MSISDN_S 2

    SQL > select decode (status, 'N/a', 'Part Hdr', 'Global') ind_type, index_name, NULL nom_partition, status

    2 from user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH '.

    Union

    3 4 Select 'Local' ind_type, index_name, nom_partition, status

    5 to user_ind_partitions where index-name in (select index_name in user_indexes where table_name = 'LOAN_RUNNING_DETAILS_SOUTH')

    6 order of 1,2,3;

    IND_TYPE INDEX_NAME NOM_PARTITION STATUS

    -------- ------------------------------ ------------------------------ --------

    Global DATE_IND1_S VALID

    Global IND_MSI_LN_LNS1_S VALID

    Global L_INDX_MSISDN_S VALID

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME < = sysdate-2 and LOANDATETIME > sysdate-15 and LOANTYPE = 1;

    SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 1161680601

    ----------------------------------------------------------------------------------------------------------------------------------

    | ID | Operation | Name                       | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

    ----------------------------------------------------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                            |     2.    84.     5 (0) | 00:00:01 |       |       |

    |*  1 |  FILTER                             |                            |       |       |            |          |       |       |

    |*  2 |   TABLE ACCESS BY INDEX ROWID | LOAN_RUNNING_DETAILS_SOUTH |     2.    84.     5 (0) | 00:00:01 | ROWID | ROWID |

    |*  3 |    INDEX RANGE SCAN | DATE_IND1_S |     2.       |     3 (0) | 00:00:01 |       |       |

    ----------------------------------------------------------------------------------------------------------------------------------

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    2 - filter ("LOANTYPE" = 1)

    3 - access("LOANDATETIME">SYSDATE@!-15 AND "LOANDATETIME"<=SYSDATE@!-2)

    17 selected lines.

    Reg,

    Hard

    Hi , HemantKChitale,

    I also update statistics manual as you say, but not see 'TABLE ACCESS FULL' good result

    What should I do? my need of production tuning, but I cannot able tune this...

    SQL > exec dbms_stats.gather_table_stats (-online 'ttt' ownname, tabname => 'LOAN_RUNNING_DETAILS_SOUTH', cascade => TRUE, estimate_percent => NULL, method_opt => 'for all columns size 254', => of degree 4);

    PL/SQL procedure successfully completed.

    SQL > explain plan for the small circle of MSISDN, TID, of LOAN_RUNNING_DETAILS_SOUTH where LOANDATETIME<=sysdate-2 and="" loandatetime="">sysdate-15 and LOANTYPE = 1;

    He explained.

    SQL > set line 200

    @?/rdbms/admin/utlxpls.sql

    SQL >

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 3659874059

    ------------------------------------------------------------------------------------------------------------------

    | ID | Operation | Name                       | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

    ------------------------------------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |       |       |

    |*  1 |  FILTER |                            |       |       |            |          |       |       |

    |   2.   PARTITION LIST ALL |                            |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

    |*  3 |    TABLE ACCESS FULL | LOAN_RUNNING_DETAILS_SOUTH |  1874K |    75 M | 19626 (2) | 00:03:56 |     1.    11.

    ------------------------------------------------------------------------------------------------------------------

    PLAN_TABLE_OUTPUT

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - filter(SYSDATE@!-2>SYSDATE@!-15)

    3 - filter("LOANDATETIME">SYSDATE@!-15 AND "LOANTYPE"=1 AND "LOANDATETIME")<>

    16 selected lines.

  • Explain Plan shows not good results.

    Hi gurus,

    Please help me understand under question.

    Whenever I have do explain plan on any sql statements he says as explained but when retriving explain plan output it shows same results again and again.

    DB - 11 GR 2 Stand alone
    ASM - configured.
    OS - RHEL 6.2.


    SQL > select count (*) in the t2114;

    COUNT (*)
    ----------
    639292

    SQL > explain plan for select count (*) from t2114;

    He explained.

    SQL > @?/rdbms/admin/utlxpls.sql

    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Hash value of plan: 1497650422

    ----------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    ----------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 6634. 524K | 2993 (19) | 00:00:01 |
    | 1. SORT ORDER BY | 6634. 524K | 2993 (19) | 00:00:01 |
    | 2. TABLE ACCESS BY INDEX ROWID | T2210 | 6634. 524K | 2947 (17) | 00:00:01 |
    |* 3 | INDEX RANGE SCAN | T2210_T | 6842. 108 (22) | 00:00:01 |
    ----------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    3 - access("T2210".") C490008000 ' =: SYS_B_0 AND "T2210".» C490009100 ' =: SYS_B_2.
    (AND "T2210". ' C301363300 '= TO_NUMBER (:SYS_B_1)).

    16 selected lines.


    SQL > explain the plan for
    2. SELECT T2114. C1 FROM T2114 WHERE ((T2114. C1000000001 =: 'SYS_B_0') AND (T2114. C536871442 =: 'SYS_B_1') AND (T2114. C536871477 =: 'SYS_B_2') AND ((: "SYS_B_3" - T2114.)) (C3) > =: 'SYS_B_4') AND ((: "SYS_B_5" - T2114.)) (C3) < =: 'SYS_B_6') AND (T2114. C1000000217 AS: 'SYS_B_7') AND (T2114. C536871478 <: 'SYS_B_8')) ORDER BY C1000000161 DESC,: 'SYS_B_9' ASC;

    He explained.

    SQL > SELECT * FROM TABLE (dbms_xplan.display);

    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Hash value of plan: 1497650422

    ----------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    ----------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 6634. 524K | 2993 (19) | 00:00:01 |
    | 1. SORT ORDER BY | 6634. 524K | 2993 (19) | 00:00:01 |
    | 2. TABLE ACCESS BY INDEX ROWID | T2210 | 6634. 524K | 2947 (17) | 00:00:01 |
    |* 3 | INDEX RANGE SCAN | T2210_T | 6842. 108 (22) | 00:00:01 |
    ----------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    3 - access("T2210".") C490008000 ' =: SYS_B_0 AND "T2210".» C490009100 ' =: SYS_B_2.
    (AND "T2210". ' C301363300 '= TO_NUMBER (:SYS_B_1)).

    16 selected lines.

    In the future, please do not use * on object.
    Use the owner, object_type, object_name
    You avoid output unreadable in doing so.

    In the output that you show, you would need to know where the PUBLIC synonym points, by querying dba_synonyms or all_synonyms.
    If she SYS. Plan_table, you can drop ARADMIN. PLAN_TABLE.
    If there is no PLAN_TABLE SYS, you have to solve this problem.

    -----------
    Sybrand Bakker
    Senior Oracle DBA

  • EXPLAIN Explain plan

    Hello
    can someone point me to full details of the Plan, including how to understand the syntax in the statement "3-filter...". "marked in red.
    This cross-history. I expect to see <>(not the equal sign) between these columns, but there is nothing:
    Actual results is also 14 ranks, but I do not see that the figure anywhere in the plan, only "12" will be one any correlation between the numbers of plan and result?
    T1 (col_1 number):
1
2
3
4

T2 (col_1 number):
3
4
5
6


SQL> explain plan for  select t1.col_1 from t1, t2 where t1.col_1 != t2.col_1;
 
Explained.
 
SQL> select * from table(dbms_xplan.display);
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1967407726
 
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    12 |   312 |     6   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |    12 |   312 |     6   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |     4 |    52 |     2   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |     3 |    39 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   3 - filter("T1"."COL_1""T2"."COL_1")          ---/*XXX
 
Note
-----
   - dynamic sampling used for this statement

    the cost based optimizer uses internal statistics to determine the number of rows that an operation will be back. For the simple query in your example, these estimates would be quite accurate if statistics have been sufficient - but they are not since we see the dynamic sampling note that indicates the missing statistics: http://blogs.oracle.com/optimizer/entry/dynamic_sampling_and_its_impact_on_the_optimizer

    -- without statistics
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    12 |   312 |    13   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |    12 |   312 |    13   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |     4 |    52 |     4   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |     3 |    39 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("T1"."ID"<>"T2"."ID")

Note
-----
   - dynamic sampling used for this statement (level=2)

-- gather statistics
exec dbms_stats.gather_table_stats(user, 'T1')
exec dbms_stats.gather_table_stats(user, 'T2')

-- with statistics (we see the 4 * 4 = 16 rows we expect)
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    16 |    96 |    13   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |    16 |    96 |    13   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |     4 |    12 |     4   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |     4 |    12 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("T1"."ID"<>"T2"."ID")

    The filter says that operation 3 complete analysis results are filtered by the given condition. If we had clues you might see an access descriptor.

    Concerning

    Martin Preiss

  • Read and understand execution Plans

    Hello
    in 10g R2 documentation (Database Performance Tuning Guide)
    I read:
     
13.4.2 Reading and Understanding Execution Plans 

The execution order in EXPLAIN PLAN output begins with the line that is the furthest indented to the right. The next step is the parent of that line. If two lines are indented equally, then the top line is normally executed first. 

Example 13-2 EXPLAIN PLAN Output 

----------------------------------------------------------------------------------- 
| Id  | Operation                     |  Name        | Rows  | Bytes | Cost (%CPU)| 
----------------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT              |              |     3 |   189 |    10  (10)| 
|   1 |  NESTED LOOPS                 |              |     3 |   189 |    10  (10)| 
|   2 |   NESTED LOOPS                |              |     3 |   141 |     7  (15)| 
|*  3 |    TABLE ACCESS FULL          | EMPLOYEES    |     3 |    60 |     4  (25)| 
|   4 |    TABLE ACCESS BY INDEX ROWID| JOBS         |    19 |   513 |     2  (50)| 
|*  5 |     INDEX UNIQUE SCAN         | JOB_ID_PK    |     1 |       |            | 
|   6 |   TABLE ACCESS BY INDEX ROWID | DEPARTMENTS  |    27 |   432 |     2  (50)| 
|*  7 |    INDEX UNIQUE SCAN          | DEPT_ID_PK   |     1 |       |            | 
-----------------------------------------------------------------------------------
    You would be kind to tell me:
    In the example above:

    Is step 5 in the first run because it is the most right?

    Step 4 is the parent of step 5?

    Step 4 is executed just after step 5 as its parent?

    If I'm totally wrong:
    What stage is executed first?
    The two steps are PARENT/CHILD?

    Thank you.

    Step 3, the FullTableScan of EMPLOYEES would be the first step must be performed. The results of EMPLOYEES joined JOBS in step 2 by analyzing the OFFERS by JOB_ID_PK.
    Therefore, step 5, the Index Scan of JOB_ID_PK would be the second step must be performed.
    Step 4, access to the WORK of the Table would be the third step must be performed.
    Due to PreFetching implemented in 10 g, step 7 and 6 DEPARTMENTS is also from 'start' to be ready to join in the result set of the join of the EMPLOYEES JOBS.

    Hemant K Collette
    http://hemantoracledba.blogspot.com

  • DECODE is changing the explain plan

    I have a statement with a decoding function in the where clause like this:
    AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

    Below plans to explain and tkprofs to 1 (no decode) and 2 (decode).

    * explain 1 *.
    {code}
    SQL statement that produced these data:
    Select * from table (dbms_xplan.display)

    PLAN_TABLE_OUTPUT

    ---------------------------------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU).
    ---------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | 7080 | 2413K | 43611 (2) |
    | 1. SORT ORDER BY | 7080 | 2413K | 5224K | 43611 (2) |
    |* 2 | FILTER |
    |* 3 | HASH JOIN | 7156. 2 438 K | 43075 (2) |
    | 4. TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745. 363KO | 83 (0) |
    |* 5 | OUTER HASH JOIN | 7156. 2292K | 42991 (2) |
    |* 6 | HASH JOIN | 7156. 1355K | 42907 (2) |
    |* 7 | HASH JOIN | 6987. 1187K | 19170 (2) |
    |* 8 | HASH JOIN | 6947 | 963K | 10376 (1) |
    |* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3. 144. 3 (0) |
    | 10. NESTED LOOPS | 6907. 897K | 8577 (1) |
    | * 11 | HASH JOIN | 2264 | 187K | 1782 (2) |
    | 12. TABLE ACCESS BY INDEX ROWID | SAMPLE | 190. 4370. 17 (0) |
    | 13. NESTED LOOPS | 2264 | 152K | 107 (1) |
    | 14. NESTED LOOPS | 12. 552. 25 (0) |
    | * 15 | TABLE ACCESS FULL | SDG_USER | 12. 288. 13 (0) |
    | 16. TABLE ACCESS BY INDEX ROWID | SDG | 1. 22. 1 (0) |
    | * 17. INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0) |
    | * 18. INDEX RANGE SCAN | FK_SAMPLE_SDG | 597. 2 (0) |
    | 19. TABLE ACCESS FULL | SAMPLE_USER | 1078K | 16 M | 1669 (1) |
    | * 20. INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0) |
    | 21. TABLE ACCESS FULL | ALIQUOT_USER | 3403K | 29 M | 1781 (3) |
    | 22. TABLE ACCESS FULL | TEST | 3423K | 104 M | 8775 (2) |
    | * 23. TABLE ACCESS FULL | RESULT | 3435K | 65 M | 23718 (2) |
    | 24. VIEW | PLATE | 21787 | 2851K | 84 (2).
    | * 25. FILTER |
    | 26. TABLE ACCESS FULL | PLATE | 21787 | 574K | 84 (2).
    | * 27. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 28. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 29. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    | * 31. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
    ---------------------------------------------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    2. ((«GROUP_ID» EST NULL ou EXISTE (SELECT / * + * / 0 DE "AGIL".) filter)) "OPERATOR_GROUP"
    "OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B1)) AND ('GROUP_ID' IS NULL) "'". "
    OR EXISTS (SELECT / * + * / 0 "LIMS".) ' ' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE
    "OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B2)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * +)) "" "."
    * / 0 "LIMS". "' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "."
    (('GROUP_ID' =: B3)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * + * / 0 "LIMS".)) "" OPERATOR_GROUP ".
    'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B4)))".
    3 - access ("U_ABS_DETERMINATION" ="DETERMINATION_ASSIGNMENT")
    5 - access("PLT".") PLATE_ID"(+) ="PLATE_ID")
    6 - access ("TEST_ID" ="TEST_ID")
    7 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
    8 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
    9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
    11 - access ("SAMPLE_ID" ="SAMPLE_ID")
    15 - filter ("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE" = 'QC' AND
    "U_WEEK_OF_PROCESSING"= TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY' = TO_NUMBER (:YEAR)).
    17 - access ("SDG_ID" ="SDG_ID")
    18 - access ("SDG_ID" ="SDG_ID")
    20 - access ("SAMPLE_ID" ="SAMPLE_ID")
    23 - filter ('NAME' = 'End result')
    25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS".")) OPERATOR_GROUP ".
    'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B1))".
    27 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    28 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    29 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    30 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
    31 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())

    Note
    -----
    -"PLAN_TABLE' is old version
    {code}


    * tkprof 1 *.
    {code}

    TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009

    Copyright (c) 1982, 2005, Oracle. All rights reserved.

    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Sorting options: by default

    ********************************************************************************
    Count = number of times OIC procedure has been executed
    CPU = time in seconds cpu execution
    elapsed = elapsed time in seconds the execution
    disc = number of physical reads from disk buffers
    Query = number of buffers for a consistent reading
    current = number of buffers in current mode (usually for the update)
    rows = number of rows processed by extracting or execute the call
    ********************************************************************************

    SELECT sdu.u_crop_group,
    SD. Name as sdg_name,
    ad.variety_name,
    ad.batch_number,
    B.SID as aliquot_name,
    Sau.u_box_code as box_code,
    Sau.u_box_position as box_position,
    t.Nom as test_name,
    r.original_result,
    PLT. Name as plate_name,
    Concat (chr (a.plate_row + 64), a.plate_column) as plate_position,
    au.u_replicate_number as replicate_number
    OF lims_sys.sdg sd,.
    lims_sys.sdg_user STO,
    lims_sys. Sample his.
    lims_sys.sample_user sau,
    lims_sys.aliquot has,
    to the lims_sys.aliquot_user,.
    lims_sys.test t,
    lims_sys. Result r,
    PLT lims_sys.plate,
    Ad lims_sys.abs_determination
    WHERE sd.sdg_id = sdu.sdg_id
    AND sd.sdg_id = sa.sdg_id
    AND sa.sample_id = sau.sample_id
    AND sau.sample_id = a.sample_id
    AND a.aliquot_id = au.aliquot_id
    AND au.aliquot_id = t.aliquot_id
    AND t.test_id = r.test_id
    AND plt.plate_id (+) = a.plate_id
    AND sdu.u_abs_determination = ad.determination_assignment
    AND a.status IN ('V', 'P', 'C')
    AND r.name = 'result '.
    AND sdu.u_client_type = "QC".
    AND sdu.u_year_of_sample_delivery = (: year)
    AND sdu.u_week_of_processing = (: week)
    - AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    ORDER BY box_code, box_position, replicate_number

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 1.15 1.16 0 0 0 0
    Fetch 1 8.53 16.10 227649 241266 0 500
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 3 9.68 17,27 227649 241266 0 500

    Chess in the library during parsing cache: 1
    Lack in the library during execution cache: 1
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97

    Rows Row Source operation
    ------- ---------------------------------------------------
    SORT ORDER BY 500 (cr = 241266 pr = 227649 pw = time 0 = 16104631 en)
    FILTER 21311 (cr = 241266 pr = 227649 pw = time 0 = 16246749 en)
    21311 HASH JOIN (cr = 241266 pr = 227649 pw = time 0 = 16225434 en)
    17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr = 374 pr = 0 pw = time 0 = 69 fr)
    21311 HASH JOIN RIGHT OUTER (cr = 240892 pr = 227649 pw = time 0 = 16170607 en)
    21895 VIEW PLATE (cr = 316 pr = 0 pw = time 0 = 43825 US)
    21895 FILTER (cr = 316 pr = 0 pw = time 0 = 43823 US)
    21895 TRAY FULL ACCESS (cr = 316 pr = 0 pw = time 0 = 31 US)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    21311 HASH JOIN (cr = 240576 pr = 227649 pw = time 0 = 16106174 en)
    21311 HASH JOIN (cr = 133559 pr 121596 pw = time = 0 = 9594130 en)
    21311 HASH JOIN (cr = 94323 pr = 83281 pw = time 0 = 6917067 en)
    21311 HASH JOIN (cr = 86383 pr 75547 pw = time = 0 = 5509672 en)
    JOIN by HASH 7776 (cr = 8134 pr = 0 pw = time 0 = 285364 en)
    TABLE ACCESS BY INDEX ROWID SAMPLE 7776 (cr = 572 pr = 0 pw = time 0 = 27152 US)
    7876 NESTED LOOPS (cr = 377 pr = 0 pw = time 0 = 488287 en)
    JOIN by HASH 99 (cr = 160 pr = 0 pw = time 0 = US 4168)
    99 TABLE ACCESS FULL SDG_USER (cr = 53 pr = 0 pw = time 0 = US 1209)
    5719 TABLE ACCESS FULL SDG (cr = 107 pr = 0 pw = time 0 = 17 US)
    7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr = 217 pr = 0 pw = time 0 = 623 en)(object id 45990)
    1079741 TABLE ACCESS FULL SAMPLE_USER (cr = 7562 pr = 0 pw = time 0 = 24 US)
    3307948 TABLE ALIQUOT FULL ACCESS (cr = 78249 pr = pw 75547 time = 0 = 3331129 en)
    3406836 TABLE ACCESS FULL ALIQUOT_USER (cr = 7940 pr 7734 pw = time = 0 = 556 en)
    3406832 TABLE TEST FULL ACCESS (cr = 39236 pr 38315 pw = time = 0 = 3413192 en)
    3406832 TABLE ACCESS FULL RESULTS (cr = 107017 pr = 106053 pw = time 0 = 6848487 en)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)

    ********************************************************************************

    Select 'x '.
    Of
    Double


    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 0.00 0.00 0 0 0 0
    Fetch 1 0.00 0.00 0 0 0 1
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 3 0.00 0.00 0 0 0 1

    Chess in the library during parsing cache: 0
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97

    Rows Row Source operation
    ------- ---------------------------------------------------
    1 DOUBLE QUICK (cr = 0 pr = 0 pw = time 0 = 3 US)

    ********************************************************************************

    Start: id: = sys.dbms_transaction.local_transaction_id; end;


    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 1 0.00 0.00 0 0 0 0
    Run 1 0.00 0.00 0 0 0 1
    Fetch 0 0.00 0.00 0 0 0 0
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 2 0.00 0.00 0 0 0 1

    Chess in the library during parsing cache: 0
    Optimizer mode: ALL_ROWS
    The analysis of the user id: 97



    ********************************************************************************

    TOTALS FOR ALL NON RECURSIVE INSTRUCTIONS

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 3 0.00 0.00 0 0 0 0
    Run 3 1.15 1.16 0 0 0 1
    Pick 2 8.53 16.10 227649 241266 0 501
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 8 9.68 17,27 227649 241266 0 502

    Chess in the library during parsing cache: 1
    Lack in the library during execution cache: 1


    TOTALS FOR ALL RECURSIVE INSTRUCTIONS

    call the query of disc elapsed to cpu count current lines
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Parse 30 0.00 0.00 0 0 0 0
    Run 30 0.00 0.00 0 0 0 0
    Get 30 0.00 0.00 0 40 0 10
    ------- ------ -------- ---------- ---------- ---------- ---------- ----------
    Total 90 0.00 0.00 0 40 0 10

    Chess in the library during parsing cache: 0

    3 the session user SQL statements.
    30 internal to SQL statements in session.
    33 SQL statements in session.
    ********************************************************************************
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Compatibility of trace files: 10.01.00
    Sorting options: by default

    8 sessions in the trace file.
    3 SQL statements of the user in the trace file.
    30 internal SQL instructions in the trace file.
    33 SQL statements in the trace file.
    6 unique SQL statements in the trace file.
    633 lines in the trace file.
    23 seconds in the trace file.
    {code}

    ZI wrote:
    I have a statement with a decoding function in the where clause like this:

    AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)

    When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

    I would interpret the results displayed differently.

    Execution which took 17 s according to the 241 266 coherent block played tkprof output gets but in order to do so he read 227 649 the disk blocks. Note that most of the table addressed by this query blocks were read through scanning of complete table that can take advantage of multiple blocks readings, for example if you unset the db_file_multiblock_read_count 10.2 (recommended) it usually try to read 1 MB with a read request, which are 128 blocks in case of standard block size 8 k. Due to several reasons not always the full size can be requested with each read request, lets say about 200 000 blocks could have been read by about 2,000 blocks multiple readings. Each read request would turn into a physical read, could you get an estimate approximate 25 MS per read times 2,000 applications-online 50 seconds (your system is running obviously better that the average assumed by ost g 10 base optimizer without collected statistics system workload, can be that some additional file caching system is involved).

    On the other hand, the execution plan that finished within 2 seconds completed 221 420 coherent block gets but did No physical reads at all. Note that most of the table blocks should be processed using one-piece random searches (ACCESS BY ROWID of the TABLE), according to the grouping of the indices factor, it could have been as many blocks that the lines have been returned to the range index scans. So you could have done with lets say more than 60,000 randomly accessed table blocks => until 60 000 monobloc required reading. So in the worst case, this may take 60 000 requests time 10ms by read-online 600 seconds, even if in reality at least some of the blocks will be stored in the buffer cache, so it should be less.

    It would be interesting to know how these two declarations with a cold buffer cache, so that both had to physical reads. I suppose the first is actually faster. Of course, if the second corresponds more to your typical situation that most of the blocks is in the buffer anyway, then it could be faster, because the blocks read by random access are more likely to stay in memory blocks read by complete sweep of the table, but in a true perspective of I/O the first is expected to be higher.

    Moreover, the change in the plan is probably caused by the fact that the additional predicate (DECODING) lowers the cardinality of the table of SDG_USER conduct so that LOOP IMBRIQUEE approach seems to be cheaper to the optimizer that the hash join/full scan table approach. Apparently the estimate is way off (by two orders of magnitude, in fact 100 instead of 1), then the plan is not really cheap, because it seems like the optimizer.

    By the way: two actual execution plans displayed in the output from tkprof are actually different from the displayed output of EXPLAIN the PLAN, so the statement has executed a little differently provided the facility to EXPLAIN the PLAN.

    Your PLAN_TABLE is old, since you are on 10g you should drop any PLAN_TABLEs that are in non - SYS diagrams, since 10 g already provides a global temporary Table as part of the default dictionary (SYS. Plan_table$ presentations via public synonym PLAN_TABLE).

    Kind regards
    Randolf

    Oracle related blog stuff:
    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/

  • Explain the explain plan

    decide to move to optimization soon. Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.

    Plan of subquery:

    image2.png.jpg

    join plan

    image2.png.jpg

    as you can see that the plan for the subquery has less than a cost. Could someone explain these outputs as to which application is more effective. I need to start somewhere.

    Thank you!

    The BEST way to get help when you ask questions is:

    1 ask questions on SPECIFIC things

    2. tell us EXACTLY what term, value, etc. ask abaout

    Book says join faster that the subquery in this example because the analyses involved. The "cost" to the subquery appears lower than the cost for the join. So it is confusing to me - aka How should I be interpreting this.

    OK - what BOOK are you talking about? There is not much interest to mention a book if you're not going to tell us which book it and provide a link to it and even a page number. This gives us the SCOPE of your question.

    This "cost for the subquery" are you talking about? Be specifc. It is in one of the plans that you posted? What plan? Whose cost is it? For example, you could say:

    I have a question for the foreground below. Why is the cost to the xx line lower than the cost of the second plan on line AA?

    This question refers CLEARLY to the info we're talking. The way in which you stating the question, we try to guess what plan and the lines you want to say.

    subquery plan:


join plan


as you can see the subquery plan has less of a cost. Could someone explain from these outputs as to which query is more efficient. I need to start from somewhere.

    Are you talking about line #1 in each of these plans?

    Please edit your post and tell us EXACTLY what you ask in the topic and refer to values and SPECIFIC lines. Also post a link to the book and a reference to a page number you got the information from.

    The optimizer generally chooses the REAL implementation with the lowest cost plan. It is not clear whether the plans that you have posted are ACTUAL spending plans that Oracle really determined and used or just explain plans.for what Oracle thought it might use.

    If the statistics are not up-to-date these plans do not yet reflect the reality of the data.

    And if the amount of data is a small number of blocks or other of these plans can run better than the other in reality.

    You can find this Oracle white paper "Explain the Plan explaining" useful

    http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

  • Need to explain Plan output in HTML format

    Hello

    I have details slider sqlid and child. And I'm able to generate explain plan SQL running as below

    SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR('xxxxxxxxxxxxxx',0,'ALLSTATS'));

    I need send the output of this customer. and the problem is the customer wants in HTML format. Advice to reel in HTML format

    concerning

    Pravin

    You can always query the PLAN_TABLE directly, and use SQL * more to empty in HTML.

    Another option is to do this with SQL Developer. Paste the SQL statement into the worksheet, and then press the explain Plan. When you see the plan, right-click on it and choose export as HTML.

    See you soon,.
    Brian

  • Explain plan for select distinct

    I got 1 of the online test and there the question has been asked. I have already answered but curious to cross-check my response with your advice...

    Question

    Explain what information plan if the show room in SQL indicates that a separate select statement is made in the SQL.


    The choices are:

    Sort by a join

    b sort by

    c single fate

    d sort aggregate

    group e - sort by

    My answer

    I gave aggregates of SORT but it seems that his unique kind, because when I run explain plan then I see (unique) hash. Please guide


    SEPARATE will identify unique rows. So in the given choice it would be KIND of UNIQUE. But oracle could go other plans as UNIQUE HASH or same INDEX FULL SCAN.

    Look at the oracle does not SORT.

    SQL> select distinct ename from emp;
ENAME
------
SMITH
BLAKE
CLARK
KING
ADAMS
TURNER
ALLEN
SCOTT
JONES
MARTIN
WARD
11 rows selected.
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------
SQL_ID  6b32yqumjmp9b, child number 0
-------------------------------------
select distinct ename from emp
Plan hash value: 984151148
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |
|   1 |  HASH UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

14 rows selected.

    Let me make an explicit ORDER BY for her to performa SORT.

    SQL> select distinct ename from emp order by 1;
ENAME
------
ADAMS
ALLEN
BLAKE
CLARK
JONES
KING
MARTIN
SCOTT
SMITH
TURNER
WARD
11 rows selected.
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
SQL_ID  f72vjx5rmm0z4, child number 0
-------------------------------------
select distinct ename from emp order by 1
Plan hash value: 725351111
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     4 (100)|          |
|   1 |  SORT UNIQUE       |      |    11 |    66 |     3  (34)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP  |    11 |    66 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

14 rows selected.
SQL>

    Version - 10.2.0.5.0

  • explain plan

    Hi all

    I use under version

    Connected to Oracle Database 11g Express Edition Release 11.2.0.2.0

    SQL > SELECT DEPTNO

    DEPT 2

    3. WHERE DEPTNO! = ALL

    4 (DEPTNO SELECT FROM EMP WHERE DEPTNO IS NOT NULL);

    DEPTNO

    ----------

    40

    Execution plan

    ----------------------------------------------------------

    Hash value of plan: 474461924

    ---------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    ---------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |      |     4.   104.     5 (20) | 00:00:01 |

    |*  1 |  HASH ANTI JOIN |      |     4.   104.     5 (20) | 00:00:01 |

    |   2.   TABLE ACCESS FULL | DEPT |     4.    52.     2 (0) | 00:00:01 |

    |*  3 |   TABLE ACCESS FULL | EMP |    14.   182.     2 (0) | 00:00:01 |

    ---------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - access ("DEPTNO" ="DEPTNO")

    3 - filter ("DEPTNO" IS NOT NULL)

    Note

    -----

    -dynamic sample used for this survey (level = 2)

    ----------------------------------------------------------------------------------------------------

    SQL > SELECT DEPTNO FROM DEPT

    2. IF YOU USE NOT IN DEPTNO (DEPTNO SELECT FROM EMP WHERE DEPTNO IS NOT NULL);

    DEPTNO

    ----------

    40

    Execution plan

    ----------------------------------------------------------

    Hash value of plan: 474461924

    ---------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    ---------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |      |     4.   104.     5 (20) | 00:00:01 |

    |*  1 |  HASH ANTI JOIN |      |     4.   104.     5 (20) | 00:00:01 |

    |   2.   TABLE ACCESS FULL | DEPT |     4.    52.     2 (0) | 00:00:01 |

    |*  3 |   TABLE ACCESS FULL | EMP |    14.   182.     2 (0) | 00:00:01 |

    ---------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - access ("DEPTNO" ="DEPTNO")

    3 - filter ("DEPTNO" IS NOT NULL)

    Note

    -----

    -dynamic sample used for this survey (level = 2)

    --------------------------------------------------------------------------------------------------

    SQL > SELECT DEPTNO

    DEPT 2

    3. WHERE THERE IS NO

    4 (SELECT * FROM EMP WHERE EMP.) DEPTNO = DEPT. DEPTNO);

    DEPTNO

    ----------

    40

    Execution plan

    ----------------------------------------------------------

    Hash value of plan: 474461924

    ---------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    ---------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |      |     4.   104.     5 (20) | 00:00:01 |

    |*  1 |  HASH ANTI JOIN |      |     4.   104.     5 (20) | 00:00:01 |

    |   2.   TABLE ACCESS FULL | DEPT |     4.    52.     2 (0) | 00:00:01 |

    |   3.   TABLE ACCESS FULL | EMP |    14.   182.     2 (0) | 00:00:01 |

    ---------------------------------------------------------------------------

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    1 - access("EMP".") DEPTNO "=" DEPT ". ("' DEPTNO ')

    Note

    -----

    -dynamic sample used for this survey (level = 2)

    My doubt is as all the query 3 generates even explain plan

    Can we consider that all queries to be the same as in the review of the performance.

    Thank you

    NOT IN and EXISTS are not the same. If there is only one NULL value in the sub query used with NOT IN then any condition fails.

    Here is a note of AskTom on this topic

    https://asktom.Oracle.com/pls/Apex/f?p=100:11:0:P11_QUESTION_ID:442029737684

  • SQL not using indexes at runtime, but by using the index in "explain plan".

    Hi all

    I am facing a problem here that I don't get to think.

    I have a SQL that makes a FULL ACCESS of TABLE into two tables and its costs are very high, but it occurs only when I run it in my program (I saw it in the session trace). If I do a "explain plan" sqlplus (SQL Navigator or PLSQL Developer) it shows that he use indexes and have a low cost. I already checked the statistics from both tables, and they are up to date.

    Did someone never facing a similar problem or knows something I can do to find my problem?

    Thank you all very much.

    Hello

    As far as I KNOW, optimizer Oracle never guarantees that an Index scan in query explain plan will be necessarily used during query execution.

    ORACLE-BASE - DBMS_XPLAN: Oracle display execution Plans

    Could you please read the above, run the query, as described and check the execution using DBMS_XPLAN plan. The cursor cache DISPLAY_CURSOR and not PLAN_TABLEs.

  • 3 clues on 3 different columns, but explain plan shows full table scan for select queries

    I have a table - used and have index - functional ind1 (upper (f_name)), index - (emp_id) ind2 ind3 (upper (l_name) functional on 3 columns diffferent - what, emp_id, l_name respectively.) Now when I check explain plans for sub queries, they all have two shows complete table for the employee of the table scan. FYI - employee table is non-parittioned.

    Can someone tell me why 3 indices are not used here?

    (1) select emp_id, upper (f_name), upper (l_name) of the employee

    (2) select upper (f_name), mp_id, upper (l_name) of the employee

    where upper (f_name) = upper (f_name)

    and emp_id = emp_id

    and upper (l_name) = upper (l_name)

    If I can push oracle (version 11) to use these indexes somewho - maybe using tips? Any help is appreciated.

    
Observations:

SQL> desc emp1;
 Name                                      Null?    Type
 ----------------------------------------- -------- -----------------
 EMPID                                      NOT NULL NUMBER
 F_NAME                                    NOT NULL VARCHAR2(3)
 L_NAME                                    NOT NULL VARCHAR2(3)
 SALARY                                    NUMBER
 JOB_ROLE                                 VARCHAR2(5)
 DEPTID                                     NUMBER

create index idx2 on emp1(empid);
create index idx1 on emp1(upper(f_name) );
create index idx3 on emp1(f_name,empid, l_name);
exec dbms_stats.gather_table_stats(user,'EMP1', cascade=>true);

8 rows selected.

SQL> explain plan for
  2  select /*+ index_join(e idx1 idx2 idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select    upper(f_name),empid,upper(l_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select /*+ index_ffs(e idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2496145112

-----------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-----------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select /*+ index(e idx3)*/   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> explain plan for
  2  select    upper(f_name),empid,upper(l_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |
-------------------------------------------------------------------------

8 rows selected.

SQL> drop index idx3;

Index dropped.

SQL> explain plan for
  2     select   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3330885630

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 20000 |   175K|    18   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMP1 | 20000 |   175K|    18   (0)| 00:00:01 |
--------------------------------------------------------------------------

8 rows selected.

SQL> create index idx3 on emp1(f_name,empid, l_name );

Index created.

SQL>  explain plan for
  2     select   upper(l_name),empid, upper(f_name) from emp1 e;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3449967945

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 20000 |   175K|    14   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | IDX3 | 20000 |   175K|    14   (0)| 00:00:01 |

Maybe you are looking for