Query Is Running Slow

Hi all,
I am runnig the query first time but it is taking very much time to run query . are there any parameter which we need to set from BIW when we run the query first time ?
when i try to dril down any char. or when i try to move any free characteristic to rows it is taking very much time.
please tell me the steps to improve the performance.
Regards,
Komik Shah

Hi,
This info may be helpful.
General tips
Using aggregates and compression.
Using less and complex cell definitions if possible.
1. Avoid using too many nav. attr
2. Avoid RKF and CKF
3. Many chars in row.
By using T-codes ST03 or ST03N
Go to transaction ST03 > switch to expert mode > from left side menu > and there in system load history and distribution for a particual day > check query execution time.
/people/andreas.vogel/blog/2007/04/08/statistical-records-part-4-how-to-read-st03n-datasets-from-db-in-nw2004
/people/andreas.vogel/blog/2007/03/16/how-to-read-st03n-datasets-from-db
Try table rsddstats to get the statistics
Using cache memoery will decrease the loading time of the report.
Run reporting agent at night and sending results to email.This will ensure use of OLAP cache. So later report execution will retrieve the result faster from the OLAP cache.
4. Go to SE38 > Run the program SAP_INFOCUBE_DESIGNS
It will shown dimension Vs Fact tables Size in percent.If you mean speed of queries on a cube as performance metric of cube,measure query runtime.
3. To check the performance of the aggregates,see the columns valuation and usage in aggregates.
Open the Aggregates...and observe VALUATION and USAGE columns.
"---" sign is the valuation of the aggregate. You can say -3 is the valuation of the aggregate design and usage. ++ means that its compression is good and access is also more (in effect, performance is good). If you check its compression ratio, it must be good. -- means the compression ratio is not so good and access is also not so good (performance is not so good).The more is the positives...more is useful the aggregate and more it satisfies the number of queries. The greater the number of minus signs, the worse the evaluation of the aggregate. The larger the number of plus signs, the better the evaluation of the aggregate.
if "-----" then it means it just an overhead. Aggregate can potentially be deleted and "+++++" means Aggregate is potentially very useful.
Refer.
http://help.sap.com/saphelp_nw70/helpdata/en/b8/23813b310c4a0ee10000000a114084/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/60/f0fb411e255f24e10000000a1550b0/frameset.htm
Note 356732 - Performance Tuning for Queries with Aggregates
5. Run your query in RSRT and run the query in the debug mode. Select "Display Aggregates Found" and "Do not use cache" in the debug mode. This will tell you if it hit any aggregates while running. If it does not show any aggregates, you might want to redesign your aggregates for the query.
Also your query performance can depend upon criteria and since you have given selection only on one infoprovider...just check if you are selecting huge amount of data in the report
Check for the query read mode in RSRT.(whether its A,X or H)..advisable read mode is X.
Generate Report in RSRT
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
Achieving BI Query Performance Building Business Intelligence
http://www.dmreview.com/issues/20051001/1038109-1.html
Performance Tuning with the OLAP Cache
http://www.sapadvisors.com/resources/Howto...PerformanceTuningwiththeOLAPCache$28pdf$29.pdf
Business Intelligence Journal Improving Query Performance in Data Warehouses
http://www.tdwi.org/Publications/BIJournal/display.aspx?ID=7891
Achieving BI Query Performance Building Business Intelligence
http://www.dmreview.com/issues/20051001/1038109-1.html
Hope this helps.
Thanks,
JituK

Similar Messages

Parallel hint causes a query to run slower?

I have an insert...select query where the select is a join between a table with one billion rows (although there is a where clause on an indexed column that restricts it to "only" 300 million), a table with 30 million rows, and a table with about 100,000 rows, where the result is about 20 rows. When I first ran it, it took about 2 hours. I added a Parallel hint, and explain plan showed that it was being used (and v$session showed that I had about 30 additional connections while it ran). but not it takes four hours.
Is there a reason parallel processing would cause a query to run slower?
insert /*+ append */ into employees_by_age_group
pay_plan
, age_range
, pay_level
, fy
, employee_count
select /*+ parallel */
       emp.pay_plan
     , to_char(d.min_age) || '-' || to_char(d.max_age) as age_range
     , emp.pay_level
     , pay.fy
     , count(pay.employee_id) as employee_count
