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

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:

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

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

What to check when comparing query performance in 2 envs

I have a query that executes in 1 sec in env A. Env A was initially was 9.2.0.5 and later upgraded to 9.2.0.6.
The same query executes in 1 min 30 secs in Env B. Env A has always been on 9.2.0.6.
The query plans and stats are same in both the environments.
What else do I need to look here?
Thanks

Sorry for giving you the incorrect info. The plans are exactly the same in both the environments. The stats are also the same . The table BIG_TBL has different rows in each enviornment. Even though it has more rows in other env the query comes back fast in that env.
The stats are almost identical on both the tables.
I executed the query in the slow environment by pointing the query to the BIG_TBL@fast_env by a db link fast_env and it came back in 3 secs.
What is wrong in the slow environment? What parametrs do i need to look or check? I am very confused now.
[ code ]
--+ SLOW ENVIRONMENT
no rows selected
Elapsed: 00:00:49.08
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=2 Bytes=232)
1 0 SORT (ORDER BY) (Cost=10 Card=2 Bytes=232)
2 1 CONCATENATION
3 2 NESTED LOOPS (OUTER) (Cost=4 Card=1 Bytes=116)
4 3 NESTED LOOPS (OUTER) (Cost=3 Card=1 Bytes=84)
5 4 NESTED LOOPS (Cost=2 Card=1 Bytes=75)
6 5 TABLE ACCESS (BY INDEX ROWID) OF 'BIG_TBL' (C
ost=1 Card=1 Bytes=44)
7 6 INDEX (RANGE SCAN) OF 'IDX_BIG_TBL' (NON-
UNIQUE) (Cost=3 Card=1)
8 5 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_A'
(Cost=1 Card=1 Bytes=31)
9 8 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_A' (UNI
QUE)
10 4 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_B' (Cost=1 C
ard=1 Bytes=9)
11 10 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_B' (UNIQUE)
12 3 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_C' (Cost=1 C
ard=1 Bytes=32)
13 12 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_C' (UNIQUE)
14 2 NESTED LOOPS (OUTER) (Cost=4 Card=1 Bytes=116)
15 14 NESTED LOOPS (OUTER) (Cost=3 Card=1 Bytes=84)
16 15 NESTED LOOPS (Cost=2 Card=1 Bytes=75)
17 16 TABLE ACCESS (BY INDEX ROWID) OF 'BIG_TBL' (C
ost=1 Card=1 Bytes=44)
18 17 INDEX (RANGE SCAN) OF 'IDX1_BIG_TBL' (N
ON-UNIQUE) (Cost=3 Card=1)
19 16 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_A'
(Cost=1 Card=1 Bytes=31)
20 19 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_A' (UNI
QUE)
21 15 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_B' (Cost=1 C
ard=1 Bytes=9)
22 21 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_B' (UNIQUE)
23 14 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_C' (Cost=1 C
ard=1 Bytes=32)
24 23 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_C' (UNIQUE)
Statistics
238 recursive calls
0 db block gets
47798 consistent gets
46256 physical reads
0 redo size
408 bytes sent via SQL*Net to client
267 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
19:16:51 SQL> connect user@fastenv
Enter password: ********
Connected.
19:17:08 SQL> set time on
19:17:10 SQL> set timing on
19:17:12 SQL> /
no rows selected
Elapsed: 00:00:00.03
19:17:14 SQL> set autotrace on
19:17:24 SQL> /
--+ FAST ENVIRONMENT
no rows selected
Elapsed: 00:00:02.00
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=2 Bytes=232)
1 0 SORT (ORDER BY) (Cost=10 Card=2 Bytes=232)
2 1 CONCATENATION
3 2 NESTED LOOPS (OUTER) (Cost=4 Card=1 Bytes=116)
4 3 NESTED LOOPS (OUTER) (Cost=3 Card=1 Bytes=84)
5 4 NESTED LOOPS (Cost=2 Card=1 Bytes=75)
6 5 TABLE ACCESS (BY INDEX ROWID) OF 'BIG_TBL' (C
ost=1 Card=1 Bytes=44)
7 6 INDEX (RANGE SCAN) OF 'IDX_BIG_TBL' (NON-
UNIQUE) (Cost=3 Card=1)
8 5 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_A'
(Cost=1 Card=1 Bytes=31)
9 8 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_A' (UNI
QUE)
10 4 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_B' (Cost=1 C
ard=1 Bytes=9)
11 10 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_B' (UNIQUE)
12 3 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_C' (Cost=1 C
ard=1 Bytes=32)
13 12 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_C' (UNIQUE)
14 2 NESTED LOOPS (OUTER) (Cost=4 Card=1 Bytes=116)
15 14 NESTED LOOPS (OUTER) (Cost=3 Card=1 Bytes=84)
16 15 NESTED LOOPS (Cost=2 Card=1 Bytes=75)
17 16 TABLE ACCESS (BY INDEX ROWID) OF 'BIG_TBL' (C
ost=1 Card=1 Bytes=44)
18 17 INDEX (RANGE SCAN) OF 'IDX1_BIG_TBL' (N
ON-UNIQUE) (Cost=3 Card=1)
19 16 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_A'
(Cost=1 Card=1 Bytes=31)
20 19 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_A' (UNI
QUE)
21 15 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_B' (Cost=1 C
ard=1 Bytes=9)
22 21 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_B' (UNIQUE)
23 14 TABLE ACCESS (BY INDEX ROWID) OF 'TABLE_C' (Cost=1 C
ard=1 Bytes=32)
24 23 INDEX (UNIQUE SCAN) OF 'IDX_TABLE_C' (UNIQUE)
Statistics
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
266 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
[ code / ]

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?

