Is it possible to avoid  "BY INDEX ROWID" access?

Hi,
I'm running a query for the primary key of a table that has a text index on a text column, something like
SELECT pkey FROM table WHERE CONTAINS( text, 'foobar' ) > 0.
As expected, the index is scanned for the matching ROWIDs and then the rows are retrieved ( BY INDEX ROWID ).
I wonder if its possible to include the primary key column in the text index, so that the table doesn't have to be access at all when querying for the primary key ( this is possible with regular indexes ).
I tried
1. creating a Composite Domain Index ( i.e. including the primary key column in the FILTER BY clause of the index )
2. creating a SDATA section on pkey
3. creating a MDATA section on pkey
In all cases, the rows were still accessed by ROWID.
Any ideas?

Our index is called "docidx". We are looking for the term "oracle". We want a count of the total hits, and a hitlist of the first two hits. For each hit we want to fetch back "author" and "pubDate" sdata sections, as well as the rowid.
We also want some summary information: for pubDate and author sections we want a count for each unique value in each section.
ctx_query.result_set('docidx', 'oracle',
    '<ctx_result_set_descriptor>
       <count/>
         <hitlist start_hit_num="1" end_hit_num="2" order="pubDate desc, score desc">
           <score/> <rowid/>
           <sdata name="author"/>
           <sdata name="pubDate"/>
         </hitlist>
       <group sdata="pubDate">
         <count/>
       </group>
       <group sdata="author">
         <count/>
       </group>
    </ctx_result_set_descriptor> ', rs); The output of that query (returned in the value "rs") is:
<ctx_result_set>
  <hitlist>
    <hit>
      <score>3</score><rowid>AAAPoEAABAAAMWsAAC</rowid>
      <sdata name="AUTHOR">John</sdata>
      <sdata name="PUBDATE">2001-01-03 00:00:00</sdata>
    </hit>
    <hit>
      <score>3</score><rowid>AAAPoEAABAAAMWsAAG</rowid>
      <sdata name="AUTHOR">John</sdata>
      <sdata name="PUBDATE">2001-01-03 00:00:00</sdata>
    </hit>
  </hitlist>
  <count>100</count>
  <groups sdata="PUBDATE">
     <group value="2001-01-01 00:00:00"><count>25</count></group>
     <group value="2001-01-02 00:00:00"><count>50</count></group>
     <group value="2001-01-03 00:00:00"><count>25</count></group>
   </groups>
   <groups sdata="AUTHOR">
     <group value="John"><count>50</count></group>
     <group value="Mike"><count>25</count></group>
     <group value="Steve"><count>25</count></group>
   </groups>
</ctx_result_set>

Similar Messages

  • 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.

  • Is it possible to create an Index in Pages '08?

    I've searched the docs and scanned the forum, but I can't find any details (or even a mention) of document index creation. I'm using Pages to create technical books (moving from Word/Quark).
    Is it possible to generate an index in Pages?

    Hello
    With the "in-the-box" features, the response is no.
    But I'm not aware of every piece of code offered by third-party developers.
    Maybe some one built such a tool.
    After all, it would not be a huge task as the application is AppleScritable.
    No, I'm not in the starting blocks
    Yvan KOENIG (from FRANCE jeudi 17 janvier 2008 22:46:23)

  • Is it possible to avoid duplicate material in Sale order creation

    Dear SD gurus
    Is it possible to avoid material duplication in va01 sale order creation. For amendment purpose the marketing user making new line item with amended qty instead of quantity change. kindly advise me to solve the problem.
    Thanks & Regards
    R.Udayakumar

    HI,
    There's no alternative to user disciplibe . Business reqt are sometimes like this only
    what you can do is use exit mv45afzz in saels order and put coding logic . this will surely work.
    {Removed by Moderator}
    regards
    Edited by: Lakshmipathi on Aug 29, 2009 6:13 PM

  • TA38633 is it possible to avoid having to do a "restore" entirely ? Also if i have to do a restore, i have windows 7- do i follow the steps for Windows XP?

    Regarding error 1601 - is it possible to avoid having to do a "restore" entirely ?
    Also if i have to do a restore, i have windows 7- do i follow the steps for Windows XP?
    Many thanks

    I'd refer to this
    http://support.apple.com/kb/TS3694 (talks about security software and this error)
    and this
    http://support.apple.com/kb/HT1414
    I've had Windows 7 for a while, but it seems the steps in iTunes are identical. 

  • 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');

  • Oracle 9.2 prefers Table Access Full over Local Index by rowid access

    There's this table that has phone call records (30 million per day) that is partitioned by month (using the date column) and stores the last 6 months.
    The primary key is date (varchar2 in yymmdd format) + call_id (a varchar2(18) with a format like this yyyymmdd+<3letters>+<sequentialnumber>)
    The partition is by range like this:
    PARTITION BY RANGE (FECHA)
    PARTITION P200804 VALUES LESS THAN ('080501')
    LOGGING
    NOCOMPRESS,
    If I run this query I get this plan
    SELECT FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID,COUNT(*)
    FROM GES_CDRS_RCNG_NEW
    WHERE FECHA BETWEEN '080801' AND '080825'
         AND TASACION IS NULL
         AND BORRADO IS NULL
    GROUP BY FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID
    Plan
    SELECT STATEMENT CHOOSECost: 78 K Bytes: 24 K Cardinality: 1 K           
         2 SORT GROUP BY Cost: 78 K Bytes: 24 K Cardinality: 1 K      
              1 TABLE ACCESS FULL GESTION.GES_CDRS_RCNG_NEW Cost: 43 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5
    If I hint the primary key index using /*+INDEX(GES_CDRS_RCNG_NEW PK_CDRS_RCNG_NEW)*/
    I get a different plan
    Plan
    SELECT STATEMENT CHOOSECost: 954 K Bytes: 24 K Cardinality: 1 K                
         3 SORT GROUP BY Cost: 954 K Bytes: 24 K Cardinality: 1 K           
              2 TABLE ACCESS BY LOCAL INDEX ROWID GESTION.GES_CDRS_RCNG_NEW Cost: 918 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5     
                   1 INDEX RANGE SCAN UNIQUE GESTION.PK_CDRS_RCNG_NEW Cost: 137 K Cardinality: 31 M Partition #: 3 Partitions accessed #5
    Looking at the cost, the full scan is way better, but this is obviously not the case. Why does this happen?
    This problem forces many querys on this table to use hints or force the index use by adding conditions to the where clause like this
    where fecha = '080801'
    and clave like '20080801%'
    when just by stating the date would be enough to choose the correct partition. It also messes up joins with other tables.
    The table is analized every month, it has statistics that claim: 237,981,000 rows, 3,222,677 blocks, GLOBAL STATS: YES, LAST ANALYZED: 15/10/2008 21:05:26, Average row length: 213.
    The partition envolved in this query has this stats: 32,520,520 rows, 442,715 blocks, analized on 27/08/2008 20:43:40
    The index has this stats: analized on 15/10/2008 21:35:32, Blevel: 3, leaf blocks: 1,056,410, distinct keys: 238,484,510.
    It is a local index and each partition has its own statistics.

    If I don't understand incorrectly the plan and the Predicater information, it seems the full scan version that costs less is actually doing a full scan from the biggining of the table (6 months) up to the 080825 date and the one using an index (hinted) does a better scan.
    without hint
    | Id  | Operation            |  Name              | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT     |                    |  1170 | 24570 | 78443 |       |       |
    |   1 |  SORT GROUP BY       |                    |  1170 | 24570 | 78443 |       |       |
    |*  2 |   TABLE ACCESS FULL  | GES_CDRS_RCNG_NEW  |    31M|   625M| 42579 |     5 |     5 |
    Predicate Information (identified by operation id):
       2 - filter("GES_CDRS_RCNG_NEW"."FECHA"<='080825')
    Note: cpu costing is offWith the hint:
    | Id  | Operation                          |  Name              | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT                   |                    |  1170 | 24570 |   953K|       |       |
    |   1 |  SORT GROUP BY                     |                    |  1170 | 24570 |   953K|       |       |
    |   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| GES_CDRS_RCNG_NEW  |    31M|   625M|   918K|     5 |     5 |
    |*  3 |    INDEX RANGE SCAN                | PK_CDRS_RCNG_NEW   |    31M|       |   136K|     5 |     5 |
    Predicate Information (identified by operation id):
       3 - access("GES_CDRS_RCNG_NEW"."FECHA">='080801' AND "GES_CDRS_RCNG_NEW"."FECHA"<='080825')
    Note: cpu costing is off

  • Encore CS6 not possible to avoid transcoding

    Why does encore CS6 transcode some H.264 streams and some not? They are different sequences exported from the same project with the same settings out of premiere CS6. The parameters of all streams equal the settings in encore. But for some it is not possible to change the setting in encore to not transcode.

    Yes, I used H.264 Bluray 1440x1080 anamorph. I guess Encore ignored the anamorph flag for some files and transcoded them a second time to 1440x1080 - the result is a visible frame with a distorted 4:3 aspect ratio. I have found a resolution. I replaced the transcoded files in the encore transcode folder with copies of the original files and renamed them like the transcoded files: "original filename"_sessionFiles_Asf_session_1_video.m4v
    Perhaps its possible to avoid transcoding by simply placing renamed copies (in that name system above) of the original files in the transcode folder. I will try it in the future.

  • How to Avoid Redundant Indexes on Indexed Views

    Let's say I have an indexed view - so far it only has a clustered index. I want to avoid redundant indexes. So let's say the view joins Customers and Orders. If I've already put a nonclustered index on every column in both base tables, it's a pretty sure
    bet that adding nonclustered indexes to the view will be redundant, right? Or not?  I'm not understanding this.

    The indexes on the view are not redundant even if on the same columns as the base tables.  The indexes on view columns materialize the result after joins and aggregations in the view query.
    Columns should generally be indexed only if they are used in join or where clauses.  An index on every column may be overkill. 
    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

  • Is it possible to created secondary indexes on ODS in Production

    Hi,
    Is it possible to created secondary indexes on ODS in Production System. I need to create secondary indexes on ODS but it is already in production. Hence Can I directly create secondary indexes without transportation from dev to production?

    Hi,
    Secondary Indexes for DSO can be transported. For the transport the DSO objects needs to be transported (R3TR ODSO <technical name>.
    Additionally, secondary Indexes are necessary quite often for DSO tables, which can be transported. In few cases you need indexes on other BW tables, but they cannot be transported. Never create additional Indexes on InfoCube tables (like E- and F-Fact tables and Dimension tables)
    Thanks & B.R.
    Vince

  • I use photoshop 6 (mac) if I subscribe to Premier CC do I have to subscribe to Photoshop CC also I want to use 6 as long as possible to avoid the subscriptions fees

    I use photoshop 6 (mac) if I subscribe to Premier CC do I have to subscribe to Photoshop CC also I want to use 6 as long as possible to avoid the subscriptions fees

    Completely separate products, so nothing to fear.
    Mylenium

  • 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

  • Sql developer 3.0: could be possible to avoid creating connections

    Hi, when connecting from oracle forms, you don't have to create a connection, in the same way I don't know if could be possible to avoid creating connections when you are using a tnsnames.ora archive.
    simple to choose the connection as in oracle forms, and the posibility to save the password.
    thank you

    As stated in the forum announcement, you can request this at the SQL Developer Exchange, so other users can vote and add weight for possible future implementation.
    Regards,
    K.

  • Using an index to access the last n values of a certain combination

    I have a large table of the following form:
    Name Typ
    ID NUMBER
    M_DATE DATE
    M_LOC NUMBER
    M_ARTICLE VARCHAR2(30)
    M_TYPE VARCHAR2(30)
    M_MEASURE VARCHAR2(50)
    VALUE NUMBER
    In this table there is only a small number of different locations, articles, types and maesures but a large number of m_date values.
    I want to access the last 10 values for a certain combination of locations, articles, types and measures.
    I have an index
    create index i_res_2 on results (m_loc, m_article, m_type, m_measure, m_date);
    In my opinion it should be possible to access the last 10 values directly by this index, but
    when I do my select in the following way it seems to me that first all datasets with the same
    locations, articles, types and maesures are selected, then sorted by date and then the last 10
    dates are selected. As those datasets are spread over the whole table it needs a higher number
    of physical reads. Is there a way to have an index on m_date and an other form of this query
    that selects the requested values with less phyical reads? (Database version is 10.2)
    SQL> select
    2 id,
    3 m_date,
    4 value
    5 from (
    6 select
    7 id,
    8 m_date,
    9 value,
    10 rank() over (order by m_date desc) r
    11 from results
    12 where m_loc = '14001'
    13 and m_article = '11211-00-00'
    14 and m_type = '0002'
    15 and m_measure = '032')
    16 where r <= 10
    17 order by m_date asc;
    ID M_DATE Value
    3931958 05.03.10 69.00
    3931960 05.03.10 69.00
    3905712 10.03.10 68.60
    3999535 10.03.10 69.70
    3985125 11.03.10 69.40
    3957851 11.03.10 69.60
    3949799 21.03.10 68.70
    4017369 21.03.10 69.00
    3951981 22.03.10 68.80
    3983554 22.03.10 68.80
    Abgelaufen: 00:00:03.00
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 48 | 6 (34)| 00:00:01 |
    | 1 | SORT ORDER BY | | 1 | 48 | 6 (34)| 00:00:01 |
    |* 2 | VIEW | | 1 | 48 | 5 (20)| 00:00:01 |
    |* 3 | WINDOW SORT PUSHED RANK | | 1 | 39 | 5 (20)| 00:00:01 |
    | 4 | TABLE ACCESS BY INDEX ROWID| RESULTS | 1 | 39 | 4 (0)| 00:00:01 |
    |* 5 | INDEX RANGE SCAN | I_RES_2 | 1 | | 3 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - filter("R"<=10)
    3 - filter(RANK() OVER ( ORDER BY INTERNAL_FUNCTION("M_DATE") DESC )<=10)
    5 - access("M_LOC"=14001 AND "M_ARTICLE"='11211-00-00' AND "M_TYPE"='0002' AND
    "M_MEASURE"='032')
    Statistiken
    1 recursive calls
    0 db block gets
    547 consistent gets
    474 physical reads
    0 redo size
    766 bytes sent via SQL*Net to client
    380 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    2 sorts (memory)
    0 sorts (disk)
    10 rows processed

    I found a solution, which is much better in terms of physical reads and consistent gets even if the optimizer calculates higher costs. But I still think, that there should be an easier way to do this:
    SQL> select
    2 id, m_date, value from results
    3 where
    4 (m_loc, m_article, m_type, m_measure, m_date)
    5 in
    6 (select m_loc, m_article, m_type, m_measure, m_date
    7 from (
    8 select /*+ first_rows(10) */ m_loc, m_article, m_type, m_measure, m_date
    9 from results
    10 where m_loc = '14001'
    11 and m_article = '11370-00-00'
    12 and m_type = '0002'
    13 and m_measure = '032'
    14 order by m_loc,m_article,m_type,m_measure,m_date desc
    15 ) where rownum < 10);
    ID M_DATE VALUE
    2495995 01.02.09 70,4
    2457657 19.01.09 66,9
    2556262 13.02.09 67,4
    2496232 01.02.09 67,6
    2465051 20.01.09 67
    2454994 19.01.09 67,4
    2545951 13.02.09 67,4
    2502216 01.02.09 67,5
    2497533 01.02.09 67,2
    9 Zeilen ausgewählt.
    Ausführungsplan
    Plan hash value: 3924867000
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 122 | 8 (25)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| RESULTS | 1 | 39 | 3 (0)| 00:00:01 |
    | 2 | NESTED LOOPS | | 1 | 122 | 8 (25)| 00:00:01 |
    | 3 | VIEW | VW_NSO_1 | 1 | 83 | 4 (25)| 00:00:01 |
    | 4 | HASH UNIQUE | | 1 | 31 | | |
    |* 5 | COUNT STOPKEY | | | | | |
    | 6 | VIEW | | 1 | 31 | 4 (25)| 00:00:01 |
    |* 7 | SORT ORDER BY STOPKEY| | 1 | 31 | 4 (25)| 00:00:01 |
    |* 8 | INDEX RANGE SCAN | I_RES_2 | 1 | 31 | 3 (0)| 00:00:01 |
    |* 9 | INDEX RANGE SCAN | I_RES_2 | 1 | | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    5 - filter(ROWNUM<10)
    7 - filter(ROWNUM<10)
    8 - access("M_LOC"=14001 AND "M_ARTICLE"='11370-00-00' AND "M_TYPE"='0002'
    AND "M_MEASURE"='032')
    9 - access("M_LOC"="$nso_col_1" AND "M_ARTICLE"="$nso_col_2" AND
    "M_TYPE"="$nso_col_3" AND "M_MEASURE"="$nso_col_4" AND "M_DATE"="$nso_col_5")
    Statistiken
    1 recursive calls
    0 db block gets
    36 consistent gets
    14 physical reads
    0 redo size
    748 bytes sent via SQL*Net to client
    381 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    9 rows processed

  • Invisible index getting accessed during query execution

    Hello Guys,
    There is a strange problem , I am encountering . I am working on tuning the performance of one of the concurrent request in our 11i ERP System having database 11.1.0.7
    I had enabled oradebug trace for the request and generated tkprof out of it. For below query which is taking time , I found that , in the trace generated , wait event is "db file sequential read" on an PO_LINES_N10 index but in the generated tkprof , for the same below query , the full table scan for PO_LINES_ALL is happening , as that table is 600 MB in size.
    Below is the query ,
    ===============
    UPDATE PO_LINES_ALL A
    SET A.VENDOR_PRODUCT_NUM = (SELECT SUPPLIER_ITEM FROM APPS.IRPO_IN_BPAUPDATE_TMP C WHERE BATCH_ID = :B1 AND PROCESSED_FLAG = 'P' AND ACTION = 'UPDATE' AND C.LINE_ID =A.PO_LINE_ID AND ROWNUM = 1 AND SUPPLIER_ITEM IS NOT NULL),
    LAST_UPDATE_DATE = SYSDATE
    ===============
    Index PO_LINES_N10 is on the column LAST_UPDATE_DATE , logically for such query , index should not have got used as that indexed column is not in select / where clause.
    Also, why there is discrepancy between tkprof and trace generated for the same query .
    So , I decided to INVISIBLE the index PO_LINES_N10 but still that index is getting accessed in the trace file .
    I have also checked the below parameter , which is false so optimizer should not make use of invisible indexes during query execution.
    SQL> show parameter invisible
    NAME TYPE VALUE
    optimizer_use_invisible_indexes boolean FALSE
    Any clue regarding this .
    Thanks and Regards,
    Prasad
    Edited by: Prasad on Jun 15, 2011 4:39 AM

    Hi Dom,
    Sorry for the late reply , but yes , an update statement is trying to update that index even if it's invisible.
    Also, it seems performance issue started appearing when this index got created , so now I have dropped that index in test environment and ran the concurrent program again with oradebug level 12 trace enabled and found bit improvement in the results .
    With index dropped -> 24 records/min got processed
    With index -> 14 records/min got processed
    so , I am looking forward without this index in the production too but before that, I have concerns regarding tkprof output. Can we further improve the performance of this query.
    Please find the below tkprof with and without index .
    ====================
    Sql statement
    ====================
    UPDATE PO_LINES_ALL A SET A.VENDOR_PRODUCT_NUM = (SELECT SUPPLIER_ITEM FROM
    APPS.IRPO_IN_BPAUPDATE_TMP C
    WHERE
    BATCH_ID = :B1 AND PROCESSED_FLAG = 'P' AND ACTION = 'UPDATE' AND C.LINE_ID =
    A.PO_LINE_ID AND ROWNUM = 1 AND SUPPLIER_ITEM IS NOT NULL),
    LAST_UPDATE_DATE = SYSDATE
    =========================
    TKPROF with Index for the above query ( processed 643 records )
    =========================
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 2499.64 2511.99 98158 645561632 13105579 1812777
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 2499.64 2511.99 98158 645561632 13105579 1812777
    =============================
    TKPROF without Index for the above query ( processed 4452 records )
    =============================
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 10746.96 10544.13 84125 3079376156 1870058 1816289
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 10746.96 10544.13 84125 3079376156 1870058 1816289
    =============================
    Explain plan which is same in both the cases
    =============================
    Rows Row Source Operation
    0 UPDATE PO_LINES_ALL (cr=3079377095 pr=84127 pw=0 time=0 us)
    1816289 TABLE ACCESS FULL PO_LINES_ALL (cr=83175 pr=83026 pw=0 time=117690 us cost=11151 size=29060624 card=1816289)
    0 COUNT STOPKEY (cr=3079292918 pr=20 pw=0 time=0 us)
    0 TABLE ACCESS BY INDEX ROWID IRPO_IN_BPAUPDATE_TMP (cr=3079292918 pr=20 pw=0 time=0 us cost=4 size=22 card=1)
    180368800 INDEX RANGE SCAN IRPO_IN_BPAUPDATE_N1 (cr=51539155 pr=3 pw=0 time=16090005 us cost=3 size=0 card=1)(object id 372721)
    There is a lot increase in the CPU ,so I would like to further tune this query. I have run SQL Tuning task but didn't get any recommendations for the same.
    Since in the trace , I have got db scattered read wait event for the table "PO_LINES_ALL" but disk reads are not much , so am not sure the performance improvement even if I pin this table (620 MB in size and is it feasible to pin , SGA is 5GB with sga_target set ) in the shared pool .
    I have already gathers stats for the concerned tables and rebuilt the indexes .
    Is there any other thing that can be performed to tune this query further and bring down CPU, time taken to execute.
    Thanks a lot for your reply.
    Thanks and Regards,
    Prasad
    Edited by: Prasad on Jun 28, 2011 3:52 AM
    Edited by: Prasad on Jun 28, 2011 3:54 AM
    Edited by: Prasad on Jun 28, 2011 3:56 AM

Maybe you are looking for