How improve performance on access path TABLE ACCESS BY INDEX ROWID ?

I have table MOVEMENT with about 26millions entries,
select rowid from movement xxx
where
xxx.sTransType > 0
AND xxx.sDevice < 1000
AND xxx.sDevice >= 0
AND (bitand(xxx.sSaleFlag,1) = 0 AND bitand(xxx.sSaleFlag,4) = 0)
AND xxx.sArtClassRef < 100
and xxx.tActionTime BETWEEN TO_DATE('13-05-2011 08:08:34', 'dd-mm-yyyy hh24:mi:ss') AND to_date('13-05-2011 14:08:34', 'dd-mm-yyyy hh24:mi:ss') ;
PLAN_TABLE_OUTPUT
Plan hash value: 679628763
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 34 | 10102 (1)| 00:02:02 |
|* 1 | TABLE ACCESS BY INDEX ROWID| MOVEMENT | 1 | 34 | 10102 (1)| 00:02:02 |
|* 2 | INDEX RANGE SCAN | MOVATIME_IX | 18489 | | 51 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("XXX"."SARTCLASSREF"<100 AND BITAND("XXX"."SSALEFLAG",1)=0 AND
BITAND("XXX"."SSALEFLAG",4)=0 AND "XXX"."STRANSTYPE">0 AND "XXX"."SDEVICE"<1000
AND "XXX"."SDEVICE">=0)
2 - access("XXX"."TACTIONTIME">=TO_DATE('2011-05-13 08:08:34', 'yyyy-mm-dd
hh24:mi:ss') AND "XXX"."TACTIONTIME"<=TO_DATE('2011-05-13 14:08:34', 'yyyy-mm-dd
hh24:mi:ss'))
there is index on tActionTime - MOVATIME_IX
This query returns 12203 rows, so I would anticipate this number in plan table in row with id 1 and column Rows
Final question if it is possible to optimize this query and what are the next steps to do it?
Thanks.

>
I thought that access path via ROWID's is the fastest way to get row
>
It is the fastest way to get the row - FROM THE TABLE.
But the ROWIDs have to be gotten from the index. That is what the INDEX RANGE SCAN is doing. It is getting the ROWIDs needed and then the TABLE ACCESS BY INDEX ROWID is getting the rows.
>
I'am still confused with COST values, TABLE ACCESS BY INDEX ROWID has 200times higher cost than INDEX RANGE SCAN,
>
The index entries for a range scan are in order so they are very compact. The actual rows might be all over the place.
Have you ever you a library? Not the online ones - I mean the old-fashioned kind that actually has books printed on paper?
If the librarian asks you, her helper, to go get all books whose title begins with the letter 'B' how would you do it?
You could go back to the stacks and look at every book on every shelf for books with titles' starting with 'B'. That is the same as a FULL TABLE SCAN.
Or you could go to the card catalog, pull out the drawer (or drawers) that has 'B' on the label and look at the information on the card. Part of that information is the location of the actual book: section, stack; that is similar to the ROWID.
The card catalog might get you to the right stack of books; then you have to search the stack sequentially to look for the book by name.
A ROWID will get Oracle to the right block but then it has to find the right row.
So the cost of getting ROWIDs from an index using a RANGE SCAN (where values are scanned in order) is a lot cheaper than actually getting the rows. The first two index entries needed might be right next to each other in order but the rows themselves might be far apart on the disk.

Similar Messages

  • Table access by index rowid taking more time

    Hi All
    I've a query like
    update tab1
      set col1 = ( select col2 from
                           tab2 
                    where tab1.id = tab2.id) table 1 has arnd 10,000 rows
    table 2 has arnd 1,700,000 rows and has a primay key on column id.
    This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
    Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
    I checked the stats for the tab2, its just three days old.
    Regards
    Ashwani

    >
    table 1 has arnd 10,000 rows
    table 2 has arnd 1,700,000 rows and has a primay key on column id.
    This query is taking around 20 secs to execute. I checked the xplan and most of time taken for table access by index rowid.
    Could you please suggest what can be the reason for this. (Can it be the clustering factor or something else)
    I checked the stats for the tab2, its just three days old.
    >
    If you checked the xplan why haven't you posted it so we can look at it? Then we could see what table is being accessed by index rowid. Presumably it is table 2 but we the plan would eliminate the need to make assumptions.
    The clustering factor could be a factor. You haven't told us how table1 is being accessed. All rows are being updated so a full table scann is most likely but again the plan would actually show the access.
    Did you query the dictionary to see what the clustering factor is? Post the results of that
    SQL> select index_name, leaf_blocks, avg_leaf_blocks_per_key, avg_data_blocks_per_key, clustering_factor, distinct_keys
    2 from dba_indexes
    3 where owner = 'schema'
    4 and index_name in ('index_b','index_a');

  • Accessing Tables using global index rowid is taking too long.

    I am using Oracle 10.2.0.4.0. I am having tables which are ~100+GB in size which is range partitioned on a date column and hash subpartitioned on primary key column. And accessing these tables using global index row id using idex range scan( size of those indexes are ~7+ GB) taking ~5+ mins which results in ~1000 rows as out put. So is this means there is some structural problem with tables/indexes or its something issue at block level? How to dig more into this issue?

    Hi,
    930254 wrote:
    I am using Oracle 10.2.0.4.0. I am having tables which are ~100+GB in size which is range partitioned on a date column and hash subpartitioned on primary key column. And accessing these tables using global index row id using idex range scan( size of those indexes are ~7+ GB) taking ~5+ mins which results in ~1000 rows as out put. So is this means there is some structural problem with tables/indexes or its something issue at block level? How to dig more into this issue?once you get a chance to run the query and collect some diagnostic info, here are the questions that you should ask yourself:
    1) where is the 5 mins spent? doing index range scan itself, doing table index access by global rowid, waiting for something, doing something else?
    2) how many reads are there and what kind (logical, physical, direct path)? per the entire query and per index range scan
    3) is there any aggregation in the query? if there is, then 1000 rows output doesn't mean anything -- you could have to access millions or billions of rows to produce a 1000 row output in an aggregate query
    The best tool to answer these questions is dbms_xplan.
    Best regards,
    Nikolay

  • How can I rename the PATH_TABLE table of an index for an XMLType column?

    I have a table having a column of type XMLType. Thus, I had created an XMLIndex with an according <tablename>PATHTABLE table.
    Now I want to rename the table as well as the associated <tablename>PATHTABLE table.
    How can I achieve this? Do I have to rename the XMLIndex as well?
    Thank you.

    "ALTER INDEX " + idxName + " PARAMETERS('PATH TABLE " + newTblName + "')";does the trick but I can't achieve renaming the index with
    ALTER INDEX " + oldIdxName + " RENAME TO '" + newIdxName + "'";
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Will Partitioning improve performance on Global Temporary Table

    Dear Guru,
    In one of complicated module I am using Global Temporary Table (GTT) for intermediate processing i.e. It will store required data in it but the rows of the data goes into 10,00,000 - 20,00,000.
    Can Partitioning or Indexing on Global Temporary Table improve the performance?
    Thanking in Advance
    Sanjeev

    Sounds like an odd use of a GTT to me, but I'm sure there are valid reasons...
    Presumably you are going to be processing all of these rows in some way? In which case I can't see how partitioning, even if it's possible (And I don't think it is) would help you.
    Indexes - sure, that might help, but again, if you are reading all/most of these rows anyway they might not help or even get used.
    Can you give a bit more detail about exactly what you are doing?
    Edited by: Carlovski on Nov 24, 2010 12:51 PM

  • How to perform clickable event on Table view

    hi!
          I am using tableview element to display my content.
    Now i want to perform clickable event on row so that on clicking particular row i can show the details of that particular row in  other view.
    Regards
    Parth

    Hi Abhijit,
    regarding #2, i am facing a strange problem. If more than one row is selected, the <valuenode>.isMultiSelcted(index) returns true only for the lead selected row. For the other selected rows it return false. Would you know how to get rid of this.
    Note that the problem is there only in case if i try to do this in the onLeadselect method. It works fine if i do this in a method which is called on click of a button !!!
    In my case, i have a requirement wherein i need to find out which are the selected rows on click of any row in the table.

  • Does improve performance to analyze all tables?

    Will the SELECT, INSERT, UPDATE and DELETE commands work faster if I analyze the main tables every month?

    It's unlikely that you will see month-on-month improvement. Once the tables get to a certain size the stats son't really get stale (if you add 10,000 records a month to a table with 10,000,000 rows, there's not really a lot of difference).
    So the advice is to gather stats for your tables once. Then use the monitoring option for tables that you think may be volatile and refresh their stats if they have grown stale. Note that in 10g the monintoring option has been deprecated because DBMS_STATS now supports the option to explicitly refresh stale statistics.
    Cheers, APC

  • How to perform 'block selection' in table control?

    Hi,
    I'm looking for an easy way to implement block selection in a table control (i.e. select one line, hit 'block select' button, select a second line, hit 'block select' button again, and all lines between first and last are selected).
    I'm currently with a customer who is on 4.0b, so I can't use the wizard, it didn't exist back then.
    I hope someone knows
    regards,
    rs

    Rob,
    I generated a quick screen with wizard doing the multiple select.  This is the code chucks it generated
    in _TOP  first part is my definition of the table to be displayed and the one column on it.
    TABLES:   zsd_act_salespr.
    DATA:
      BEGIN OF wk_rec.
            INCLUDE STRUCTURE zsd_act_salespr.
    DATA:
        sel    TYPE c,
      END OF wk_rec,
      it_wk   LIKE STANDARD TABLE OF wk_rec.
       controls: TBLCLT_MAIN type tableview using screen 0100.   " Table Control on screen
    in I01
    *&spwizard: input modul for tc 'TBLCLT_MAIN'. do not change this line!
    *&spwizard: mark table
    module TBLCLT_MAIN_mark input.
      data: g_TBLCLT_MAIN_wa2 like line of IT_WK.
      if TBLCLT_MAIN-line_sel_mode = 1.
         loop at IT_WK into g_TBLCLT_MAIN_wa2
           where SEL = 'X'.
           g_TBLCLT_MAIN_wa2-SEL = ''.
           modify IT_WK
             from g_TBLCLT_MAIN_wa2
             transporting SEL.
         endloop.
      endif.
      modify IT_WK
        from WK_REC
        index TBLCLT_MAIN-current_line
        transporting SEL.
    endmodule.
    in the screen workflow
    PROCESS BEFORE OUTPUT.
    *&spwizard: pbo flow logic for tablecontrol 'TBLCLT_MAIN'
      module TBLCLT_MAIN_change_tc_attr.
    *&spwizard: module TBLCLT_MAIN_change_col_attr.
      loop at   IT_WK
           into WK_REC
           with control TBLCLT_MAIN
           cursor TBLCLT_MAIN-current_line.
    *&spwizard:   module TBLCLT_MAIN_change_field_attr
      endloop.
    PROCESS AFTER INPUT.
    *&spwizard: pai flow logic for tablecontrol 'TBLCLT_MAIN'
      loop at IT_WK.
        chain.
          field WK_REC-SPNUM.
        endchain.
        field WK_REC-SEL
          module TBLCLT_MAIN_mark on request.
      endloop.
    *&spwizard: module TBLCLT_MAIN_change_tc_attr.
    *&spwizard: module TBLCLT_MAIN_change_col_attr.
    in the O01
    *&spwizard: output module for tc 'TBLCLT_MAIN'. do not change this line!
    *&spwizard: update lines for equivalent scrollbar
    module TBLCLT_MAIN_change_tc_attr output.
      describe table IT_WK lines TBLCLT_MAIN-lines.
    endmodule.
    in the F01 nothing
    Edited by: Paul Chapman on Apr 24, 2008 4:56 PM

  • How to make optimizer fetch and join values from Indexes, no table access.

    Hi All,
    i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
    Execution Plan
    Plan hash value: 1209914516
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | | 6 (17)| 00:00:01 | | |
    | 1 | SORT AGGREGATE | | 1 | | | | | |
    |* 2 | FILTER | | | | | | | |
    | 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
    | 4 | NESTED LOOPS | | 1 | 24 | 4 (25)| 00:00:01 | | |
    | 5 | SORT UNIQUE | | 1 | 10 | 2 (0)| 00:00:01 | | |
    | 6 | TABLE ACCESS BY INDEX ROWID | INVOICELINEDISB | 1 | 10 | 2 (0)| 00:00:01 | | |
    |* 7 | INDEX RANGE SCAN | IDX_INVLINEDISB_UOMCD | 1 | | 1 (0)| 00:00:01 | | |
    | 8 | PARTITION HASH ITERATOR | | 1 | 14 | 1 (0)| 00:00:01 | KEY | KEY |
    |* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB | 1 | 14 | 1 (0)| 00:00:01 | ROWID | ROWID |
    |* 10 | INDEX UNIQUE SCAN | P_INVOICEHEADERDISB_PART | 1 | | 0 (0)| 00:00:01 | KEY | KEY |
    Predicate Information (identified by operation id):
    2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
    "INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
    "INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
    7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
    9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
    10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
    Statistics
    0 recursive calls
    0 db block gets
    14 consistent gets
    0 physical reads
    0 redo size
    410 bytes sent via SQL*Net to client
    385 bytes received via SQL*Net from client

    Jonathan Lewis wrote:
    930254 wrote:
    Hi All,
    i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
    Execution Plan
    Plan hash value: 1209914516
    | Id  | Operation                              | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                       |                          |     1 |       |     6  (17)| 00:00:01 |       |       |
    |   1 |  SORT AGGREGATE                        |                          |     1 |       |            |          |       |       |
    |*  2 |   FILTER                               |                          |       |       |            |          |       |       |
    |   3 |    FAST DUAL                           |                          |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   4 |    NESTED LOOPS                        |                          |     1 |    24 |     4  (25)| 00:00:01 |       |       |
    |   5 |     SORT UNIQUE                        |                          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
    |   6 |      TABLE ACCESS BY INDEX ROWID       | INVOICELINEDISB          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
    |*  7 |       INDEX RANGE SCAN                 | IDX_INVLINEDISB_UOMCD    |     1 |       |     1   (0)| 00:00:01 |       |       |
    |   8 |     PARTITION HASH ITERATOR            |                          |     1 |    14 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |*  9 |      TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB        |     1 |    14 |     1   (0)| 00:00:01 | ROWID | ROWID |
    |* 10 |       INDEX UNIQUE SCAN                | P_INVOICEHEADERDISB_PART |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    Predicate Information (identified by operation id):
    2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
    "INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
    "INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
    7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
    9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
    10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
    The sort unique at line 5 is surprising, I can't think of an obvious reason why it should appear unless the optimizer is trying to do something very clever to work around a problem we can't see (such as a statistics error with the hash partitioned indexe).
    Assuming that the test would do better starting with invoiceheaderdisn.paypkl I have to ask if you have an index on INVOICELINEDISB(INVOICEPK).The optimizer's choice of driving table indeed looks odd. Could it be due to misleading statistics or plain bug or just a case of CBO preferring a non-partitioned table over partitioned table when deciding the driving table? I must admit this design does look odd as it appears INVOICEHEADERDISB is a parent table and INVOICELINEDISB is a child table but somehow the parent table has been partitioned (using hash partitioning, I assume) but the child table is not.
    However, once CBO has decided the driving table, the SORT UNIQUE is not quite surprising. Assuming optimizer knows that there is a parent-child relationship between INVOICEHEADERDISB and INVOICELINEDISB table (based on INVOICEPK column), CBO needs to access only INVOICEPK and UNITOFMEASURECD columns fron the INVOICELINEDISB table in order to process the join. It uses index range scan on UNITOFMEASURECD table in order to get (part of) the necessary data and then accesses INVOICELINEDISB table to get the values of INVOICEPK column. Being a child table, it is possible that the driving row source will contain duplicate values for INVOICEPK column but not necessarily sorted. As CBO knows that outer table (i.e. INVOICEHEADERDISB) has a PK on INVOICEPK column, each row in driving row source will have either 1 or 0 rows matching from outer table. It appears that CBO "decides" that by eliminating the duplicate values of the INVOICEPK from driving row source, it can reduce the number of times the INVOICEHEADERDISB table is accessed.
    Now I am not sure if CBO does all this (eliminating duplicates from driving row source) only because the outer table is partitioned.
    Coming back to OP's original question, I believe OP will have to change the index definitions in order to avoid table access for this query. But there has to be a strong and logical argument to make this kind of change for just one query.
    Hope this helps.

  • How to improve performance of the attached query

    Hi,
    How to improve performance of the below query, Please help. also attached explain plan -
    SELECT Camp.Id,
    rCam.AccountKey,
    Camp.Id,
    CamBilling.Cpm,
    CamBilling.Cpc,
    CamBilling.FlatRate,
    Camp.CampaignKey,
    Camp.AccountKey,
    CamBilling.billoncontractedamount,
    (SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
    rCam.AccountKey as AccountKey
    FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
    WHERE Camp.AccountKey = rCam.AccountKey
    AND Camp.AvCampaignKey = rCam.AvCampaignKey
    AND Camp.AccountKey = CamBilling.AccountKey
    AND Camp.CampaignKey = CamBilling.CampaignKey
    AND rCam.AccountKey = xSite.AccountKey
    AND rCam.AvSiteKey = xSite.AvSiteKey
    AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
    to_date('01-01-2011', 'DD-MM-YYYY')
    GROUP By rCam.AccountKey,
    Camp.Id,
    CamBilling.Cpm,
    CamBilling.Cpc,
    CamBilling.FlatRate,
    Camp.CampaignKey,
    Camp.AccountKey,
    CamBilling.billoncontractedamount
    Explain Plan :-
    Description Object_owner Object_name Cost Cardinality Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
    SORT AGGREGATE 1 13
    VIEW GEMINI_REPORTING 14 1 13
    HASH GROUP BY 14 1 103
    NESTED LOOPS 13 1 103
    HASH JOIN 12 1 85
    TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
    NESTED LOOPS 9 5 325
    HASH JOIN 7 1 40
    SORT UNIQUE 2 1 18
    TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
    INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
    TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
    INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
    TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
    TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
    INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

    duplicate thread..
    How to improve performance of attached query

  • How to improve performance of attached query

    Hi,
    How to improve performance of the below query, Please help. also attached explain plan -
    SELECT Camp.Id,
    rCam.AccountKey,
    Camp.Id,
    CamBilling.Cpm,
    CamBilling.Cpc,
    CamBilling.FlatRate,
    Camp.CampaignKey,
    Camp.AccountKey,
    CamBilling.billoncontractedamount,
    (SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
    rCam.AccountKey as AccountKey
    FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
    WHERE Camp.AccountKey = rCam.AccountKey
    AND Camp.AvCampaignKey = rCam.AvCampaignKey
    AND Camp.AccountKey = CamBilling.AccountKey
    AND Camp.CampaignKey = CamBilling.CampaignKey
    AND rCam.AccountKey = xSite.AccountKey
    AND rCam.AvSiteKey = xSite.AvSiteKey
    AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
    to_date('01-01-2011', 'DD-MM-YYYY')
    GROUP By rCam.AccountKey,
    Camp.Id,
    CamBilling.Cpm,
    CamBilling.Cpc,
    CamBilling.FlatRate,
    Camp.CampaignKey,
    Camp.AccountKey,
    CamBilling.billoncontractedamount
    Explain Plan :-
    Description Object_owner Object_name Cost Cardinality Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
    SORT AGGREGATE 1 13
    VIEW GEMINI_REPORTING 14 1 13
    HASH GROUP BY 14 1 103
    NESTED LOOPS 13 1 103
    HASH JOIN 12 1 85
    TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
    NESTED LOOPS 9 5 325
    HASH JOIN 7 1 40
    SORT UNIQUE 2 1 18
    TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
    INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
    TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
    INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
    TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
    TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
    INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

    duplicate thread..
    How to improve performance of attached query

  • High cost of TABLE ACCESS BY LOCAL INDEX ROWID

    Hi,
    We are having a query which is running very slow, while checking the execution plan we found high cost on "TABLE ACCESS BY LOCAL INDEX ROWID"
    Db version : 11.2.0.1
    EBS version: 12.1.2
    Os version : Aix 6.1
    SID        : 567
    ADDRESS    : 07000004EB12A7A8
    HASH_VALUE : 556917643
    MODULE     : ora_rw20_run@erpprodapp (TNS V1-V3)
    PROGRAM    : ora_rw20_run@erpprodapp (TNS V1-V3)
    MACHINE    : erpprodapp
    CHILD CNT  : 2
    [  Current SQL  ]
    SELECT API.INVOICE_TYPE_LOOKUP_CODE
    ,   DECODE(API.INVOICE_TYPE_LOOKUP_CODE, 'CREDIT', 0, Z.AMT_VAL ) CREDIT_VAL, 0 ACCT_CR
    ,   API.EXCHANGE_RATE EXCHANGE_RATE
    ,   API.EXCHANGE_RATE_TYPE EXCHANGE_RATE_TYPE, API.INVOICE_CURRENCY_CODE INVOICE_CURRENCY_CODE
    ,   API.EXCHANGE_DATE EXCHANGE_DATE
    FROM AP_INVOICES_ALL API, AP_INVOICE_DISTRIBUTIONS_ALL APD, (SELECT NVL(SUM(APD.AMOUNT),0) AMT_VAL
    ,   API.INVOICE_ID
    FROM AP_INVOICES_ALL API, AP_INVOICE_DISTRIBUTIONS_ALL APD
    WHERE API.INVOICE_ID = APD.INVOICE_ID
    AND API.INVOICE_TYPE_LOOKUP_CODE <> :B6
    AND APD.MATCH_STATUS_FLAG = 'A'
    AND API.VENDOR_ID = :B5
    AND API.VENDOR_SITE_ID = :B4
    AND APD.ACCOUNTING_DATE < :B3
    AND (API.ORG_ID = :B2
    OR API.ORG_ID IS NULL)
    AND APD.LINE_TYPE_LOOKUP_CODE <> :B1
    GROUP BY API.INVOICE_ID) Z
    WHERE Z.INVOICE_ID = API.INVOICE_ID
    AND API.INVOICE_ID = APD.INVOICE_ID
    AND APD.ROWID = (SELECT ROWID
    FROM AP_INVOICE_DISTRIBUTIONS_ALL WHERE ROWNUM=1
    AND INVOICE_ID=APD.INVOICE_ID
    AND MATCH_STATUS_FLAG = 'A'
    AND ACCOUNTING_DATE < :B3 )
    AND API.INVOICE_TYPE_LOOKUP_CODE <> :B6
    AND APD.MATCH_STATUS_FLAG = 'A'
    AND API.VENDOR_ID = :B5 AND API.VENDOR_SITE_ID = :B4
    AND APD.ACCOUNTING_DATE < :B3
    AND (API.ORG_ID = :B2
    OR API.ORG_ID IS NULL)
    AND ((API.INVOICE_TYPE_LOOKUP_CODE <> :B9 )
    OR ( (API.INVOICE_TYPE_LOOKUP_CODE = :B9 ) AND ( NOT EXISTS (SELECT '1'
    FROM AP_INVOICE_PAYMENTS_ALL APP, AP_CHECKS_ALL APC
    WHERE APP.CHECK_ID = APC.CHECK_ID
    AND APP.INVOICE_ID = API.INVOICE_ID
    AND APC.PAYMENT_TYPE_FLAG = 'R' ) ) ) ) AND API.INVOICE_CURRENCY_CODE =NVL( :B8
    ,  API.INVOICE_CURRENCY_CODE)
    AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
    SELECT API.INVOICE_TYPE_LOOKUP_CODE, DECODE(API.INVOICE_TYPE_LOOKUP_CODE,'CREDIT'
    ,   DECODE(STATUS_LOOKUP_CODE,'VOIDED', APP.AMOUNT+ NVL(DISCOUNT_AMOUNT_TAKEN
    ,   0) , ABS(APP.AMOUNT)+ ABS(NVL(DISCOUNT_AMOUNT_TAKEN, 0)) )
    ,   0) CREDIT_VAL, 0 ACCT_CR, APC.EXCHANGE_RATE EXCHANGE_RATE
    ,   APC.EXCHANGE_RATE_TYPE EXCHANGE_RATE_TYPE
    ,   API.PAYMENT_CURRENCY_CODE INVOICE_CURRENCY_CODE, APC.EXCHANGE_DATE EXCHANGE_DATE
    FROM AP_INVOICES_ALL API, AP_INVOICE_PAYMENTS_ALL APP, AP_CHECKS_ALL APC
    WHERE APP.INVOICE_ID = API.INVOICE_ID
    AND APP.CHECK_ID = APC.CHECK_ID AND APC.STATUS_LOOKUP_CODE IN (:B15 ,:B14 ,:B13 ,:B12 ,:B11
    ,  :B10 )
    AND API.VENDOR_ID = :B5
    AND API.VENDOR_SITE_ID = :B4
    AND APP.ACCOUNTING_DATE < TRUNC(:B3 )
    AND ( API.ORG_ID = :B2
    OR API.ORG_ID IS NULL )
    AND EXISTS (
    SELECT '1'
    FROM AP_INVOICE_DISTRIBUTIONS_ALL APD , AP_INVOICE_LINES_ALL APIL
    WHERE APD.INVOICE_ID = API.INVOICE_ID
    AND APIL.INVOICE_ID = APD.INVOICE_ID
    AND APD.MATCH_STATUS_FLAG ='A'
    AND APIL.LINE_NUMBER = APD.INVOICE_LINE_NUMBER)
    AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
    AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
    SELECT 'LOSS' INVOICE_TYPE_LOOKUP_CODE, 0 CREDIT_VAL, DECODE(XAL.ACCOUNTING_CLASS_CODE
    ,  'LOSS', ACCOUNTED_DR,0) ACCT_CR
    ,   XAL.CURRENCY_CONVERSION_RATE EXCHANGE_RATE , XAL.CURRENCY_CONVERSION_TYPE EXCHANGE_RATE_TYPE
    ,   XAL.CURRENCY_CODE INVOICE_CURRENCY_CODE
    ,   XAL.CURRENCY_CONVERSION_DATE EXCHANGE_DATE
    FROM XLA_AE_LINES XAL, XLA_AE_HEADERS XAH, XLA_TRANSACTION_ENTITIES XTE, AP_INVOICES_ALL API
    WHERE XAL.APPLICATION_ID = 200
    AND XAL.AE_HEADER_ID = XAH.AE_HEADER_ID
    AND XAL.ACCOUNTING_CLASS_CODE IN ( :B18 ,:B17 )
    AND XAH.APPLICATION_ID = 200 AND XAH.ENTITY_ID = XTE.ENTITY_ID
    AND XTE.APPLICATION_ID = 200 AND XTE.ENTITY_CODE =:B16
    AND XTE.SOURCE_ID_INT_1 = API.INVOICE_ID
    AND API.VENDOR_ID = :B5
    AND API.VENDOR_SITE_ID = :B4
    AND XAH.ACCOUNTING_DATE < :B3
    AND (API.ORG_ID = :B2
    OR API.ORG_ID IS NULL )
    AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
    AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7 ,API.ACCTS_PAY_CODE_COMBINATION_ID) UNION ALL
    SELECT 'LOSS' INVOICE_TYPE_LOOKUP_CODE, 0 CREDIT_VAL, DECODE(XAL.ACCOUNTING_CLASS_CODE
    ,  'LOSS', ACCOUNTED_DR,0) ACCT_CR
    ,   XAL.CURRENCY_CONVERSION_RATE EXCHANGE_RATE , XAL.CURRENCY_CONVERSION_TYPE EXCHANGE_RATE_TYPE
    ,   XAL.CURRENCY_CODE INVOICE_CURRENCY_CODE
    ,   XAL.CURRENCY_CONVERSION_DATE EXCHANGE_DATE
    FROM XLA_AE_LINES XAL, XLA_AE_HEADERS XAH, XLA_TRANSACTION_ENTITIES XTE, AP_INVOICES_ALL API, AP_CHECKS_ALL AC
    ,   AP_INVOICE_PAYMENTS_ALL APP
    WHERE XAL.APPLICATION_ID = 200
    AND XAL.AE_HEADER_ID = XAH.AE_HEADER_ID
    AND XAL.ACCOUNTING_CLASS_CODE IN ( :B18 ,:B17 )
    AND XAH.APPLICATION_ID = 200
    AND XAH.ENTITY_ID = XTE.ENTITY_ID
    AND XTE.APPLICATION_ID = 200
    AND XTE.ENTITY_CODE = :B19
    AND XTE.SOURCE_ID_INT_1 = AC.CHECK_ID
    AND XAH.EVENT_ID = APP.ACCOUNTING_EVENT_ID
    AND API.INVOICE_ID = APP.INVOICE_ID AND APP.CHECK_ID = AC.CHECK_ID
    AND AC.STATUS_LOOKUP_CODE IN (:B15 ,:B14 ,:B13 , :B12 ,:B11 ,:B10 )
    AND API.VENDOR_ID = :B5
    AND API.VENDOR_SITE_ID = :B4
    AND XAH.ACCOUNTING_DATE < :B3
    AND (API.ORG_ID = :B2
    OR API.ORG_ID IS NULL )
    AND API.INVOICE_CURRENCY_CODE =NVL( :B8 ,API.INVOICE_CURRENCY_CODE)
    AND API.ACCTS_PAY_CODE_COMBINATION_ID = NVL(:B7
    ,  API.ACCTS_PAY_CODE_COMBINATION_ID)
    Plan hash value: 1352234085
    | Id  | Operation                                | Name                         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Ps
    |   0 | SELECT STATEMENT                         |                              |       |       |  1904 (100)|          |       |
    |   1 |  UNION-ALL                               |                              |       |       |            |          |       |
    |   2 |   FILTER                                 |                              |       |       |            |          |       |
    |   3 |    NESTED LOOPS                          |                              |       |       |            |          |       |
    |   4 |     NESTED LOOPS                         |                              |     1 |    87 |    20   (5)| 00:06:09 |       |
    |   5 |      NESTED LOOPS                        |                              |     1 |    60 |    17   (6)| 00:05:14 |       |
    |   6 |       VIEW                               |                              |     1 |    18 |    15   (7)| 00:04:37 |       |
    |   7 |        HASH GROUP BY                     |                              |     1 |    54 |    15   (7)| 00:04:37 |       |
    |   8 |         NESTED LOOPS                     |                              |       |       |            |          |       |
    |   9 |          NESTED LOOPS                    |                              |     1 |    54 |    14   (0)| 00:04:19 |       |
    |  10 |           TABLE ACCESS BY INDEX ROWID    | AP_INVOICES_ALL              |     1 |    27 |    11   (0)| 00:03:23 |       |
    |  11 |            INDEX RANGE SCAN              | AP_INVOICES_N2               |    11 |       |     3   (0)| 00:00:56 |       |
    |  12 |           INDEX RANGE SCAN               | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     2   (0)| 00:00:37 |       |
    |  13 |          TABLE ACCESS BY INDEX ROWID     | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     3   (0)| 00:00:56 |       |
    |  14 |       TABLE ACCESS BY INDEX ROWID        | AP_INVOICES_ALL              |     1 |    42 |     2   (0)| 00:00:37 |       |
    |  15 |        INDEX UNIQUE SCAN                 | AP_INVOICES_U1               |     1 |       |     1   (0)| 00:00:19 |       |
    |  16 |      INDEX RANGE SCAN                    | AP_INVOICE_DISTRIBUTIONS_N33 |     1 |       |     2   (0)| 00:00:37 |       |
    |  17 |       COUNT STOPKEY                      |                              |       |       |            |          |       |
    |  18 |        TABLE ACCESS BY INDEX ROWID       | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     4   (0)| 00:01:14 |       |
    |  19 |         INDEX RANGE SCAN                 | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     3   (0)| 00:00:56 |       |
    |  20 |     TABLE ACCESS BY INDEX ROWID          | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    27 |     3   (0)| 00:00:56 |       |
    |  21 |    NESTED LOOPS                          |                              |       |       |            |          |       |
    |  22 |     NESTED LOOPS                         |                              |     1 |    17 |     6   (0)| 00:01:51 |       |
    |  23 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_PAYMENTS_ALL      |     1 |    10 |     4   (0)| 00:01:14 |       |
    |  24 |       INDEX RANGE SCAN                   | AP_INVOICE_PAYMENTS_N1       |     1 |       |     3   (0)| 00:00:56 |       |
    |  25 |      INDEX UNIQUE SCAN                   | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
    |  26 |     TABLE ACCESS BY INDEX ROWID          | AP_CHECKS_ALL                |     1 |     7 |     2   (0)| 00:00:37 |       |
    |  27 |   NESTED LOOPS SEMI                      |                              |     1 |   102 |    25   (0)| 00:07:41 |       |
    |  28 |    NESTED LOOPS                          |                              |     1 |   100 |    20   (0)| 00:06:09 |       |
    |  29 |     NESTED LOOPS                         |                              |     1 |    67 |    18   (0)| 00:05:32 |       |
    |  30 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICES_ALL              |     1 |    42 |    15   (0)| 00:04:37 |       |
    |  31 |       INDEX RANGE SCAN                   | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
    |  32 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_PAYMENTS_ALL      |     1 |    25 |     3   (0)| 00:00:56 |       |
    |  33 |       INDEX RANGE SCAN                   | AP_INVOICE_PAYMENTS_N1       |     1 |       |     2   (0)| 00:00:37 |       |
    |  34 |     TABLE ACCESS BY INDEX ROWID          | AP_CHECKS_ALL                |     1 |    33 |     2   (0)| 00:00:37 |       |
    |  35 |      INDEX UNIQUE SCAN                   | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
    |  36 |    VIEW PUSHED PREDICATE                 | VW_SQ_1                      |     1 |     2 |     5   (0)| 00:01:33 |       |
    |  37 |     NESTED LOOPS                         |                              |     1 |    20 |     5   (0)| 00:01:33 |       |
    |  38 |      TABLE ACCESS BY INDEX ROWID         | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    11 |     4   (0)| 00:01:14 |       |
    |  39 |       INDEX RANGE SCAN                   | AP_INVOICE_DISTRIBUTIONS_N33 |     2 |       |     3   (0)| 00:00:56 |       |
    |  40 |      INDEX UNIQUE SCAN                   | AP_INVOICE_LINES_U1          |     1 |     9 |     1   (0)| 00:00:19 |       |
    |  41 |   NESTED LOOPS                           |                              |       |       |            |          |       |
    |  42 |    NESTED LOOPS                          |                              |     1 |   113 |  1825   (0)| 09:20:33 |       |
    |  43 |     NESTED LOOPS                         |                              |     1 |    79 |  1822   (0)| 09:19:38 |       |
    |  44 |      MERGE JOIN CARTESIAN                |                              |     1 |    50 |  1820   (0)| 09:19:01 |       |
    |  45 |       TABLE ACCESS BY INDEX ROWID        | AP_INVOICES_ALL              |     1 |    27 |    15   (0)| 00:04:37 |       |
    |  46 |        INDEX RANGE SCAN                  | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
    |  47 |       BUFFER SORT                        |                              | 17282 |   388K|  1805   (0)| 09:14:24 |       |
    |  48 |        PARTITION LIST SINGLE             |                              | 17282 |   388K|  1805   (0)| 09:14:24 |   KEY |
    |  49 |         TABLE ACCESS BY LOCAL INDEX ROWID| XLA_AE_HEADERS               | 17282 |   388K|  1805   (0)| 09:14:24 |     1 |
    |  50 |          INDEX RANGE SCAN                | XLA_AE_HEADERS_N5            |  5445 |       |   100   (0)| 00:30:43 |     1 |
    |  51 |      PARTITION LIST SINGLE               |                              |     1 |    29 |     2   (0)| 00:00:37 |   KEY |
    |  52 |       TABLE ACCESS BY LOCAL INDEX ROWID  | XLA_TRANSACTION_ENTITIES     |     1 |    29 |     2   (0)| 00:00:37 |     1 |
    |  53 |        INDEX UNIQUE SCAN                 | XLA_TRANSACTION_ENTITIES_U1  |     1 |       |     1   (0)| 00:00:19 |     1 |
    |  54 |     PARTITION LIST SINGLE                |                              |     1 |       |     2   (0)| 00:00:37 |   KEY |
    |  55 |      INDEX RANGE SCAN                    | XLA_AE_LINES_U1              |     1 |       |     2   (0)| 00:00:37 |     1 |
    |  56 |    TABLE ACCESS BY LOCAL INDEX ROWID     | XLA_AE_LINES                 |     1 |    34 |     3   (0)| 00:00:56 |     1 |
    |  57 |   NESTED LOOPS                           |                              |       |       |            |          |       |
    |  58 |    NESTED LOOPS                          |                              |     1 |   151 |    30   (0)| 00:09:13 |       |
    |  59 |     NESTED LOOPS                         |                              |     1 |   135 |    28   (0)| 00:08:37 |       |
    |  60 |      NESTED LOOPS                        |                              |     1 |   101 |    25   (0)| 00:07:41 |       |
    |  61 |       NESTED LOOPS                       |                              |     1 |    72 |    23   (0)| 00:07:04 |       |
    |  62 |        NESTED LOOPS                      |                              |     1 |    43 |    18   (0)| 00:05:32 |       |
    |  63 |         TABLE ACCESS BY INDEX ROWID      | AP_INVOICES_ALL              |     1 |    27 |    15   (0)| 00:04:37 |       |
    |  64 |          INDEX RANGE SCAN                | AP_INVOICES_N7               |    15 |       |     3   (0)| 00:00:56 |       |
    |  65 |         TABLE ACCESS BY INDEX ROWID      | AP_INVOICE_PAYMENTS_ALL      |     1 |    16 |     3   (0)| 00:00:56 |       |
    |  66 |          INDEX RANGE SCAN                | AP_INVOICE_PAYMENTS_N1       |     1 |       |     2   (0)| 00:00:37 |       |
    |  67 |        PARTITION LIST SINGLE             |                              |     1 |    29 |     5   (0)| 00:01:33 |   KEY |
    |  68 |         TABLE ACCESS BY LOCAL INDEX ROWID| XLA_AE_HEADERS               |     1 |    29 |     5   (0)| 00:01:33 |     1 |
    |  69 |          INDEX RANGE SCAN                | XLA_AE_HEADERS_N2            |     1 |       |     2   (0)| 00:00:37 |     1 |
    |  70 |       PARTITION LIST SINGLE              |                              |     1 |    29 |     2   (0)| 00:00:37 |   KEY |
    |  71 |        TABLE ACCESS BY LOCAL INDEX ROWID | XLA_TRANSACTION_ENTITIES     |     1 |    29 |     2   (0)| 00:00:37 |     1 |
    |  72 |         INDEX UNIQUE SCAN                | XLA_TRANSACTION_ENTITIES_U1  |     1 |       |     1   (0)| 00:00:19 |     1 |
    |  73 |      PARTITION LIST SINGLE               |                              |     1 |    34 |     3   (0)| 00:00:56 |   KEY |
    |  74 |       TABLE ACCESS BY LOCAL INDEX ROWID  | XLA_AE_LINES                 |     1 |    34 |     3   (0)| 00:00:56 |     1 |
    |  75 |        INDEX RANGE SCAN                  | XLA_AE_LINES_U1              |     1 |       |     2   (0)| 00:00:37 |     1 |
    |  76 |     INDEX UNIQUE SCAN                    | AP_CHECKS_U1                 |     1 |       |     1   (0)| 00:00:19 |       |
    |  77 |    TABLE ACCESS BY INDEX ROWID           | AP_CHECKS_ALL                |     1 |    16 |     2   (0)| 00:00:37 |       |
    XLA_AE_HEADERS is a table partition
    Regards,
    Gaurav

    Thanks for the prompt reply.
    XLA_AE_HEADERS is a table partition and showing high cost on TABLE ACCESS BY LOCAL INDEX ROWID similarly XLA_TRANSACTION_ENTITIES is also a table partion
    OWNER    SEGMENT_NAME                   SEGMENT_T BYTES/1024/1024
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR        2014.375
    XLA      XLA_AE_HEADERS                 TABLE PAR          4424.5
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125
    XLA      XLA_AE_HEADERS                 TABLE PAR          10.125
    XLA      XLA_AE_HEADERS                 TABLE PAR            .125

  • How to performance tune this query

    I need some inputs on how to do performance tuning on this query to improve performance.
    It takes around 45 secs to run. Is it possible to make any improvements in this by putting hints or writing in another way?
    select count(*)
    as nCount from A ,
    B ,
    C
    WHERE A.COL1 = B.COL1 AND
    A.COl2 <> 'COM' AND
    B.COL2 = C.COL1 AND
    B.COl3 IS NULL AND
    B.COL4 = 'TEST'
    This is the query plan:
    Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
    SELECT STATEMENT Optimizer Mode=CHOOSE 1 51
    SORT AGGREGATE 1 37
    HASH JOIN 48 K 1 M 51
    TABLE ACCESS FULL A 68 K 998 K 32
    NESTED LOOPS 98 K 2 M 5
    TABLE ACCESS BY INDEX ROWID B 142 K 2 M 4
    INDEX SKIP SCAN XIF37B 142 K 6
    INDEX UNIQUE SCAN XPKC 1 5

    Mcka
    As well as EXPLAIN PLAN, let us know what proportion of rows are visited by this query. It may be that it is not using a full table scan when it should (or vice versa).
    And of course we'd need to know what indexes are available, and how selective they are for the predicated you have in this query ...
    Regards Nigel

  • Explain plan : need advice in improving performance

    Hi,
    DB : 10.2.0.4
    platform: Solaris
    SGA: 8 G
    one of my query is taking too much time, explain plan gives below output.
    kindly advise what i can do to improve the performance
    PLAN_TABLE_OUTPUT
    Plan hash value: 430877948
    | Id  | Operation                    | Name                          | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                               |  8143 | 1081K| 31130   (1)| 00:06:14 |
    |*  1 | FILTER | |       |       |            |          |
    |*  2 | TABLE ACCESS BY INDEX ROWID| ID_TICKET_DETAILS             |  8143 | 1081K|   494   (0)| 00:00:06 |
    |*  3 | INDEX SKIP SCAN           | TKT_IDX_21                    |     1 | |   493   (0)| 00:00:06 |
    |*  4 | TABLE ACCESS BY INDEX ROWID| ID_DELIVERY_DEBIT_SLIP_DETAIL |     1 | 34 |     3   (0)| 00:00:01 |
    |   5 | NESTED LOOPS              |                               |     2 | 124 |     7   (0)| 00:00:01 |
    |*  6 | TABLE ACCESS FULL        | ID_DELIVERY_DEBIT_SLIP_HEADER | 32243 | 881K|     2   (0)| 00:00:01 |
    |*  7 | INDEX RANGE SCAN         | DSD_DELIVERY_DEBIT_UKEY       |     1 | |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "ID_DELIVERY_DEBIT_SLIP_HEADER"
    "ID_DELIVERY_DEBIT_SLIP_HEADER","ID_DELIVERY_DEBIT_SLIP_DETAIL" "ID_DELIVERY_DEBIT_SLIP_DETAIL" WHERE
    "DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
    "DSH_COMPANY"="DSD_COMPANY" AND "DSD_TICKET_NUMBER" IS NOT NULL AND
    LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER") AND "DSH_DELIVERY_DEBIT"='DEBIT'))
       2 - filter((:1 IS NULL OR "TICKET_AIRLINE"=:2) AND "TICKET_REFERENCE_2" IS NULL AND
    "TICKET_RECEIPT_NUMBER" IS NULL AND "TICKET_CARD_RECEIPT_NUMBER" IS NULL AND
    "TICKET_SYSTEM_DOC_NUMBER" IS NULL)
       3 - access("TICKET_REFERENCE_1" IS NULL)
           filter("TICKET_REFERENCE_1" IS NULL AND TO_NUMBER("TICKET_COMPANY")=1)
       4 - filter("DSD_TICKET_NUMBER" IS NOT NULL AND LNNVL(:B1||:B2<>"DSD_AIRLINE"||"DSD_TICKET_NUMBER"))
       6 - filter("DSH_DELIVERY_DEBIT"='DEBIT')
       7 - access("DSH_COMPANY"="DSD_COMPANY" AND "DSH_DOCUMENT_TYPE"="DSD_DOCUMENT_TYPE" AND
    "DSH_DOCUMENT_NUMBER"="DSD_DOCUMENT_NUMBER")
    Note
       - SQL profile "SYS_SQLPROF_014f902e2ea4c002" used for this statement

    some comments:
    it would be more simple to read the plan with indentatitions: you could use a fixed-width font
    it's hard to tell much about the plan without seeing the corresponding query (though in this case the predicate section gives some information on the query - especially step 1)
    the plan shows the use of a sql profile: so the CBO uses additional statistics to generate the plan
    in step 3 there is an index skip scan: that's only a good idea if there are few distinct values for the leading column of the index and the selectivity of "TICKET_REFERENCE_1" IS NULL is good
    in step 6 there is a Full Table Scan for the driving table of a nested loops join: the cost value for the scan is very small and so is the cost for the complete NL join - and that could be misleading
    I would use the gather_plan_statistics hint to get a plan with rowsource statistics to check if the cardinalities the CBO works with are correct. If they are not you could try to disable the profile (or create a new profile; of course after checking who created the profile and for what reasons). With an accurate sql profile the CBO should have enough information to create an accurate plan in most cases.
    Regards
    Martin

  • Using a Value index on XMLIndex path table.

    I am trying to understand how to capitalize on the VALUE index created on a XMLIndex path table. So far, I have not been able to successfully use it. I am not sure whether I am misunderstanding the way it is intended to be used? Or am making a mistake somewhere else along the way. Here is a use-case where I think that it should be getting picked up by the optimizer:
    CREATE TABLE TEST_TABLE
        (ID VARCHAR2(128) NOT NULL,
        XML_DATA XMLTYPE NOT NULL,
        CONSTRAINT TEST_PK PRIMARY KEY (ID))
    XMLTYPE COLUMN XML_DATA STORE AS BINARY XML;
    -- Populate the table with some random data.  Here, our single attribute should be
    -- unique for each row.
    INSERT INTO TEST_TABLE (
      SELECT dbms_random.string('A', 15), XMLElement("Test", XMLAttributes(dbms_random.string('A', 15) as "someAttr"))
      FROM DUAL
      CONNECT BY LEVEL <= 20000 );
    CREATE INDEX test_xmlindex_ix ON TEST_TABLE(XML_DATA) INDEXTYPE IS XDB.XMLIndex
      PARAMETERS('
        PATHS (Include (/Test/@someAttr))
        PATH TABLE      test_path_table
        PATH ID INDEX   test_path_id_ix
        ORDER KEY INDEX test_key_ix
        VALUE INDEX     test_value_ix ');
    -- Not sure if I need these or not?
    CALL DBMS_STATS.GATHER_TABLE_STATS ('MYSCHEMA', 'TEST_TABLE');
    CALL DBMS_STATS.GATHER_TABLE_STATS ('MYSCHEMA, 'TEST_PATH_TABLE');
    -- Now, I would expect this query to use the Value index that was created.
    -- Instead, the Explain plan indicates that TEST_PATH_ID_IX was used..
    SELECT xml_data
    FROM   test_table v
    WHERE  extractValue(v.xml_data, '/Test/@someAttr') = ?
    Here are the operations listed in the explain plan for the query:
    SELECT STATEMENT
    FILTER
    TABLE ACCESS(FULL) MYSCHEMA.TEST_TABLE
    TABLE ACCESS(BY INDEX ROWID) MYSCHEMA.TEST_PATH_TABLE
    INDEX(RANGE SCAN) MYSCHEMA.TEST_PATH_ID_IXIf I understand everything correctly, here, there is no reason why the PATH ID index should have been used. Isn't this index strictly for the XML tags themselves? Why wouldn't it use the Value index?
    Thanks,
    Jon

    PATH_TABLE
    +=======================================================+
    | PathID |  RID  | Order_Key | Locator |     Value      |
    |-------------------------------------------------------|
    |  RAW   | rowid |    RAW    |   RAW   | varchar2(4000) |
    |-------------------------------------------------------|
    |        |       |           |         |                |
    |        |       |           |         |                |
    |        |       |           |         |                |
    |        |       |           |         |                |
    |        |       |           |         |                |
    |        |       |           |         |                |
    |        |       |           |         |                |
    +=======================================================+
    XMLIndex
    1) PATH  INDEX: (PathID, RID)              - BTree
    2) ORDER INDEX: (RID, ORDER_KEY)           - BTree
    3) VALUE INDEX: (substr("VALUE",1,1599))   - Function Based
    Locator: Pointer to XML Fragments
    XMLIndex - Namespace issue...
    I believe that (although I don't know the exact mechanics) that it will use the path index first to find the needed
    tree node / path, then will look for a locator that matches the request and if not will do an full table scan
    afterwards, if not successful, trying to limit the request with the filter at hand, so see if it can be used, to
    minimize the sub-results.
    Message was edited by:
    Marco Gralike

Maybe you are looking for

  • Need help converting MAC OS 9 to MAC OS X sound files - PLEASE HELP

    Hi, I have some old MAC OS 9 sounds that I would like to convert to work with MAC OSX. I noticed that these files I backed up on CD years ago are now reading as Unix Executable Files. How do I convert them to work with MAC OS X? Sincerely, Drew

  • Application hotkeys and keyboard layouts in KDE[SOLVED]

    Hi, For as long as I use Linux, I've been annoyed by this particular trouble: change layout from en to ru, for instance, and get your hotkeys (like Ctrl-S) unresponsive. Granted, that the trouble sometimes goes - to come back later on . I tried Googl

  • Error BC30198 ')' Expected

    I'm trying to perform a series of calculations in SSDT 12 and the first I thought would be extremely basic. It works as an expression in a textbox but when I try the same thing in a variable I get an error. I'm trying to do "85 - used percentage". Us

  • JSF ViewExpiredException

    We are getting ViewExpiredException in our application which is based on SEAM framework... It is using Mojara implementation of JSF (version 1.2_12) ... Issues comes only few times during few form submission events and not able to reproduce at all. B

  • Expression

    How do I query for a end_date > sysdate using the Expression ? My equivalent query in plsql select * from myTable where ( end_date is null or end_date > sysdate ) I have: Expression exp1 = myObj.get("end_date").equal(null); I need to add the sysdate