Query runs slower in function

Why is it that a query takes more than 15 seconds to run in a function, but only one second when run separately in a query editor window in Toad? Here's the query, where piSiteID, piProtocolID, DrugType1 and DrugType2 are all parameters and v_drug_packs_dispensable is a view that loads almost instantly. I have added all the necessary indexes (or at least I think so).
SELECT MIN(DRUG_EXPIRE_DT) INTO ExpDate
FROM V_DRUG_PACKS_DISPENSABLE dp
WHERE SITE_ID = piSiteID
AND PROTOCOL_ID = piProtocolID
and drug_type_id = DrugType1 or drug_type_id = DrugType2;
If you take this same function and put it in an Editor window and fill in the parameters, it executes immediately.

Toadthat's the answer.... Toad tends to only show the first x rows, try to get the last row in Toad and you'll notice it takes more time (comparable to the function). Toad does a first-rows optimalization.

Similar Messages

  • Query of query - running slower on 64 bit CF than 32 bit CF

    Greetings...
    I am seeing behavior where pages that use query-of-query run slower on 64-bit Coldfusion 9.01 than on 32-bit Coldfusion 9.01.
    My server specs are : dual processer virtual machine, 4 GIG ram, Windows 2008 Datacenter Server r2 64-bit, Coldfusion 9.01. Note that the coldfusion is literally "straight out of the box", and is using all default settings - the only thing I configured in CF is a single datasource.
    The script I am using to benchmark this runs a query that returns 20,000 rows with fields id, firstname, lastname, email, city, datecreated. I then loop through all 20,000 records, and for each record, I do a query-of-query (on the same master query) to find any other record where the lastname matches that of the record I'm currently on. Note that I'm only interested in using this process for comparative benchmarking purposes, and I know that the process could be written more efficiently.
    Here are my observed execution times for both 64-bit and 32-bit Coldfusion (in seconds) on the same machine.
    64 bit CF 9.01: 63,49,52,52,52,48,50,49,54 (avg=52 seconds)
    32 bit CF 9.01: 47,45,43,43,45,41,44,42,46 (avg=44 seconds)
    It appears from this that 64-bit CF performs worse than 32-bit CF when doing query-of-query operations. Has anyone made similar observations, and is there any way I can tune the environment to improve 64 bit performance?
    Thanks for any help you can provide!
    By the way, here's the code that is generating these results:
    <!--- Allrecs query returns 20000 rows --->
    <CFQUERY NAME="ALLRECS" DATASOURCE="MyDsn">
        SELECT * FROM MyTBL
    </CFQUERY>
    <CFLOOP QUERY="ALLRECS">
        <CFQUERY NAME="SAMELASTNAME" DBTYPE="QUERY">
            SELECT * FROM ALLRECS
            WHERE LN=<CFQUERYPARAM VALUE="#ALLRECS.LN#" CFSQLTYPE="CF_SQL_VARCHAR">
            AND ID<><CFQUERYPARAM VALUE="#AllRecs.ID#" CFSQLTYPE="CF_SQL_INTEGER">
        </CFQUERY>
        <CFIF SameLastName.RecordCount GT 20>
            #AllRecs.LN#, #AllRecs.FN# : #SameLastName.RecordCount# other records with same lastname<BR>
        </CFIF>
    </CFLOOP>

    BoBear2681 wrote:
    ..follow-up: ..Thanks for the follow-up. I'll be interested to hear the progress (or otherwise, as the case may be).
    As an aside. I got sick of trying to deal with Clip because it could only handle very small Clip sizes. AFAIR it was 1 second of 44.1 KHz stereo. From that point, I developed BigClip.
    Unfortunately BigClip as it stands is even less able to fulfil your functional requirement than Clip, in that only one BigClip can be playing at a time. Further, it can be blocked by other sound applications (e.g. VLC Media Player, Flash in a web page..) or vice-versa.

  • Query runs slower when using variables & faster when using hard coded value

    Hi,
    My query runs slower when i use variables but it runs faster when i use hard coded values. Why it is behaving like this ?
    My query is in cursor definition in a procedure. Procedure runs faster when using hard coded valus and slower when using variables.
    Can anybody help me out there?
    Thanks in advance.

    Hi,
    Thanks for ur reply.
    here is my code with Variables:
    Procedure populateCountryTrafficDetails(pWeekStartDate IN Date , pCountry IN d_geography.country_code%TYPE) is
    startdate date;
    AR_OrgId number(10);
    Cursor cTraffic is
    Select
              l.actual_date, nvl(o.city||o.zipcode,'Undefined') Site,
              g.country_code,d.customer_name, d.customer_number,t.contrno bcn,
              nvl(r.dest_level3,'Undefined'),
              Decode(p.Product_code,'820','821','821','821','801') Product_Code ,
              Decode(p.Product_code,'820','Colt Voice Connect','821','Colt Voice Connect','Colt Voice Line') DProduct,
              sum(f.duration),
              sum(f.debamount_eur)
              from d_calendar_date l,
              d_geography g,
              d_customer d, d_contract t, d_subscriber s,
              d_retail_dest r, d_product p,
              CPS_ORDER_DETAILS o,
              f_retail_revenue f
              where
              l.date_key = f.call_date_key and
              g.geography_key = f.geography_key and
              r.dest_key = f.dest_key and
              p.product_key = f.product_key and
              --c.customer_key = f.customer_key and
              d.customer_key = f.customer_key and
              t.contract_key = f.contract_key and
              s.SUBSCRIBER_KEY = f.SUBSCRIBER_KEY and
              o.org_id(+) = AR_OrgId and
              g.country_code = pCountry and
              l.actual_date >= startdate and
              l.actual_date <= (startdate + 90) and
              o.cli(+) = s.area_subno and
              p.product_code in ('800','801','802','804','820','821')
              group by
              l.actual_date,
              o.city||o.zipcode, g.country_code,d.customer_name, d.customer_number,t.contrno,r.dest_level3, p.product_code;
    Type CountryTabType is Table of country_traffic_details.Country%Type index by BINARY_INTEGER;
    Type CallDateTabType is Table of country_traffic_details.CALL_DATE%Type index by BINARY_INTEGER;
    Type CustomerNameTabType is Table of Country_traffic_details.Customer_name%Type index by BINARY_INTEGER;
    Type CustomerNumberTabType is Table of Country_traffic_details.Customer_number%Type index by BINARY_INTEGER;
    Type BcnTabType is Table of Country_traffic_details.Bcn%Type index by BINARY_INTEGER;
    Type DestinationTypeTabType is Table of Country_traffic_details.DESTINATION_TYPE%Type index by BINARY_INTEGER;
    Type ProductCodeTabType is Table of Country_traffic_details.Product_Code%Type index by BINARY_INTEGER;
    Type ProductTabType is Table of Country_traffic_details.Product%Type index by BINARY_INTEGER;
    Type DurationTabType is Table of Country_traffic_details.Duration%Type index by BINARY_INTEGER;
    Type DebamounteurTabType is Table of Country_traffic_details.DEBAMOUNTEUR%Type index by BINARY_INTEGER;
    Type SiteTabType is Table of Country_traffic_details.Site%Type index by BINARY_INTEGER;
    CountryArr CountryTabType;
    CallDateArr CallDateTabType;
    Customer_NameArr CustomerNameTabType;
    CustomerNumberArr CustomerNumberTabType;
    BCNArr BCNTabType;
    DESTINATION_TYPEArr DESTINATIONTYPETabType;
    PRODUCT_CODEArr PRODUCTCODETabType;
    PRODUCTArr PRODUCTTabType;
    DurationArr DurationTabType;
    DebamounteurArr DebamounteurTabType;
    SiteArr SiteTabType;
    Begin
         startdate := (trunc(pWeekStartDate) + 6) - 90;
         Exe_Pos := 1;
         Execute Immediate 'Truncate table country_traffic_details';
         dropIndexes('country_traffic_details');
         Exe_Pos := 2;
         /* Set org ID's as per AR */
         case (pCountry)
         when 'FR' then AR_OrgId := 81;
         when 'AT' then AR_OrgId := 125;
         when 'CH' then AR_OrgId := 126;
         when 'DE' then AR_OrgId := 127;
         when 'ES' then AR_OrgId := 123;
         when 'IT' then AR_OrgId := 122;
         when 'PT' then AR_OrgId := 124;
         when 'BE' then AR_OrgId := 132;
         when 'IE' then AR_OrgId := 128;
         when 'DK' then AR_OrgId := 133;
         when 'NL' then AR_OrgId := 129;
         when 'SE' then AR_OrgId := 130;
         when 'UK' then AR_OrgId := 131;
         else raise_application_error (-20003, 'No such Country Code Exists.');
         end case;
         Exe_Pos := 3;
    dbms_output.put_line('3: '||to_char(sysdate, 'HH24:MI:SS'));
         populateOrderDetails(AR_OrgId);
    dbms_output.put_line('4: '||to_char(sysdate, 'HH24:MI:SS'));
         Exe_Pos := 4;
         Open cTraffic;
         Loop
         Exe_Pos := 5;
         CallDateArr.delete;
    FETCH cTraffic BULK COLLECT
              INTO CallDateArr, SiteArr, CountryArr, Customer_NameArr,CustomerNumberArr,
              BCNArr,DESTINATION_TYPEArr,PRODUCT_CODEArr, PRODUCTArr, DurationArr, DebamounteurArr LIMIT arraySize;
              EXIT WHEN CallDateArr.first IS NULL;
                   Exe_pos := 6;
                        FORALL i IN 1..callDateArr.last
                        insert into country_traffic_details
                        values(CallDateArr(i), CountryArr(i), Customer_NameArr(i),CustomerNumberArr(i),
                        BCNArr(i),DESTINATION_TYPEArr(i),PRODUCT_CODEArr(i), PRODUCTArr(i), DurationArr(i),
                        DebamounteurArr(i), SiteArr(i));
                        Exe_pos := 7;
    dbms_output.put_line('7: '||to_char(sysdate, 'HH24:MI:SS'));
         EXIT WHEN ctraffic%NOTFOUND;
    END LOOP;
         commit;
    Exe_Pos := 8;
              commit;
    dbms_output.put_line('8: '||to_char(sysdate, 'HH24:MI:SS'));
              lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_CUSTNO ON country_traffic_details (CUSTOMER_NUMBER)';
              execDDl(lSql);
              lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_BCN ON country_traffic_details (BCN)';
              execDDl(lSql);
              lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_PRODCD ON country_traffic_details (PRODUCT_CODE)';
              execDDl(lSql);
              lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_SITE ON country_traffic_details (SITE)';
              execDDl(lSql);
              lSql := 'CREATE INDEX COUNTRY_TRAFFIC_DETAILS_DESTYP ON country_traffic_details (DESTINATION_TYPE)';
              execDDl(lSql);
              Exe_Pos:= 9;
    dbms_output.put_line('9: '||to_char(sysdate, 'HH24:MI:SS'));
    Exception
         When Others then
         raise_application_error(-20003, 'Error in populateCountryTrafficDetails at Position: '||Exe_Pos||' The Error is '||SQLERRM);
    End populateCountryTrafficDetails;
    In the above procedure if i substitute the values with hard coded values i.e. AR_orgid = 123 & pcountry = 'Austria' then it runs faster.
    Please let me know why it is so ?
    Thanks in advance.

  • Query Runs Slow in Forms

    I have a search query that uses the substr function to fetch some records.The query runs fine when executing SQL*PLUS or any other client like PL/SQL Developer. The same query is dead slow in Forms interface.
    Can anyone suggest?

    Both the query use the substr function. Here is the query. only highlighted IF condition evaluates to true.
         V_SEARCH VARCHAR2(255);
    BEGIN
         --- SET MOBILENO
         IF :CONTROL.MOBILENO IS NOT NULL AND LENGTH(:CONTROL.MOBILENO) <= 7 THEN
              IF :CONTROL.QRY_MOBILENO = 'P' THEN
                   V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) = '||''''||:CONTROL.MOBILENO||'''';
              ELSIF :CONTROL.QRY_MOBILENO = 'S' THEN
                   V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||''''||:CONTROL.MOBILENO||'%''';     
              ELSIF :CONTROL.QRY_MOBILENO = 'E' THEN
                   V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||'''%'||:CONTROL.MOBILENO||'''';     
              ELSIF :CONTROL.QRY_MOBILENO = 'C' THEN
                   V_SEARCH := V_SEARCH||' AND substr(MOBILENO,5,7) LIKE '||'''%'||:CONTROL.MOBILENO||'%''';     
              END IF;     
         ELSIF :CONTROL.MOBILENO IS NOT NULL AND LENGTH(:CONTROL.MOBILENO) <= 11 THEN
              IF :CONTROL.QRY_MOBILENO = 'P' THEN
                   V_SEARCH := V_SEARCH||' AND MOBILENO = '||''''||:CONTROL.MOBILENO||'''';
              ELSIF :CONTROL.QRY_MOBILENO = 'S' THEN
                   V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||''''||:CONTROL.MOBILENO||'%''';     
              ELSIF :CONTROL.QRY_MOBILENO = 'E' THEN
                   V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||'''%'||:CONTROL.MOBILENO||'''';     
              ELSIF :CONTROL.QRY_MOBILENO = 'C' THEN
                   V_SEARCH := V_SEARCH||' AND MOBILENO LIKE '||'''%'||:CONTROL.MOBILENO||'%''';     
              END IF;     
         END IF;     
         --NDC
         IF :CONTROL.NDC IS NOT NULL THEN
                   V_SEARCH := V_SEARCH||' AND SUBSTR(MOBILENO,1,4) = '||''''||:CONTROL.NDC||'''';
         END IF;
         --Number Type
         IF :CONTROL.number_type IS NOT NULL THEN
                   V_SEARCH := V_SEARCH||' AND number_type = '||''''||:CONTROL.number_type||'''';
         END IF;     
         --Status
         IF :CONTROL.status IS NOT NULL THEN
                   V_SEARCH := V_SEARCH||' AND status = '||''''||substr(:CONTROL.status,1,1)||'''';
         END IF;     
         --CITY
         IF :CONTROL.CITY IS NOT NULL THEN
                   V_SEARCH := V_SEARCH||' AND LOC_NAME = '||''''||:CONTROL.CITY||'''';
         END IF;     
         --REGION
         IF :CONTROL.REGION IS NOT NULL THEN
                   V_SEARCH := V_SEARCH||' AND COMM_REGION = '||''''||:CONTROL.REGION||'''';
         END IF;     
         --RECYCLE FLAG
         IF :CONTROL.RECYCLE_FLAG <> 'A' THEN
              V_SEARCH := V_SEARCH||' AND RECYCLE_FLAG = '||''''||:CONTROL.RECYCLE_FLAG||'''';
         END IF;
         --EXECUTE QUERY
         V_SEARCH := SUBSTR(V_SEARCH,5);     
    GO_BLOCK('NO_INVENTORY');
         SET_BLOCK_PROPERTY('NO_INVENTORY',ONETIME_WHERE,V_SEARCH);
         EXECUTE_QUERY;
    END;

  • Query running slow

    Below query is running slow is there any other way to write the query which will enhance the performance.
    select ld.cst_fle_seq,
         tf.date_pro,
         lj.case_num ,
         ca.reference,
         rr.rej_txt
    from
         load_judg lj,
         rej_rea rr ,
         pl_case ca,
         tp_files tf ,
         tp tp
    where rr.rej_code(+) = ld.rej_code
    and ca.case_num (+)=lj.case_num
    and tp.seq =tf.seq
    and lj.cred_code(+) =tp.cst_code
    and tp.format =9
    and valid=''Y''
    and tf.fle_name like ''%F%''
    and lj.rej_code is not null
    and trunc(date_pro)=trunc(sysdate)
    Thanks in advance
    Jha

    Here is the explan plan of the query
    - SELECT STATEMENT Optimizer=CHOOSE (Cost=16 Card=1 Bytes=225)
    -NESTED LOOPS (Cost=16 Card=1 Bytes=225)
    -NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=192)
    - HASH JOIN (Cost=14 Card=1 Bytes=147)
    - MERGE JOIN (CARTESIAN) (Cost=9 Card=4 Bytes=432)
    -TABLE ACCESS (FULL) OF LOAD_JUDGMENTS (Cost=1 Card=1 Bytes=69)
    - SORT (JOIN)
    -TABLE ACCESS (FULL) OF TAPE_FILES
    -TABLE ACCESS (FULL) OF TAPES (Cost=4 Card=418 Bytes=16302)
    -TABLE ACCESS (BY ROWID) OF REJECT_REASONS
    -INDEX (UNIQUE SCAN) OF REJ_PK (UNIQUE)
    -TABLE ACCESS (BY ROWID) OF CASES
    -INDEX (UNIQUE SCAN) OF CASE_PK (UNIQUE)
    sorry, as I have checked the tables and its not a cartesian.
    Thanks
    Jha

  • Query running slow after 1000 rows in oracle

    Hi.
    I have one query which is fetching miln of rows.. the query runs very fast till 1000 to 1500 records after that it run very slow. Can you please help ,what could be the reason?
    Thanks

    831269 wrote:
    I have one query which is fetching miln of rows.. Why are you fetching that many rows? What is your client code going to do with a million rows? And why do you expect this to be fast? A million rows worth of I/O has to be done by Oracle (that will likely be mostly from disk and not buffer cache). That million rows has to be copied from the Oracle's SGA to client memory. If your client is PL/SQL code, that will be copied into the PGA. If your client is external, then that copy has to happen across platform boundaries and the network too.
    Then your code churns away on processing a million rows... doing what exactly? That "+what+" will need to be done once per row, for a million times. If it takes 10ms per row, that means almost 3h of client processing time.
    Fetching that many rows..? Often a design and coding mistake. Always an exception to the rule. Will never be "fast".
    And scalability and performance need to be addressed by re-examining the requirements, optimising the design that necessitates fetching that many rows, and using techniques such as parallel processing and thread safe code design.

  • Query Running Slow due to nvl.

    I have a Cursor Based query written as a Procedure.when i invoke that procedure,I found that two condition statements are the ones which is making my query run very slow.
    Since this has been handled with NVL statements query is running very slow.Currently query takes more than one hour to execute.if i comment these two statements and run the query,it takes ony 20 secs to complete.
    Those two statements are
    'and rbsa.batch_source_id = nvl(p_source_type_id, rbsa.batch_source_id)'
    'and rsa.salesrep_id between nvl(p_from_salesrep_id, rsa.salesrep_id) and nvl(p_to_salesrep_id, rsa.salesrep_id)'
    Is there any other alternative to replace these two statements by other means.
    Thanks in Advance...

    Dear Friend,
    Please try to replace nvl(p_source_type_id, rbsa.batch_source_id) with decode(p_source_type_id,NULL,rbsa.batch_source_id,p_source_type_id)
    It will speedup your query.
    Regards
    Ahamed Rafeeque Cherkala

  • SDO_ANYINTERACT query runs slower with numerous iterations

    hi all,
    I have some PL/SQL code within a loop that take longer and longer to run as it iterates through the loop.
    I have identified the problem function below. It seems that the SDO_ANYINTERACT takes longer and longer to execute the more it is called.
    I have found a bug on metalink 7003151 with indicates a potential memory leak issue. Could this be a cause? I know that this function runs as expected using Oracle Express. The issue is on a development server which has been patched to 10.2.0.4.
    FUNCTION SEARCHFORFEATURE(sTABLE VARCHAR2,gGEOM MDSYS.SDO_GEOMETRY, nSEARCH NUMBER) RETURN VARCHAR2 IS
    TYPE typNIMSREF IS TABLE OF VARCHAR2(10);
    vNIMSREF TYPNIMSREF;
    sSQL VARCHAR2(500);
    BEGIN
         sSQL := 'SELECT NIMSREF FROM ' || sTABLE || ' S WHERE SDO_ANYINTERACT(S.GEOLOC, :gGEOM) = 'TRUE';
         EXECUTE IMMEDIATE sSQL BULK COLLECT INTO vNIMSref USING gGEOM;
         IF vNIMSREF.COUNT = 1 THEN
              RETURN vNIMSREF(1);
         ELSIF vNIMSREF.COUNT > 1 THEN
              RETURN '-1';
         ELSE
              RETURN '-2';
         END IF;
    EXCEPTION -- exception-handling part starts here
         WHEN OTHERS THEN
         dbms_output.put_line(SQLERRM);
         dbms_output.put_line(sSQL);
    END SEARCHFORFEATURE;
    Thanks in advance
    Daniel

    I have run the query in SQLPLUS. As a single call performance is as expected. I ahve included the XPLAN. I have also tried using SDO_RELATE and SDO_INSIDE but it still slows down after a number if interations. I have looked at bug 7003151 but there are not available patches for a window 32bit OS.
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 3399 | 331K| 3 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| WATER_NODES | 3399 | 331K| 3 (0)| 00:00:01 |
    |* 2 | DOMAIN INDEX | WATER_NODES_SDX | | | | |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
    2 - access("MDSYS"."SDO_ANYINTERACT"("S"."GEOLOC","MDSYS"."SDO_GEOMETRY"(2003,82086,
    NULL,"SDO_ELEM_INFO_ARRAY"(1,1003,4),"SDO_ORDINATE_ARRAY"(123455.9,123456,123456.1,1234
    56,123456,123456.1)))='TRUE')

  • Spatial query runs slow on view

    Hello,
    I have two tables and one of them has geometry column. I created view to join those two tables based on id column which has been indexed for both tables.
    t1(
    id number(9),
    name varchar2(20)
    t2(
    id number(9),
    geom MDSYS.SDO_GEOMETRY
    CREATE VIEW v1 (
    id,
    name,
    geom
    ) AS
    SELECT /*+ FIRST_ROWS */ t1.id, t1.name, t2.geom
    FROM t1,t2
    WHERE t1.id = t2.id
    When I query the view with following statement it runs very slow (there are more then 1 million rows in t2 table)
    SELECT * FROM v1
    WHERE mdsys.sdo_filter(geom, [a rectangle],'querytype=window') = 'TRUE';
    but
    SELECT /*+ FIRST_ROWS */ t1.id, t1.name,t2.geom
    FROM t1,t2
    WHERE t1.id=t2.id
    and mdsys.sdo_filter(geom, [a rectangle],'querytype=window') = 'TRUE';
    returns almost instantly. Can some one tell me what is wrong with the "create view" statement?
    Thanks

    Thank you for your reply. Here are the plans. The view looks for the spatial index first.
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 21 | 756 | 10 (60)|
    | 1 | NESTED LOOPS | | 21 | 756 | 10 (60)|
    | 2 | TABLE ACCESS BY INDEX ROWID| T2 | 5269 | 123K| 3 (0)|
    | 3 | DOMAIN INDEX | T2_SDX | | | |
    | 4 | TABLE ACCESS BY INDEX ROWID| T1 | | | |
    | 5 | INDEX RANGE SCAN | T1_ID_IDX | 1 | | 0 (0)|
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 21 | 756 | 99 (3)|
    | 1 | TABLE ACCESS BY INDEX ROWID | T2 | 1 | 24 | 99 (3)|
    | 2 | NESTED LOOPS | | 21 | 756 | 99 (3)|
    | 3 | TABLE ACCESS FULL | T1 | 21 | 252 | 2 (0)|
    | 4 | BITMAP CONVERSION TO ROWIDS | | | | |
    | 5 | BITMAP AND | | | | |
    | 6 | BITMAP CONVERSION FROM ROWIDS| | | | |
    | 7 | INDEX RANGE SCAN | T2_ID_IDX | 1 | | 2 (0)|
    | 8 | BITMAP CONVERSION FROM ROWIDS| | | | |
    | 9 | SORT ORDER BY | | | | |
    | 10 | DOMAIN INDEX | T2_SDX | 1 | | |
    -----------------------------------------------------------------------------------------------------

  • Query running slow in one node

    Hi All,
    We are running 4-node Oracle 10g RAC (linux 64-bit). The query is running fast in one node, but the same query is running very slow in the other node. And sometimes, we see pin S wait on X wait event in top 5 events.
    Has anyone faced this kind of situation before ?
    Thanks,
    Kumar

    Hi,
    Execute your query on node where query is running very slow. Get SID and execute query above to see what is event of waiting.
    exec dbms_application_info.set_client_info('@sw2')
    -- file sw2.sql
    col event  format     a25  heading "Wait Event" trunc
    col state  format     a15  heading "Wait State" trunc
    col siw    format   99999  heading "Waited So|Far (ms)"
    col wt     format 9999999  heading "Time Waited|(ms)"
    select event,
           state,
           seconds_in_wait siw,
           wait_time wt
    from   v$session_wait
    where  sid = &sid
    order by event;
    exec dbms_application_info.set_client_info('@sw1');
    -- file  sw1.sql
    set linesize 30000
    set pagesize 200
    col sid      format    9999  heading "SID"
    col username format     a10  heading "USERNAME"
    col osuser   format     a20  heading "OSUSER"
    col event    format     a25  heading "Wait Event" trunc
    col state    format     a15  heading "Wait State" trunc
    col siw      format   99999  heading "Waited So|Far (ms)"
    col wt       format 9999999  heading "Time Waited|(ms)"
    col sw1      format 9999999  heading "File"
    col sw2      format 9999999  heading "Block"
    col Objeto   format a50
    select sw.event,
           sw.p1,
           sw.p2,
           sw.p3,
           sw.state,
           s.sid,
           S.osuser,
           s.username,
           nvl(s.program, s.module),
           sw.seconds_in_wait siw,
           sw.wait_time wt
      from gv$session_wait sw,
           gv$session s
    WHERE sw.sid = s.sid
       and sw.EVENT NOT LIKE 'SQL%'
       and username is not NULL
       and s.inst_id = sw.inst_id
       and sw.event not like 'PX%'
    order by 1, 6, 7;Regards,
    Levi Pereira

  • Sql query runs slower from the application

    Hi,
    We are using oracle 9ias on AIX box.The jdk version used: 1.3.1 . From the j2ee application when we perfom a search, the sql query takes for ever to return the results. I know that we are waiting on the database because I can see the query working when I look at TOAD.But if i run the same query on the database server itself, it returns the results in less than a sec. Could you guys throw some light on how we could troubleshoot this problem. Thanks.

    When the results have to travel over the network, it is slow, and when they don't, it is fast.
    That is what you are saying, correct?
    So your approach should be to not bring so much data over the network. Don't select columns you don't need, and don't select rows you don't need.

  • Query running slow after upgrading

    Hi,
    We have one query that is running very slow in the 10.2.0.4 database after upgrading from 9.2.0.8 HP-UX B11.31. In 9.2.0.8 database it used to take 5 mins. But in the new 10.2.0.4 database it takes around 36 mins.The query is given below.
    SELECT a.transaction_date,
                    a.ORD_PROD_BE_ID,
                    a.SLS_POSTD_DT_BE_ID,
                     a.net_trd_amt,
                    a.trd_actl_un_qty,
                    t.FISC_MO_CD, 
                    t.FY_CD
    FROM fact_net_trd_sls a,
                dim_tm_mv t,
                dim_prod b,
                (SELECT DISTINCT kit_prod_cd FROM kal_kit_bom) c
    WHERE b.be_id = a.ORD_PROD_BE_ID
    AND b.end_date >SYSDATE
    AND t.be_id = a.SLS_POSTD_DT_BE_ID
    AND t.end_date > SYSDATE
    AND c.kit_prod_cd (+)= b.base_prod_cd
    AND t.FY_CD IN (SELECT DISTINCT FY_CD FROM DIM_tm_MV T WHERe T.DAY_STRT_PRD_OF_TM=TRUNC(SYSDATE))
    and nvl2(c.kit_prod_cd,'K','FG') = 'FG'
    ORDER BY  a.ORD_PROD_BE_ID,a.TRANSACTION_DATE;The plan in 9i is below,
    PLAN_TABLE_OUTPUT
    | Id  | Operation                           |  Name                  | Rows  | Bytes |TempSpc| Cost  |
    |   0 | SELECT STATEMENT                    |                        |  2861K|  1585M|       |   170K|
    |   1 |  VIEW                               |                        |  2861K|  1585M|       |   170K|
    |   2 |   SORT UNIQUE                       |                        |  2861K|   654M|  1397M|   170K|
    |*  3 |    FILTER                           |                        |       |       |       |       |
    |*  4 |     HASH JOIN OUTER                 |                        |       |       |       |       |
    |*  5 |      HASH JOIN                      |                        |  1998K|   445M|  4056K| 63419 |
    |*  6 |       TABLE ACCESS BY INDEX ROWID   | DIM_PROD               | 53189 |  3428K|       |   283 |
    |   7 |        BITMAP CONVERSION TO ROWIDS  |                        |       |       |       |       |
    |   8 |         BITMAP INDEX FULL SCAN      | XN3_DIM_PROD           |       |       |       |       |
    |   9 |       TABLE ACCESS BY INDEX ROWID   | FACT_NET_TRD_SLS       |  4081 |   203K|       |   118 |
    |  10 |        NESTED LOOPS                 |                        |  1998K|   320M|       | 57607 |
    |* 11 |         HASH JOIN SEMI              |                        |   490 | 57330 |       |   208 |
    |* 12 |          TABLE ACCESS FULL          | DIM_TM_MV              | 15180 |  1260K|       |   195 |
    |  13 |          TABLE ACCESS BY INDEX ROWID| DIM_TM_MV              |     1 |    32 |       |     1 |
    |* 14 |           INDEX RANGE SCAN          | XN4_DIM_TM_MV          |     1 |       |       |     1 |
    |* 15 |         INDEX RANGE SCAN            | FACT_NET_TRD_SLS_IDX3  |  4081 |       |       |    54 |
    |  16 |      TABLE ACCESS FULL              | KAL_KIT_BOM            | 14175 | 85050 |       |    24 |
    Predicate Information (identified by operation id):
       3 - filter(NVL2("KAL_KIT_BOM"."KIT_PROD_CD",'K','FG')='FG')
       4 - access("B"."BASE_PROD_CD"=("KAL_KIT_BOM"."KIT_PROD_CD"(+)))
       5 - access("B"."BE_ID"="A"."ORD_PROD_BE_ID")
       6 - filter("B"."END_DATE">SYSDATE@!)
      11 - access("SYS_ALIAS_0000"."FY_CD"="T"."FY_CD")
      12 - filter("SYS_ALIAS_0000"."END_DATE">SYSDATE@!)
      14 - access("T"."DAY_STRT_PRD_OF_TM"=TRUNC(SYSDATE@!))
      15 - access("SYS_ALIAS_0000"."BE_ID"="A"."SLS_POSTD_DT_BE_ID")
    Note: cpu costing is off
    36 rows selected.The plan in 10g is below.
    Operation           Object Name     Rows     Bytes     Cost       Object Node      In/Out  PStart    PStop
    SELECT STATEMENT Optimizer Mode=ALL_ROWS                             34                           1382                                                       
      VIEW                   34           19 K        1382                                                       
        SORT UNIQUE                               34           7 K          1382                                                       
          FILTER                                                                                                                             
            HASH JOIN OUTER                   34           7 K          1375                                                       
              MAT_VIEW ACCESS BY INDEX ROWID           WHSUSR.DIM_TM_MV 1              81           1                                                              
                NESTED LOOPS                      24           5 K          1350                                                       
                  NESTED LOOPS                    740         105 K     1336                                                       
                    MERGE JOIN CARTESIAN                              1              95           1332                                                       
                      TABLE ACCESS BY INDEX ROWID              WHSUSR.DIM_PROD      52 K        3 M        279                                                         
                        BITMAP CONVERSION TO ROWIDS                                                                                                                      
                          BITMAP INDEX FULL SCAN     WHSUSR.XN3_DIM_PROD                                                                                                           
                      BUFFER SORT                   1              30           9223372036 G                                                   
                        SORT UNIQUE                               1              30           1                                                              
                          MAT_VIEW ACCESS BY INDEX ROWID               WHSUSR.DIM_TM_MV 1              30           1                                                                           
                            INDEX RANGE SCAN               WHSUSR.XN4_DIM_TM_MV      1                              1                                                              
                    TABLE ACCESS BY INDEX ROWID                TRANSDATA.FACT_NET_TRD_SLS             740         36 K        4                                                                    
                      INDEX RANGE SCAN     TRANSDATA.FACT_NET_TRD_SLS_IDX2 2 K                         1                                                              
                  INDEX RANGE SCAN         WHSUSR.XN1_DIM_TM_MV      1                              1                                                              
              TABLE ACCESS FULL               EDW_DBA.KAL_KIT_BOM            14 K        83 K        24                                                            We have checked that the statistics are uptodate. Please help with suggestions.
    Thanks in advane.

    Most likely, the index stats are not up-to-date, please double check.
    h5. In 9i, FACT_NET_TRD_SLS_IDX3 is used to scan the fact.
    Time dimension is used to filter out most records in fact table first, then join to Product dimension.
    h5. In 10g, FACT_NET_TRD_SLS_IDX2 is used to scan the fact.
    Time dimension "MERGE JOIN CARTESIAN" to Product dimension first to form a data set, and then use it to filter the fact table.
    If the stats for FACT_NET_TRD_SLS_IDX2 let ORACLE believe that much less records will remain/survive after the join, 10g will use it.
    It seems to me that cartesian join Time x Product is going to generate a much bigger data set than estimated, then the nested loop after that will take a long time to iterate through.
    Why don't you partition your fact table BY RANGE(SLS_POSTD_DT_BE_ID) to make it simpler?

  • Gl_code_combinations query running slow

    Hi All,
    I have a simple query
    SELECT code_combination_id
    FROM gl_code_combinations gcc
    WHERE segment1 || '-' || segment2 || '-' || segment3 || '-' ||
    segment4 || '-' || segment5 || '-' || segment6 || '-' ||
    segment7 = '1G-000-000000-0000-000-1857'-----------------PARAMETER
    AND ENABLED_FLAG = 'Y'
    AND END_DATE_ACTIVE IS NULL;
    As per the DBA this query is running really slow. Is there a way i could increase the performance of this. Using hints or forcing index.
    Any help on this will be appreciated.
    Thanks & Regards,
    Ritesh

    Hi,
    Query will take less time if you use gl_code_combinations_kfv table which is a replica of gl_code_combination table...
    try this :
    +SELECT *+
    FROM gl_code_combinations_kfv gcc
    Where concatenated_segments='1G-000-000000-0000-000-1857'
    or padded_concatenated_segments='1G-000-000000-0000-000-1857'
    AND ENABLED_FLAG = 'Y'
    AND END_DATE_ACTIVE IS NULL;
    Your feedback will be hghly appreciated.
    Thanks,
    S.P DASH

  • SQL query running slow

    Hi
    i have a query when i run it for the first time it returs result in 30 mins after few mins (say 2 m ins) if i run the same query it fetches result in 3 mins) can any one hel me to tune the issu
    when i saw AWR report i showed too many disk I/o and sql messege to client wait events
    DB: Oracle 10g
    O/S: Unix
    DB cahce size :1GB
    help Pleae

    PLAN_TABLE_OUTPUT
    Plan hash value: 3961783764
    | Id  | Operation                            | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                     |                            |     2 |   390 |   361   (2)| 00:00:05 |
    |   1 |  SORT GROUP BY                       |                            |     2 |   390 |   361   (2)| 00:00:05 |
    |   2 |   VIEW                               |                            |     2 |   390 |   360   (1)| 00:00:05 |
    |   3 |    UNION-ALL                         |                            |       |       |            |          |
    |   4 |     NESTED LOOPS                     |                            |     1 |   297 |   344   (1)| 00:00:05 |
    |*  5 |      HASH JOIN                       |                            |     1 |   231 |   343   (1)| 00:00:05 |
    |   6 |       TABLE ACCESS FULL              | TRAN_VH_INV_SS_PART        |  3634 | 72680 |   213   (0)| 00:00:03 |
    |*  7 |       HASH JOIN                      |                            |  1799 |   370K|   129   (2)| 00:00:02 |
    |   8 |        TABLE ACCESS FULL             | MAST_MF_NAME               |     4 |    84 |     5   (0)| 00:00:01 |
    |*  9 |        HASH JOIN                     |                            |  1799 |   333K|   123   (1)| 00:00:02 |
    |* 10 |         HASH JOIN                    |                            |  1552 |   209K|   120   (1)| 00:00:02 |
    |* 11 |          TABLE ACCESS FULL           | HIST_VH_INV_SS_PART        |  1188 | 62964 |   115   (0)| 00:00:02 |
    |  12 |          NESTED LOOPS                |                            | 24566 |  2039K|     4   (0)| 00:00:01 |
    |  13 |           TABLE ACCESS BY INDEX ROWID| MAST_YM_YARD               |     1 |    29 |     1   (0)| 00:00:01 |
    |* 14 |            INDEX UNIQUE SCAN         | MAST_YM_YARD_01            |     1 |       |     0   (0)| 00:00:01 |
    |  15 |           TABLE ACCESS BY INDEX ROWID| TRAN_VH_INV_SUB_SERVICE    | 24566 |  1343K|     3   (0)| 00:00:01 |
    |* 16 |            INDEX RANGE SCAN          | TRAN_VH_INV_SUB_SERVICE_02 |     1 |       |     2   (0)| 00:00:01 |
    |  17 |         TABLE ACCESS BY INDEX ROWID  | TRAN_VH_INV                |  3863 |   196K|     3   (0)| 00:00:01 |
    |* 18 |          INDEX RANGE SCAN            | TRAN_VH_INV_02             |     1 |       |     2   (0)| 00:00:01 |
    |* 19 |      TABLE ACCESS BY INDEX ROWID     | TRAN_VH_INV_WORKSHEET      |     1 |    66 |     1   (0)| 00:00:01 |
    |* 20 |       INDEX UNIQUE SCAN              | TRAN_VH_INV_WORKSHEET_01   |     1 |       |     0   (0)| 00:00:01 |
    |  21 |     NESTED LOOPS                     |                            |     1 |   297 |    16   (0)| 00:00:01 |
    |  22 |      NESTED LOOPS                    |                            |     1 |   277 |    14   (0)| 00:00:01 |
    |  23 |       NESTED LOOPS                   |                            |     1 |   224 |    10   (0)| 00:00:01 |
    |  24 |        NESTED LOOPS                  |                            |     1 |   203 |     9   (0)| 00:00:01 |
    |  25 |         NESTED LOOPS                 |                            |     1 |   151 |     7   (0)| 00:00:01 |
    |  26 |          NESTED LOOPS                |                            |     1 |    85 |     5   (0)| 00:00:01 |
    |  27 |           TABLE ACCESS BY INDEX ROWID| MAST_YM_YARD               |     1 |    29 |     1   (0)| 00:00:01 |
    |* 28 |            INDEX UNIQUE SCAN         | MAST_YM_YARD_01            |     1 |       |     0   (0)| 00:00:01 |
    |  29 |           TABLE ACCESS BY INDEX ROWID| TRAN_VH_SHP_SUB_SERVICE    |     1 |    56 |     4   (0)| 00:00:01 |
    |* 30 |            INDEX RANGE SCAN          | TRAN_VH_SHP_SUB_SERVICE_02 |     1 |       |     3   (0)| 00:00:01 |
    |* 31 |          TABLE ACCESS BY INDEX ROWID | TRAN_VH_SHP_WORKSHEET      |     1 |    66 |     2   (0)| 00:00:01 |
    |* 32 |           INDEX UNIQUE SCAN          | TRAN_VH_SHP_WORKSHEET_01   |     1 |       |     1   (0)| 00:00:01 |
    |* 33 |         TABLE ACCESS BY INDEX ROWID  | TRAN_VH_SHP                |     1 |    52 |     2   (0)| 00:00:01 |
    |* 34 |          INDEX UNIQUE SCAN           | TRAN_VH_SHP_01             |     1 |       |     1   (0)| 00:00:01 |
    |  35 |        TABLE ACCESS BY INDEX ROWID   | MAST_MF_NAME               |     1 |    21 |     1   (0)| 00:00:01 |
    |* 36 |         INDEX UNIQUE SCAN            | MAST_MF_NAME_01            |     1 |       |     0   (0)| 00:00:01 |
    |* 37 |       TABLE ACCESS BY INDEX ROWID    | HIST_VH_SHP_SS_PART        |     1 |    53 |     4   (0)| 00:00:01 |
    |* 38 |        INDEX RANGE SCAN              | HIST_VH_SHP_SS_PART_01     |     5 |       |     2   (0)| 00:00:01 |
    |* 39 |      TABLE ACCESS BY INDEX ROWID     | TRAN_VH_SHP_SS_PART        |     1 |    20 |     2   (0)| 00:00:01 |
    |* 40 |       INDEX UNIQUE SCAN              | TRAN_VH_SHP_SS_PART_01     |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       5 - access("C"."SUB_SERVICE_SEQ_NUM"="H"."SUB_SERVICE_SEQ_NUM" AND
                  "C"."PDI_PART_ORDER_NUM"="H"."PDI_PART_ORDER_NUM" AND
                  "C"."SUB_SERVICE_PART_SEQ_NUM"="H"."SUB_SERVICE_PART_SEQ_NUM")
       7 - access("D"."MFG_CODE"="E"."MFG_CODE")
       9 - access("D"."YARD_CODE"="A"."YARD_CODE" AND "D"."VIN_NUM"="B"."VIN_NUM" AND
                  "B"."TERMINAL_SEQ_NO"="D"."TERMINAL_SEQ_NO" AND "B"."YARD_CODE"="D"."YARD_CODE")
      10 - access("B"."SUB_SERVICE_SEQ_NUM"="C"."SUB_SERVICE_SEQ_NUM")
      11 - filter("C"."PART_FRANCHISE">=U' ' AND TRUNC(INTERNAL_FUNCTION("C"."ACTUAL_ISSUE_DATE_TIME"))<>TO_DAT
                  E(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  AND "C"."PART_FRANCHISE"<=U'~')
      14 - access("A"."TERMINAL_SEQ_NO"=1 AND "A"."YARD_CODE"=U'1')
      16 - access("B"."TERMINAL_SEQ_NO"=1 AND "B"."YARD_CODE"=U'1')
      18 - access("D"."TERMINAL_SEQ_NO"=1 AND "D"."YARD_CODE"=U'1')
      19 - filter("G"."YARD_CODE"=U'1' AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<>TO_DATE('
                  0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "G"."TERMINAL_SEQ_NO"=1 AND
                  (TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
                  'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<TO_DATE(' 2010-06-01
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE('
                  2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(
                   2010-06-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))<=TO_DAT
    E
                  (' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
                  TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))=TO_DATE(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
                  OR TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
                  'syyyy-mm-dd hh24:mi:ss')) AND "G"."VIN_NUM"="D"."VIN_NUM")
      20 - access("G"."WORKSHEET_NUM"="B"."WORKSHEET_NUM")
      28 - access("A"."TERMINAL_SEQ_NO"=1 AND "A"."YARD_CODE"=U'1')
      30 - access("B"."TERMINAL_SEQ_NO"=1 AND "B"."YARD_CODE"=U'1')
      31 - filter("G"."YARD_CODE"=U'1' AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<>TO_DATE('
                  0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "G"."TERMINAL_SEQ_NO"=1)
      32 - access("G"."WORKSHEET_NUM"="B"."WORKSHEET_NUM")
      33 - filter("D"."YARD_CODE"=U'1' AND "D"."TERMINAL_SEQ_NO"=1)
      34 - access("G"."VIN_NUM"="D"."VIN_NUM")
           filter("D"."VIN_NUM"="B"."VIN_NUM")
      36 - access("D"."MFG_CODE"="E"."MFG_CODE")
      37 - filter("C"."PART_FRANCHISE">=U' ' AND TRUNC(INTERNAL_FUNCTION("C"."ACTUAL_ISSUE_DATE_TIME"))<>TO_DAT
                  E(' 0001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  AND "C"."PART_FRANCHISE"<=U'~' AND (TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))>=TO_DATE(' 2010-06-01
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<=TO_DATE('
                  2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."START_DATE_TIME"))<TO_DATE
                  ' 2010-06-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  (TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(' 2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))>=TO_DATE(' 2010-06-01 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))<=TO_DATE(' 2010-06-30 00:00:00',
                  'syyyy-mm-dd hh24:mi:ss') OR TRUNC(INTERNAL_FUNCTION("G"."END_DATE_TIME"))=TO_DATE(' 0001-01-01 00:00:00',
                  'syyyy-mm-dd hh24:mi:ss')) OR TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))>=TO_DATE(' 2010-06-01
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(INTERNAL_FUNCTION("C"."ISSUE_DATE_TIME"))<=TO_DATE('
                  2010-06-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
      38 - access("B"."SUB_SERVICE_SEQ_NUM"="C"."SUB_SERVICE_SEQ_NUM")
      39 - filter("C"."PDI_PART_ORDER_NUM"="H"."PDI_PART_ORDER_NUM")
      40 - access("C"."SUB_SERVICE_SEQ_NUM"="H"."SUB_SERVICE_SEQ_NUM" AND
    PLAN_TABLE_OUTPUT
                  "C"."SUB_SERVICE_PART_SEQ_NUM"="H"."SUB_SERVICE_PART_SEQ_NUM")
    Note
       - SQL profile "SYS_SQLPROF_014aab7522964001" used for this statementEdited by: user629451 on Sep 22, 2010 12:23 AM
    Edited by: user629451 on Sep 22, 2010 12:25 AM

  • What to check in my query running slow

    Hi,
    Our 11g database was migrated from one platform to another. A query which ran very quickly before on the source platform now takes ages to run on the target platform. Please could you point me in the right direction as to what things I should check to fix this problem?
    thank you

    Hi,
    Following are the areas which can be explored. I hope this will help you.
    1) Check the Explain plan for both servers. I hope you know how to gahter the explain plan for quries. Its better to use dbms_XPLAIN
    -Most probably your explain plan will be different..
    2) Check the init parameters of source and target tables
    3) check the optimizer parameters of source and target tables. Parameters like optimizer_ind_cost_adj,sort_area_size,hash_area_size,Optimizer_mode,cursor_sharing etc
    4) check the data volumn of source and target tables.
    5) Check the statistics of source and target tables. Its cumbersome to compare the statistics of source and target. So what you can do is
    a) Take the export of statistics of target tables
    b) Import those statistics to source tables(Before importing take the backup of source table statistics)
    c) Once done the check the explain plan, it should be the same like target database.
    -If step 2 confirms that statistics is the problem then you should take the export of source table statistics and import in target to get the same explain plan.
    HTH

Maybe you are looking for

  • How can i use JWSDP1.6 from Ant tool to convert .wsdl file into Java class

    Hi All, i m very new in the development field.plese help me... i have a .wsdl file and i have to make some modification in the file and return this file with build file used in Ant tool. means my requirement is to conver the .wsdl file into java clas

  • RFC to SOAP

    Hi all, What is Web Services and explain RFC to SOAP scenario step by step. Thanks

  • I trying to publish a web page from iweb, but it doesn't recognize my MobileMe account

    I trying to publish a web page from iweb, but it doesn't recognize my MobileMe accouI trying to publish a web page from iweb, but it doesn't recognize my MobileMe account, what can I do?

  • Ipod shuffle does not work

    Hi All, I pull my ipod shuffle with out doing "Safely Remove Hardware" so now when i connect my ipod shuffle to my USB my computer does read it. it still charge and i ipod shuffle still work and everything, but my computer does not read the ipod so i

  • Error sec_error_bad_der with normal Certificate?

    Greetings, friends of Mozilla, We are a Certification authority, but from Mozilla Firefox 37.0.1 we have been having troubles to access pages secured by our ssl web servers certificate. Customers receive the "sec_error_bad_der". we haven´t any troubl