Query on time ..................

Hi
This is the query on time.
I am getting the current system time using sy-uzeit.I want the one hour after time from the current time.
eg. current time : 8:25
one hour after time : 9:25
Is there any funtion module to get the one hour time from the current time,or if somebody face such prob pls post the code.
Thanks
mrutyun^

Try this:
newtime = sy-uzeit + 3600.

Similar Messages

  • Query execution time

    Dear SCN,
    I am new to BOBJ Environment. I have created a webi report on top of bex query by using BISC connection. Bex query is build for Vendor Ageing Analysis. My bex query will take very less time to execute the report (max 1 min). But in case of webi is takeing around 5 min when i click on refresh. I have not used any conditions,filters,restrictions are done at webi level all are done at bex level only.
    Please let me know techniques to optimize the query execution time in webi. Currently we are in BO 4.0.
    Regards,
    PRK

    Hi Praveen
    Go through this document for performance optimization using BICS connection
    http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0e3c552-e419-3010-1298-b32e6210b58d?QuickLink=index&…

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

  • Help required in optimizing the query response time

    Hi,
    I am working on a application which uses a jdbc thin client. My requirement is to select all the table rows in one table and use the column values to select data in another table in another database.
    The first table can have maximum of 6 million rows but the second table rows will be around 9000.
    My first query is returning within 30-40 milliseconds when the table is having 200000 rows. But when I am iterating the result set and query the second table the query is taking around 4 millisecond for each query.
    the second query selection criteria is to find the value in the range .
    for example my_table ( varchar2 column1, varchar2 start_range, varchar2 end_range);
    My first query returns a result which then will be used to select using the following query
    select column1 from my_table where start_range < my_value and end_range> my_value;
    I have created an index on start_range and end_range. this query is taking around 4 millisseconds which I think is too much.
    I am using a preparedStatement for the second query loop.
    Can some one suggest me how I can improve the query response time?
    Regards,
    Shyam

    Try the code below.
    Pre-requistee: you should know how to pass ARRAY objects to oracle and receive resultsets from java. There are 1000s of samples available on net.
    I have written a sample db code for the same interraction.
    Procedure get_list takes a array input from java and returns the record set back to java. You can change the tablenames and the creteria.
    Good luck.
    DROP TYPE idlist;
    CREATE OR REPLACE TYPE idlist AS TABLE OF NUMBER;
    CREATE OR REPLACE PACKAGE mypkg1
    AS
       PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor);
    END mypkg1;
    CREATE OR REPLACE PACKAGE BODY mypkg1
    AS
       PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor)
       AS
          ctr   NUMBER;
       BEGIN
          DBMS_OUTPUT.put_line (myval_list.COUNT);
          FOR x IN (SELECT object_name, object_id, myvalue
                      FROM user_objects a,
                           (SELECT myval_list (ROWNUM + 1) myvalue
                              FROM TABLE (myval_list)) b
                     WHERE a.object_id < b.myvalue)
          LOOP
             DBMS_OUTPUT.put_line (   x.object_name
                                   || ' - '
                                   || x.object_id
                                   || ' - '
                                   || x.myvalue
          END LOOP;
       END;
    END mypkg1;
    [pre]
    Testing the code above. Make sure dbms output is ON.
    [pre]
    DECLARE
       a      idlist;
       refc   sys_refcursor;
       c number;
    BEGIN
       SELECT x.nu
       BULK COLLECT INTO a
         FROM (SELECT 5000 nu
                 FROM DUAL) x;
       mypkg1.get_list (a, refc);
    END;
    [pre]
    Vishal V.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • How to run a query several times?

    Hi all,
    Anyone has a clue for the following situation:
    We have made a query (on the web) with several characteristics and key-figures. One of the characteristics has unique values that occurs only once (something like numbers for documents in R/3). The query was build with only one user-input variable based on this characteristic. The query was build especially for printing and fits exactly on a A4-paper.
    We would like to give the end-user a tool in which he/she can store several values for the characteristic. On the basis of these stored values the system has to run the query several times.
    Something for the Reporting Agent or is there an other solution?
    Thanks in advance,
    Henk.

    hi Henk,
    'control query' in few words is to filter data with combination of characteristic value.
    http://help.sap.com/saphelp_nw04s/helpdata/en/6e/b5663a5fb46752e10000000a11402f/frameset.htm
    Control Query for Pre-calculating Web Templates
    Definition
    A control query is a help query that you execute before you execute the queries in the Web template, and use the result to parameterize the Web template.
    Use
    You can specify a control query as significant information in the Reporting Agent settings for a Web template. When you specify a control query, the system does not pre-calculate the Web template itself, but a number of filtered views from the Web template.
    We particularly recommend this procedure when wanting to calculate several Web templates only distinguished by their filter values in one swoop.
    Using a control query in particular allows you to formulate complex selection criteria for the data to be pre-calculated.
    Pre-calculate only the TOP50 customers, whose data is frequently requested, for example.
    Structure
    A very simple query, which contains exactly those characteristics in the drilldown in the rows according to which the Web template will be filtered, is particularly suitable as a control query. Every row in the table that a control query delivers, subsequently serves as a dynamic filter for the Web template views.
    The respective combination of characteristic values is used as a filter for the Web template Data Provider for each table row. The background run produces pre-calculated data records, in actual fact one data record for each table row that delivers a control query.
    If a characteristic does not appear in a view, the filter value is ignored.
    In addition, you automatically get only those filter value combinations, for which data exists in the InfoCube used to define the control query.
    Example
    A typical application of this approach for pre-calculating a Web template is with cockpit applications, since they are controlled mainly through selection lists and no real OLAP navigation is necessary.
    You can also use a control query for filtering when pre-calculating Crystal reports queries. You can find additional information under Defining Crystal Reports Queries Settings.

  • How to obtain the Query Response Time of a query?

    Given the Average Length of Row of tables and the number of rows in each table,
    is there a way we get the query response time of a query involving
    those tables. Query includes joins as well.
    For example, suppose there 3 tables t1, t2, t3. I wish to obtain the
    time it takes for the following query:
    Query
    SELECT t1.col1, t2.col2
    FROM t1, t2, t3
    WHERE t1.col1 = t2.col2
    AND t1.col2 IN ('a', 'c', 'd')
    AND t2.col1 = t3.col2
    AND t2.col1 = t1.col1 (+)
    ORDER BY t1.col1
    Given are:
    Average Row Length of t1 = 200 bytes
    Average Row Length of t2 = 100 bytes
    Average Row Length of t3 = 500 bytes
    No of rows in t1 = 100
    No of rows in t2 = 1000
    No of rows in t3 = 500
    What is required is the 'query response time' for the said query.

    I do not know how to do it myself. But if you are running Oracle 10g, I believe that there is a new tool called: SQL Tuning Advisor which might be able to help.
    Here are some links I found doing a google search, and it looks like it might meet your needs and even give you more information on how to improve your code.
    http://www.databasejournal.com/features/oracle/article.php/3492521
    http://www.databasejournal.com/features/oracle/article.php/3387011
    http://www.oracle.com/technology/obe/obe10gdb/manage/perflab/perflab.htm
    http://www.oracle.com/technology/pub/articles/10gdba/week18_10gdba.html
    http://www.oracle-base.com/articles/10g/AutomaticSQLTuning10g.php
    Have fun reading:
    You can get help from teachers, but you are going to have to learn a lot by yourself, sitting alone in a room ....Dr. Seuss
    Regards
    Tim

  • Oracle View that stores the Query execution time

    Hi Gurus
    i m using Oracle 10G in Unix. I wudiold like to know which Data dictionary view stores the execution of a query. If it is not stored then hw to find the query execution time other than (Set timing on) command. What is the use of elapsed time and what is the difference between execution time and elapsed time? How to calculate the execution time of a query.
    THanks
    Ram

    If you have a specific query you're going to run in SQL*Plus, just do
    a 'set timing on' before you execute the query.
    If you've got application SQL coming in from all over the place, you can
    identify specific SQL in V$SQL/ and look at ELAPSED_TIME/EXECUTIONS
    to get an average elapsed time.
    If you've got an application running SQL, and you need to know the
    specific timing of a specific execution (as opposed to an average),
    you can use DBMS_SUPPORT to set trace in the session that your
    application is running in, and then use TkProf to process the resulting
    trace file.

  • Query takes time to execute

    I am creating a jsp application . . . .I am retreiving some values from my database oracle 10g..my query taking time to execute even in isql plus..am uisng tomcat5 and oracle 10gR2..can anyone pls tell me why it happens...my query fetches data from four tables...i dont know exactly why its taking so muc time say 50seconds...when i run the application in my local host it retrievs fast when i do that in server it creates a problem..
    Actually it works fine when i deployed in my client server it takes time sometimes it takes atmost one minute
    1.pls tell me how can i test my query about the performance
    2.is der any command in oracle to test
    3.how much bytes it takes

    Look at this thread...
    When your query takes too long ...

  • Query optimium time

    Hi friends
    how to check the query optimum time, whether the query is taking proper time for execution or not, i mean to say query is taking proper time or more time than usual, if its taking more time how to resolve it.
    please forward some links

    Hi,
    You can go to ST03 and see the complete statistics of the query.....How much time it took and at what level(OLAP, DB, Frontend) it took maximum time.
    Got to ST03 --> select BI Workload --> Select the time period for which you want to see the details
    Select Query Runtimes and there you can select Aggregation by Query on the right hand side .
    Hope this helps.

  • Slow query execution time

    Hi,
    I have a query which fetches around 100 records from a table which has approximately 30 million records. Unfortunately, I have to use the same table and can't go ahead with a new table.
    The query executes within a second from RapidSQL. The problem I'm facing is it takes more than 10 minutes when I run it through the Java application. It doesn't throw any exceptions, it executes properly.
    The query:
    SELECT aaa, bbb, SUM(ccc), SUM(ddd), etc
    FROM MyTable
    WHERE SomeDate= date_entered_by_user  AND SomeString IN ("aaa","bbb")
    GROUP BY aaa,bbbI have an existing clustered index on SomeDate and SomeString fields.
    To check I replaced the where clause with
    WHERE SomeDate= date_entered_by_user  AND SomeString = "aaa"No improvements.
    What could be the problem?
    Thank you,
    Lobo

    It's hard for me to see how a stored proc will address this problem. I don't think it changes anything. Can you explain? The problem is slow query execution time. One way to speed up the execution time inside the RDBMS is to streamline the internal operations inside the interpreter.
    When the engine receives a command to execute a SQL statement, it does a few things before actually executing the statement. These things take time. First, it checks to make sure there are no syntax errors in the SQL statement. Second, it checks to make sure all of the tables, columns and relationships "are in order." Third, it formulates an execution plan. This last step takes the most time out of the three. But, they all take time. The speed of these processes may vary from product to product.
    When you create a stored procedure in a RDBMS, the processes above occur when you create the procedure. Most importantly, once an execution plan is created it is stored and reused whenever the stored procedure is ran. So, whenever an application calls the stored procedure, the execution plan has already been created. The engine does not have to anaylze the SELECT|INSERT|UPDATE|DELETE statements and create the plan (over and over again).
    The stored execution plan will enable the engine to execute the query faster.
    />

  • Query execution time estimation....

    Hi All,
    Is it possible to estimate query execution time using explain plan?
    Thanks in advance,
    Santosh.

    The cost estimated by the cost based optimizer is actually representing the time it takes to process the statement expressed in units of the single block read-time. Which means if you know the estimated time a single block read request requires you can translate this into an actual time.
    Starting with Oracle 9i this information (the time to perform single block/multi block read requests) is actually available if you gather system statistics.
    And this is what 10g actually does, as it shows an estimated TIME in the explain plan output based on these assumptions. Note that 10g by default uses system statistics, even if they are not explicitly gathered. In this case Oracle 10g uses the NOWORKLOAD statistics generated on the fly at instance startup.
    Of course the time estimates shown by Oracle 10g may not even be close to the actual execution time as it is only an estimate based on a model and input values (statistics) and therefore might be way off due to several reasons, the same applies in principle to the cost shown.
    Regards,
    Randolf
    Oracle related stuff:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle:
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Table defination in datatype size can effect on query execution time.

    Hello Oracle Guru,
    I have one question , suppose I have create one table with more than 100 column
    and i tacke every column datatype varchar2(4000).
    Actual data are in every column not more than 300 character so in this case
    if i execute only select query
    so oracle cursor internaly read up to 4000 character one by one
    or it read character one by one and in last character ex. 300 it will stop there.
    If i reduce varchar2 size 300 instend of 4000 in table defination,
    so is it effect on select query execution time ?
    Thanks in advance.

    When you declare VARCHAR2 column you specify maximum size that can be stored in that column. Database stores actual number of bytes (plus 2 bytes for length). So if yiou insert 300 character string, only 302 bytes will be used (assuming database character set is single byte character set).
    SY.

  • Identifying query execution time

    Hello,
    I would like to know how can I figure out the actual query execution time in Oracle.
    Regards

    Oracle Documentation is your best friend.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2113.htm#i1417057
    ELAPSED_TIME --> Elapsed time (in microseconds) used by this cursor for parsing, executing, and fetching
    Asif Momen
    http://momendba.blogspot.com

  • How to know query execution time in sql plus

    HI
    I want to know the query execution time in sql plus along with statistics
    I say set time on ;
    set autotrace on ;
    select * from view where usr_id='abcd';
    if the result is 300 rows it scrolls till all the rows are retrieved and finally gives me execution time as 40 seconds or 1 minute.. (this is after all the records are scrolled )
    but when i execute it in toad it gives 350 milli seconds..
    i want to see the execution time in sql how to do this
    database server 11g and client is 10g
    regards
    raj

    what is the difference between .. the
    statistics gathered in sql plus something like this and the one that i get from plan_table in toad?
    how to format the execution plan I got in sqlplus in a proper understanding way?
    statistics in sqlplus
    tatistics
             0  recursive calls
             0  db block gets
           164  consistent gets
             0  physical reads
             0  redo size
         29805  bytes sent via SQL*Net to client
           838  bytes received via SQL*Net from client
            25  SQL*Net roundtrips to/from client
             1  sorts (memory)
             0  sorts (disk)
           352  rows processedexecution plan in sqlplus... how to format this
    xecution Plan
      0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=21 Card=1 Bytes=10
             03)
      1    0   HASH (UNIQUE) (Cost=21 Card=1 Bytes=1003)
      2    1     MERGE JOIN (CARTESIAN) (Cost=20 Card=1 Bytes=1003)
      3    2       NESTED LOOPS
      4    3         NESTED LOOPS (Cost=18 Card=1 Bytes=976)
      5    4           NESTED LOOPS (Cost=17 Card=1 Bytes=797)
      6    5             NESTED LOOPS (OUTER) (Cost=16 Card=1 Bytes=685)
      7    6               NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=556
      8    7                 NESTED LOOPS (Cost=14 Card=1 Bytes=427)
      9    8                   NESTED LOOPS (Cost=5 Card=1 Bytes=284)
    10    9                     TABLE ACCESS (BY INDEX ROWID) OF 'USR_XR
             EF' (TABLE) (Cost=4 Card=1 Bytes=67)
    11   10                       INDEX (RANGE SCAN) OF 'USR_XREF_PK' (I
             NDEX (UNIQUE)) (Cost=2 Card=1)
    12    9                     TABLE ACCESS (BY INDEX ROWID) OF 'USR_DI
             M' (TABLE) (Cost=1 Card=1 Bytes=217)
    13   12                       INDEX (UNIQUE SCAN) OF 'USR_DIM_PK' (I
             NDEX (UNIQUE)) (Cost=0 Card=1)
    14    8                   TABLE ACCESS (BY INDEX ROWID) OF 'HDS_FCT'
              (TABLE) (Cost=9 Card=1 Bytes=143)
    15   14                     INDEX (RANGE SCAN) OF 'HDS_FCT_IX2' (IND
             EX) (Cost=1 Card=338)
    16    7                 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_
             COMM' (TABLE) (Cost=1 Card=1 Bytes=129)
    17   16                   INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK'
              (INDEX (UNIQUE)) (Cost=0 Card=1)
    18    6               TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_CO
             MM' (TABLE) (Cost=1 Card=1 Bytes=129)
    19   18                 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK' (
             INDEX (UNIQUE)) (Cost=0 Card=1)
    20    5             TABLE ACCESS (BY INDEX ROWID) OF 'PROD_DIM' (TAB
             LE) (Cost=1 Card=1 Bytes=112)
    21   20               INDEX (UNIQUE SCAN) OF 'PROD_DIM_PK' (INDEX (U
             NIQUE)) (Cost=0 Card=1)
    22    4           INDEX (UNIQUE SCAN) OF 'CUST_DIM_PK' (INDEX (UNIQU
             E)) (Cost=0 Card=1)
    23    3         TABLE ACCESS (BY INDEX ROWID) OF 'CUST_DIM' (TABLE)
             (Cost=1 Card=1 Bytes=179)
    24    2       BUFFER (SORT) (Cost=19 Card=22 Bytes=594)
    25   24         INDEX (FAST FULL SCAN) OF 'PROD_DIM_AK1' (INDEX (UNI
             QUE)) (Cost=2 Card=22 Bytes=594)

  • Query Execution Time for a Query causing ORA-1555

    dear Gurus
    I have ORA-01555 error , earlier I used the Query Duration mentioned in Alert Log and increased the Undo Retention as I did not find th UnDOBLKS column of v$undostat high for the time of occurence of ORA-01555..
    But new ORA-01555 is coming whose query duration exceeds Undo Retention time..
    My question -
    1. Is it possible to accurately find the query duration time besides the Alert Log file ?

    abhishek, as you are using an undo tablespace and have already increased the time that undo data is retained via undo_retention then you might want to consider the following ideas which were useful with 1555 error under manual rbs segment management.
    1- Tune the query. The faster a query runs the less likely a 1555 will occur.
    2- Look at the processing. If a process was reading and updating the same table while committing frequenctly then the process under manual rbs management would basically create its own 1555 error rather than just being the victum of another process changing data and the rbs data being overlaid while the long running query was still running. With undo management the process could be generating more data than can be held for the undo_retention period but because it is committed Oracle has been told it doesn't really have to keep the data for use rolling back a current transaction so it gets discarded to make room for new changes.
    If you find item 2 is true then separating the select from the update will likely eliminate the 1555. You do this by building a driving table that has the keys of the rows to be updated or deleted. Then you use the driver to control accessing the target table.
    3- If the cause of the 1555 is or may be delayed block cleanout then select * from the target prior to running the long running query.
    Realistically you might need to increase the size of the undo tablespace to hold all the change data and the value of the undo_retention parameter to be longer than the job run time. Which brings up back to option 1. Tune every query in the process so that the job run time is reduced to optimal.
    HTH -- Mark D Powell --
    dear mark
    Thanks for the excellent advise..I found that the error is coming because of frequent commits..which is item 2 as u righly mentioned ..
    I think I need to keep a watch on the queries running , I was just trying to find the execution time for the queries..If there is any way to find the query duration without running a trace ..
    regards
    abhishek

  • How can I reduce BEx Query execution time

    Hi,
    I have a question regarding query execution time in BEx.
    I have a query that takes 45 mins to 1 hour to execute in BEx analyser. This query is run on a daily basis and hence I am keen to reduce the execution time.  Are there any programs or function modules that can help in reducing query execution time?
    Thanks and Regards!

    Hi Sriprakash,
    1.Check if your cube is performance tuned: in the manage cube from RSA1 / performance tab: check if all indexes and statistics are green. Aggregate IDx should as well be.
    2.Condense your cubes regularly
    3. Evaluate the creation of an aggregate with all characteristic used in the query (RSDDV).
    4.Evaluate the creation of a "change run aggregate": based on a standalone NavAttr (without its basic char in the aggr.) but pay attention to the consequent change run when loading master data.
    5. Partition (physically) your cubes systematically when possible (RSDCUBE, menu, partitioning)
    6. Consider logical partitioning (by year or comp_code or ...) and make use of multiproviders in order to keep targets not too big...
    7.Consider creating secondary indexes when reporting on ODS (RSDODS)
    8.Check if the query runtime is due the master data read or the infoprovider itself, or the OLAP processor and/or any other cause in tx ST03N
    9.Consider improving your master reads by creating customized IDX (BITMAP if possible and depending on your data) on master data table and/or attribute SIDs when using NAvs.
    10.Check that your basis team did a good job and have applied the proper DB parameters
    11.Last but not least: fine tune your datamodel precisely.
    hope this will give you an idea.
    Cheers
    Sunil

Maybe you are looking for