Query running slow when using case inside when

Hi All,
I am in the process of creating a query as per the following conditions:
select count(*) from Alpha A, Beta B
where
(case
when
A.col1='Pete' and substr(A.col2,1,12)=substr(B.col2,1,12)
then 1
else
-- for all other cases when A.col1 is not equal to 'Pete', substr 1-15 needs to be checked on A and B
when A.col1 != 'Pete' and substr(A.col2,1,15)=substr(B.col2,1,15)
then 1
else 0
end)=1
When i run the whole query together, it continues to run forever and i have to eventually kill it. However, when i run the 2 WHEN clauses seperately, it runs within a second and fetches me the correct data. What goes wrong while merging these two inside 2 WHEN clauses that it causes the query to drag?
Please advise.
Thanks in advance.

Not sure,
Are you saying that you need both the counts seperately? or a combined count?
how are you joining alpha and beta tables? what is the join condition?
you need to do something like this,
SELECT COUNT(CASE WHEN
                    (A.col1 = 'Pete' AND SUBSTR(A.col2,,1,12)=SUBSTR(B.col2,,1,13))
                 OR ( A.col1 != 'Pete' AND SUBSTR(A.col2,,1,15)=SUBSTR(B.col2,,1,15))
                THEN 1 ELSE 0
             END)
FROM alpha A, beta b
WHERE alpha.join_cloumn= beta.join_columnG.

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.

Why does this query run slow ??

