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

Similar Messages

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

  • How to create spatial query (sdo_relate) on 2 views

    Hi, I want to create a spatial query in the form of:
    select /*+ORDERED*/ column1,column2
    from view1,view2
    where sdo_relate(view2.geometry,view1.geometry,'mask= ... ')Both views are very fast and return a smal number of rows out of a large dataset. I would expect that running the spatial query on this selection should be fast but when performing the above query it takes quite some time.
    It seems that the spatial query is performed on the underlying tables before the views make their selection.
    What is a good way to handle this kind of problem? How to make the spatial query to be executed on the resultset of the views?
    thanks Rene

    Hi Udo,
    Let me tell you a bit more about the requirements of the application.
    We have a table with geometries. Some geometries are buildings, others are roads, trees, parking areas, etc.
    We let users specify what geometries they are interested in. This can be the type (tree, building) or a list of types, plus some other selection such as type of tree, name of road etc. Based on the specifications the application creates a view that returns exactly the geometries the user is interested in.
    Users may not only be interested in just a tree but may be looking for a tree located inside a building, or a building within a certain distance from a road. This then would be the query I am talking about in this post. Two views and a spatial relationship between them.
    Depending on the definition of the views and the data currently loaded the number of rows returned by the views will vary. I can't be there all the time making sure that the correct table is queried first and the correct hints are given. This is why we have the CBO. But it seems to do a poor job when it comes to spatial queries.
    Rene

  • Why do i get ORA-03113 when doing a spatial query against union all view?

    Hi, i created the following view
    CREATE OR REPLACE FORCE VIEW cola_markets_v
    AS
      (SELECT mkt_id, NAME, shape shape_a, NULL shape_b, NULL shape_c,
              NULL shape_d
         FROM COLA_MARKETS
        WHERE NAME = 'cola_a')
       UNION ALL
      (SELECT mkt_id, NAME, NULL shape_a, shape shape_b, NULL shape_c,
              NULL shape_d
         FROM COLA_MARKETS
        WHERE NAME = 'cola_b')
       UNION ALL
      (SELECT mkt_id, NAME, NULL shape_a, NULL shape_b, shape shape_c,
              NULL shape_d
         FROM COLA_MARKETS
        WHERE NAME = 'cola_c')
       UNION ALL
      (SELECT mkt_id, NAME, NULL shape_a, NULL shape_b, NULL shape_c,
              shape shape_d
         FROM COLA_MARKETS
        WHERE NAME = 'cola_d');added the necessary entries in USER_SDO_GEOM_METADATA and created a spatial index on COLA_MARKETS (SHAPE). However, when i do a spatial query against this view, i get ORA-03113. A spatial query against the base table works fine. Any ideas why this happens? (This is Oracle 10.2.0.3.0)
    Thanks in advance, Markus
    PS: This is my spatial query
    SELECT *
      FROM cola_markets_v t
    WHERE sdo_filter (t.shape_a,
                             SDO_GEOMETRY (2003,
                                           NULL,
                                           NULL,
                                           sdo_elem_info_array (1, 1003, 3),
                                           sdo_ordinate_array (1, 1, 2, 2)
                             'querytype=window'
                            ) = 'TRUE';

    Thank you for your reply. I have tried it with 11.1.0.6.0 today and it works. This might be an issue with 10.2.0.3.0.

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

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

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

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

  • SECURITY query running slow with Prompts!!

    Hello All,
    Version: PeopleSoft HRMS 9 with PeopleTools 8.49.09
    DB Version: 10.2.0.3 (Oracle)
    My client is running a security query, given below, with and without prompts. Without prompts it is completing in 35 seconds but with prompts (even if the values in the prompts are blank!), the query is taking more than 4-5 hours but not completing!!
    SELECT /*+ OPT_PARAM('_optimizer_mjc_enabled', 'false')
    opt_param('_optimizer_cartesian_enabled', 'false') opt_param('optimizer_index_caching', 0) opt_param('optimizer_index_cost_adj', 0)*/ B.OPRID, A.EMPLID, A.PWCUK_LEGACY_ID, A.NAME, A.EMPL_STATUS, A.EMPL_CLASS,
    to_char(to_date( TO_CHAR(A.HIRE_DT, 'YYYY-MM-DD'), 'yyyy-mm-dd'), 'dd/mm/yyyy'),
    to_char(to_date(decode( TO_CHAR(A.REHIRE_DT, 'YYYY-MM-DD'), '',
    TO_CHAR(A.HIRE_DT, 'YYYY-MM-DD'), TO_CHAR(A.REHIRE_DT, 'YYYY-MM-DD')), 'yyyy-mm-dd'), 'dd/mm/yyyy'),
    to_char(to_date( TO_CHAR(A.TERMINATION_DT, 'YYYY-MM-DD'), 'yyyy-mm-dd'), 'dd/mm/yyyy'), A.DEPTID, A.DEPT_DESCR, A.PWCUK_BUSINESSUNIT, A.PWCUK_BU_DESCR, A.PWCUK_SUBREGION, A.PWCUK_SR_DESCR,
    A.PWCUK_REGION, A.PWCUK_R_DESCR, B.ROWSECCLASS, E.CLASSDEFNDESC, C.ROLENAME, D.DESCR,
    Case C.ROLENAME When 'UK_OTG_Query_Access' then 'Y' When 'UK_Self_Service_Query_Access' then 'Y' When 'UK_Prtner_Affairs_Query_Acces' then 'Y' When 'UK_SelfServ_Sens_Basic_Query' then 'Y' When 'UK_ESC_Extra_Query_Access' then 'Y' When 'UK_BCI_Query_Access' then 'Y' When 'UK_Self_Service_Non_Sens_Q Acc' then 'Y' Else 'N' END, TO_CHAR(A.EFFDT, 'YYYY-MM-DD'),
    TO_CHAR(A.EFFDT, 'YYYY-MM-DD'), D.ROLENAME FROM PS_PWCUK_EMP_C_VW A, PS_PERS_SRCH_QRY A1, PSOPRDEFN B, PS_ROLEU SER_VW C, PSROLEDEFN D, PSCLASSDEFN E WHERE A.EMPLID = A1.EMPLID
    AND A1.OPRID = 'kcooper001a' AND ( B.OPRID = A.PWCE_GUID AND B.OPRID = C.OPRID AND C.ROLENAME NOT IN ('Orbit User', 'PWCUK_LOS_ADMIN_PLANNER', 'Query Designer', 'Query User', 'PWCE_EMEA_AUDIT_RLE_NO_BSE_TBL', 'PWCE_REPORT_DIST', 'EOPP_USER', 'PAPP_USER', 'PWCUK_XMLP_REPORT_DEVELOPER', 'GBR_PEOPLE_MANAGER_CONFIG_UPD', 'PWCUK_EX_EMPLOYEE', 'ReportSuperUser', 'PWCE JOBCODE LOAD UTILITY',
    'PWCE EMPLOYEE RVW LOAD ACCESS', 'PwCE Bonus Upload Access', 'GBR_EP_SYSADMIN') AND ( C.ROLENAME NOT LIKE 'PWCUK_EP%' OR C.ROLENAME = 'PWCUK_EP_ADMIN') AND C.ROLENAME NOT LIKE 'PWCUK_SP%' AND C.ROLENAME NOT LIKE 'GBR_PMGR%' AND 0 < INSTR(:1, decode(trim(:2), null, ' ', B.OPRID)) AND 0 < INSTR(:3, decode(trim(:4), null, ' ', B.EMPLID)) AND 0 < INSTR(:5, decode(trim(:6), null, ' ', A.PWCUK_LEGACY_ID)) A
    ND 0 < INSTR(:7, decode(trim(:8), null, ' ', C.ROLENAME)) AND 0 < INSTR(:9, decode(trim(:10), null, ' ', E.CLASSID)) AND C.ROLENAME = D.ROLENAME AND E.CLASSID = B.ROWSECCLASS ) ORDER BY 4, 20Below are some more useful information I have gathered from DB level for this query:
    +--------------------------------------------------------------------------------------------------+
    |Plan HV     Min Snap  Max Snap  Execs       LIO            PIO            CPU         Elapsed     |
    +--------------------------------------------------------------------------------------------------+
    |770792495   39602     39747     5           1,181,648,326  6,823          7,433.93    7,481.60    |
    +--------------------------------------------------------------------------------------------------+
    ========== PHV = 770792495==========
    First seen from "10/19/12 10:00:44" (snap #39602)
    Last seen from  "10/25/12 11:00:28" (snap #39747)
    Execs          LIO            PIO            CPU            Elapsed
    =====          ===            ===            ===            =======
    5              1,181,648,326  6,823          7,433.93       7,481.60
    Plan hash value: 770792495
    | Id  | Operation                           | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                    |                    |       |       |    35 (100)|          |
    |   1 |  SORT ORDER BY                      |                    |     1 |   645 |    35   (6)| 00:00:01 |
    |   2 |   NESTED LOOPS                      |                    |     1 |   645 |    34   (3)| 00:00:01 |
    |   3 |    NESTED LOOPS                     |                    |     6 |  1122 |    10  (10)| 00:00:01 |
    |   4 |     NESTED LOOPS                    |                    |     1 |   165 |     5   (0)| 00:00:01 |
    |   5 |      NESTED LOOPS                   |                    |     1 |   122 |     4   (0)| 00:00:01 |
    |   6 |       NESTED LOOPS                  |                    |     1 |    81 |     3   (0)| 00:00:01 |
    |   7 |        NESTED LOOPS                 |                    |   552 | 29256 |     2   (0)| 00:00:01 |
    |   8 |         INDEX FULL SCAN             | PSAPSROLEUSER      |   550 | 15950 |     1   (0)| 00:00:01 |
    |   9 |         TABLE ACCESS BY INDEX ROWID | PS_ROLEXLATOPR     |     1 |    24 |     1   (0)| 00:00:01 |
    |  10 |          INDEX UNIQUE SCAN          | PS_ROLEXLATOPR     |     1 |       |     1   (0)| 00:00:01 |
    |  11 |        TABLE ACCESS BY INDEX ROWID  | PSOPRDEFN          |     1 |    28 |     1   (0)| 00:00:01 |
    |  12 |         INDEX UNIQUE SCAN           | PS_PSOPRDEFN       |     1 |       |     1   (0)| 00:00:01 |
    |  13 |       TABLE ACCESS BY INDEX ROWID   | PSCLASSDEFN        |     1 |    41 |     1   (0)| 00:00:01 |
    |  14 |        INDEX UNIQUE SCAN            | PS_PSCLASSDEFN     |     1 |       |     1   (0)| 00:00:01 |
    |  15 |      TABLE ACCESS BY INDEX ROWID    | PSROLEDEFN         |     1 |    43 |     1   (0)| 00:00:01 |
    |  16 |       INDEX UNIQUE SCAN             | PS_PSROLEDEFN      |     1 |       |     1   (0)| 00:00:01 |
    |  17 |     VIEW                            | PS_PERS_SRCH_QRY   |   483 | 10626 |     5  (20)| 00:00:01 |
    |  18 |      SORT UNIQUE                    |                    |   483 | 62790 |     5  (20)| 00:00:01 |
    |  19 |       NESTED LOOPS                  |                    |   483 | 62790 |     4   (0)| 00:00:01 |
    |  20 |        NESTED LOOPS                 |                    |   483 | 49749 |     3   (0)| 00:00:01 |
    |  21 |         NESTED LOOPS                |                    |     1 |    67 |     2   (0)| 00:00:01 |
    |  22 |          TABLE ACCESS BY INDEX ROWID| PSOPRDEFN          |     1 |    40 |     1   (0)| 00:00:01 |
    |  23 |           INDEX UNIQUE SCAN         | PS_PSOPRDEFN       |     1 |       |     1   (0)| 00:00:01 |
    |  24 |          TABLE ACCESS BY INDEX ROWID| PS_SJT_OPR_CLS     |     1 |    27 |     1   (0)| 00:00:01 |
    |  25 |           INDEX RANGE SCAN          | PS_SJT_OPR_CLS     |     1 |       |     1   (0)| 00:00:01 |
    |  26 |         TABLE ACCESS BY INDEX ROWID | PS_SJT_CLASS_ALL   |   482 | 17352 |     1   (0)| 00:00:01 |
    |  27 |          INDEX RANGE SCAN           | PS_SJT_CLASS_ALL   |  1158 |       |     1   (0)| 00:00:01 |
    |  28 |        INDEX RANGE SCAN             | PS_SJT_PERSON      |     1 |    27 |     1   (0)| 00:00:01 |
    |  29 |    VIEW                             | PS_PWCUK_EMP_C_VW  |     1 |   458 |     4   (0)| 00:00:01 |
    |  30 |     UNION ALL PUSHED PREDICATE      |                    |       |       |            |          |
    |  31 |      TABLE ACCESS BY INDEX ROWID    | PS_PWCUK_EMPLOYEES |     1 |   169 |     1   (0)| 00:00:01 |
    |  32 |       INDEX RANGE SCAN              | PS_PWCUK_EMPLOYEES |     1 |       |     1   (0)| 00:00:01 |
    |  33 |      FILTER                         |                    |       |       |            |          |
    |  34 |       NESTED LOOPS OUTER            |                    |     1 |   220 |     3   (0)| 00:00:01 |
    |  35 |        NESTED LOOPS OUTER           |                    |     1 |   208 |     2   (0)| 00:00:01 |
    |  36 |         TABLE ACCESS BY INDEX ROWID | PS_PWCUK_EX_EMPLS  |     1 |   161 |     1   (0)| 00:00:01 |
    |  37 |          INDEX RANGE SCAN           | PS_PWCUK_EX_EMPLS  |     1 |       |     1   (0)| 00:00:01 |
    |  38 |         TABLE ACCESS BY INDEX ROWID | PS_PWCE_EP_ROLES   |     1 |    47 |     1   (0)| 00:00:01 |
    |  39 |          INDEX RANGE SCAN           | PS_PWCE_EP_ROLES   |     1 |       |     1   (0)| 00:00:01 |
    |  40 |        INDEX RANGE SCAN             | PS_PWCUK_EMPLOYEES |     1 |    12 |     1   (0)| 00:00:01 |
    |  41 |       SORT AGGREGATE                |                    |     1 |    23 |            |          |
    |  42 |        INDEX RANGE SCAN             | PS_PWCE_EP_ROLES   |     1 |    23 |     1   (0)| 00:00:01 |
                                                  Summary Execution Statistics Over Time
                                                                                  Avg                 Avg
    Snapshot                          Avg LIO             Avg PIO          CPU (secs)      Elapsed (secs)
    Time            Execs            Per Exec            Per Exec            Per Exec            Per Exec
    19-OCT 10:00        1      374,309,812.00            1,469.00            2,286.32            2,291.32
    25-OCT 10:00        3       86,033,085.00            1,567.67              543.68              546.11
    25-OCT 11:00        1      549,239,259.00              651.00            3,516.56            3,551.96
    avg                        336,527,385.33            1,229.22            2,115.52            2,129.80
    sum                 5
                                                  Per-Plan Execution Statistics Over Time
                                                                                             Avg                 Avg
          Plan Snapshot                          Avg LIO             Avg PIO          CPU (secs)      Elapsed (secs)
    Hash Value Time            Execs            Per Exec            Per Exec            Per Exec            Per Exec
    770792495 19-OCT 10:00        1      374,309,812.00            1,469.00            2,286.32            2,291.32
               25-OCT 10:00        3       86,033,085.00            1,567.67              543.68              546.11
               25-OCT 11:00        1      549,239,259.00              651.00            3,516.56            3,551.96
    avg                                   336,527,385.33            1,229.22            2,115.52            2,129.80
    sum                            5I'm not at all proficient in PeopleSoft.
    Please advice how we can get faster runs for this query.
    Note: We have already checked all other possibilities, like network, application, web services, etc, and they look normal.
    Thanks,
    Suddhasatwa

    If the hints are there only for the "cost", then I'm sorry to say, but they are useless. Did you say that was not efficient to the Oracle Support ?
    I asked earlier if that query already ran in a reasonnable time, is it the case, or always took that time ? Is it a change of behaviour after a db upgrade ?
    Have you tried to work with AWR snapshots with a short gap in between ? I mean between the AWR snapshots (every 15 minutes or so), not between the runs of the query.
    If there's no values for the bind variables, I assume this is what you mean when you said "no prompts", then Oracle can go much faster because of the few (or no?) data repartition to retrieve.
    However, when given values to some (all?) of the bind variables, then all the problem will be on the data repartition. That's why I was asking how you gathered statistics on the involved objects, in other words, the histograms may be wrong somehow.
    There's a lot of litterature on this, have a look to the Jonathan Lewis blog for more information.
    Anyway, I think there's not enough information here and does not look easy to work on it in that state from the other side of the network.
    Nicolas.

Maybe you are looking for

  • ICloud not streaming music to iPhone 4s

    For some reason, my iPhone 4s will not stream songs directly from the cloud. Instead, it will attempt to download every song any time I attempt to play one...emphasis on the word attempt. Most of the time, the song won't play at all. Other times, it

  • PP Order types

    Dear All, My client has a requirement that he needs two different Order types for both semi finished and Finished product..But we can assign only one order type in plant parameters for MRP...How this can be possible... Please Suggest... Regards, Pawa

  • Early 2009 MacBook backlight inverter problem?

    My early 2009 MacBook is having a bit of trouble with the display backlight. Nowadays in order to get the backlight to turn on I need to fiddle around with the display until it comes on, then I have to keep it steady or it may go out again. I have tr

  • 336 new pantone colors

    Hi ! I have a problem: the recently released 336 pantone colors are not included in the latest CS6 InDesign pantone color libraries. Does anybody know how to get thes new colors integrated in InDesign? kindly, Jes

  • Change Image Prefix at the Application Level

    Hi All, I have an APEX installation and the image prefix has been set as /j/. I have changed this to /i/ using the reset_image_prefix.sql script. This however does not update the Image Prefix field in the Applications Definition (the entry still appe