from
select /*+ index(pay_info pay_info_index_on_site) */
         employee_id
       , extract(year from (dte_ppe_end + 92)) as fy
       , count(employee_id) as num_recs
from pay_info
where extract(month from dte_ppe_end) = 10
and   extract(day from dte_ppe_end) between 14 and 27
and   substr(pay_type, 1, 1) IN ('A', 'B', 'C')
and   site like 'Z%'
group by employee_id, extract(year from (dte_ppe_end + 92))
) pay
join
select employee_id
       , pay_plan
       , pay_grade
       , pay_step
       , file_date
from
    select /*+ index(employee_info employee_info_index_on_site) */
           employee_id
         , pay_level
         , file_date
         , max(file_date)
           over (partition by extract(year from (file_date + 61)))
           as last_file_date
    from employee_info
    where site like 'Z%'
where file_date = last_file_date
) emp
on (
     emp.employee_id = pay.employee_id
     and extract(year from emp.file_date) = pay.fy - 1
join (
       select employee_id
            , dob
       from (
              select employee_id
                   , date_birth
                   , row_number() over (partition by employee_id order by date_file desc) as r
              from employee_birthdates
              where site like 'Z%'
       where r = 1
     ) dob
on dob.employee_id = pay.employee_id
join
            select 20 as min_age, 24 as max_age from dual
union all select 25 as min_age, 29 as max_age from dual
union all select 30 as min_age, 34 as max_age from dual
union all select 35 as min_age, 39 as max_age from dual
union all select 40 as min_age, 44 as max_age from dual
union all select 45 as min_age, 49 as max_age from dual
union all select 50 as min_age, 54 as max_age from dual
union all select 55 as min_age, 59 as max_age from dual
union all select 60 as min_age, 64 as max_age from dual
union all select 65 as min_age, 69 as max_age from dual
union all select 70 as min_age, 74 as max_age from dual
union all select 75 as min_age, 79 as max_age from dual
union all select 80 as min_age, 84 as max_age from dual
union all select 85 as min_age, 89 as max_age from dual
union all select 90 as min_age, 94 as max_age from dual
union all select 95 as min_age, 99 as max_age from dual
) d
group by emp.pay_plan, d.min_age, d.max_age, emp.pay_level, pay.fy;

Paul - here are three different explain plans
First, the original one (without the parallel hint):
INSERT STATEMENT ALL_ROWS                                              Cost: 26,684,255 Bytes: 114 Cardinality: 1
35 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
    34 HASH GROUP BY                                                    Cost: 26,684,255 Bytes: 114 Cardinality: 1
      33 NESTED LOOPS                                                   Cost: 26,684,254 Bytes: 114 Cardinality: 1
        14 HASH JOIN                                                    Cost: 26,684,222 Bytes: 108 Cardinality: 1
          9 MERGE JOIN                                                  Cost: 4,408,803 Bytes: 8,322 Cardinality: 146
            3 VIEW DONBOT_DBA.                                          Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
              2 WINDOW SORT PUSHED RANK                                 Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
                1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
            8 SORT JOIN                                                 Cost: 4,293,940 Bytes: 3,645 Cardinality: 135
              7 VIEW DONBOT_DBA.                                        Cost: 4,293,939 Bytes: 3,645 Cardinality: 135
                6 SORT GROUP BY                                         Cost: 4,293,939 Bytes: 4,185 Cardinality: 135
                  5 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO          Cost: 4,293,938 Bytes: 4,185 Cardinality: 135
                    4 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE     Cost: 487,124 Cardinality: 402,683,034
          13 VIEW DONBOT_DBA                                            Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
            12 WINDOW SORT                                              Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
              11 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
                10 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE   Cost: 50,419 Cardinality: 38,019,281
        32 VIEW DONBOT_DBA
          31 UNION-ALL
            15 FAST DUAL Cost: 2 Cardinality: 1
            16 FAST DUAL Cost: 2 Cardinality: 1
            17 FAST DUAL Cost: 2 Cardinality: 1
            18 FAST DUAL Cost: 2 Cardinality: 1
            19 FAST DUAL Cost: 2 Cardinality: 1
            20 FAST DUAL Cost: 2 Cardinality: 1
            21 FAST DUAL Cost: 2 Cardinality: 1
            22 FAST DUAL Cost: 2 Cardinality: 1
            23 FAST DUAL Cost: 2 Cardinality: 1
            24 FAST DUAL Cost: 2 Cardinality: 1
            25 FAST DUAL Cost: 2 Cardinality: 1
            26 FAST DUAL Cost: 2 Cardinality: 1
            27 FAST DUAL Cost: 2 Cardinality: 1
            28 FAST DUAL Cost: 2 Cardinality: 1
            29 FAST DUAL Cost: 2 Cardinality: 1
            30 FAST DUAL Cost: 2 Cardinality: 1          Next, one with the parallel hint:
INSERT STATEMENT ALL_ROWS                                                                              Cost: 26,507,111 Bytes: 114 Cardinality: 1
51 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
    50 PX COORDINATOR
      49 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10005 :Q1005                                     Cost: 26,507,111 Bytes: 114 Cardinality: 1
        48 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1005                                           Cost: 26,507,111 Bytes: 114 Cardinality: 1
          47 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1005                                            Cost: 26,507,111 Bytes: 114 Cardinality: 1
            46 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10004 :Q1004                                    Cost: 26,507,111 Bytes: 114 Cardinality: 1
              45 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,111 Bytes: 114 Cardinality: 1
                44 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1004                                    Cost: 26,507,111 Bytes: 114 Cardinality: 1
                  25 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004                                     Cost: 26,507,109 Bytes: 108 Cardinality: 1
                    17 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                  Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                      16 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10003 :Q1003                          Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                        15 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1003                               Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
                          7 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1003
                            6 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                           Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                              5 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000                     Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                                4 VIEW DONBOT_DBA.                                                      Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
                                  3 SORT GROUP BY                                                       Cost: 4,293,939 Bytes: 2,077 Cardinality: 67
                                    2 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO                        Cost: 4,293,938 Bytes: 2,077 Cardinality: 67
                                      1 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE                   Cost: 487,124 Cardinality: 199,756,151
                          14 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1003                      Cost: 7,561 Bytes: 29,625,180 Cardinality: 987,506
                            13 WINDOW SORT PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1003             Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                              12 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003                        Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                11 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 :Q1002                Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                  10 WINDOW CHILD PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1002      Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
                                    9 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002             Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
                                      8 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT EMPLOYEE_BIRTHDATES :Q1002     Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
                    24 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1004
                      23 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004                                Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                        22 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10001                               Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                          21 VIEW DONBOT_DBA.                                                           Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
                            20 WINDOW SORT                                                              Cost: 22,205,605 Bytes: 417,522,615 Cardinality: 11,284,395
                              19 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO                        Cost: 22,137,046 Bytes: 417,522,615 Cardinality: 11,284,395
                                18 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE                   Cost: 50,419 Cardinality: 18,859,958
                  43 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1004                              Cost: 32 Bytes: 6 Cardinality: 1
                    42 UNION-ALL PARALLEL_COMBINED_WITH_PARENT :Q1004
                      26 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      27 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      28 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      29 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      30 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      31 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      32 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      33 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      34 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      35 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      36 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      37 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      38 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      39 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      40 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1
                      41 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004         Cost: 2 Cardinality: 1                  Finally, one without the parallel hint, and without the index hint on PAY_TABLE:
INSERT STATEMENT ALL_ROWS                                              Cost: 23,348,654 Bytes: 114 Cardinality: 1
34 LOAD AS SELECT ARMYMP.EMPLOYEES_BY_AGE
    33 HASH GROUP BY                                                    Cost: 23,348,654 Bytes: 114 Cardinality: 1
      32 NESTED LOOPS                                                   Cost: 23,348,653 Bytes: 114 Cardinality: 1
        13 HASH JOIN                                                    Cost: 23,348,621 Bytes: 108 Cardinality: 1
          8 MERGE JOIN                                                  Cost: 1,073,202 Bytes: 8,322 Cardinality: 146
            3 VIEW DONBOT_DBA.                                          Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
              2 WINDOW SORT PUSHED RANK                                 Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
                1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES           Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
            7 SORT JOIN                                                 Cost: 958,339 Bytes: 3,645 Cardinality: 135
              6 VIEW DONBOT_DBA.                                        Cost: 958,338 Bytes: 3,645 Cardinality: 135
                5 SORT GROUP BY                                         Cost: 958,338 Bytes: 4,185 Cardinality: 135
                  4 TABLE ACCESS FULL TABLE PAY_INFO                    Cost: 958,337 Bytes: 4,185 Cardinality: 135
          12 VIEW DONBOT_DBA.                                           Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
            11 WINDOW SORT                                              Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
              10 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO        Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
                9 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_UIC              Cost: 50,419 Cardinality: 38,019,281
        31 VIEW DONBOT_DBA.                                             Cost: 32 Bytes: 6 Cardinality: 1
          30 UNION-ALL
            14 FAST DUAL Cost: 2 Cardinality: 1
            15 FAST DUAL Cost: 2 Cardinality: 1
            16 FAST DUAL Cost: 2 Cardinality: 1
            17 FAST DUAL Cost: 2 Cardinality: 1
            18 FAST DUAL Cost: 2 Cardinality: 1
            19 FAST DUAL Cost: 2 Cardinality: 1
            20 FAST DUAL Cost: 2 Cardinality: 1
            21 FAST DUAL Cost: 2 Cardinality: 1
            22 FAST DUAL Cost: 2 Cardinality: 1
            23 FAST DUAL Cost: 2 Cardinality: 1
            24 FAST DUAL Cost: 2 Cardinality: 1
            25 FAST DUAL Cost: 2 Cardinality: 1
            26 FAST DUAL Cost: 2 Cardinality: 1
            27 FAST DUAL Cost: 2 Cardinality: 1
            28 FAST DUAL Cost: 2 Cardinality: 1
            29 FAST DUAL Cost: 2 Cardinality: 1        I am surprised the cost without the index is less than the cost with it, considering that it is replacing a Table Access By Index Rowid with a Table Access Full on a table with 1 billion (1000 million) records.
Igor - two questions:
One - I cannot find "Materialize" in the hints in the SQL Reference anywhere. What does it do?
Two - does replacing subqueries with With clauses make that much of a difference?

Why query is running slow....?morning evrything is fine...

in the morning all queries r running well..?
but now what happened...
evry query is taking half an hour to run?
what might be the possible reasons?
problem is not in my system...some server issue...what might be that?
Message was edited by:
neeraja devi

Hi neeraja,
As said above ,you Can check in RSRTand OLAPCACHE.In RSRt,You can also check whether the query is hitting the right aggregates or not to pull the data.
Apart from this, you can also Check with BW statistics and check where the problem lies
<b>And another important T-code is St03n.</b> .here you can analyse why the query is taking more time than required to execute.
As far as problem is concerned,if it is a server issue,please contact your Basis Consultant and also verify the Rfc connection.
Regards,
amar

SQl query are running slow in comparison to oracle 8i

Hi everybody,
I have two systems one is Oracle 9i on Windows 2000 and
one is Oracle 8i running on Windows 2000. The database structure is the same. When I run the following qry in
Oracle 9i
SELECT COUNT (a.aint_ac_no) AS total_ac_no, adet_int_rate,
SUM (fun_max_cbal_bal (a.aint_ac_no,
a.aint_subsys_cd,
TO_DATE ('30/01/2009', 'DD/MM/YYYY')
) AS balance
FROM domst120 a, domst730 b
WHERE a.aint_interest_slab_cd = b.adet_srno
AND a.aint_subsys_cd = '137'
AND fun_max_cbal_bal (a.aint_ac_no,
a.aint_subsys_cd,
TO_DATE ('30/01/2009', 'DD/MM/YYYY')
) <> 0
AND a.aint_eff_date =
(SELECT MAX (c.aint_eff_date)
FROM domst120 c
WHERE a.aint_bank_cd = c.aint_bank_cd
AND a.aint_branch_cd = c.aint_branch_cd
AND a.aint_bank_cd = '857'
AND a.aint_branch_cd = '6'
AND a.aint_subsys_cd = c.aint_subsys_cd
AND a.aint_ac_no = c.aint_ac_no)
GROUP BY b.adet_int_rate
ORDER BY b.adet_int_rate
it takes 6 min to complete.
the same qry running in Oracle 8i takes 2 seconds
to complete.
The index structure is same in both systems also the tables
were analyzed with compute statistics.

What do you expect?! Oracle 9i and Oracle 8i are different particularly by optimizer cost-based(9i) and rule-based(8i) :)
what about both execution plans?

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 can run in Oracle 10g but very slow in 11g

Hi,
We've just migrated to Oracle 11g and we noticed that some of our view are very slow (it takes seconds in 10g and takes 30 minutes in 11g), and the tables are using the local table.
Do any of you face the same issue?
This is our query:
SELECT
A.wellbore
,a.depth center
,d.MD maxbc
,d.XDELT xbc
,d.YDELT ybc
,e.MD minac
,e.XDELT xac
,e.YDELT yac
from
table_A d,table_A e, table_B a
where a.wellbore = d.WELLBORE (+)
and a.wellbore = e.WELLBORE(+)
and d.MD = (select max(MD) from table_A b where b.MD < a.depth and
d.wellBORE = b.wellBORE)
and e.md = (select min(md) from table_A c where c.MD > a.depth and
e.wellBORE = c.wellBORE);

Thanks I will move to the correct one..
Rafi,
Build the Indexes and it is still slow. I am querying from a view from another database, which is in 10g instances.
Moved: Query can run in Oracle 10g but very slow in 11g
Edited by: 924400 on Apr 1, 2012 6:03 PM
Edited by: 924400 on Apr 1, 2012 6:26 PM

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

Strange problem... Query runs faster, but report runs slow...

Hi Gurus,
We are using Report 10g on 10g Application server and solaris. we created a report on a table which has 10,000 rows. The report has 25 columns. when we run this query in Toad it took 12 sec for fetching all these 10,000 rows
But when we run the report with Destype = 'FILE' and Desformat = 'DELIMITEDDDATA', it is taking 5 to 8 minutes
to open in excel ( we concatenated mimetype=vnd-msexcel at the end of the url if the Destype=FILE). We removed the layout in the report as it is taking 10 to 15 mins to run to Screen with Desformat=HTML/PDF(formating pages taking more time). We are wondering why DELIMITEDDATA format is taking long time as it runs only query.
Does RWSERVLET take more time of writing the data to the Physical file in the cache dir? Our cache size is 1 GB. we have 2 report servers clustered. Tracing is off.
Please advise me if there are any report server settings to boost the performance.
Thanks alot,
Ram.

Duplicate of Strange problem... Query runs faster, but report runs slow... in the Reports forum.
[Thread closed]

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

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

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

Query Runs Slow in Forms

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

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

Query Running Slow 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 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.

Gl_code_combinations query running slow

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

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

Query runs slower after INSERT

Hi All,
We have a java swing application that uses JDBC to interact with an Oracle database.
The user can display a list of data from one database table, then click a button which will insert a row into a different table using data from the highlighted row in the displayed list.
As long as the user does not click the "insert" button, [s]he can open and close the window displaying the list as many times as [s]he wants, and it runs very fast.
However, after the user clicks on the "insert" button, the query suddenly runs extremely slowly.
Also note that this behaviour only occurs on one particular database server:
Oracle9i Enterprise Edition Release 9.2.0.4.0
Sun-Fire-V210 with SunOS 5.9
The behaviour does not happen on other machines.
(None of the other machines have the same combination of database server and platform.)
Note that all the clients use the same JDK and JDBC driver.
Any suggestions on where we should look in order to discover the cause of this behaviour?
Thanks,
Avi.

Kamal,
In the trace file produced, the rowid pseudo-row has been added to my SQL query. Here is an excerpt:
(Note that the ALTER SESSION command was done via JDBC from our application.)
The following statements encountered a error during parse:
select rowid, FDU.DESK_USAGE_ROW_ID
from FLIGHTS F, FLIGHT_DESK_USAGE FDU
where ...
Error encountered: ORA-00918Error message for code ORA-00918 is "column ambiguously defined".
Since "rowid" is a pseudo column and since there are two tables involved in the query, obviously the unqualified "rowid" is ambiguous.
Naturally, I didn't put "rowid" in my original SELECT statment.
Is this added by JDBC, or by the Oracle optimizer, or what?
Thanks,
Avi.

Select running slow in prod but work fine in T-1

We have a query which run very slow on production database it is taking around 7 min to run.
While it is working fine on T-1 database which gets refreshed every night, here it takes around 3 seconds.
both the os version and database versions are same.
Database is also refreshed and have same data and statistics.
please update what could be the reason?
SELECT c.txt_master_claim_no "Master Claim No",
c.num_serial_no "Serial No",
TO_CHAR(c.dat_loss_date, 'dd / mm / yyyy') "Loss Date",
d.departmentname "Line of Business",
m.productname "Product",
tab.stat "Status"
FROM (SELECT t.num_claim_no, 'REPUDIATION' stat, num_update_no
FROM gc_clm_gen_info t, gc_clm_os a
WHERE t.num_update_no =
(SELECT MAX(p.num_update_no)
FROM gc_clm_gen_info p
WHERE p.num_claim_no = t.num_claim_no)
AND t.txt_claim_status = 'X'
AND a.cur_os_amount = 0
AND a.num_ac_year * 100 + a.num_ac_month =
(select max(s.num_ac_year * 100 + s.num_ac_month)
from gc_clm_os s
where s.num_claim_no = a.num_claim_no)
AND t.num_claim_no = a.num_claim_no
UNION
SELECT a.num_claim_no, 'DISBURSE' stat, num_update_no
FROM gc_clm_os a, gc_clm_gen_info b
WHERE a.cur_os_amount = 0
AND a.num_ac_year * 100 + a.num_ac_month =
(select max(s.num_ac_year * 100 + s.num_ac_month)
from gc_clm_os s
where s.num_claim_no = a.num_claim_no)
AND b.num_update_no >
(SELECT MAX(x.num_update_no)
FROM gc_clm_gen_info x
WHERE x.num_claim_no = b.num_claim_no
AND x.txt_claim_status in ('F', 'X'))
AND a.num_claim_no = b.num_claim_no
UNION
SELECT a.num_claim_no, 'DISBURSE' stat, num_update_no
FROM gc_clm_os a, gc_clm_gen_info b
WHERE a.cur_os_amount = 0
AND a.num_ac_year * 100 + a.num_ac_month =
(select max(s.num_ac_year * 100 + s.num_ac_month)
from gc_clm_os s
where s.num_claim_no = a.num_claim_no)
AND b.num_update_no =
(SELECT MAX(x.num_update_no)
FROM gc_clm_gen_info x
WHERE x.num_claim_no = b.num_claim_no)
AND a.num_claim_no = b.num_claim_no
And b.txt_claim_status = 'F'
and not exists
(select 1
from gc_clm_payment_details p
where p.num_claim_no = a.num_claim_no
and p.txt_status in ('APPROVAL DUE', 'APPROVED'))
) tab,
gc_clm_gen_info c,
uw_product_master m,
uw_department_master d
WHERE tab.num_claim_no = c.num_claim_no
AND c.num_update_no =
(SELECT MAX(d.num_update_no)
FROM gc_clm_gen_info d
WHERE d.num_claim_no = c.num_claim_no)
AND c.num_department_code = d.departmentcode
AND m.productcode = c.num_product_code
AND M.DEPARTMENTCODE=D.DEPARTMENTCODE
AND c.txt_claim_status NOT IN ('O', 'S')
AND c.num_update_no = tab.num_update_no
AND c.num_claim_no not in
(select p.num_claim_no
from gc_clm_payment_details p, gc_clmmst_resource_type r
where p.num_type_of_party = r.num_resource_type_cd
and r.txt_loss_exp = 'E'
and p.txt_status = 'APPROVAL DUE') and Upper(C.txt_master_claim_no) like '%C231110020345%' order by c.NUM_CLAIM_NO Desc;
Edited by: user12195658 on Mar 24, 2011 7:27 AM

from T-1 explain plan output is:
Explain complete.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 132 | | 5862 (4)|
| 1 | SORT ORDER BY | | 1 | 132 | | 5862 (4)|
| 2 | NESTED LOOPS | | 1 | 132 | | 5853 (4)|
| 3 | NESTED LOOPS | | 1 | 97 | | 5852 (4)|
| 4 | NESTED LOOPS | | 1 | 83 | | 5851 (4)|
| 5 | VIEW | | 78 | 2574 | | 5617 (4)|
| 6 | SORT UNIQUE | | 78 | 6992 | | 5617 (78)|
| 7 | UNION-ALL | | | | | |
| 8 | FILTER | | | | | |
| 9 | HASH JOIN | | 29 | 1943 | | 1266 (5)|
| 10 | HASH JOIN | | 2895 | 115K| | 584 (5)|
| 11 | INDEX FAST FULL SCAN | IND_GC_CLM_GEN_INFO | 2437 | 43866 | | 353 (5)|
| 12 | TABLE ACCESS FULL | GC_CLM_OS | 36517 | 820K| | 229 (4)|
| 13 | VIEW | VW_SQ_1 | 43391 | 1101K| | 680 (4)|
| 14 | HASH GROUP BY | | 43391 | 1313K| 4712K| 680 (4)|
| 15 | TABLE ACCESS FULL | GC_CLM_OS | 65293 | 1976K| | 228 (4)|
| 16 | SORT AGGREGATE | | 1 | 15 | | |
| 17 | INDEX RANGE SCAN | IND_GC_CLM_GEN_INFO | 6 | 90 | | 3 (0)|
| 18 | HASH JOIN | | 76 | 6840 | | 2001 (5)|
| 19 | HASH JOIN | | 2207 | 137K| | 1338 (5)|
| 20 | HASH JOIN | | 365 | 17885 | 1256K| 1054 (4)|
| 21 | TABLE ACCESS FULL | GC_CLM_OS | 36517 | 820K| | 229 (4)|
| 22 | VIEW | VW_SQ_2 | 43391 | 1101K| | 680 (4)|
| 23 | HASH GROUP BY | | 43391 | 1313K| 4712K| 680 (4)|
| 24 | TABLE ACCESS FULL | GC_CLM_OS | 65293 | 1976K| | 228 (4)|
| 25 | INDEX FAST FULL SCAN | PK_GC_CLM_GEN_INFO | 262K| 3849K| | 276 (5)|
| 26 | VIEW | VW_SQ_3 | 30152 | 765K| | 661 (5)|
| 27 | HASH GROUP BY | | 30152 | 883K| 3336K| 661 (5)|
| 28 | INDEX FAST FULL SCAN | IND_GC_CLM_GEN_INFO | 46690 | 1367K| | 356 (6)|
| 29 | FILTER | | | | | |
| 30 | HASH JOIN | | 511 | 43435 | | 1535 (5)|
| 31 | HASH JOIN ANTI | | 337 | 22579 | | 1180 (4)|
| 32 | HASH JOIN | | 365 | 17885 | 1256K| 1054 (4)|
| 33 | TABLE ACCESS FULL | GC_CLM_OS | 36517 | 820K| | 229 (4)|
| 34 | VIEW | VW_SQ_4 | 43391 | 1101K| | 680 (4)|
| 35 | HASH GROUP BY | | 43391 | 1313K| 4712K| 680 (4)|
| 36 | TABLE ACCESS FULL | GC_CLM_OS | 65293 | 1976K| | 228 (4)|
| 37 | INDEX FAST FULL SCAN | IND_GC_CLM_PAYMENT_DETAILS | 2396 | 43128 | | 125 (6)|
| 38 | INDEX FAST FULL SCAN | IND_GC_CLM_GEN_INFO | 44253 | 777K| | 354 (5)|
| 39 | SORT AGGREGATE | | 1 | 15 | | |
| 40 | INDEX RANGE SCAN | IND_GC_CLM_GEN_INFO | 6 | 90 | | 3 (0)|
| 41 | TABLE ACCESS BY INDEX ROWID | GC_CLM_GEN_INFO | 1 | 50 | | 3 (0)|
| 42 | INDEX RANGE SCAN | PK_GC_CLM_GEN_INFO | 1 | | | 2 (0)|
| 43 | SORT AGGREGATE | | 1 | 15 | | |
| 44 | INDEX RANGE SCAN | IND_GC_CLM_GEN_INFO | 6 | 90 | | 3 (0)|
| 45 | NESTED LOOPS | | 1 | 26 | | 5 (0)|
| 46 | TABLE ACCESS BY INDEX ROWID| GC_CLM_PAYMENT_DETAILS | 1 | 21 | | 4 (0)|
| 47 | INDEX RANGE SCAN | IND_GC_CLM_PAYMENT_DETAILS | 1 | | | 3 (0)|
| 48 | TABLE ACCESS BY INDEX ROWID| GC_CLMMST_RESOURCE_TYPE | 1 | 5 | | 1 (0)|
| 49 | INDEX UNIQUE SCAN | PK_GC_CLMMST_RESOURCE_TYPE | 1 | | | 0 (0)|
| 50 | INDEX RANGE SCAN | UW_DEPARTMENT_MASTER_INDX | 1 | 14 | | 1 (0)|
| 51 | INDEX RANGE SCAN | IND_UW_PRODUCT_MASTER | 1 | 35 | | 1 (0)|
Note
- 'PLAN_TABLE' is old version
61 rows selected.

Query Is Running Slow

Similar Messages

Maybe you are looking for