hi ,
i have the following query
SELECT
PT.PT_ID,
PCD_INST.CALL_PCD_NAME,
RC.RC_ID,
RC.RC_TITLE,
PCD.PCD_TITLE,
RC.E_TYPE
FROM
PT,
PCD_INST,
RC,
PCD,
PCD_INST_RS
WHERE
( PT.PT_ID = PCD_INST.PCD_ID )
AND ( PCD.PCD_ID = PCD_INST_RS.PCD_ID )
AND ( (RC.RC_NAME = PCD_INST_RS.RC_NAME) AND (RC.RC_ACTIVE_FLAG = 'A') )
AND ( (PCD.PCD_ID LIKE PCD_INST.CALL_PCD_NAME || '.%') AND (PCD.PCD_AFLAG = 'A') )
AND (
( PT.PT_AFLAG = 'A' )
AND ( PT.OBS_FLAG <> 'Y' )
AND ( PCD.PCD_AFLAG = 'A' )
AND ( PCD.OBS_FLAG <> 'Y' )
AND ( RC.RC_AFLAG = 'A' )
AND ( RC.OBS_FLAG <> 'Y' )
AND   TO_NUMBER (PCD_INST.INST_NUM) = 123
AND ( PCD_INST_RS.H = 'Y' )
AND ( PCD_INST_RS.MP = 'Y' )
AND PT.PSTATUS = 'A')and the execution plan
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=228 Card=1 Bytes=205
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'PCD_INST' (Cost=
          2 Card=136 Bytes=4352)
   2    1     NESTED LOOPS (Cost=228 Card=1 Bytes=205)
   3    2       MERGE JOIN (CARTESIAN) (Cost=227 Card=3 Bytes=519)
   4    3         TABLE ACCESS (BY INDEX ROWID) OF 'PCD_INST_RS'
                 (Cost=4 Card=1 Bytes=41)
   5    4           NESTED LOOPS (Cost=141 Card=1 Bytes=143)
   6    5             MERGE JOIN (CARTESIAN) (Cost=57 Card=28 Bytes=28
          56)
   7    6               TABLE ACCESS (BY INDEX ROWID) OF 'RC' (Cos
          t=2 Card=1 Bytes=52)
   8    7                 INDEX (RANGE SCAN) OF 'RC_IDX1' (NON
          -UNIQUE) (Cost=1 Card=1)
   9    6               BUFFER (SORT) (Cost=55 Card=65 Bytes=3250)
10    9                 TABLE ACCESS (BY INDEX ROWID) OF 'PCD' (Cos
          t=56 Card=65 Bytes=3250)
11   10                   INDEX (RANGE SCAN) OF 'PCD_IDX_1' (NON
          -UNIQUE) (Cost=30 Card=25944)
12    5             INDEX (RANGE SCAN) OF 'PCD_INST_RS
          _PK' (UNIQUE) (Cost=3 Card=233)
13    3         BUFFER (SORT) (Cost=223 Card=165 Bytes=4950)
14   13           TABLE ACCESS (FULL) OF 'PART' (Cost=86 Card=165 By
          tes=4950)
15    2       INDEX (RANGE SCAN) OF 'PCD_INST_PK' (UNIQUE) (
          Cost=2 Card=1)what would you suggest so the performance can be much better ?
or anything that i shld take note from the execution plan ?
current it took > 4 hrs to retrieve abt 300 - 400k records
tks & rdgs

Probably all the additional brackets in the where
clause.
Just kidding, but it would help to see what is
happening better if you got rid of them, e.g.
WHERE
( PT.PT_ID = PCD_INST.PCD_ID )
AND ( PCD.PCD_ID = PCD_INST_RS.PCD_ID )Should be
WHERE
PT.PT_ID = PCD_INST.PCD_ID
AND   PCD.PCD_ID = PCD_INST_RS.PCD_ID You could remove the to_number
AND   PCD_INST.INST_NUM = '123'
anything that i shld take note from the executionplan ?
What is shld?
retrieve abt 300 - 400k recordsHow many is abt?
SELECT STATEMENT Optimizer=CHOOSE (Cost=228Card=1 Bytes=205)Optimizer thinks it is going to return 1 row so your
statistics are way off.
What is rdgs?hi ,
i'll first remove the bracket and the to_number and try
then
i'll check with the DBA to see if the stats are up to date
sorry for the short-form, i was reminded earlier not to use that but i forgot
shld --> should
rdgs --> regards

What to check in my query running slow

Similar Messages

Maybe you are looking for