Cartesian Query

Hi,
I'm using Toplink 11g with Weblogic 10.3.0.
The application is generating query having cartesian product on one single table; here goes an example;
SELECT t0.ID_REQUEST,
t0.RD_NUM_RETRY,
t0.RD_START_TIME,
t0.EVENT_ID,
t0.RD_END_TIME,
t0.MSISDN,
t0.RD_STATUS,
t0.RET_MESSAGE,
t0.REQUEST,
t0.RD_BILL_DATE,
t0.SERVICE_CLASS,
t0.CSP,
t0.SERVICE_ID,
t0.RET_CODE,
t0.SERVICE_KEY,
t0.RD_ID,
t0.SERVICE_NAME,
t0.RD_CESS,
t0.TOTAL_AMOUNT,
t0.BILLED_PARTIAL
FROM BILLING_NOT_SUCCESS t0, BILLING_NOT_SUCCESS t1
WHERE ( ( ( ( (t0.RD_STATUS = 'PARKED') AND (t0.RD_END_TIME > SYSDATE))
AND (t0.RD_CESS = 0))
AND (t1.MSISDN = xxxxxxxxx))
Is there any particular reason for this or it's simply an error?
I'm afraid of the owerhead generated by this cartesian product: How can I (should I?) avoid Toplink to generate query of this kind?
Thank you veri much indeed.
AND (t1.RET_CODE IN ('006', '201', '058')));
L.D.

