Select query taking time

THe following query is taking time. Is there anyway better to write this query.
SELECT PROGRAM_NAME_ID ,PROGRAM_NAME,sum(balance)"Unpaid Balance"
    FROM (
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM  BILLING B,
PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND  p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
and b.SUBMIT_STATUS='S'
union
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM  MV_BILLING B,
MV_PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND  p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
order by report_period,program_name_id )
where balance>=0
GROUP BY PROGRAM_NAME_ID,PROGRAM_NAME
ORDER BY PROGRAM_NAME_ID

Hi,
This is totally right.
>
Being one such call. The price for calling pl/sql functions in SQL can be quite high. I'd highly recommend you find a way to incorporate the pl/sql code into the SQL query.
>
but, try with this query. I hope would help you and return the rows you want.
SELECT   program_name_id, program_name,
           SUM (  tuff_generic_pkg.get_total (billing_key, program_key)
                + NVL (penalty_interest (billing_key,
                                         program_key,
                                         company_id,
                                         report_period
                       0
         - payment_amount (company_id, program_key, report_period) balance
    FROM (SELECT program_name_id, program_name, t.billing_key, t.program_key,
                 b.company_id, b.report_period
            FROM billing b, prog_surch t, mv_program_dict p
           WHERE b.billing_key = t.billing_key
             AND p.program_key = t.program_key(+)
             AND company_id = :p3_hide_comp
             AND b.submit_status = 'S'
          UNION
          SELECT program_name_id, program_name, t.billing_key, t.program_key,
                 b.company_id, b.report_period report_period, company_id
            FROM mv_billing b, mv_prog_surch t, mv_program_dict p
           WHERE b.billing_key = t.billing_key
             AND p.program_key = t.program_key(+)
             AND company_id = :p3_hide_comp) sub
   WHERE   (  tuff_generic_pkg.get_total (billing_key, program_key)
            + NVL (penalty_interest (billing_key,
                                     program_key,
                                     company_id,
                                     report_period
                   0
         - payment_amount (company_id, program_key, report_period) >= 0
GROUP BY program_name_id, program_nameObviosly I cannot testing.
HTH -- johnxjean --

Similar Messages

  • Select query taking more time..

    Hi friends..
    The below inner join statement is taking more time ,  can any  body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
    SELECT a~vbeln from vbap as a inner join vakpa as b
          on avbeln = bvbeln
          into corresponding fields of table IT_VAKPA
          where a~WERKS IN S_IWERKS
          and a~pstyv NE 'ZRS'
          and b~vkorg = IVKORG
          and b~audat IN IAUDAT
          and b~vtweg IN IVTWEG.
    Regards
    Chetan

    Hi Chetan ,
    VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
    My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
    I am sure performance of query will be improved.
    If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
    However I will recommend you to go for first option only. If this does not work then go for second option.
    Hopfully this will help you.
    Regards,
    Nikhil

  • SELECT query taking long time

    Hi All,
    I am trying to run one SELECT statement which uses 6 tables. That query generally take 25-30 minutes to generate output.
    Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.
    What else I should check in order to figure out why my SELECT statement is taking time?
    Any help will be much appreciated.
    Thanks!

    Please let me know if you still want me to provide all the information mentioned in the link.Yes, please.
    Before you can even start optimizing, it should be clear what parts of the query are running slow.
    The links contains the steps to take regarding how to identify the things that make the query run slow.
    Ideally you post a trace/tkprof report with wait events, it'll show on what time is being spent, give an execution plan and a database version all in once...
    Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.Well, something must have changed.
    And you must indentify what exactly has changed, but it's a broad range you have to check:
    - it could be outdated table statistics
    - it could be data growth or skewness that makes Optimizer choose a wrong plan all of a sudden
    - it could be a table that got modified with some bad index
    - it could be ...
    So, by posting the information in the link, you'll leave less room for guesses from us, so you'll get an explanation that makes sense faster or, while investigating by following the steps in the link, you'll get the explanation yourself.

  • Select query taking Much time

    Dear all ,
    I am fetching data from pool table a006.  The select query is mentioned below.
    select * from a005 into table i_a005 for all wntries in it_table
                 where  kappl  = 'V'
                 and      kschl   IN  s_kschl
                 and     vkorg   in   s_vkorg
                 and     vtweg  in   s_vtgew
                 and     matnr   in s_matnr
                 and    knumh  =  it_table-knumh .
    here every fields are primary key fields except one field knumh which is comparing with table it_table. Because of these field this query is taking too much time as KNUMH is not primary key. And a005 is pool table . So , i cant create index for same. If there is alternate solutions , than please let me know..
    Thank You ,
    And in technical setting of table ITS Metioned as Fully buffered and size category is 0 .. But data are around 9000000. Is it issue or What ?  Can somebody tell some genual reason ? Or improvement in my select query.........
    Edited by: TVC6784 on Jun 30, 2011 3:31 PM

    TVC6784 wrote:
    Hi Yuri ,
    >
    > Thanks for your reply....I will check as per your comment...
    > bUT if i remove field KNUMH  From selection condition and also for all entries in it_itab ,  than data fetch very fast As KNUMH is not primary key..
    > .  the example is below
    >
    > select * from a005 into table i_a005
    > where kappl = 'V'
    > and kschl IN s_kschl
    > and vkorg in s_vkorg
    > and vtweg in s_vtgew
    > and matnr in s_matnr.
    >
    > Can you comment anything about it ?
    >
    > And can you please say how can i check its size as you mention that is  2-3 Mb More   ?
    >
    > Edited by: TVC6784 on Jun 30, 2011 7:37 PM
    I cannot see the trace and other information about the table so I cannot judge why the select w/o KNUMH is faster.
    Basically, if the table is buffered and it's contents is in the SAP application server memory, the access should be really fast. Does not really matter if it is with KNUMH or without.
    I would really like to see at least ST05 trace of your report that is doing this select. This would clarify many things.
    You can check the size by multiplying the entries in A005 table by 138. This is (in my test system) the ABAP width of the structure.
    If you have 9.000.000 records in A005, then it would take 1,24 Gb in the buffer (which is a clear sign to unbuffer).

  • Select query taking too much time to fetch data from pool table a005

    Dear all,
    I am using 2 pool table a005 and a006 in my program. I am using select query to fetch data from these table. i.e. example is mentioned below.
    select * from a005 into table t_a005 for all entries in it_itab
                       where vkorg in s_vkorg
                       and     matnr in  s_matnr
                       and     aplp   in  s_aplp
                       and     kmunh = it_itab-kmunh.
    here i can't create index also as tables are pool table...If there is any solutions , than please help me for same..
    Thanks ,

    it would be helpful to know what other fields are in the internal table you are using for the FOR ALL ENTRIES.
    In general, you should code the order of your fields in the select in the same order as they appear in the database.  If you do not have the top key field, then the entire database is read. If it's large then it's going to take a lot of time.  The more key fields from the beginning of the structure that you can supply at faster the retrieval.
    Regards,
    Brent

  • Select Query taking long time to run second time

    Hi All,
    I have Oracle 11gR1 in windows server 2008 R2 .
    I have some tables with 10 million records . When i run the select query for those tables first time it gives me result in 15 seconds but if i am running the same script second time from the same session I am getting the result in 15 minutes to complete ..
    Why it is happening? What may be the solution for this ?
    Thanks & Regards,
    Vikash jain(Junior DBA)

    Hi Mohamed,
    I just saw that both the times for the same query execution plan is different ..
    here are the details :
    First time Second Time
    g84m3qqjv2p3q g84m3qqjv2p3q
    2733045235 1310485984
    So plz tell me how should i force database to use the first execution plan ?
    I got this script for forcing the Db to use the same execution plan
    accept sql_id -
    prompt 'Enter value for sql_id: ' -
    default 'X0X0X0X0'
    accept plan_hash_value -
    prompt 'Enter value for plan_hash_value: ' -
    default 'X0X0X0X0'
    accept fixed -
    prompt 'Enter value for fixed (NO): ' -
    default 'NO'
    accept enabled -
    prompt 'Enter value for enabled (YES): ' -
    default 'YES'
    accept plan_name -
    prompt 'Enter value for plan_name (ID_sqlid_planhashvalue): ' -
    default 'X0X0X0X0'
    set feedback off
    set sqlblanklines on
    set serveroutput on
    declare
    l_plan_name varchar2(40);
    l_old_plan_name varchar2(40);
    l_sql_handle varchar2(40);
    ret binary_integer;
    l_sql_id varchar2(13);
    l_plan_hash_value number;
    l_fixed varchar2(3);
    l_enabled varchar2(3);
    major_release varchar2(3);
    minor_release varchar2(3);
    begin
    select regexp_replace(version,'\..*'), regexp_substr(version,'[0-9]+',1,2) into major_release, minor_release from v$instance;
    minor_release := 2;
    l_sql_id := '&&sql_id';
    l_plan_hash_value := to_number('&&plan_hash_value');
    l_fixed := '&&fixed';
    l_enabled := '&&enabled';
    ret := dbms_spm.load_plans_from_cursor_cache(
    sql_id=>l_sql_id,
    plan_hash_value=>l_plan_hash_value,
    fixed=>l_fixed,
    enabled=>l_enabled);
    if minor_release = '1' then
    -- 11gR1 has a bug that prevents renaming Baselines
    dbms_output.put_line(' ');
    dbms_output.put_line('Baseline created.');
    dbms_output.put_line(' ');
    else
    -- This statements looks for Baselines create in the last 4 seconds
    select sql_handle, plan_name,
    decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
    into l_sql_handle, l_old_plan_name, l_plan_name
    from dba_sql_plan_baselines spb
    where created > sysdate-(1/24/60/15);
    ret := dbms_spm.alter_sql_plan_baseline(
    sql_handle=>l_sql_handle,
    plan_name=>l_old_plan_name,
    attribute_name=>'PLAN_NAME',
    attribute_value=>l_plan_name);
    dbms_output.put_line(' ');
    dbms_output.put_line('Baseline '||upper(l_plan_name)||' created.');
    dbms_output.put_line(' ');
    end if;
    end;
    undef sql_id
    undef plan_hash_value
    undef plan_name
    undef fixed
    set feedback on
    Output:
    Enter value for sql_id: g84m3qqjv2p3q
    Enter value for plan_hash_value: 2733045235
    Enter value for fixed (NO):
    Enter value for enabled (YES):
    Enter value for plan_name (ID_sqlid_planhashvalue): g84m3qqjv2p3q
    old 16: l_sql_id := '&&sql_id';
    new 16: l_sql_id := 'g84m3qqjv2p3q';
    old 17: l_plan_hash_value := to_number('&&plan_hash_value');
    new 17: l_plan_hash_value := to_number('2733045235');
    old 18: l_fixed := '&&fixed';
    new 18: l_fixed := 'NO';
    old 19: l_enabled := '&&enabled';
    new 19: l_enabled := 'YES';
    old 40: decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
    new 40: decode('g84m3qqjv2p3q','X0X0X0X0','SQLID_'||'g84m3qqjv2p3q'||'_'||'2733045235','g84m3qqjv2p3q')
    declare
    ERROR at line 1:
    ORA-01403: no data found
    ORA-06512: at line 39
    Kindly help me to resolve the issue ..
    Thanks & Regards,
    Vikash Jain(Junior DBA)

  • Query taking time

    We have this query which is taking a long time to execute. From the explain plan what i found out is there is a full table scan going on W_GL_OTHER_F. Please help in identifying the problem area and solutions.
    The query is,
    select D1.c1 as c1,
         D1.c2 as c2,
         D1.c3 as c3,
         D1.c4 as c4,
         D1.c5 as c5,
         D1.c6 as c6,
         D1.c7 as c7,
         D1.c8 as c8
    from
         (select distinct D1.c2 as c1,
                   D1.c3 as c2,
                   D1.c4 as c3,
                   D1.c5 as c4,
                   D1.c6 as c5,
                   D1.c7 as c6,
                   D1.c8 as c7,
                   D1.c1 as c8,
                   D1.c5 as c9
              from
                   (select sum(case  when T324628.OTHER_DOC_AMT is null then 0 else T324628.OTHER_DOC_AMT end ) as c1,
                             T91397.GL_ACCOUNT_NUM as c2,
                             T149255.SEGMENT_VAL_CODE as c3,
                             T148908.SEGMENT_VAL_DESC as c4,
                             T148543.HIER4_CODE as c5,
                             T148543.HIER4_NAME as c6,
                             T91707.ACCT_DOC_NUM as c7,
                             T91707.X_LINE_DESCRIPTION as c8
                        from
                             W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */ ,
                             W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */ ,
                             W_STATUS_D T96094 /* Dim_W_STATUS_D_Generic */ ,
                             WC_GL_OTHER_F_MV T324628 /* Fact_WC_GL_OTHER_MV */ ,
                             W_GL_SEGMENT_D T149255 /* Dim_W_GL_SEGMENT_D_Segment1 */ ,
                             W_GL_SEGMENT_D T148937 /* Dim_W_GL_SEGMENT_D_Segment3 */ ,
                             W_HIERARCHY_D T148543 /* Dim_W_HIERARCHY_D_Segment3 */ ,
                             W_GL_SEGMENT_D T148908 /* Dim_W_GL_SEGMENT_D_Segment2 */
                        where  ( T91397.ROW_WID = T91707.GL_ACCOUNT_WID and T91707.DOC_STATUS_WID = T96094.ROW_WID and T96094.ROW_WID = T324628.DOC_STATUS_WID and T148543.HIER_CODE = T148937.SEGMENT_LOV_ID and T148543.HIER20_CODE = T148937.SEGMENT_VAL_CODE and T324628.DELETE_FLG = 'N' and T324628.X_CURRENCY_CODE = 'CAD' and T148543.HIER4_CODE <> '00000000000' and T91397.RECON_TYPE_CODE is not null and T91397.ROW_WID = T324628.GL_ACCOUNT_WID and T91397.ACCOUNT_SEG3_CODE = T148937.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG3_ATTRIB = T148937.SEGMENT_LOV_ID and T91397.ACCOUNT_SEG2_CODE = T148908.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG2_ATTRIB = T148908.SEGMENT_LOV_ID and T91397.ACCOUNT_SEG1_CODE = T149255.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG1_ATTRIB = T149255.SEGMENT_LOV_ID and (T96094.W_STATUS_CODE in ('POSTED', 'REVERSED')) and T91397.GL_ACCOUNT_NUM like '%98%' )
                        group by T91397.GL_ACCOUNT_NUM, T91707.ACCT_DOC_NUM, T91707.X_LINE_DESCRIPTION, T148543.HIER4_CODE, T148543.HIER4_NAME, T148908.SEGMENT_VAL_DESC, T149255.SEGMENT_VAL_CODE
                   ) D1
         ) D1
    order by c1, c2, c3, c4, c5, c6, c7The plan is,
    PLAN_TABLE_OUTPUT
    Plan hash value: 3196636288
    | Id  | Operation                             | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Psto
    |   0 | SELECT STATEMENT                      |                     |   810K|   306M|       |   266K  (1)| 01:20:03 |       |       |
    |   1 |  HASH GROUP BY                        |                     |   810K|   306M|   320M|   266K  (1)| 01:20:03 |       |       |
    |*  2 |   HASH JOIN                           |                     |   810K|   306M|    38M|   239K  (1)| 01:11:56 |       |       |
    |*  3 |    MAT_VIEW ACCESS FULL               | WC_GL_OTHER_F_MV    |  1137K|    40M|       |  9771   (2)| 00:0
    |*  4 |    HASH JOIN                          |                     |   531K|   189M|       |   222K  (1)| 01:06:38 |       |       |
    |   5 |     INLIST ITERATOR                   |                     |       |       |       |            |          |       |       |
    |*  6 |      INDEX RANGE SCAN                 | W_STATUS_D_U2       |     4 |    56 |       |     1   (0)| 00:00:01 |   
    |*  7 |     HASH JOIN                         |                     |   607K|   208M|  8704K|   222K  (1)| 01:06:38 |       |       |
    |*  8 |      HASH JOIN                        |                     | 40245 |  8214K|  2464K| 10843   (2)| 00:03:16 |       |       |
    |   9 |       VIEW                            | index$_join$_007    | 35148 |  2025K|       |   122  (32)| 00:00:03 |       |
    |* 10 |        HASH JOIN                      |                     |       |       |       |            |          |       |       |
    |* 11 |         HASH JOIN                     |                     |       |       |       |            |          |       |       |
    |* 12 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  13 |           BITMAP CONVERSION TO ROWIDS |                     | 35148 |  2025K|       |     1   (0)| 00:00:01 |       |   
    |  14 |            BITMAP INDEX FULL SCAN     | W_HIERARCHY_D_M2    |       |       |       |            |          |       |     
    |  15 |           BITMAP CONVERSION TO ROWIDS |                     | 35148 |  2025K|       |    24   (0)| 00:00:01 |       |   
    |  16 |            BITMAP INDEX FULL SCAN     | W_HIERARCHY_D_M4    |       |       |       |            |          |       |     
    |  17 |          BITMAP CONVERSION TO ROWIDS  |                     | 35148 |  2025K|       |    24   (0)| 00:00:01 |       |   
    |* 18 |           BITMAP INDEX FULL SCAN      | X_W_HIERARCHY_D_M11 |       |       |       |            |          |       |     
    |  19 |         BITMAP CONVERSION TO ROWIDS   |                     | 35148 |  2025K|       |    33   (0)| 00:00:01 |       |   
    |  20 |          BITMAP INDEX FULL SCAN       | X_W_HIERARCHY_D_M12 |       |       |       |            |          |       |     
    |* 21 |       HASH JOIN                       |                     | 40246 |  5895K|  4096K| 10430   (2)| 00:03:08 |       |      
    |  22 |        VIEW                           | index$_join$_008    | 65417 |  3321K|       |   197  (14)| 00:00:04 |      
    |* 23 |         HASH JOIN                     |                     |       |       |       |            |          |       |       |
    |* 24 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  25 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  3321K|       |     3   (0)| 00:00:01 |       |   
    |  26 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  27 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  3321K|       |    66   (2)| 00:00:02 |       |   
    |  28 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |  29 |          BITMAP CONVERSION TO ROWIDS  |                     | 65417 |  3321K|       |   100   (1)| 00:00:02 |       |   
    |  30 |           BITMAP INDEX FULL SCAN      | W_GL_SEGMENT_D_M3   |       |       |       |            |          |       |     
    |* 31 |        HASH JOIN                      |                     | 40246 |  3851K|       |  9953   (1)| 00:03:00 |       |       |
    |  32 |         VIEW                          | index$_join$_006    | 65417 |  1149K|       |    82  (18)| 00:00:02 |       |      
    |* 33 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  34 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  1149K|       |     3   (0)| 00:00:01 |       |   
    |  35 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  36 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  1149K|       |    66   (2)| 00:00:02 |       |   
    |  37 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |* 38 |         HASH JOIN                     |                     | 40246 |  3144K|       |  9870   (1)| 00:02:58 |       |       |
    |  39 |          VIEW                         | index$_join$_005    | 65417 |  1149K|       |    82  (18)| 00:00:02 |       |     
    |* 40 |           HASH JOIN                   |                     |       |       |       |            |          |       |       |
    |  41 |            BITMAP CONVERSION TO ROWIDS|                     | 65417 |  1149K|       |     3   (0)| 00:00:01 |       |   
    |  42 |             BITMAP INDEX FULL SCAN    | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  43 |            BITMAP CONVERSION TO ROWIDS|                     | 65417 |  1149K|       |    66   (2)| 00:00:02 |       |   
    |  44 |             BITMAP INDEX FULL SCAN    | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |* 45 |          TABLE ACCESS FULL            | W_GL_ACCOUNT_D      | 40246 |  2436K|       |  9788   (1)| 00:02:57
    |  46 |      PARTITION RANGE ALL              |                     |    11M|  4261M|       |   152K  (2)| 00:45:43 |     1 |1048
    |  47 |       TABLE ACCESS FULL               | W_GL_OTHER_F        |    11M|  4261M|       |   152K  (2)| 00:45:43
    Predicate Information (identified by operation id):
       2 - access("T96094"."ROW_WID"="T324628"."DOC_STATUS_WID" AND "T91397"."ROW_WID"="T324628"."GL_ACC
       3 - filter("T324628"."X_CURRENCY_CODE"='CAD' AND "T324628"."DELETE_FLG"='N')
       4 - access("T91707"."DOC_STATUS_WID"="T96094"."ROW_WID")
       6 - access("T96094"."W_STATUS_CODE"='POSTED' OR "T96094"."W_STATUS_CODE"='REVERSED')
       7 - access("T91397"."ROW_WID"="T91707"."GL_ACCOUNT_WID")
       8 - access("T148543"."HIER_CODE"="T148937"."SEGMENT_LOV_ID" AND "T148543"."HIER20_CODE"="T148937"
      10 - access(ROWID=ROWID)
      11 - access(ROWID=ROWID)
      12 - access(ROWID=ROWID)
      18 - filter("T148543"."HIER4_CODE"<>'00000000000')
      21 - access("T91397"."ACCOUNT_SEG2_CODE"="T148908"."SEGMENT_VAL_CODE" AND
                  "T91397"."ACCOUNT_SEG2_ATTRIB"="T148908"."SEGMENT_LOV_ID")
      23 - access(ROWID=ROWID)
      24 - access(ROWID=ROWID)
      31 - access("T91397"."ACCOUNT_SEG3_CODE"="T148937"."SEGMENT_VAL_CODE" AND
                  "T91397"."ACCOUNT_SEG3_ATTRIB"="T148937"."SEGMENT_LOV_ID")
      33 - access(ROWID=ROWID)
      38 - access("T91397"."ACCOUNT_SEG1_CODE"="T149255"."SEGMENT_VAL_CODE" AND
                  "T91397"."ACCOUNT_SEG1_ATTRIB"="T149255"."SEGMENT_LOV_ID")
      40 - access(ROWID=ROWID)
      45 - filter("T91397"."GL_ACCOUNT_NUM" LIKE '%98%' AND "T91397"."RECON_TYPE_CODE" IS NOT NULL)
    79 rows selected.

    user605926 wrote:
    We have this query which is taking a long time to execute. From the explain plan what i found out is there is a full table scan going on W_GL_OTHER_F. Please help in identifying the problem area and solutions.
    The plan is,
    PLAN_TABLE_OUTPUT
    Plan hash value: 3196636288
    | Id  | Operation                             | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Psto
    |   0 | SELECT STATEMENT                      |                     |   810K|   306M|       |   266K  (1)| 01:20:03 |       |       |
    |   1 |  HASH GROUP BY                        |                     |   810K|   306M|   320M|   266K  (1)| 01:20:03 |       |       |
    |*  2 |   HASH JOIN                           |                     |   810K|   306M|    38M|   239K  (1)| 01:11:56 |       |       |
    |*  3 |    MAT_VIEW ACCESS FULL               | WC_GL_OTHER_F_MV    |  1137K|    40M|       |  9771   (2)| 00:0
    |*  4 |    HASH JOIN                          |                     |   531K|   189M|       |   222K  (1)| 01:06:38 |       |       |
    |   5 |     INLIST ITERATOR                   |                     |       |       |       |            |          |       |       |
    |*  6 |      INDEX RANGE SCAN                 | W_STATUS_D_U2       |     4 |    56 |       |     1   (0)| 00:00:01 |   
    |*  7 |     HASH JOIN                         |                     |   607K|   208M|  8704K|   222K  (1)| 01:06:38 |       |       |
    |*  8 |      HASH JOIN                        |                     | 40245 |  8214K|  2464K| 10843   (2)| 00:03:16 |       |       |
    |   9 |       VIEW                            | index$_join$_007    | 35148 |  2025K|       |   122  (32)| 00:00:03 |       |
    |* 10 |        HASH JOIN                      |                     |       |       |       |            |          |       |       |
    |* 11 |         HASH JOIN                     |                     |       |       |       |            |          |       |       |
    |* 12 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  13 |           BITMAP CONVERSION TO ROWIDS |                     | 35148 |  2025K|       |     1   (0)| 00:00:01 |       |   
    |  14 |            BITMAP INDEX FULL SCAN     | W_HIERARCHY_D_M2    |       |       |       |            |          |       |     
    |  15 |           BITMAP CONVERSION TO ROWIDS |                     | 35148 |  2025K|       |    24   (0)| 00:00:01 |       |   
    |  16 |            BITMAP INDEX FULL SCAN     | W_HIERARCHY_D_M4    |       |       |       |            |          |       |     
    |  17 |          BITMAP CONVERSION TO ROWIDS  |                     | 35148 |  2025K|       |    24   (0)| 00:00:01 |       |   
    |* 18 |           BITMAP INDEX FULL SCAN      | X_W_HIERARCHY_D_M11 |       |       |       |            |          |       |     
    |  19 |         BITMAP CONVERSION TO ROWIDS   |                     | 35148 |  2025K|       |    33   (0)| 00:00:01 |       |   
    |  20 |          BITMAP INDEX FULL SCAN       | X_W_HIERARCHY_D_M12 |       |       |       |            |          |       |     
    |* 21 |       HASH JOIN                       |                     | 40246 |  5895K|  4096K| 10430   (2)| 00:03:08 |       |      
    |  22 |        VIEW                           | index$_join$_008    | 65417 |  3321K|       |   197  (14)| 00:00:04 |      
    |* 23 |         HASH JOIN                     |                     |       |       |       |            |          |       |       |
    |* 24 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  25 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  3321K|       |     3   (0)| 00:00:01 |       |   
    |  26 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  27 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  3321K|       |    66   (2)| 00:00:02 |       |   
    |  28 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |  29 |          BITMAP CONVERSION TO ROWIDS  |                     | 65417 |  3321K|       |   100   (1)| 00:00:02 |       |   
    |  30 |           BITMAP INDEX FULL SCAN      | W_GL_SEGMENT_D_M3   |       |       |       |            |          |       |     
    |* 31 |        HASH JOIN                      |                     | 40246 |  3851K|       |  9953   (1)| 00:03:00 |       |       |
    |  32 |         VIEW                          | index$_join$_006    | 65417 |  1149K|       |    82  (18)| 00:00:02 |       |      
    |* 33 |          HASH JOIN                    |                     |       |       |       |            |          |       |       |
    |  34 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  1149K|       |     3   (0)| 00:00:01 |       |   
    |  35 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  36 |           BITMAP CONVERSION TO ROWIDS |                     | 65417 |  1149K|       |    66   (2)| 00:00:02 |       |   
    |  37 |            BITMAP INDEX FULL SCAN     | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |* 38 |         HASH JOIN                     |                     | 40246 |  3144K|       |  9870   (1)| 00:02:58 |       |       |
    |  39 |          VIEW                         | index$_join$_005    | 65417 |  1149K|       |    82  (18)| 00:00:02 |       |     
    |* 40 |           HASH JOIN                   |                     |       |       |       |            |          |       |       |
    |  41 |            BITMAP CONVERSION TO ROWIDS|                     | 65417 |  1149K|       |     3   (0)| 00:00:01 |       |   
    |  42 |             BITMAP INDEX FULL SCAN    | W_GL_SEGMENT_D_M1   |       |       |       |            |          |       |     
    |  43 |            BITMAP CONVERSION TO ROWIDS|                     | 65417 |  1149K|       |    66   (2)| 00:00:02 |       |   
    |  44 |             BITMAP INDEX FULL SCAN    | W_GL_SEGMENT_D_M2   |       |       |       |            |          |       |     
    |* 45 |          TABLE ACCESS FULL            | W_GL_ACCOUNT_D      | 40246 |  2436K|       |  9788   (1)| 00:02:57
    |  46 |      PARTITION RANGE ALL              |                     |    11M|  4261M|       |   152K  (2)| 00:45:43 |     1 |1048
    |  47 |       TABLE ACCESS FULL               | W_GL_OTHER_F        |    11M|  4261M|       |   152K  (2)| 00:45:43
    Predicate Information (identified by operation id):
    2 - access("T96094"."ROW_WID"="T324628"."DOC_STATUS_WID" AND "T91397"."ROW_WID"="T324628"."GL_ACC
    3 - filter("T324628"."X_CURRENCY_CODE"='CAD' AND "T324628"."DELETE_FLG"='N')
    4 - access("T91707"."DOC_STATUS_WID"="T96094"."ROW_WID")
    6 - access("T96094"."W_STATUS_CODE"='POSTED' OR "T96094"."W_STATUS_CODE"='REVERSED')
    7 - access("T91397"."ROW_WID"="T91707"."GL_ACCOUNT_WID")
    8 - access("T148543"."HIER_CODE"="T148937"."SEGMENT_LOV_ID" AND "T148543"."HIER20_CODE"="T148937"
    10 - access(ROWID=ROWID)
    11 - access(ROWID=ROWID)
    12 - access(ROWID=ROWID)
    18 - filter("T148543"."HIER4_CODE"<>'00000000000')
    21 - access("T91397"."ACCOUNT_SEG2_CODE"="T148908"."SEGMENT_VAL_CODE" AND
    "T91397"."ACCOUNT_SEG2_ATTRIB"="T148908"."SEGMENT_LOV_ID")
    23 - access(ROWID=ROWID)
    24 - access(ROWID=ROWID)
    31 - access("T91397"."ACCOUNT_SEG3_CODE"="T148937"."SEGMENT_VAL_CODE" AND
    "T91397"."ACCOUNT_SEG3_ATTRIB"="T148937"."SEGMENT_LOV_ID")
    33 - access(ROWID=ROWID)
    38 - access("T91397"."ACCOUNT_SEG1_CODE"="T149255"."SEGMENT_VAL_CODE" AND
    "T91397"."ACCOUNT_SEG1_ATTRIB"="T149255"."SEGMENT_LOV_ID")
    40 - access(ROWID=ROWID)
    45 - filter("T91397"."GL_ACCOUNT_NUM" LIKE '%98%' AND "T91397"."RECON_TYPE_CODE" IS NOT NULL)
    79 rows selected.
    You may want to have a look at <a href="HOW TO: Post a SQL statement tuning request - template posting">HOW TO: Post a SQL statement tuning request - template posting</a> to see what more details are needed in order for somebody to provide better answer.
    Based on what you have posted so far, you may want to share details of following questions (in addition to details in above link)
    1) How much time does the query currently take to execute? How much time do you expect it to take? Also, how are you measuring query execution time?
    2) Your plan suggests that the query is expected to return 810K rows. Is this figure close to actual number of records? What are you doing with this huge amount of data?

  • Select query giving Time out dump

    Hi All,
        I have written a select query on a table in BW system.The code for the same is attached below.The table contains some 6,00,000 records.This query is giving a time out error.Kindly look into the query and advice ways to make it work.Thanks.
        IF NOT lt_temp[] IS INITIAL.
          SELECT /bic/zprrmatnr objvers /bic/zprclwynr /bic/zprrmdlr
                 FROM  /bic/pzprrmatnr
                 INTO CORRESPONDING FIELDS OF TABLE lt_zprrmatnr
                 FOR ALL ENTRIES IN lt_temp
                 WHERE /bic/zprclwynr = lt_temp-temp
                 AND   objvers = 'A'.
        ENDIF.
    Thanks and Regards,
    Faisal

    Not only is it BW, it is also a customer table. Have a look here on how to research yourself:
    Please Read before Posting in the Performance and Tuning Forum
    Thomas

  • Select Query on time stamp.

    Hello Gurus,
    Please help me in writing a select query with the where condition on time stamp for the field IBSP-VALFR and IBSP-VALTO, with the current system time stamp. I need pick all the values which falls in these two fields with the current time stamp.
    Thanks & Regards,
    Naresh.

    Hi,
    some how my code is not working...Please look at my code.
    convert date sy-datum
                 time sy-uzeit
       into time stamp low_validity
      time zone sy-zonlo.
    SELECT  SP_INSTANCE INSTANCE EQUNO MATNO SERNO
             FROM IBSP INTO TABLE IT_IBSP
             for all entries in it_IBIN
             where ( SP_INSTANCE = IT_IBIN-INSTANCE OR
                   INSTANCE = IT_IBIN-INSTANCE ) and
                   VALFR Le low_validity and
                   VALTO ge low_validity.
    Its getting the values for which VALTO is less than current date.
    Thanks & Regards,
    Naresh.

  • A simple select query taking forever

    Hi All
    I am not able to execute a simple select query, I traced my session and here is TKPROF of that Trace.
    Solaris 8 , Oracle 10.2.0.4.0
    TKPROF: Release 10.2.0.4.0 -
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: 502_ora_28260.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    select OBJECT_ID , ORACLE_USERNAME , SESSION_ID
    from
      v$locked_object
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.03      32.86          0          0          6           0
    total        3      0.03      32.86          0          0          6           0
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: SYS
    Rows     Row Source Operation
          0  MERGE JOIN  (cr=0 pr=0 pw=0 time=60 us)
          0   SORT JOIN (cr=0 pr=0 pw=0 time=58 us)
          0    MERGE JOIN  (cr=0 pr=0 pw=0 time=42 us)
          1     SORT JOIN (cr=0 pr=0 pw=0 time=2443 us)
       1105      FIXED TABLE FULL X$KSUSE (cr=0 pr=0 pw=0 time=1204 us)
          0     SORT JOIN (cr=0 pr=0 pw=0 time=41 us)
       1001      FIXED TABLE FULL X$KTCXB (cr=0 pr=0 pw=0 time=16132 us)
          0   SORT JOIN (cr=0 pr=0 pw=0 time=0 us)
          0    FIXED TABLE FULL X$KTADM (cr=0 pr=0 pw=0 time=0 us)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      buffer busy waits                              34        0.97         32.83
      SQL*Net break/reset to client                   1        0.00          0.00
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.03      32.86          0          0          6           0
    total        3      0.03      32.86          0          0          6           0
    Misses in library cache during parse: 1
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     1       19.00         19.00
      buffer busy waits                              34        0.97         32.83
      SQL*Net break/reset to client                   1        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        1  user  SQL statements in session.
        0  internal SQL statements in session.
        1  SQL statements in session.
    Trace file: 502_ora_28260.trc
    Trace file compatibility: 10.01.00
    Sort options: default
           0  session in tracefile.
           1  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           1  SQL statements in trace file.
           1  unique SQL statements in trace file.
          64  lines in trace file.
          32  elapsed seconds in trace file. There is nothing fishy in alert logs... Please guide
    Thanks

    There it is TOP
    $ RUMPSHAKER>top
    load averages:  6.63,  7.45,  7.88;                    up 33+12:02:33           
    3631 processes: 3616 sleeping, 5 zombie, 1 stopped, 9 on cpu
    CPU states: 58.6% idle, 18.2% user, 23.2% kernel,  0.0% iowait,  0.0% swap
    Memory: 192G phys mem, 92G free mem, 96G swap, 96G free swap
       PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
    13752 ora0005    1  19    0 4243M 4219M sleep    5:21 62.78% oracle
    17758 ora0005    1  25    0 1174M 1156M cpu      1:05 37.12% oracle
    17923 root       1  57    0   18M   14M sleep  689:07 13.59% ecap_monitor
    20777 root      12  58    0   14M   13M sleep  864:33 11.55% OracleAgent
    18884 ora0004    1   1    0  830M  813M sleep    0:01  9.54% oracle
    12070 ora0004   61  58    0  320M  315M sleep   28.5H  8.29% emagent
    20347 root      16  59    0   33M   25M sleep   26.0H  6.34% caiUxsA2
    17949 ist0005    1  53    0 7984K 4984K cpu      0:00  3.93% top
         1 root       1  59    0 2912K 1288K sleep   32.2H  3.75% init
    15035 ora0001    1  46    0   32M   22M sleep  166:43  2.98% tnslsnr
      5748 ora0004   11  54    0  516M  496M sleep  389:37  2.78% oracle
    20567 ora0004    1  55    0   27M   22M sleep    0:00  2.69% sqlplus
      6730 ora0001    1  33    0  632M  616M sleep    0:06  2.67% oracle
    20557 ora0004    1  56    0   27M   23M sleep    0:00  2.53% sqlplus
      5355 ora0005    1  59    0 1154M 1137M sleep    0:04  2.46% oracleand VMSTAT 2 5
    $ RUMPSHAKER> vmstat 2 5
    kthr      memory            page            disk          faults      cpu
    r b w   swap  free  re  mf pi po fr de sr s0 s1 s2 sd   in   sy   cs us sy id
    6 8 0 143125576 74272080 4628 24012 488 150 149 0 0 4 4 -2 0 25037 192698 65249 38 26 36
    1 3 0 162803992 95246464 1989 6989 0 4 4 0 0 6 6 0  0 9170 57822 26434 8 13 79
    1 7 0 162801352 95240296 3043 15633 4 9737 9682 0 0 0 0 0 0 11277 73516 38200 16 16 68
    3 10 0 162801560 95227920 3326 12729 16 16862 16774 0 0 1 1 0 0 11377 86054 44758 16 17 68
    1 10 0 162784520 95186488 9638 48359 24 11682 11626 0 0 13 13 0 0 13484 149366 44205 23 29 47

  • Select query taking long time (more then 6 min)

    Dear experts,
    DATA:IT_CHEQ2 TYPE TABLE OF TY_BSAS,
         WA_CHEQ2 LIKE LINE OF IT_CHEQ2.
    DATA : IT_CHEQ3 TYPE STANDARD TABLE OF TY_BSAS WITH HEADER LINE.
    TYPES:BEGIN OF TY_BSAS,
           BUKRS TYPE BSAS-BUKRS,
           HKONT TYPE BSAS-HKONT,
           AUGDT TYPE BSAS-AUGDT,
           AUGBL TYPE BSAK-AUGBL,
           ZUONR TYPE BSAK-ZUONR,
           GJAHR TYPE BSAK-GJAHR,
           BELNR TYPE BSAK-BELNR,
           BUZEI TYPE BSAK-BUZEI,
           BUDAT TYPE BSAK-BUDAT,
           XBLNR TYPE BSAK-XBLNR,
           BLART TYPE BSAK-BLART,
           SHKZG TYPE BSAK-SHKZG,
           DMBTR TYPE BSAK-DMBTR,
           WMWST TYPE BSAK-WMWST,
          AUGGJ TYPE BSAK-AUGGJ, " CLEARING FYSICAL YEAR
           OT_TAX TYPE BSAK-DMBTR,
           TDS   TYPE BSAK-DMBTR,
           VAT    TYPE BSAK-DMBTR, "Vat amount
           WCT   TYPE BSAK-DMBTR,
           ADV    TYPE BSAK-DMBTR,  "Advance
           CHAMT TYPE BSAK-DMBTR,
           CHNO  TYPE PAYR-CHECT,
           CHDATE TYPE PAYR-ZALDT,
           DBIT_NOTE TYPE BSAK-DMBTR,
           PAY_ADJ   TYPE BSAK-DMBTR,
           PEND_SES TYPE BSAK-DMBTR, "PENDING SES
           CR_PARTY(50)  TYPE C,
          END OF TY_BSAS.
    SELECT BUKRS HKONT AUGDT AUGBL ZUONR GJAHR BELNR BUZEI BUDAT XBLNR BLART SHKZG
                      DMBTR WMWST
                      FROM BSAS INTO " APPENDING
               CORRESPONDING FIELDS OF TABLE IT_CHEQ3
                      FOR ALL ENTRIES IN IT_CHEQ2
                      WHERE AUGBL = IT_CHEQ2-AUGBL and
                        BUKRS = IT_CHEQ2-BUKRS   AND
    *                  AUGBL = IT_CHEQ2-AUGBL
                          GJAHR = IT_CHEQ2-GJAHR
                      AND  XBLNR = IT_CHEQ2-XBLNR.
    line company code  hkont       augdt               augbl               zuonr              gjahr        belnr                 buzei  budat
    1     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     005     20110831
    xblnr       blart        shkzg
    RA03     KZ         H            37067.00         0.00     2011     0.00     0.00
    2     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     006     20110831
         RA03     KZ     H     393850.00     0.00     2011     0.00     0.00
    3     1018     0012100030     20110831     2100009710     20110831     2011     2100009710     004     20110831     RA03     KZ     S     723589.13     0.00     2011     0.00     0.00
    4     1018     0012100030     20110831     2100009710     20110823     2011     3900001250     001     20110823     RA03     RS     H     712921.13     0.00     2011     0.00     0.00
    5     1018     0023200000     20110831     2100009710     20110831     2011     2100009710     008     20110831     RA03     KZ     H     21788.00     0.00     2011     0.00     0.00
    6     1018     0023200000     20110831     2100009710     20110831     2011     2100009710     007     20110831     RA03     KZ     H     1162821.00     0.00     2011     0.00     0.00
    if i put same entry in se11 for bsas it takes 7 second
    and in query takes  more then 6 min ,kindly tell why
    help me gurus
    regards
    victor

    Tested point 2.
    There is no difference.
    REPORT  Z_YZ_SELECT_ORDER.
    types: begin of t_orderadm,
             description type CRMT_PROCESS_DESCRIPTION,
             created_at type COMT_CREATED_AT_USR,
             LOGICAL_SYSTEM type CRMT_LOGSYS,
             TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
             VERIFY_DATE type CRMT_VERIFY_DATE,
             GUID type CRMT_OBJECT_GUID,
           end of t_orderadm.
    types: begin of t_orderadm_1,
             GUID type CRMT_OBJECT_GUID,
             description type CRMT_PROCESS_DESCRIPTION,
             LOGICAL_SYSTEM type CRMT_LOGSYS,
             TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
             created_at type COMT_CREATED_AT_USR,
             VERIFY_DATE type CRMT_VERIFY_DATE,
           end of t_orderadm_1.
    data: lt_orders type table of t_orderadm,
          lt_orders_1 type table of t_orderadm_1.
    select description created_at logical_system template_type verify_date guid
      into table lt_orders
      from crmd_orderadm_h.
    select guid description logical_system template_type created_at verify_date
      into table lt_orders_1
      from crmd_orderadm_h.
    write 'done'.
    First select - mixed order of fields. Response time: 82.155 microseconds for 39380 records selected.
    Second select - fields in the order of the table. Response time: 81.061 microseconds for the same 39380 records selected.
    Then I changed the order of SELECT statements. I have put first the select with ordered fields, and second - select with mixed order of fields. The runtimes were the following:
    Ordered fields - 82.649 microseconds
    Mixed order of fields - 80.270 microseconds.
    So I'm going to change the Wiki page in order to avoid  in future advices that make no sense.

  • Query taking time to execute

    Hello,
    i have created one query based on inventory cube 0IC_C03. when i am executing the infocube based on a particular date i am able to see the output but when i am executing the query on the basis of that particular date given while executing the cube the query is taking long time to execute and throwing a message of time limit exceed.
    could anyone suggest me why the query is showing such nessage along with resolution.
    Thanks,
    Kumkum
    Edited by: kumkum basu on Nov 29, 2010 2:33 PM

    Hi,
    There can be number of reason.
    What you can do is:-
    put the unwanted characteristics in Free Characteristics
    Remove unwanted cell reference
    Try using partitions in cubes
    Use aggregates for summarised data.
    f the above options doesnt work, then try pre-caching.This will definitely help!
    Use proper selections to get small subset of data.
    Goto RSRT>> type your query name>> Query properties>> select cache mode=4
    In addition to RSRT, ST05 (sql trace), SE30 (runtime analysis) and system statistics (ST03) may help you in identifying performance issues with a report.
    Thanks,.
    Saveen Kumar

  • Simple Select Query Taking 5-10s

    We have a web server on the same lan as the DB server.
    A simple select * from tablename (~100 entries) is taking
    anywhere from 30ms to 10 seconds lan. ASP code on the web server
    provides instant (30ms) queries. Ping is never <1ms. If I point
    to a remote DB server, the same query is never more than 300ms
    (which is great for over the internet).
    I enabled logging in CFAdmin -> Datasources and shortly
    after my select * from tablename I see this:
    spy(2009/02/28 16:39:00.539)>>
    Connection[2].setReadOnly(boolean readOnly)
    spy(2009/02/28 16:39:00.539)>> readOnly = false
    spy(2009/02/28 16:39:00.539)>> OK
    spy(2009/02/28 16:39:05.726)>> OK (true)
    We need to get this up and running ASAP. Please help!!

    > I'm connecting to SQL Server 2000 on a Win2k3 box.
    > The default CF8 Installation.
    > Every table this happens for.
    OK. I think CF8 runs the most recent JDBC drivers too. It
    might pay to
    check that though.
    > Select * is needed, because we have existing sites we
    are migrating a lot of
    > which use select *.
    Sure. But just for the purposes of experimentation, change
    your test code
    to specify columns to see if it makes any difference.
    It might pay to get hold of FusionReactor to check what CF is
    doing with
    the queries, under the hood.
    Adam

  • Count query taking time

    I have a query -->select c1,c2,c3 from table1 . This query takes only few milliseconds. But when I take count from the same query i.e. when I execute select count(c1,c2,c3) from table1 then it takes a very long time (about 1 min). The table1 contains about 25000 rows. Please help to improve performance of Count query.

    Satej wrote:
    I have a query -->select c1,c2,c3 from table1 . This query takes only few milliseconds. But when I take count from the same query i.e. when I execute select count(c1,c2,c3) from table1 then it takes a very long time (about 1 min).Classic misperception of Toad, SQL Navigator and similar tool users. All these tools fetch just first result screen and show time it took to fetch just that and not the time to fetch all rows. And in order to count you need to fetch all rows.l That is why select count(*) takes longer. But 1 min for 25000 rows is a bit long. Check execution plan to see what is going on.
    SY.

  • Query taking time to load

    Hi:
    We are using a common component for generating query screens wherein we just have to pass a query number to the component which in turn return a list view of records.
    We have a particular Query which when executed through Toad or any SQL tool returns records within 4-5 seconds but the same one takes almost 3 minutes to load from Front End.
    What could be the possible reason for the page to take so much time to load.
    We are using WebSphere 6.0.2.17 server. Is there any settings to be done for statement cache size or for any connection timeout or is there anything to be done at Oracle side.
    Since the moment we change the query number to some simple query like select * from dual kind the screen loads instantly.
    P.S: The query takes almost 4-5 seconds to execute in backend through TOAD.
    Avadhoot Sawant

    So 45 or 47? Nevertheless ...
    This is hardly a heavy calculation, the savings will be dismal. Also anything numeric is very easy on CPU in general.
    But
    convert( numeric(8,5), (convert( numeric,T3.COl7) / 1000000))
    is not optimal.
    CONVERT( NUMERIC(8,5),300 / 1000000.00000 )
    Is
    Now it boils to how to make load faster: do it in parallel. Find how many sockets the machine have and split the table into as many chunks. Also profile to find out where it spends most of the time. I saw sometimes the network is not letting me thru so you
    may want to play with buffers, and packet sizes, for example if OLEDB used increase the packet size two times see if works faster, then x2 more and so forth.
    To help you further you need to tell more e.g. what is this source, destination, how you configured the load.
    Please understand that there is no Silver Bullet anywhere, or a blanket solution, and you need to tell me your desired load time. E.g. if you tell me it needs to load in 5 min I will give your ask a pass.
    Arthur
    MyBlog
    Twitter

Maybe you are looking for