Hi,
thank you very much for answering.
I'm using toplink, included adding toplink.jar in classpath of my Weblogic project.
Weblogic version is 10.3.0. (no JPA2.0). It's used to implement data access metods beeing used by SINGLETON Clustered application.
Sessions are configured as SERVERSessions distributed by a broker.
Sessions are configured in sessions.xml.
Thi is the most external methos building the query:
public List<BillingNotSuccess> getFNDRecords(String msisdn) throws Exception {
     List<BillingNotSuccess> billRes = null;
     Expression exp = null, exp1 = null;
     exp = getConditions().and(exprBuild.get("msisdn").equal(msisdn));
     String retCodeCondition = null;
     String valueR = configurator.getParameterValue(Parameters.PARAM_RETRY_CODES_RELOAD);
     logger.debug("mcss.retry.codes.reload: "+valueR);
     if (valueR != null && !valueR.equalsIgnoreCase("")){
          retCodeCondition = valueR;
     String valueP = configurator.getParameterValue(Parameters.PARAM_RETRY_CODES_PARTIAL);
     logger.debug("mcss.retry.codes.partial: "+valueP);
     if (valueP != null && !valueP.equalsIgnoreCase("")){
          retCodeCondition = (retCodeCondition!=null)?retCodeCondition+","+valueP:valueP;
     if (retCodeCondition != null){
          exp1 = exprBuild.get("retCode").in(retCodeCondition.split(","));
     billRes =  readWithConditionOrdering(BillingNotSuccess.class, "rdStartTime", exp.and(exp1));
     traceResult(billRes);
     return billRes;
This is the method used to build AND conditions shared by other business methods:
private Expression getConditions() throws Exception {
     Expression exp = null, exp1 = null, exp2 = null;
     exprBuild = new ExpressionBuilder(BillingNotSuccess.class);
     exp = exprBuild.get("rdStatus").equal("PARKED");
     exp1 = exprBuild.get("rdEndTime").greaterThan(new Date());
     exp2 = exprBuild.get("rdCess").equal(0);
     return exp.and(exp1).and(exp2);
Thank you very much again and please let me know if I can help with any further details.
Best regards.
L.D.

Similar Messages

  • Merge Join Cartesian performing bad on 10g

    Hello All,
    I have a merge join cartesian query that took seconds in 8i. Once the database was upgraded to 10g, the same query is taking hours. In looking at the explain plans, it looks like the access paths are identical.
    Has anyone encountered this issue?
    Thanks.

    Sometimes the cost-based optimizer will do cartesian joins to optimize a query. Seeing the word "cartesian" in a query plan is still a major red flag to my eyes. Also, performance changes between versions are usually expected, though most people complain about 9i to 10g results these days :)
    Are you sure you need to be doing a cartesian join at all? As Fly pointed out they have a bad reputation, and yours must be running badly as per your post. I personally get more efficient results from hash joins over sort merges these days so that's something you can look at.
    Try variations on your query to generate execution plans to see if you can get better results. Don't forget to actually time results since plan statistics have been known to be out-of-touch with actual run performance.
    Good luck!

  • Query resulting in cartesian product-plz help

    select count(distinct e.hiredate),count(distinct b.hiredate) from scott.emp e, scott.emp b where e.hiredate<to_date('01-DEC-80','DD-MON-YY') and b.hiredate<to_date('23-JUN-81','DD-MON-YY')

    Hi,
    When I query it individually its giving me as below and its correct.
    SQL> select count(hiredate) from scott.emp where hiredate<'01-DEC-81';
    COUNT(HIREDATE)
    9
    SQL> select count(hiredate) from scott.emp where hiredate<'23-JUN-81';
    COUNT(HIREDATE)
    6
    Now I want these two merged in same query and it should give me the same result
    SQL> select count(distinct e.hiredate),count(distinct b.hiredate) from scott.emp
    e, scott.emp b where e.hiredate<'01-DEC-80' and b.hiredate<'23-JUN-81';
    COUNT(DISTINCTE.HIREDATE) COUNT(DISTINCTB.HIREDATE)
    0 0
    But its giving me either cartesian product or the result above.
    I have already used logical operator AND .

  • Query having cartesian product

    hi
    i have the following query
    select f.item_number, case when f.item_number='1020101002' then f.calc_cement_sk else f.calc_amount end act
                from XXNP_OPN_JOBLOG_EST_002 F WHERE f.OPN_JOBLOG_001_ID ='6369'
    output
    ITEM_NUMBER     ACT
    1020101001     NULL
    1020111001     NULL
    1020112001     NULL
    1020113004     NULL
    1020101002     494
    1020102007     232
    1020103004     37
    1020104004     557
    1020106002     20896
    1020111001     5
    1020112005     16253
    1020112008     46
    1020113004     40
    1020222010     1393
    ie 14 rows
    another query
    SELECT J.ITEM_NUMBER,j.opn_value  FROM XXNP_OPN_JOBLOG_RES_005 J  WHERE  J.OPN_JOBLOG_001_ID ='6369' 
    output
    ITEM_NUMBER     OPN_VALUE
    1010101003     1
    1010101004     3
    1010101005     2
    1010104016     1
    1010103001     76
    1010103002     228
    1010106001     2
    1010106006     147
    1010107010     1
    1010109009     1
    1010107015     866
    1010107014     799
    1010107016     1631
    ie 13 rows
    when i do
    select f.item_number, case when f.item_number='1020101002' then f.calc_cement_sk else f.calc_amount end act ,j.opn_value
           from XXNP_OPN_JOBLOG_EST_002 F ,XXNP_OPN_JOBLOG_RES_005 J   where   f.OPN_JOBLOG_001_ID = J.OPN_JOBLOG_001_ID and f.OPN_JOBLOG_001_ID ='6369'
    i get 182 rows :( i know its due to cartesian product
    is there any way i can get 27 rows  only ,can i get the output in the format given below
    ITEM_NUMBER     ACT                  opn_value
    1020101001     NULL
    1020111001     NULL
    1020112001     NULL
    1020113004     NULL
    1020101002     494
    1020102007     232
    1020103004     37
    1020104004     557
    1020106002     20896
    1020111001     5
    1020112005     16253
    1020112008     46
    1020113004     40
    1020222010     1393
    1010101003                                                                     1                                                    
    1010101004                                                                     3                                                              
    1010101005                                                                      2
    1010104016                                                                      1
    1010103001                                                                     76
    1010103002                                                                      228
    1010106001                                                                      2
    1010106006                                                                     147
    1010107010                                                                      1
    1010109009                                                                        1
    1010107015                                                                      866
    1010107014                                                                      791
    1010107016                                                                    1631kindly guide
    thanking in advance
    Edited by: makdutakdu on Mar 31, 2011 8:03 AM

    hi
    script for XXNP_OPN_JOBLOG_RES_005
    CREATE TABLE XXNP_OPN_JOBLOG_RES_005
      OPN_JOBLOG_005_ID  NUMBER,
      OPN_JOBLOG_001_ID  NUMBER,
      WIP_ENTITY_ID      NUMBER,
      WIP_ENTITY_NAME    VARCHAR2(240 BYTE),
      OPN_RESOURCE_CODE  VARCHAR2(30 BYTE),
      OPN_UOM_CODE       VARCHAR2(30 BYTE),
      OPN_VALUE          NUMBER,
      OPN_MOV_DATE       DATE,
      ORG_ID             NUMBER(15),
      CREATION_DATE      DATE,
      CREATED_BY         NUMBER(15),
      LAST_UPDATE_DATE   DATE,
      LAST_UPDATED_BY    NUMBER(15),
      LAST_UPDATE_LOGIN  NUMBER(15),
      OPN_RESOURCE_DESC  VARCHAR2(500 BYTE),
      ITEM_PRICE         NUMBER,
      ITEM_NUMBER        NUMBER(10),
      DIS_PER            NUMBER(3),
      EST_VALUE          NUMBER(15,3),
      VAL_ESTAB          NUMBER(15,3)
    script for XXNP_OPN_JOBLOG_EST_002
    CREATE TABLE XXNP_OPN_JOBLOG_EST_002
      OPN_JOBLOG_002_ID   NUMBER,
      OPN_JOBLOG_007_ID   NUMBER,
      INVENTORY_ITEM_ID   NUMBER,
      ITEM_NUMBER         VARCHAR2(20 BYTE),
      ITEM_NAME           VARCHAR2(40 BYTE),
      ITEM_UOM            VARCHAR2(30 BYTE),
      ITEM_VALUE          NUMBER,
      ITEM_PERCENT        NUMBER,
      OPN_AMOUNT          NUMBER,
      ITEM_CEMENT_SK      NUMBER,
      ORG_ID              NUMBER(15),
      CREATION_DATE       DATE,
      CREATED_BY          NUMBER(15),
      LAST_UPDATE_DATE    DATE,
      LAST_UPDATED_BY     NUMBER(15),
      LAST_UPDATE_LOGIN   NUMBER(15),
      OPN_JOBLOG_001_ID   NUMBER,
      OPN_JOBLOG_006_ID   NUMBER,
      ITEM_REF            NUMBER,
      DESCRIPTION         VARCHAR2(500 BYTE),
      CALC_AMOUNT         NUMBER,
      CALC_CEMENT_SK      NUMBER,
      )

  • Could anyone help me to avoid Cartesian join in this query?

    Hi, guys:
    Could you help me on this query? I must generate a Cartesian join, but I do not know why it happens. dt.debtorkey, cl.clientkey, inv.invoicekey, ag.agingkey are primary keys of each table. The problem is: I got same tuple for 8 times.
    select dt.debtorkey, cl.clientkey,  inv.invoicekey, ag.agingkey, dt.DebtorNo, dt.Name as "debtor Name", dt.State,  cl.ClientNo, cl.Name as "Client Name",  inv.InvNo, inv.PurchOrd, inv.Amt,
    to_char(inv.InvDate, 'MM-DD-YY') invoice_date,  to_char(ag.DateLastBuy, 'MM-DD-YY') aging_lastbuy, to_char(ag.DateLastPmt, 'MM-DD-YY') aging_lastpmt
    from aging ag, invoices inv, debtors dt, clients cl
    where ag.clientkey=cl.clientkey
    and ag.debtorkey=dt.debtorkey
    and inv.clientkey=cl.clientkey
    and inv.debtorkey=dt.debtorkey
    and ((inv.InvDate>=to_date(:P16_DP_IDF_START_DATE, 'MM/DD/YYYY')
    and inv.InvDate<=to_date(:P16_DP_IDF_END_DATE, 'MM/DD/YYYY')
    and ag.DateLastBuy=to_date(:P16_DP_IDF_LAST_BUY,'MM/DD/YYYY')
    order by dt.name;Thanks a lot!

    Hi,
    Thanks for help. I am sorry for that I do not know how to upload a picture of explain plan. I am struggling to find how to provide sample data. I hope this data format could be at least useful.
    "DEBTORKEY","CLIENTKEY","INVOICEKEY","AGINGKEY","DEBTORNO","debtor Name","STATE","CLIENTNO","Client Name","INVNO","PURCHORD","AMT","INVOICE_DATE"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
    8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"I do not know why the tuples with same primary key repeat 8 times.
    Edited by: lxiscas on Oct 24, 2012 4:08 PM
    Edited by: lxiscas on Oct 24, 2012 4:10 PM

  • Puzzled By Cartesian Join In Query

    If I do this query:
    SELECT count(*)
    FROM
    mode_change_history psch
    JOIN mode_link psl USING (mode_index)
    WHERE
    psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
    The query takes less than a second and I get the desired results. If I modify the query by adding an additional join to the analysts table, like this:
    SELECT count(*)
    FROM
    mode_change_history psch
    JOIN mode_link psl USING (mode_index)
    JOIN analysts a USING (analyst_id)
    WHERE
    psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
    The query takes too long (about a minute) and generates a cartesian product(according to the explain plan) when joining the analysts table.
    Notes:
    I've removed the column names from the SELECT clause and replaced it with a count(*) just to simply this example.
    Relevant info on the tables being joined:
    mode_change_history columns
    mode_index
    date_changed
    analyst_id
    justification
    change_type
    Primary key on this table: mode_index,date_changed,analyst_id
    Approximate rows in table: 50,000
    mode_link columns
    mode_index
    mode_name
    parameter_set_id
    Primary key on this table is: mode_index
    Approximate rows in table: 20,000
    analysts columns
    analyst_id
    user_name
    full_name
    Primary key on this table is: analyst_id
    Approximate rows in table: 500
    As you can see, none of the tables have many rows.
    After joining the first two tables listed in the query the result of the join would have rows containing mode_index (from mode_change_history and mode_link tables) that satisfy the WHERE clause. This intermediate result set should include the additional column analyst_id from the mode_change_history table. Then I would expect the RDBMS to join the rows from the analysts table that have analyst_id's in the intermediate result set. This does not appear to be happening since I'm seeing the cartesian join line show up in the execution plan.
    Any ideas on what's going on?
    I would post the explain plans but the Oracle instance is on a network that is not connected to the Internet so I can't easily post any output.
    Thank you

    I don't use them myself. but I did have to debug somebody else's code which was giving all kinds of random results. natural three way join (sounds dirty) - ha!
    also, I've seen discrepancies between the manuals for different versions on the syntax and rules. one manual states that the USING clause is only valid for outer joins. another release states that it's good for inner and outer. I've also seen differences regarding the use of the word NATURAL.
    the bug it isn't that the optimizer uses a merge join carteian to resolve it (which could still give the correct answer, but possibly not with optimal performance). it's that it screws up the join criteria and returns a cartesian product result set.
    my opinion - screw ansi, I'm using oracle syntax. and if some new guy with a t-sql background doesn't like it, tough. I came from a C & Pascal background and had an oracle manual thrown in my lap (it was long enough ago that manuals were still printed, and luckily, being v5, the manuals were small and didn't damage anything).

  • Merge cartesian join in query plan

    Hi All
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
    W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
    I am trying to sue dynamic sampling, but it doesn't seem to work.
    please help on this.

    user8650395 wrote:
    Hi All
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
    W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
    I am trying to sue dynamic sampling, but it doesn't seem to work.
    please help on this.Interesting.
    There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
    One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
    Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified.

  • Cartesian Join query optimization

    Hello Experts!
    I have a question about cartesian join query which might look a bit weird.
    Assume the SQL query like that:
    SELECT DISTINCT A.NAME
    FROM A, B, C;
    Here we have cartesian join for 3 tables A, B and C.
    It looks to me, in order to get the result for such a particular SQL tables/sets B and C need to be accessed only to ensure they return at least 1 row (otherwise result set is empty), query table A, but there is no actual need to join the data.
    If you run such a query Oracle is doing full table scans and actually joins the data.
    Yes, DBMS is doing exactly what you are asking for, but I wonder if there is any way (SQL hint or db parameter or anything else) to enforce more optimal access path here?
    Obvious solution to remove B and C tables from the SELECT statement is not acceptable. :-)
    Thank you!

    Your statement in the other thread indicates you don't understand how the BI prompts actually work because you say you want it to do something that doesn't make sense for it to do.
    Of course Product and Account levels will be constrained to the interval you specified. It wouldn't make sense for them not to be. Because that would mean returning data for based on product and account levels that has a different open data range than what you specified.
    All UI prompt dialogs I have seen use AND relationships between the parameters. If there are three parameters (A, B, C) then the ultimate relationship is 'A AND B AND C'; not 'A OR (B AND C)', 'A AND (B OR C)', 'A OR (B OR C).
    Unless the tool allows you to select OR relationships you need to use a separate dialog box (parameter dialog) for each condition set.:-)
    I understand how BI prompts work and basically agree on your comment, but there are two problems here:
    1. I need to convince the customer his original requirements are not valid. Customer want it to work different way and there are some reasons why.
    2. There are pretty large dimensions and fact tables used here, so when I choose filter criteria for the Product (which is small table) to populate/recalculate prompt values, large SR dimension and fact tables are joined too, and if there are Account dimension filters added, huge Account dimension will be added as well. This looks to be a bit sub-optimal for just populating the Product prompt values.
    Of course, technically this is solvable, but requires to put some extra effort and does not solve the 1st issue.
    That other link doesn't explain the sample code you posted in this thread. Post the actual query that is being generated and the query that you want to actually use.This is what is generated:
    >
    select distinct T311691.X_CUST_SUBTYPE as c1
    from
    WC_LOV_SR_AREA_H T311695,
    WC_LOV_PROD_H T311687,
    WC_LOV_CUST_TYPE_H T311691,
    W_SRVREQ_D T302384 /* Dim_W_SRVREQ_D */
    where ( T311687.LEV1 = 'Product X' and T311691.X_CUST_TYPE = 'Business' and T302384.OPEN_DT between TO_DATE('2012-03-01 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') and TO_DATE('2012-03-31 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') )
    order by c1
    >
    This is what is actually needed to query this data:
    >
    select distinct T311691.X_CUST_SUBTYPE as c1
    from
    WC_LOV_CUST_TYPE_H T311691
    where ( T311691.X_CUST_TYPE = 'Business' )
    order by c1

  • Merge Join Cartesian in XML query

    Hi Sir
    I am getting Merge join cartesian in the below XML query
    SELECT
    x.empno,
    x1.empno AS INDEXempno
    FROM
    emp_vw x,
    emp_index x1,
    table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
    WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
    I am getting Merge join cartesian in XML query. whereeas below query i am running by I am not getting merge join cartesian
    SELECT
    x.empno,
    x1.empno AS INDEXempno
    FROM
    emp_vw_v6 x,
    emp_index_v6 x1,
    table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
    WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
    Here emp_vw is a view and emp_index is a table.This is not giving merge join cartesian
    However both the view and table are interdependent.
    Please help me to resolve the performance of the first query as it is taking a lot of time to execute.?
    Thanks & Regards
    Thakur Manoj R

    Please post a working test case, and follow the guidelines here : {message:id=9360002}
    What are the differences between the view and table in the first query and the two others (*_v6) in the second query?                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Merge Cartesian in query

    Hi
    below query is running 1 minutes on test server however it is stucking on production for more than 8 hours .
    I compared explain plan for both queries ,on test server,optimizer is using hash join however on production ,optimizer is using Merge Cartesian join .
    I tried query with ordered hit ,we get rid of mergecartesian join but cost got increased
    now please advice ,if we should go by this ordered hit method on production or not not
    or suggets any other ways .
    below is query
    SELECT DISTINCT acct_promo_hdr.row_id, '401000', 'EXPORTED',
    acct_promo_hdr.src_num, 'PLAN_ACCOUNT_PROMOTION',
    promo_hdr_org.NAME
    FROM siebel.s_src acct_promo_hdr,
    siebel.s_mdf_alloc deal,
    siebel.s_bu promo_hdr_org
    -- siebel.s_contact contact,
    -- siebel.s_user usr
    WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
    AND acct_promo_hdr.row_id = deal.promo_id
    AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
    -- AND acct_promo_hdr.created_by = contact.row_id
    -- AND contact.row_id = usr.row_id
    AND EXISTS (
    SELECT 1
    FROM approval acb_approval
    WHERE acb_approval.status NOT IN
    ('11', '12', '65', '77')
    AND acct_promo_hdr.src_num =
    acb_approval.commit_num)
    AND deal.status_cd IN
    ('Cancel',
    'Cancelled',
    'Committed',
    'On Hold',
    'Processing Claim',
    'Paid In Part',
    'Paid In Full',
    'Hold'
    explain plan on production
    PLAN_TABLE_OUTPUT
    Plan hash value: 115701554
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 133 | 207 (2)| 00:00:03 |
    | 1 | HASH UNIQUE | | 1 | 133 | 207 (2)| 00:00:03 |
    | 2 | NESTED LOOPS | | | | | |
    | 3 | NESTED LOOPS | | 1 | 133 | 206 (1)| 00:00:03 |
    | 4 | NESTED LOOPS | | 1 | 112 | 205 (1)| 00:00:03 |
    | 5 | MERGE JOIN CARTESIAN | | 1 | 57 | 67 (2)| 00:00:01 |
    | 6 | SORT UNIQUE | | 1 | 30 | 64 (0)| 00:00:01 |
    |* 7 | TABLE ACCESS FULL | APPROVAL | 1 | 30 | 64 (0)| 00:00:01 |
    | 8 | BUFFER SORT | | 3 | 81 | 3 (34)| 00:00:01 |
    | 9 | TABLE ACCESS FULL | S_BU | 3 | 81 | 2 (0)| 00:00:01 |
    | 10 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 55 | 137 (0)| 00:00:02 |
    |* 11 | INDEX RANGE SCAN | S_SRC_U2 | 1 | | 137 (0)| 00:00:02 |
    |* 12 | INDEX RANGE SCAN | S_MDF_ALLOC_F8 | 12 | | 1 (0)| 00:00:01 |
    |* 13 | TABLE ACCESS BY INDEX ROWID | S_MDF_ALLOC | 11 | 231 | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    7 - filter("ACB_APPROVAL"."STATUS"<>'11' AND "ACB_APPROVAL"."STATUS"<>'12' AND
    "ACB_APPROVAL"."STATUS"<>'65' AND "ACB_APPROVAL"."STATUS"<>'77')
    11 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID" AND
    "ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION')
    filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
    "ACB_APPROVAL"."COMMIT_NUM"=TO_NUMBER("ACCT_PROMO_HDR"."SRC_NUM"))
    12 - access("ACCT_PROMO_HDR"."ROW_ID"="DEAL"."PROMO_ID")
    13 - filter("DEAL"."STATUS_CD"='Cancel' OR "DEAL"."STATUS_CD"='Cancelled' OR
    "DEAL"."STATUS_CD"='Committed' OR "DEAL"."STATUS_CD"='Hold' OR "DEAL"."STATUS_CD"='On
    Hold' OR "DEAL"."STATUS_CD"='Paid In Full' OR "DEAL"."STATUS_CD"='Paid In Part' OR
    "DEAL"."STATUS_CD"='Processing Claim')
    35 rows selected.

    pujakhetan wrote:
    Tables are analysed on production .Well, the stats are indicating to the optimizer that the filter at #7 (<tt>ACB_APPROVAL_STATUS {noformat}<{noformat}> '11'</tt> etc) will return 1 row (usually indicating it thinks there are no rows to process), so if that is not the case then something has gone wrong. I'm guessing the 'good' plan you see in test has higher cardinality figures?
    I tried query with ordered hit, we get rid of merge cartesian join but cost got increased nowIgnore the 'cost', it is just a figure calculated by the optimizer to indicate the relative resources required by different query plans - according to the available stats - and if those stats are out or something else is confusing it then the figure will be meaningless. Look at it this way - if the cost calculation was right, your query would already have the best plan.
    Also the problem was not the join order but the join method, so I don't see an 'ordered' hint necessarily helping.
    btw placing <tt></tt> tags around your code and execution plan will make it a lot easier to read.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Cartesian join in the SQL query

    Hi,
    I have a problem when joining two tables that cannot join directly. As I read (please correct me if I'm wrong), two dims have to join by one fact in order to extract information from them. This way, I created logical source tables with SQL query that join both dims. So, if for example Dim A and Dim B cannot join directly, I created a "mapping table" which is a select that joins these 2 tables in the proper way and the fields are the row_wids from these tables. This way, I created the following model diagram for this relationship:
    DimActivity -< FactMapping >- DimPNR
    DimActivity -< FactActivity >- DimMapping
    DimPNR -< FactPNR >- DimMapping
    Now, I can extract information from both dims and their metrics, except in one case; If I extract info from ("Segment Designer") "Dim-Activity", "Dim-PNR", "Fact-Activity" and "Fact-PNR", I get a query that first calculates the metric from Activity, then calculates the metric from PNR, and when it joins both queries, I get cardinality because it doesn't join through the "mapping tables". The whole query is:
    WITH
    SAWITH0 AS (select sum(T690608."QTY") as c1,
    T690608."ASSET_NUM" as c2
    from "W_ASSET_D" T690608 /* Dim_W_ASSET_D */
    group by T690608."ASSET_NUM"),
    SAWITH1 AS (select sum(T682428."COST") as c1,
    T682428."STATUS_WID" as c2
    from "W_ACTIVITY_F" T682428 /* Dim_W_ACTIVITY_F */
    group by T682428."STATUS_WID")
    select distinct SAWITH0.c2 as c1,SAWITH1.c2 as c2,SAWITH1.c1 as c3,SAWITH0.c1 as c4
    from
    SAWITH0,SAWITH1
    Why there is no condition joining SAWITH0 and SAWITH1? Is there a way to force this to be an inner join? I'm looking forward to your answer, since this problem is urgent within this project. Thank you in advance

    Ok.
    I assume that you have for one activity several asset PNR and for one asset several activity.
    The factPNR is on this way a real bridge table. It's a way to be able to design a many-to-many relationship.
    Have a look here for more detail on how to build a many-to-many relationship :
    http://gerardnico.com/wiki/dw/data_quality/relationships#many-to-many
    Therefore I assume that you want this design :
    DimActivity -< FactActivity >- < FactPNR >- DimPNR  and you will have :
    DimActivity -< FactActivity >- < BridgeTable >- DimPNR  How to build your bridge table ?
    In the physical layer, :
    * create a new table BridgeActivityPNR, open it and select "statement"
    * enter your sql statement
    SELECT DISTINCT A.ROW_WID ACTIVIDAD_WID, B.ROW_WID ASSET_WID
    FROM W_ACTIVITY_F A,
    W_ASSET_D B,
    W_SRVREQ_D C,
    X_S_CMPT_MTRC_F D,
    X_S_ASSET_FEA_D E
    WHERE A.X_SRA_SR_ID=C.INTEGRATION_ID AND
    C.X_VLG_FLIGHT_ID=D.X_ROW_ID AND
    D.X_ROW_ID=E.X_CM_ID AND
    E.X_ASSET_ID=B.X_ROW_ID* add two columns in the column tab : ACTIVIDAD_WID and ASSET_WID
    * create the physical join with the table FactActivity and DimPNR
    * drag and drop in the business model your table BridgeActivityPNR
    * in the BMM, create the complex join like this :
    DimActivity -< FactActivity >- < BridgeTable >- DimPNR  * open your logical bridge table and check the bridge table option.
    And you are done if I didn't forget anything.
    A complete example here :
    http://gerardnico.com/wiki/dat/obiee/obiee_bridge_table

  • How to take Cartesian product on logical subsets of rows in SELECT query?

    Hi All,
    I have the following data in seg_tab table.
    Seg_no
    Seg_value
    1
    01
    2
    001
    2
    002
    3
    100040
    3
    100041
    3
    100042
    3
    100043
    Expected result, which is produced by joining the logical subsets (by seg_no) in rows. The segments can vary, for simplicity it is 3 but it can grow upto any level.
    Codes
    01.001.100040
    01.001.100041
    01.001.100042
    01.001.100043
    01.002.100040
    01.002.100041
    01.002.100042
    01.002.100043
    The SQL statements required to create tables and populate it with the data is given below:
    CREATE TABLE seg_tab (seg_no NUMBER, seg_value VARCHAR2(10));
    --1st Subset
    INSERT INTO seg_tab VALUES (1,'01');
    --2nd Subset
    INSERT INTO seg_tab VALUES (2,'001');
    INSERT INTO seg_tab VALUES (2,'002');
    --3rd Subset
    INSERT INTO seg_tab VALUES (3,'100040');
    INSERT INTO seg_tab VALUES (3,'100041');
    INSERT INTO seg_tab VALUES (3,'100042');
    INSERT INTO seg_tab VALUES (3,'100043');
    Any help on guiding how to write the SQL statement will be highly appreciated.
    Many Thanks
    Kind Regards,
    Bilal

    Another way
    with
    seg_tab as
    (select 1 seg_no,'01' seg_value from dual union all
    select 2,'001' from dual union all
    select 2,'002' from dual union all
    select 3,'100040' from dual union all
    select 3,'100041' from dual union all
    select 3,'100042' from dual union all
    select 3,'100043' from dual
    concatenator(seg,codes) as
    (select seg_no,seg_value
       from seg_tab
      where seg_no = 1
    union all
    select s.seg_no,c.codes || '.' || s.seg_value
       from concatenator c,
            seg_tab s
      where s.seg_no = c.seg + 1
    select codes
      from concatenator
    where seg = (select max(seg_no) from seg_tab)
    order by codes
    CODES
    01.001.100040
    01.001.100041
    01.001.100042
    01.001.100043
    01.002.100040
    01.002.100041
    01.002.100042
    01.002.100043
    Regards
    Etbin

  • Help optimizing query with function

    Hello experts,
    I need your help optmizing this query which has a condition that matches on results of non-deterministic function. The non-deterministic functino is fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY. Values that it returns depends on contents of a table, so I can't really create a function index.
    Any input will be appreciated. Thanks in advance!
    Sorry I couln't format the query plan properly. Can somebody advise how? Thanks again!
    Giovanni
    explain plan for
    WITH tg AS
    (SELECT taxgroup_code FROM taxgroup
    WHERE taxgroup_code = 'TAXGROUP2' --?
    AND taxgroup_delete_ind = 'N' AND taxgroup_active_ind = 'A'),
    le_hb AS
    (SELECT tgi.taxgroup_code, tgi.legalentity_id, tgi.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
    FROM tg, taxgroupitem tgi, orgunit_vw ou
    WHERE tg.taxgroup_code = tgi.taxgroup_code
    AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id = ou.hyperionbase_id
    UNION
    SELECT tgi.taxgroup_code, tgi.legalentity_id, ou.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
    FROM tg, taxgroupitem tgi, orgunit_vw ou
    WHERE tg.taxgroup_code = tgi.taxgroup_code
    AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id IS NULL),
    au AS
    (SELECT appusage_code FROM appusage WHERE appusage_code = 'CONSOLIDATION'),
    prs AS
    (SELECT prs_key,
    (CASE WHEN instr(prs_key, ':') = 0 THEN prs_key
    ELSE SUBSTR(prs_key, 1, (instr(prs_key, ':')-1) ) END) first_val
    FROM
    (SELECT fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(164415 --?
    ) prs_key
    FROM dual
    grs AS
    (SELECT prs.*, fd.fielddata_group_sequence fd_grpseq
    FROM prs, fielddata fd, le_hb
    WHERE prs.first_val = fd.fielddata_value
    AND le_hb.legalentity_id = fd.legalentity_id
    AND le_hb.hyperionbase_id = fd.hyperionbase_id),
    fdk AS
    (SELECT
    cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
    fd.fielddata_value fd_val, fd.fielddata_group_sequence fd_grpseq,
    ROW_NUMBER() OVER (PARTITION BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence)
    ORDER BY fd.fielddata_group_sequence) rn,
    grs.prs_key
    FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td, appusage au
    WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
    AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
    AND cd.tabledef_id = td.tabledef_id
    AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
    and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
    AND cd.celldef_key_ind = 'Y'
    AND fd.fielddata_delete_ind = 'N'
    AND td.tabledef_id = 2265
    fda AS
    (SELECT
    cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
    TO_CHAR(TO_NUMBER(SUM(fd.fielddata_value))) fd_val,
    MIN(fd.fielddata_group_sequence) fd_grpseq,
    grs.prs_key
    FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td
    WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
    AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
    AND cd.tabledef_id = td.tabledef_id
    AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
    and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
    AND cd.celldef_adjustable_ind = 'Y'
    AND fd.fielddata_delete_ind = 'N'
    AND td.tabledef_id = 2265
    GROUP BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence),
    grs.prs_key
    SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fdk.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
    'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
    cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
    cd.celldef_column_sequence, cd.celldef_column_label,
    cd.celldef_column_sort_order, NULL tablecell_id, fdk.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
    'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
    TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
    fdk.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
    fdk.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
    TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
    fdk.fd_key
    FROM fdk, celldef cd, appusageaccess aua, au
    WHERE fdk.celldef_id = cd.celldef_id
    AND cd.celldef_id = aua.celldef_id
    AND aua.appusage_code = au.appusage_code
    AND fdk.rn = 1
    UNION ALL
    SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fda.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
    'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
    cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
    cd.celldef_column_sequence, cd.celldef_column_label,
    cd.celldef_column_sort_order, NULL tablecell_id, fda.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
    'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
    TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
    fda.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
    fda.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
    TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
    fda.fd_key
    FROM fda, celldef cd, appusageaccess aua, au
    WHERE fda.celldef_id = cd.celldef_id
    AND cd.celldef_id = aua.celldef_id
    AND aua.appusage_code = au.appusage_code
    ORDER BY fielddata_group_sequence, celldef_column_sequence
    Query Plan:
    Plan hash value: 522363234
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 6227 | 249 (2)| 00:00:03 |
    | 1 | TEMP TABLE TRANSFORMATION | | | | | |
    | 2 | LOAD AS SELECT | | | | | |
    |* 3 | TABLE ACCESS BY INDEX ROWID | TAXGROUP | 1 | 14 | 1 (0)| 00:00:01 |
    |* 4 | INDEX UNIQUE SCAN | PK_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    | 5 | LOAD AS SELECT | | | | | |
    | 6 | SORT UNIQUE | | 4 | 224 | 12 (59)| 00:00:01 |
    | 7 | UNION-ALL | | | | | |
    | 8 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 1 | 29 | 2 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 1 | 56 | 5 (0)| 00:00:01 |
    | 10 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
    | 11 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
    | 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    |* 13 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
    |* 14 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    |* 15 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 1 | | 1 (0)| 00:00:01 |
    | 16 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 3 | 87 | 2 (0)| 00:00:01 |
    | 17 | NESTED LOOPS | | 3 | 168 | 5 (0)| 00:00:01 |
    | 18 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
    | 19 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
    | 20 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    |* 21 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
    |* 22 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    |* 23 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 3 | | 1 (0)| 00:00:01 |
    | 24 | LOAD AS SELECT | | | | | |
    |* 25 | INDEX UNIQUE SCAN | PK_APPUSAGE | 1 | 10 | 0 (0)| 00:00:01 |
    | 26 | LOAD AS SELECT | | | | | |
    |* 27 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 7 | 147 | 28 (0)| 00:00:01 |
    | 28 | NESTED LOOPS | | 27 | 1269 | 117 (1)| 00:00:02 |
    | 29 | NESTED LOOPS | | 4 | 104 | 4 (0)| 00:00:01 |
    | 30 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
    | 31 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 33 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 34 | SORT ORDER BY | | 2 | 6227 | 248 (51)| 00:00:03 |
    | 35 | UNION-ALL | | | | | |
    | 36 | NESTED LOOPS | | 1 | 4110 | 125 (2)| 00:00:02 |
    | 37 | MERGE JOIN CARTESIAN | | 1 | 4093 | 124 (2)| 00:00:02 |
    | 38 | NESTED LOOPS | | 1 | 4076 | 122 (2)| 00:00:02 |
    |* 39 | VIEW | | 1 | 4043 | 121 (2)| 00:00:02 |
    |* 40 | WINDOW SORT PUSHED RANK | | 1 | 2099 | 121 (2)| 00:00:02 |
    | 41 | MERGE JOIN CARTESIAN | | 1 | 2099 | 120 (1)| 00:00:02 |
    | 42 | NESTED LOOPS | | 1 | 2099 | 119 (1)| 00:00:02 |
    | 43 | NESTED LOOPS | | 1 | 2088 | 118 (1)| 00:00:02 |
    |* 44 | HASH JOIN | | 1 | 2077 | 117 (1)| 00:00:02 |
    |* 45 | TABLE ACCESS BY INDEX ROWID| FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
    | 46 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
    | 47 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
    |* 48 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
    | 49 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 50 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 51 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 52 | VIEW | | 27 | 54405 | 2 (0)| 00:00:01 |
    | 53 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
    | 54 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
    |* 55 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
    |* 56 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
    |* 57 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 58 | BUFFER SORT | | 5 | | 120 (2)| 00:00:02 |
    | 59 | INDEX FULL SCAN | PK_APPUSAGE | 5 | | 1 (0)| 00:00:01 |
    | 60 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
    |* 61 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 62 | BUFFER SORT | | 1 | 17 | 123 (2)| 00:00:02 |
    | 63 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
    | 64 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    | 65 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
    |* 66 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
    | 67 | NESTED LOOPS | | 1 | 2117 | 124 (2)| 00:00:02 |
    | 68 | MERGE JOIN CARTESIAN | | 1 | 2100 | 123 (2)| 00:00:02 |
    | 69 | NESTED LOOPS | | 1 | 2083 | 121 (2)| 00:00:02 |
    | 70 | VIEW | | 1 | 2050 | 120 (2)| 00:00:02 |
    | 71 | HASH GROUP BY | | 1 | 2091 | 120 (2)| 00:00:02 |
    | 72 | NESTED LOOPS | | 1 | 2091 | 119 (1)| 00:00:02 |
    | 73 | NESTED LOOPS | | 1 | 2080 | 118 (1)| 00:00:02 |
    |* 74 | HASH JOIN | | 1 | 2069 | 117 (1)| 00:00:02 |
    |* 75 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
    | 76 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
    | 77 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
    |* 78 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
    | 79 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 80 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 81 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 82 | VIEW | | 27 | 54189 | 2 (0)| 00:00:01 |
    | 83 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
    | 84 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
    |* 85 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
    |* 86 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
    |* 87 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 88 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
    |* 89 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 90 | BUFFER SORT | | 1 | 17 | 122 (2)| 00:00:02 |
    | 91 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
    | 92 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    | 93 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
    |* 94 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
    4 - access("TAXGROUP_CODE"='TAXGROUP2')
    13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
    14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
    15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
    21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
    22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
    23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
    25 - access("APPUSAGE_CODE"='CONSOLIDATION')
    27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
    THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
    SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
    5),':')-1) END )
    33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    39 - filter("FDK"."RN"=1)
    40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
    ."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
    44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
    "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
    45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
    48 - access("TD"."TABLEDEF_ID"=2265)
    51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
    56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
    57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
    61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
    66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
    74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
    "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
    75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
    78 - access("TD"."TABLEDEF_ID"=2265)
    81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
    86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
    87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
    89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
    94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")

    Thanks cd.
    Here's the query plan:
    Query Plan:
    Plan hash value: 522363234
    | Id  | Operation                               | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                        |                            |     2 |  6227 |   249   (2)| 00:00:03 |
    |   1 |  TEMP TABLE TRANSFORMATION              |                            |       |       |            |          |
    |   2 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |*  3 |    TABLE ACCESS BY INDEX ROWID          | TAXGROUP                   |     1 |    14 |     1   (0)| 00:00:01 |
    |*  4 |     INDEX UNIQUE SCAN                   | PK_TAXGROUP                |     1 |       |     0   (0)| 00:00:01 |
    |   5 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |   6 |    SORT UNIQUE                          |                            |     4 |   224 |    12  (59)| 00:00:01 |
    |   7 |     UNION-ALL                           |                            |       |       |            |          |
    |   8 |      TABLE ACCESS BY INDEX ROWID        | ORGUNIT                    |     1 |    29 |     2   (0)| 00:00:01 |
    |   9 |       NESTED LOOPS                      |                            |     1 |    56 |     5   (0)| 00:00:01 |
    |  10 |        NESTED LOOPS                     |                            |     1 |    27 |     3   (0)| 00:00:01 |
    |  11 |         VIEW                            |                            |     1 |    10 |     2   (0)| 00:00:01 |
    |  12 |          TABLE ACCESS FULL              | SYS_TEMP_0FD9D9B51_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |* 13 |         TABLE ACCESS BY INDEX ROWID     | TAXGROUPITEM               |     1 |    17 |     1   (0)| 00:00:01 |
    |* 14 |          INDEX RANGE SCAN               | XF1_TAXGROUPITEM_TAXGROUP  |     1 |       |     0   (0)| 00:00:01 |
    |* 15 |        INDEX RANGE SCAN                 | XF1_ORGUNIT_ID             |     1 |       |     1   (0)| 00:00:01 |
    |  16 |      TABLE ACCESS BY INDEX ROWID        | ORGUNIT                    |     3 |    87 |     2   (0)| 00:00:01 |
    |  17 |       NESTED LOOPS                      |                            |     3 |   168 |     5   (0)| 00:00:01 |
    |  18 |        NESTED LOOPS                     |                            |     1 |    27 |     3   (0)| 00:00:01 |
    |  19 |         VIEW                            |                            |     1 |    10 |     2   (0)| 00:00:01 |
    |  20 |          TABLE ACCESS FULL              | SYS_TEMP_0FD9D9B51_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |* 21 |         TABLE ACCESS BY INDEX ROWID     | TAXGROUPITEM               |     1 |    17 |     1   (0)| 00:00:01 |
    |* 22 |          INDEX RANGE SCAN               | XF1_TAXGROUPITEM_TAXGROUP  |     1 |       |     0   (0)| 00:00:01 |
    |* 23 |        INDEX RANGE SCAN                 | XF1_ORGUNIT_ID             |     3 |       |     1   (0)| 00:00:01 |
    |  24 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |* 25 |    INDEX UNIQUE SCAN                    | PK_APPUSAGE                |     1 |    10 |     0   (0)| 00:00:01 |
    |  26 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |* 27 |    TABLE ACCESS BY INDEX ROWID          | FIELDDATA                  |     7 |   147 |    28   (0)| 00:00:01 |
    |  28 |     NESTED LOOPS                        |                            |    27 |  1269 |   117   (1)| 00:00:02 |
    |  29 |      NESTED LOOPS                       |                            |     4 |   104 |     4   (0)| 00:00:01 |
    |  30 |       FAST DUAL                         |                            |     1 |       |     2   (0)| 00:00:01 |
    |  31 |       VIEW                              |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  32 |        TABLE ACCESS FULL                | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 33 |      INDEX RANGE SCAN                   | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  34 |   SORT ORDER BY                         |                            |     2 |  6227 |   248  (51)| 00:00:03 |
    |  35 |    UNION-ALL                            |                            |       |       |            |          |
    |  36 |     NESTED LOOPS                        |                            |     1 |  4110 |   125   (2)| 00:00:02 |
    |  37 |      MERGE JOIN CARTESIAN               |                            |     1 |  4093 |   124   (2)| 00:00:02 |
    |  38 |       NESTED LOOPS                      |                            |     1 |  4076 |   122   (2)| 00:00:02 |
    |* 39 |        VIEW                             |                            |     1 |  4043 |   121   (2)| 00:00:02 |
    |* 40 |         WINDOW SORT PUSHED RANK         |                            |     1 |  2099 |   121   (2)| 00:00:02 |
    |  41 |          MERGE JOIN CARTESIAN           |                            |     1 |  2099 |   120   (1)| 00:00:02 |
    |  42 |           NESTED LOOPS                  |                            |     1 |  2099 |   119   (1)| 00:00:02 |
    |  43 |            NESTED LOOPS                 |                            |     1 |  2088 |   118   (1)| 00:00:02 |
    |* 44 |             HASH JOIN                   |                            |     1 |  2077 |   117   (1)| 00:00:02 |
    |* 45 |              TABLE ACCESS BY INDEX ROWID| FIELDDATA                  |   117 |  3744 |    28   (0)| 00:00:01 |
    |  46 |               NESTED LOOPS              |                            |   466 | 28892 |   114   (0)| 00:00:02 |
    |  47 |                NESTED LOOPS             |                            |     4 |   120 |     2   (0)| 00:00:01 |
    |* 48 |                 INDEX UNIQUE SCAN       | PK_TABLEDEF                |     1 |     4 |     0   (0)| 00:00:01 |
    |  49 |                 VIEW                    |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  50 |                  TABLE ACCESS FULL      | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 51 |                INDEX RANGE SCAN         | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  52 |              VIEW                       |                            |    27 | 54405 |     2   (0)| 00:00:01 |
    |  53 |               TABLE ACCESS FULL         | SYS_TEMP_0FD9D9B54_2EBE182 |    27 |  1269 |     2   (0)| 00:00:01 |
    |  54 |             TABLE ACCESS BY INDEX ROWID | TABLECELL                  |     1 |    11 |     1   (0)| 00:00:01 |
    |* 55 |              INDEX UNIQUE SCAN          | XF1_TBLCEL_DATA            |     1 |       |     0   (0)| 00:00:01 |
    |* 56 |            TABLE ACCESS BY INDEX ROWID  | CELLDEF                    |     1 |    11 |     1   (0)| 00:00:01 |
    |* 57 |             INDEX UNIQUE SCAN           | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  58 |           BUFFER SORT                   |                            |     5 |       |   120   (2)| 00:00:02 |
    |  59 |            INDEX FULL SCAN              | PK_APPUSAGE                |     5 |       |     1   (0)| 00:00:01 |
    |  60 |        TABLE ACCESS BY INDEX ROWID      | CELLDEF                    |     1 |    33 |     1   (0)| 00:00:01 |
    |* 61 |         INDEX UNIQUE SCAN               | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  62 |       BUFFER SORT                       |                            |     1 |    17 |   123   (2)| 00:00:02 |
    |  63 |        VIEW                             |                            |     1 |    17 |     2   (0)| 00:00:01 |
    |  64 |         TABLE ACCESS FULL               | SYS_TEMP_0FD9D9B53_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |  65 |      TABLE ACCESS BY INDEX ROWID        | APPUSAGEACCESS             |     1 |    17 |     1   (0)| 00:00:01 |
    |* 66 |       INDEX UNIQUE SCAN                 | AK_APPUSAGEACCESS          |     1 |       |     0   (0)| 00:00:01 |
    |  67 |     NESTED LOOPS                        |                            |     1 |  2117 |   124   (2)| 00:00:02 |
    |  68 |      MERGE JOIN CARTESIAN               |                            |     1 |  2100 |   123   (2)| 00:00:02 |
    |  69 |       NESTED LOOPS                      |                            |     1 |  2083 |   121   (2)| 00:00:02 |
    |  70 |        VIEW                             |                            |     1 |  2050 |   120   (2)| 00:00:02 |
    |  71 |         HASH GROUP BY                   |                            |     1 |  2091 |   120   (2)| 00:00:02 |
    |  72 |          NESTED LOOPS                   |                            |     1 |  2091 |   119   (1)| 00:00:02 |
    |  73 |           NESTED LOOPS                  |                            |     1 |  2080 |   118   (1)| 00:00:02 |
    |* 74 |            HASH JOIN                    |                            |     1 |  2069 |   117   (1)| 00:00:02 |
    |* 75 |             TABLE ACCESS BY INDEX ROWID | FIELDDATA                  |   117 |  3744 |    28   (0)| 00:00:01 |
    |  76 |              NESTED LOOPS               |                            |   466 | 28892 |   114   (0)| 00:00:02 |
    |  77 |               NESTED LOOPS              |                            |     4 |   120 |     2   (0)| 00:00:01 |
    |* 78 |                INDEX UNIQUE SCAN        | PK_TABLEDEF                |     1 |     4 |     0   (0)| 00:00:01 |
    |  79 |                VIEW                     |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  80 |                 TABLE ACCESS FULL       | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 81 |               INDEX RANGE SCAN          | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  82 |             VIEW                        |                            |    27 | 54189 |     2   (0)| 00:00:01 |
    |  83 |              TABLE ACCESS FULL          | SYS_TEMP_0FD9D9B54_2EBE182 |    27 |  1269 |     2   (0)| 00:00:01 |
    |  84 |            TABLE ACCESS BY INDEX ROWID  | TABLECELL                  |     1 |    11 |     1   (0)| 00:00:01 |
    |* 85 |             INDEX UNIQUE SCAN           | XF1_TBLCEL_DATA            |     1 |       |     0   (0)| 00:00:01 |
    |* 86 |           TABLE ACCESS BY INDEX ROWID   | CELLDEF                    |     1 |    11 |     1   (0)| 00:00:01 |
    |* 87 |            INDEX UNIQUE SCAN            | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  88 |        TABLE ACCESS BY INDEX ROWID      | CELLDEF                    |     1 |    33 |     1   (0)| 00:00:01 |
    |* 89 |         INDEX UNIQUE SCAN               | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  90 |       BUFFER SORT                       |                            |     1 |    17 |   122   (2)| 00:00:02 |
    |  91 |        VIEW                             |                            |     1 |    17 |     2   (0)| 00:00:01 |
    |  92 |         TABLE ACCESS FULL               | SYS_TEMP_0FD9D9B53_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |  93 |      TABLE ACCESS BY INDEX ROWID        | APPUSAGEACCESS             |     1 |    17 |     1   (0)| 00:00:01 |
    |* 94 |       INDEX UNIQUE SCAN                 | AK_APPUSAGEACCESS          |     1 |       |     0   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
       3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
       4 - access("TAXGROUP_CODE"='TAXGROUP2')
      13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
      14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
      15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
      21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
      22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
      23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
      25 - access("APPUSAGE_CODE"='CONSOLIDATION')
      27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
                  THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
                  SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
                  5),':')-1) END )
      33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      39 - filter("FDK"."RN"=1)
      40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
                  ."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
      44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
                  "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
      45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
      48 - access("TD"."TABLEDEF_ID"=2265)
      51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
      56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
      57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
      61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
      66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
      74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
                  "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
      75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
      78 - access("TD"."TABLEDEF_ID"=2265)
      81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
      86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
      87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
      89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
      94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")

  • Sql Query Tuning. Please help me to tune this query

    Hi All ,
    I have this problematic Sql . It is taking huge time to execute. It contains a view CIDV, which i think is the bottleneck.
    I have pasted the query below. I will be pasting TKPROF and explain plan for the same. Please advice me to tune this query.
    SELECT GCC.SEGMENT1 || '.' || GCC.SEGMENT2 || '.' || GCC.SEGMENT3 || '.' ||
           GCC.SEGMENT4 || '.' || GCC.SEGMENT5 || '.' || GCC.SEGMENT6 || '.' ||
           GCC.SEGMENT7 || '.' || GCC.SEGMENT8 || '.' || GCC.SEGMENT9 OFFSET_ACCOUNT,
           OOD.ORGANIZATION_CODE,
           CIDV.SUBINVENTORY_CODE OFFSET_SUBINV,
           MIL.SEGMENT1 || '.' || MIL.SEGMENT2 || '.' || MIL.SEGMENT3 || '.' ||
           MIL.SEGMENT4 || '.' || MIL.SEGMENT5 OFFSET_LOCATOR,
           CIDV.LAST_UPDATE_LOGIN
      FROM APPS.CST_INV_DISTRIBUTION_V       CIDV,
           APPS.GL_CODE_COMBINATIONS         GCC,
           APPS.MTL_ITEM_LOCATIONS           MIL,
           APPS.ORG_ORGANIZATION_DEFINITIONS OOD
    WHERE CIDV.TRANSACTION_ID = :B2
       AND CIDV.PRIMARY_QUANTITY = (-1) * :B1
       AND CIDV.REFERENCE_ACCOUNT = GCC.CODE_COMBINATION_ID
       AND OOD.ORGANIZATION_ID = CIDV.ORGANIZATION_ID
       AND MIL.INVENTORY_LOCATION_ID = CIDV.LOCATOR_ID
       AND GCC.ACCOUNT_TYPE = 'A'****************
    TKPROF
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute  68337     10.32      10.32          0          0          0           0
    Fetch    68337    229.75     936.36      58819    6743323       1121       68232
    total   136675    240.07     946.69      58819    6743323       1121       68232
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 203     (recursive depth: 1)
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
             1          1          1  MERGE JOIN CARTESIAN (cr=102 pr=15 pw=0 time=193608 us cost=56 size=219 card=1)
             1          1          1   NESTED LOOPS  (cr=100 pr=15 pw=0 time=193483 us cost=53 size=219 card=1)
             1          1          1    NESTED LOOPS  (cr=99 pr=15 pw=0 time=193407 us cost=52 size=215 card=1)
             1          1          1     NESTED LOOPS  (cr=96 pr=15 pw=0 time=193378 us cost=51 size=190 card=1)
             1          1          1      NESTED LOOPS  (cr=93 pr=15 pw=0 time=193284 us cost=49 size=162 card=1)
             1          1          1       NESTED LOOPS  (cr=89 pr=14 pw=0 time=185515 us cost=46 size=138 card=1)
             1          1          1        NESTED LOOPS  (cr=85 pr=12 pw=0 time=157975 us cost=44 size=81 card=1)
             1          1          1         NESTED LOOPS  (cr=83 pr=12 pw=0 time=157925 us cost=43 size=73 card=1)
             1          1          1          NESTED LOOPS  (cr=81 pr=12 pw=0 time=157641 us cost=43 size=132 card=2)
             1          1          1           VIEW  CST_INV_DISTRIBUTION_V (cr=78 pr=12 pw=0 time=156386 us cost=41 size=118 card=2)
             1          1          1            UNION-ALL  (cr=78 pr=12 pw=0 time=156378 us)
             0          0          0             NESTED LOOPS OUTER (cr=44 pr=9 pw=0 time=124997 us cost=20 size=291 card=1)
             0          0          0              NESTED LOOPS  (cr=44 pr=9 pw=0 time=124993 us cost=18 size=255 card=1)
             0          0          0               NESTED LOOPS  (cr=44 pr=9 pw=0 time=124990 us cost=18 size=251 card=1)
            33         33         33                MERGE JOIN CARTESIAN (cr=25 pr=6 pw=0 time=98544 us cost=14 size=192 card=1)
             1          1          1                 NESTED LOOPS OUTER (cr=22 pr=5 pw=0 time=85754 us cost=12 size=156 card=1)
             1          1          1                  NESTED LOOPS  (cr=19 pr=4 pw=0 time=79830 us cost=10 size=120 card=1)
             1          1          1                   NESTED LOOPS OUTER (cr=17 pr=4 pw=0 time=79813 us cost=9 size=113 card=1)
             1          1          1                    NESTED LOOPS  (cr=15 pr=4 pw=0 time=79752 us cost=8 size=106 card=1)
             1          1          1                     NESTED LOOPS  (cr=11 pr=2 pw=0 time=43120 us cost=6 size=93 card=1)
             1          1          1                      NESTED LOOPS  (cr=7 pr=2 pw=0 time=43087 us cost=4 size=83 card=1)
             1          1          1                       NESTED LOOPS  (cr=6 pr=2 pw=0 time=43072 us cost=4 size=80 card=1)
             1          1          1                        TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=2 pw=0 time=43042 us cost=4 size=76 card=1)
             1          1          1                         INDEX UNIQUE SCAN MTL_MATERIAL_TRANSACTIONS_U1 (cr=4 pr=2 pw=0 time=43011 us cost=3 size=0 card=1)(object id 12484094)
             1          1          1                        INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=20 us cost=0 size=764 card=191)(object id 9983)
             1          1          1                       INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=54 card=18)(object id 9987)
             1          1          1                      INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=27 us cost=2 size=736324450 card=73632445)(object id 12484155)
             1          1          1                     INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=2 pw=0 time=36626 us cost=2 size=957481070 card=73652390)(object id 12484137)
             1          1          1                    TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=42 us cost=1 size=3290 card=470)
             1          1          1                     INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=28 us cost=0 size=0 card=1)(object id 9847)
             1          1          1                   TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=12 us cost=1 size=3290 card=470)
             1          1          1                    INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=0 card=1)(object id 9847)
             0          0          0                  INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=5915 us cost=2 size=36 card=1)(object id 705891)
            33         33         33                 BUFFER SORT (cr=3 pr=1 pw=0 time=12713 us cost=12 size=36 card=1)
            33         33         33                  INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=12582 us cost=2 size=36 card=1)(object id 705891)
             0          0          0                TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=19 pr=3 pw=0 time=26591 us cost=4 size=59 card=1)
            66         66         66                 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=18 pr=2 pw=0 time=13607 us cost=3 size=0 card=3)(object id 12484127)
             0          0          0               INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=4 card=1)(object id 9847)
             0          0          0              INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=36 card=1)(object id 705891)
             1          1          1             NESTED LOOPS  (cr=34 pr=3 pw=0 time=31269 us cost=21 size=288 card=1)
             1          1          1              NESTED LOOPS  (cr=30 pr=3 pw=0 time=31161 us cost=19 size=275 card=1)
             1          1          1               NESTED LOOPS  (cr=26 pr=3 pw=0 time=31105 us cost=17 size=265 card=1)
             1          1          1                NESTED LOOPS  (cr=25 pr=3 pw=0 time=31082 us cost=17 size=261 card=1)
             1          1          1                 NESTED LOOPS OUTER (cr=23 pr=3 pw=0 time=31027 us cost=16 size=254 card=1)
             1          1          1                  NESTED LOOPS  (cr=21 pr=3 pw=0 time=30980 us cost=15 size=247 card=1)
             1          1          1                   NESTED LOOPS  (cr=20 pr=3 pw=0 time=30957 us cost=15 size=243 card=1)
             1          1          1                    NESTED LOOPS OUTER (cr=19 pr=3 pw=0 time=30926 us cost=15 size=240 card=1)
             1          1          1                     NESTED LOOPS  (cr=16 pr=3 pw=0 time=30389 us cost=13 size=204 card=1)
             1          1          1                      NESTED LOOPS  (cr=11 pr=0 pw=0 time=665 us cost=9 size=131 card=1)
             1          1          1                       NESTED LOOPS OUTER (cr=8 pr=0 pw=0 time=306 us cost=7 size=95 card=1)
             1          1          1                        TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=5 pr=0 pw=0 time=37 us cost=5 size=59 card=1)
             2          2          2                         INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=4 pr=0 pw=0 time=17 us cost=4 size=0 card=3)(object id 12484127)
             1          1          1                        INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=216 us cost=2 size=36 card=1)(object id 705891)
             1          1          1                       INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=352 us cost=2 size=36 card=1)(object id 705891)
             1          1          1                      TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=3 pw=0 time=29716 us cost=4 size=73 card=1)
             1          1          1                       INDEX RANGE SCAN MTL_MATERIAL_TRANSACTIONS_N23 (cr=4 pr=3 pw=0 time=29588 us cost=3 size=0 card=1)(object id 12484133)
             0          0          0                     INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=520 us cost=2 size=36 card=1)(object id 705891)
             1          1          1                    INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=22 us cost=0 size=3 card=1)(object id 9987)
             1          1          1                   INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=16 us cost=0 size=4 card=1)(object id 9983)
             1          1          1                  TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=34 us cost=1 size=7 card=1)
             1          1          1                   INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=19 us cost=0 size=0 card=1)(object id 9847)
             1          1          1                 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=44 us cost=1 size=7 card=1)
             1          1          1                  INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=14 us cost=0 size=0 card=1)(object id 9847)
             1          1          1                INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=13 us cost=0 size=4 card=1)(object id 9847)
             1          1          1               INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=49 us cost=2 size=10 card=1)(object id 12484155)
             1          1          1              INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=0 pw=0 time=96 us cost=2 size=13 card=1)(object id 12484137)
             1          1          1           TABLE ACCESS BY INDEX ROWID HR_ALL_ORGANIZATION_UNITS (cr=3 pr=0 pw=0 time=1246 us cost=1 size=7 card=1)
             1          1          1            INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK (cr=2 pr=0 pw=0 time=24 us cost=0 size=0 card=1)(object id 250158)
             1          1          1          INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK (cr=2 pr=0 pw=0 time=275 us cost=0 size=7 card=1)(object id 689101)
             1          1          1         TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=38 us cost=1 size=8 card=1)
             1          1          1          INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=15 us cost=0 size=0 card=1)(object id 9847)
             1          1          1        TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS (cr=4 pr=2 pw=0 time=27531 us cost=2 size=57 card=1)
             1          1          1         INDEX UNIQUE SCAN GL_CODE_COMBINATIONS_U1 (cr=3 pr=1 pw=0 time=19925 us cost=1 size=0 card=1)(object id 51426)
             1          1          1       TABLE ACCESS BY INDEX ROWID MTL_ITEM_LOCATIONS (cr=4 pr=1 pw=0 time=7758 us cost=3 size=24 card=1)
             1          1          1        INDEX RANGE SCAN MTL_ITEM_LOCATIONS_U1 (cr=3 pr=0 pw=0 time=51 us cost=2 size=0 card=1)(object id 9761)
             1          1          1      TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=85 us cost=2 size=28 card=1)
             1          1          1       INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=29 us cost=1 size=0 card=2)(object id 5379798)
             1          1          1     TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=25 us cost=1 size=25 card=1)
             1          1          1      INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=11 us cost=1 size=0 card=1)(object id 5379798)
             1          1          1    INDEX FULL SCAN GL_SETS_OF_BOOKS_U2 (cr=1 pr=0 pw=0 time=69 us cost=1 size=4 card=1)(object id 1380842)
             1          1          1   BUFFER SORT (cr=2 pr=0 pw=0 time=110 us cost=55 size=0 card=1)
             1          1          1    TABLE ACCESS FULL FND_PRODUCT_GROUPS (cr=2 pr=0 pw=0 time=59 us cost=3 size=0 card=1)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      library cache lock                              2        0.00          0.00
      library cache pin                               2        0.00          0.00
      Disk file operations I/O                      249        0.00          0.00
      db file sequential read                     58819        2.61        714.28
      gc cr grant 2-way                            5198        0.16          4.52
      gc current grant busy                           1        0.00          0.00
      KJC: Wait for msg sends to complete           517        0.00          0.05
      library cache: mutex X                        433        0.01          0.04
      gc cr grant congested                          28        0.08          0.18
      latch: ges resource hash list                   5        0.00          0.00
      gc current block 2-way                        513        0.11          0.61
      gc current block congested                      2        0.00          0.00
      latch: gc element                              16        0.00          0.01
      latch: cache buffers chains                     4        0.00          0.00
      latch: object queue header operation            3        0.00          0.00
    ********************************************************************************

    Explain Plan for the query
    SELECT STATEMENT, GOAL = ALL_ROWS               Cost=56     Cardinality=1     Bytes=219
    MERGE JOIN CARTESIAN               Cost=56     Cardinality=1     Bytes=219
      NESTED LOOPS               Cost=53     Cardinality=1     Bytes=219
       NESTED LOOPS               Cost=52     Cardinality=1     Bytes=215
        NESTED LOOPS               Cost=51     Cardinality=1     Bytes=190
         NESTED LOOPS               Cost=49     Cardinality=1     Bytes=162
          NESTED LOOPS               Cost=46     Cardinality=1     Bytes=138
           NESTED LOOPS               Cost=44     Cardinality=1     Bytes=81
            NESTED LOOPS               Cost=43     Cardinality=1     Bytes=73
             NESTED LOOPS               Cost=43     Cardinality=2     Bytes=132
              VIEW     Object owner=APPS     Object name=CST_INV_DISTRIBUTION_V     Cost=41     Cardinality=2     Bytes=118
               UNION-ALL                         
                NESTED LOOPS OUTER               Cost=20     Cardinality=1     Bytes=291
                 NESTED LOOPS               Cost=18     Cardinality=1     Bytes=255
                  NESTED LOOPS               Cost=18     Cardinality=1     Bytes=251
                   MERGE JOIN CARTESIAN               Cost=14     Cardinality=1     Bytes=192
                    NESTED LOOPS OUTER               Cost=12     Cardinality=1     Bytes=156
                     NESTED LOOPS               Cost=10     Cardinality=1     Bytes=120
                      NESTED LOOPS OUTER               Cost=9     Cardinality=1     Bytes=113
                       NESTED LOOPS               Cost=8     Cardinality=1     Bytes=106
                        NESTED LOOPS               Cost=6     Cardinality=1     Bytes=93
                         NESTED LOOPS               Cost=4     Cardinality=1     Bytes=83
                          NESTED LOOPS               Cost=4     Cardinality=1     Bytes=80
                           TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_MATERIAL_TRANSACTIONS     Cost=4     Cardinality=1     Bytes=76
                            INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_MATERIAL_TRANSACTIONS_U1     Cost=3     Cardinality=1     
                           INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_TRANSACTION_TYPES_U1     Cost=0     Cardinality=191     Bytes=764
                          INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_TXN_SOURCE_TYPES_U1     Cost=0     Cardinality=18     Bytes=54
                         INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_SYSTEM_ITEMS_B_U1     Cost=2     Cardinality=73632445     Bytes=736324450
                        INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_SYSTEM_ITEMS_TL_U1     Cost=2     Cardinality=73652390     Bytes=957481070
                       TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_PARAMETERS     Cost=1     Cardinality=470     Bytes=3290
                        INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     
                      TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_PARAMETERS     Cost=1     Cardinality=470     Bytes=3290
                       INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     
                     INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                    BUFFER SORT               Cost=12     Cardinality=1     Bytes=36
                     INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                   TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_TRANSACTION_ACCOUNTS     Cost=4     Cardinality=1     Bytes=59
                    INDEX RANGE SCAN     Object owner=INV     Object name=MTL_TRANSACTION_ACCOUNTS_N1     Cost=3     Cardinality=3     
                  INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     Bytes=4
                 INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                NESTED LOOPS               Cost=21     Cardinality=1     Bytes=288
                 NESTED LOOPS               Cost=19     Cardinality=1     Bytes=275
                  NESTED LOOPS               Cost=17     Cardinality=1     Bytes=265
                   NESTED LOOPS               Cost=17     Cardinality=1     Bytes=261
                    NESTED LOOPS OUTER               Cost=16     Cardinality=1     Bytes=254
                     NESTED LOOPS               Cost=15     Cardinality=1     Bytes=247
                      NESTED LOOPS               Cost=15     Cardinality=1     Bytes=243
                       NESTED LOOPS OUTER               Cost=15     Cardinality=1     Bytes=240
                        NESTED LOOPS               Cost=13     Cardinality=1     Bytes=204
                         NESTED LOOPS               Cost=9     Cardinality=1     Bytes=131
                          NESTED LOOPS OUTER               Cost=7     Cardinality=1     Bytes=95
                           TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_TRANSACTION_ACCOUNTS     Cost=5     Cardinality=1     Bytes=59
                            INDEX RANGE SCAN     Object owner=INV     Object name=MTL_TRANSACTION_ACCOUNTS_N1     Cost=4     Cardinality=3     
                           INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                          INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                         TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_MATERIAL_TRANSACTIONS     Cost=4     Cardinality=1     Bytes=73
                          INDEX RANGE SCAN     Object owner=INV     Object name=MTL_MATERIAL_TRANSACTIONS_N23     Cost=3     Cardinality=1     
                        INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_LOOKUP_VALUES_U1     Cost=2     Cardinality=1     Bytes=36
                       INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_TXN_SOURCE_TYPES_U1     Cost=0     Cardinality=1     Bytes=3
                      INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_TRANSACTION_TYPES_U1     Cost=0     Cardinality=1     Bytes=4
                     TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_PARAMETERS     Cost=1     Cardinality=1     Bytes=7
                      INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     
                    TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_PARAMETERS     Cost=1     Cardinality=1     Bytes=7
                     INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     
                   INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     Bytes=4
                  INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_SYSTEM_ITEMS_B_U1     Cost=2     Cardinality=1     Bytes=10
                 INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_SYSTEM_ITEMS_TL_U1     Cost=2     Cardinality=1     Bytes=13
              TABLE ACCESS BY INDEX ROWID     Object owner=HR     Object name=HR_ALL_ORGANIZATION_UNITS     Cost=1     Cardinality=1     Bytes=7
               INDEX UNIQUE SCAN     Object owner=HR     Object name=HR_ORGANIZATION_UNITS_PK     Cost=0     Cardinality=1     
             INDEX UNIQUE SCAN     Object owner=HR     Object name=HR_ALL_ORGANIZATION_UNTS_TL_PK     Cost=0     Cardinality=1     Bytes=7
            TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_PARAMETERS     Cost=1     Cardinality=1     Bytes=8
             INDEX UNIQUE SCAN     Object owner=INV     Object name=MTL_PARAMETERS_U1     Cost=0     Cardinality=1     
           TABLE ACCESS BY INDEX ROWID     Object owner=GL     Object name=GL_CODE_COMBINATIONS     Cost=2     Cardinality=1     Bytes=57
            INDEX UNIQUE SCAN     Object owner=GL     Object name=GL_CODE_COMBINATIONS_U1     Cost=1     Cardinality=1     
          TABLE ACCESS BY INDEX ROWID     Object owner=INV     Object name=MTL_ITEM_LOCATIONS     Cost=3     Cardinality=1     Bytes=24
           INDEX RANGE SCAN     Object owner=INV     Object name=MTL_ITEM_LOCATIONS_U1     Cost=2     Cardinality=1     
         TABLE ACCESS BY INDEX ROWID     Object owner=HR     Object name=HR_ORGANIZATION_INFORMATION     Cost=2     Cardinality=1     Bytes=28
          INDEX RANGE SCAN     Object owner=HR     Object name=HR_ORGANIZATION_INFORMATIO_FK2     Cost=1     Cardinality=2     
        TABLE ACCESS BY INDEX ROWID     Object owner=HR     Object name=HR_ORGANIZATION_INFORMATION     Cost=1     Cardinality=1     Bytes=25
         INDEX RANGE SCAN     Object owner=HR     Object name=HR_ORGANIZATION_INFORMATIO_FK2     Cost=1     Cardinality=1     
       INDEX FULL SCAN     Object owner=GL     Object name=GL_SETS_OF_BOOKS_U2     Cost=1     Cardinality=1     Bytes=4
      BUFFER SORT               Cost=55     Cardinality=1     
       TABLE ACCESS FULL     Object owner=APPLSYS     Object name=FND_PRODUCT_GROUPS     Cost=3     Cardinality=1     

  • Query taking high  CPU usage

    Hi,
    I have a Oracle 9.2 DB with 2 cpu's,when i took a statspack report i found that CPU Time is very hight i,e more that 81%....
    one of the query is taking near about 51% CPU Usage...
    i.e
    SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE)  */DISTINCT CF_COURSE_CODE   FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL  WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID  AND
    SFCD_FEE_TYPE_CODE = CF_TYPE_CODE  AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT'  ) AND SFCH_TXN_CODE = :b1  AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C'  ) AND SFCH_APPR_UID IS NOT NULL  
    AND SFCH_APPR_DT IS NOT NULL   AND SFCH_NO = :b2  AND NOT EXISTS  (SELECT 'X'   FROM OM_STUDENT_HEAD  WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO  AND NVL(STUD_CLO_STATUS,0) != 1  AND
    NVL(STUD_REG_STATUS,0) != 23  AND STUD_COURSE_CODE != 'CCT'  AND CF_COURSE_CODE= STUD_COURSE_CODE )  ORDER BY 1 DESCExplain Plan for......
    SQL> select * from table(dbms_xplan.display());
    PLAN_TABLE_OUTPUT
    | Id  | Operation                                  |  Name
       | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT                           |
    PLAN_TABLE_OUTPUT
       |     1 |    69 |    45 |       |       |
    |   1 |  SORT UNIQUE                               |
       |     1 |    69 |    27 |       |       |
    |   2 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | OT_STUDENT_FEE_COL_DETL
       |     1 |    12 |     2 | ROWID | ROW L |
    |   3 |    NESTED LOOPS                            |
       |     1 |    69 |     9 |       |       |
    PLAN_TABLE_OUTPUT
    |   4 |     NESTED LOOPS                           |
       |     1 |    57 |     7 |       |       |
    |   5 |      TABLE ACCESS BY GLOBAL INDEX ROWID    | OT_STUDENT_FEE_COL_HEAD
       |     1 |    48 |     5 | ROWID | ROW L |
    |   6 |       INDEX SKIP SCAN                      | OT_STUDENT_FEE_COL_HEAD_UK0
    1  |     1 |       |     4 |       |       |
    |   7 |      INLIST ITERATOR                       |
       |       |       |       |       |       |
    PLAN_TABLE_OUTPUT
    |   8 |       TABLE ACCESS BY INDEX ROWID          | OM_COURSE_FEE
       |     1 |     9 |     2 |       |       |
    |   9 |        INDEX RANGE SCAN                    | OCF_CFC_CODE
       |     1 |       |     1 |       |       |
    |  10 |         FILTER                             |
       |       |       |       |       |       |
    |  11 |          TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD
    PLAN_TABLE_OUTPUT
       |     1 |    21 |     4 | ROWID | ROW L |
    |  12 |           INDEX RANGE SCAN                 | IDM_STUD_SRN_COURSE
       |     1 |       |     3 |       |       |
    |  13 |     INDEX RANGE SCAN                       | IDM_SFCD_FEE_TYPE_CODE
       | 34600 |       |     1 |       |       |
    PLAN_TABLE_OUTPUT
    Note: cpu costing is off, PLAN_TABLE' is old version
    21 rows selected.
    SQL>Statspack report
    DB Name         DB Id    Instance     Inst Num Release     Cluster Host
    ai          1372079993 ai11              1 9.2.0.6.0   YES     ai1
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
    Begin Snap:       175 12-Dec-08 13:21:33  #######        .0
      End Snap:       176 12-Dec-08 13:56:09  #######        .0
       Elapsed:               34.60 (mins)
    Cache Sizes (end)
    ~~~~~~~~~~~~~~~~~
                   Buffer Cache:     3,264M      Std Block Size:          8K
               Shared Pool Size:       608M          Log Buffer:        977K
    Load Profile
    ~~~~~~~~~~~~                            Per Second       Per Transaction
                      Redo size:              5,727.62             21,658.54
                  Logical reads:             16,484.89             62,336.32
                  Block changes:                 32.49                122.88
                 Physical reads:                200.46                758.03
                Physical writes:                  5.08                 19.23
                     User calls:                 97.43                368.44
                         Parses:                 11.66                 44.11
                    Hard parses:                  0.39                  1.48
                          Sorts:                  3.22                 12.19
                         Logons:                  0.02                  0.06
                       Executes:                 36.70                138.77
                   Transactions:                  0.26
      % Blocks changed per Read:    0.20    Recursive Call %:     28.65
    Rollback per transaction %:   20.95       Rows per Sort:    131.16
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00       Redo NoWait %:    100.00
                Buffer  Hit   %:   98.79    In-memory Sort %:     99.99
                Library Hit   %:   98.92        Soft Parse %:     96.65
             Execute to Parse %:   68.21         Latch Hit %:     99.98
    Parse CPU to Parse Elapsd %:   60.50     % Non-Parse CPU:     99.48
    Shared Pool Statistics        Begin   End
                 Memory Usage %:   90.06   89.79
        % SQL with executions>1:   72.46   72.46
      % Memory for SQL w/exec>1:   69.42   69.51
    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~                                                     % Total
    Event                                               Waits    Time (s) Ela Time
    CPU time                                                        3,337    81.43
    db file sequential read                            60,550         300     7.32
    global cache cr request                           130,852         177     4.33
    db file scattered read                             72,915         101     2.46
    db file parallel read                               3,384          75     1.84
    Cluster Statistics for DB: ai  Instance: ai11  Snaps: 175 -176
    Global Cache Service - Workload Characteristics
    Ave global cache get time (ms):                            1.3
    Ave global cache convert time (ms):                        2.1
    Ave build time for CR block (ms):                          0.1
    Ave flush time for CR block (ms):                          0.3
    Ave send time for CR block (ms):                           0.3
    Ave time to process CR block request (ms):                 0.7
    Ave receive time for CR block (ms):                        4.9
    Ave pin time for current block (ms):                       0.0
    Ave flush time for current block (ms):                     0.0
    Ave send time for current block (ms):                      0.3
    Ave time to process current block request (ms):            0.3
    Ave receive time for current block (ms):                   2.8
    Global cache hit ratio:                                    1.5
    Ratio of current block defers:                             0.0
    % of messages sent for buffer gets:                        1.4
    % of remote buffer gets:                                   0.1
    Ratio of I/O for coherence:                                1.1
    Ratio of local vs remote work:                             9.7
    Ratio of fusion vs physical writes:                        0.1
    Global Enqueue Service Statistics
    Ave global lock get time (ms):                             0.8
    Ave global lock convert time (ms):                         0.0
    Ratio of global lock gets vs global lock releases:         1.1
    GCS and GES Messaging statistics
    Ave message sent queue time (ms):                          0.4
    Ave message sent queue time on ksxp (ms):                  2.7
    Ave message received queue time (ms):                      0.2
    Ave GCS message process time (ms):                         0.1
    Ave GES message process time (ms):                         0.1
    % of direct sent messages:                                19.4
    % of indirect sent messages:                              43.5
    % of flow controlled messages:                            37.1
    GES Statistics for DB: ai  Instance: ai11  Snaps: 175 -176
    Statistic                                    Total   per Second    per Trans
    dynamically allocated gcs resourc                0          0.0          0.0
    dynamically allocated gcs shadows                0          0.0          0.0
    flow control messages received                   0          0.0          0.0
    flow control messages sent                       0          0.0          0.0
    gcs ast xid                                      0          0.0          0.0
    gcs blocked converts                         1,231          0.6          2.2
    gcs blocked cr converts                      2,432          1.2          4.4
    gcs compatible basts                             0          0.0          0.0
    gcs compatible cr basts (global)               658          0.3          1.2
    gcs compatible cr basts (local)             57,822         27.9        105.3
    gcs cr basts to PIs                              0          0.0          0.0
    gcs cr serve without current lock                0          0.0          0.0
    gcs error msgs                                   0          0.0          0.0
    gcs flush pi msgs                              821          0.4          1.5
    gcs forward cr to pinged instance                0          0.0          0.0
    gcs immediate (compatible) conver              448          0.2          0.8
    gcs immediate (null) converts                1,114          0.5          2.0
    gcs immediate cr (compatible) con           42,094         20.3         76.7
    gcs immediate cr (null) converts           396,284        190.9        721.8
    gcs msgs process time(ms)                   42,220         20.3         76.9
    gcs msgs received                          545,133        262.6        993.0
    gcs out-of-order msgs                            5          0.0          0.0
    gcs pings refused                                1          0.0          0.0
    gcs queued converts                              0          0.0          0.0
    gcs recovery claim msgs                          0          0.0          0.0
    gcs refuse xid                                   0          0.0          0.0
    gcs retry convert request                        0          0.0          0.0
    gcs side channel msgs actual                 2,397          1.2          4.4
    gcs side channel msgs logical              232,024        111.8        422.6
    gcs write notification msgs                     15          0.0          0.0
    gcs write request msgs                         278          0.1          0.5
    gcs writes refused                               1          0.0          0.0
    ges msgs process time(ms)                    4,873          2.3          8.9
    ges msgs received                           39,769         19.2         72.4
    global posts dropped                             0          0.0          0.0
    global posts queue time                          0          0.0          0.0
    global posts queued                              0          0.0          0.0
    global posts requested                           0          0.0          0.0
    global posts sent                                0          0.0          0.0
    implicit batch messages received            39,098         18.8         71.2
    implicit batch messages sent                33,386         16.1         60.8
    lmd msg send time(ms)                          635          0.3          1.2
    lms(s) msg send time(ms)                         2          0.0          0.0
    messages flow controlled                   196,546         94.7        358.0
    messages received actual                   182,783         88.0        332.9
    messages received logical                  584,848        281.7      1,065.3
    messages sent directly                     102,657         49.4        187.0
    messages sent indirectly                   230,329        110.9        419.5
    msgs causing lmd to send msgs                9,169          4.4         16.7
    msgs causing lms(s) to send msgs             3,347          1.6          6.1
    msgs received queue time (ms)              142,759         68.8        260.0
    msgs received queued                       584,818        281.7      1,065.2
    msgs sent queue time (ms)                   99,300         47.8        180.9
    msgs sent queue time on ksxp (ms)          608,239        293.0      1,107.9
    msgs sent queued                           230,391        111.0        419.7
    msgs sent queued on ksxp                   229,013        110.3        417.1
    GES Statistics for DB: ai  Instance: ai11  Snaps: 175 -176
    Statistic                                    Total   per Second    per Trans
    process batch messages received             65,059         31.3        118.5
    process batch messages sent                 50,959         24.5         92.8
    Wait Events for DB: ai  Instance: ai11  Snaps: 175 -176
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                         Total Wait   wait    Waits
    Event                               Waits   Timeouts   Time (s)   (ms)     /txn
    db file sequential read            60,550          0        300      5    110.3
    global cache cr request           130,852        106        177      1    238.3
    db file scattered read             72,915          0        101      1    132.8
    db file parallel read               3,384          0         75     22      6.2
    latch free                          7,253      1,587         52      7     13.2
    enqueue                            44,947          0         16      0     81.9
    log file parallel write             2,140          0          6      3      3.9
    db file parallel write                341          0          5     14      0.6
    global cache open x                 1,134          3          4      4      2.1
    CGS wait for IPC msg              166,993    164,390          4      0    304.2
    library cache lock                  3,169          0          3      1      5.8
    log file sync                         494          0          3      5      0.9
    row cache lock                        702          0          3      4      1.3
    DFS lock handle                     6,900          0          2      0     12.6
    control file parallel write           689          0          2      3      1.3
    control file sequential read        2,785          0          2      1      5.1
    wait for master scn                   687          0          2      2      1.3
    global cache null to x                699          0          2      2      1.3
    global cache s to x                   778          5          1      2      1.4
    direct path write                     148          0          0      3      0.3
    SQL*Net more data to client         3,621          0          0      0      6.6
    global cache open s                   149          0          0      2      0.3
    library cache pin                      78          0          0      2      0.1
    ksxr poll remote instances          3,536      2,422          0      0      6.4
    LGWR wait for redo copy                12          6          0      9      0.0
    buffer busy waits                      23          0          0      5      0.0
    direct path read                        9          0          0     10      0.0
    buffer busy global CR                   5          0          0     17      0.0
    SQL*Net break/reset to clien          172          0          0      0      0.3
    global cache quiesce wait               4          1          0      7      0.0
    KJC: Wait for msg sends to c           86          0          0      0      0.2
    BFILE get length                       67          0          0      0      0.1
    global cache null to s                  9          0          0      1      0.0
    BFILE open                              6          0          0      0      0.0
    BFILE read                             60          0          0      0      0.1
    BFILE internal seek                    60          0          0      0      0.1
    BFILE closure                           6          0          0      0      0.0
    cr request retry                        4          4          0      0      0.0
    SQL*Net message from client       201,907          0    180,583    894    367.8
    gcs remote message                171,236     43,749      3,975     23    311.9
    ges remote message                 79,324     40,722      2,017     25    144.5
    SQL*Net more data from clien          447          0          9     21      0.8
    SQL*Net message to client         201,901          0          0      0    367.8
    Background Wait Events for DB: ai  Instance: ai11  Snaps: 175 -176
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                         Total Wait   wait    Waits
    Event                               Waits   Timeouts   Time (s)   (ms)     /txn
    enqueue                            44,666          0         16      0     81.4
    latch free                          4,895        108          6      1      8.9
    log file parallel write             2,140          0          6      3      3.9
    db file parallel write                341          0          5     14      0.6
    CGS wait for IPC msg              166,969    164,366          4      0    304.1
    DFS lock handle                     6,900          0          2      0     12.6
    control file parallel write           689          0          2      3      1.3
    control file sequential read        2,733          0          2      1      5.0
    wait for master scn                   687          0          2      2      1.3
    ksxr poll remote instances          3,528      2,419          0      0      6.4
    LGWR wait for redo copy                12          6          0      9      0.0
    db file sequential read                 7          0          0      9      0.0
    global cache null to x                 26          0          0      2      0.0
    global cache open x                    16          0          0      1      0.0
    global cache cr request                 1          0          0      0      0.0
    rdbms ipc message                  28,636     20,600     16,937    591     52.2
    gcs remote message                171,254     43,746      3,974     23    311.9
    pmon timer                            708        686      2,022   2856      1.3
    ges remote message                 79,305     40,719      2,017     25    144.5
    smon timer                            125          0      1,972  15776      0.2
    SQL ordered by Gets for DB: ai  Instance: ai11  Snaps: 175 -176
    -> End Buffer Gets Threshold:     10000
    -> Note that resources reported for PL/SQL includes the resources used by
       all SQL statements called within the PL/SQL code.  As individual SQL
       statements are also reported, it is possible and valid for the summed
       total % to exceed 100
                                                         CPU      Elapsd
      Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
         17,503,305           84      208,372.7   51.1   676.25   1218.80   17574787
    SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE)  */DISTINCT CF_COU
    RSE_CODE   FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT
    FEECOL_DETL  WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID  AND SFCD_FE
    E_TYPE_CODE = CF_TYPE_CODE  AND CF_COURSE_CODE IN ( 'PE1','PE2',
    'CCT','CPT'  ) AND SFCH_TXN_CODE = :b1  AND SFCD_SUBSCRBE_JOURNA

    user00726 wrote:
    somw of the changes that have been done....
    cai11_lmd0_15771.trc.
    Thu Oct 2 13:35:48 2008
    CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
    CKPT: Current size = 2512 MB, Target size = 3072 MB
    CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
    Thu Oct 2 13:35:50 2008
    ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
    Thu Oct 2 14:04:34 2008
    ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
    ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
    Thu Oct 2 15:24:14 2008
    CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
    CKPT: Current size = 3072 MB, Target size = 2512 MB
    CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
    Thu Oct 2 15:24:20 2008
    ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
    Thu Oct 2 15:32:33 2008
    CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
    CKPT: Current size = 2512 MB, Target size = 3072 MB
    CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
    Thu Oct 2 15:32:34 2008
    ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
    Thu Oct 2 15:36:46 2008
    ALTER SYSTEM SET shared_pool_size='640M' SCOPE=BOTH SID='icai11';
    Thu Oct 2 16:33:52 2008
    CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
    CKPT: Current size = 3072 MB, Target size = 2512 MB
    CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
    Thu Oct 2 16:33:56 2008
    ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
    Thu Oct 2 16:39:30 2008
    ALTER SYSTEM SET pga_aggregate_target='750M' SCOPE=BOTH SID='icai11';Just to make certain that I am not missing anything, if the above you set (all scaled to GB just for the sake of comparison):
    sga_max_size=4885GB
    db_cache_size=3GB
    shared_pool_size=0.625GB
    pga_aggregate_target=0.733GB
    The SQL statement is forcing the use of a specific index, is this the best index?:
    SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
    SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
    AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
    NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESC
    Unfortunately, explain plans, even with dbms_xplan.display, may not show the actual execution plan - this is more of a problem when the SQL statement includes bind variables (capturing a 10046 trace at level 8 or 12 will help). With the information provided, it looks like the problem is with the number of logical reads performed: 17,503,305 in 84 executions = 208,373 logical reads per execution. Something is causing the SQL statement to execute inefficiently, possibly a join problem between tables, possibly the forced use of an index.
    From one of my previous posts related to this same SQL statement:
    SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE)  */ DISTINCT
      CF_COURSE_CODE
    FROM
      OM_COURSE_FEE,
      OT_STUDENT_FEE_COL_HEAD,
      OT_STUDENT_FEE_COL_DETL
    WHERE
      SFCH_SYS_ID = SFCD_SFCH_SYS_ID
      AND SFCD_FEE_TYPE_CODE = CF_TYPE_CODE
      AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT'  )
      AND SFCH_TXN_CODE = :b1
      AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C'  )
      AND SFCH_APPR_UID IS NOT NULL
      AND SFCH_APPR_DT IS NOT NULL
      AND SFCH_NO = :b2
      AND NOT EXISTS (
        SELECT
          'X'
        FROM
          OM_STUDENT_HEAD
        WHERE
          STUD_SRN = SFCH_STUD_SRN_TEMP_NO
          AND NVL(STUD_CLO_STATUS,0) != 1
          AND NVL(STUD_REG_STATUS,0) != 23
          AND STUD_COURSE_CODE != 'CCT'
          AND CF_COURSE_CODE = STUD_COURSE_CODE)
    ORDER BY
      1 DESC
    | Id  | Operation                                  |  Name                     | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT                                                             1      69      34
    |   1 |  SORT UNIQUE                                                                 1      69      22
    |   2 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | OT_STUDENT_FEE_COL_DETL   |     1 |    12 |     2 | ROWID | ROW L |
    |   3 |    NESTED LOOPS                                                              1      69       9
    |   4 |     NESTED LOOPS                                                             1      57       7
    |   5 |      TABLE ACCESS BY GLOBAL INDEX ROWID    | OT_STUDENT_FEE_COL_HEAD   |     1 |    48 |     5 | ROWID | ROW L |
    |   6 |       INDEX SKIP SCAN                       OT_STUDENT_FEE_COL_HEAD_UK0|     1 |     1 |     4 |
    |   7 |      INLIST ITERATOR                       |
    |   8 |       TABLE ACCESS BY INDEX ROWID          | OM_COURSE_FEE             |     1 |     9 |     2 |       |       |
    |   9 |        INDEX RANGE SCAN                    | OCF_CFC_CODE              |     1 |       |     1 |       |       |
    |  10 |         FILTER                            
    |  11 |          TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD           |     1 |    21 |     4 | ROWID | ROW L |
    |  12 |           INDEX RANGE SCAN                 | IDM_STUD_SRN_COURSE       |     1 |       |     3 |       |       |
    |  13 |     INDEX RANGE SCAN                       | IDM_SFCD_FEE_TYPE_CODE    | 34600 |       |     1 |       |       |It appears, based just on the SQL statement, that there is no direct relationship between OM_COURSE_FEE and OT_STUDENT_FEE_COL_HEAD, yet the plan above indicates that the two tables are being joined together, likely as a result of the index hint. There is the possibility of additional predicates being generated by Oracle which will make this possible without introducing a Cartesian join, but those predicates are not displayed with an explain plan (they will appear with a DBMS_XPLAN). I may not be remembering correctly, but if the optimizer goal is set to first rows, a Cartesian join might appear in a plan as a nested loops join - Jonathan will know for certain if that is the case.
    Have you investigated the above as a possible cause? If you know that there is a problem with this one SQL statement, a 10046 trace at level 8 or 12 is much more helpful than a Statspack report.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

Maybe you are looking for

  • Lion + Safari made Google Earth stop working properly

    Upgraded to Lion now Google Earth Plugin won't work on Safari anymore. It works perfectly on Firefox, Chrome and Opera. I would like to keep using...please help. Thanks. It worked FLAWLESSLY (Safari & Google Earth) on Snow Leopard before upgrading to

  • Opinions on FCP w/ Quad or 8-core

    Do you think it's worth the extra money to invest in the 8 core Mac Pro, instead of Quad, mostly for use with Final Cut Studio?

  • Check Printing FBZ5/ F-58

    Hi all,    I am using these two transactions for check printing. How to print check from it. I am creating smartform. How can i attach this to the transaction? Thanks in advamce

  • Anchors above anchored frames

    Hi all, I'm developing some templates for computer software manuals. I need a nice neat generic method for adding images and their titles. I need the figure titles to be positioned in the side heading, aligned with the top of the figure beside it. Fo

  • Metadata for file

    How to create a custom metadata for a file/document to be uploaded to KM and use just that metadata in search. Kiran