Query from source table takes lots of time

I have to load data from an Oracle table which has millions of records. The loading knowledge module I am using is 'lkm sql to oracle'.
I see that the query from the source database takes lot of time and doing a full table scan where as it supposed to be using an index.
I dont have any lkm with 'lkm oracle to oracle'. Some how I need to add a hint to this source query. How I can do this?

This LKM is not indicated to large volume of data, try to use LKM Oracle to Oracle (DBLINK), see ODI KMs documentation for more information.
Related to HINTS you can add this with KM options, see that some Oracle ODI11g new KMs already have some options to do it, so you can put the hint on interface options of KM or define the temp index on the interface

Similar Messages

Function Module Extraction from KONV Table taking lot of time for extractio

Hi
I have a requirement wherein i need to get records from KONV Table (Conditions (Transaction Data) ). i need the data corresponding to Application (KAPPL) = 'F'.
For this i had written one function module but it is taking lot of time (@ 2.5 hrs) for fetching records as there are large number of records in KONV Table.
I am pasting the Function Module code for reference.
<b>kindly guide me as to how the extraction performance can be improved.</b>
<b>Function Module Code:</b>
FUNCTION ZBW_SHPMNT_COND.
""Local interface:
*" IMPORTING
*"     VALUE(I_REQUNR) TYPE SBIWA_S_INTERFACE-REQUNR
*"     VALUE(I_ISOURCE) TYPE SBIWA_S_INTERFACE-ISOURCE OPTIONAL
*"     VALUE(I_MAXSIZE) TYPE SBIWA_S_INTERFACE-MAXSIZE OPTIONAL
*"     VALUE(I_INITFLAG) TYPE SBIWA_S_INTERFACE-INITFLAG OPTIONAL
*"     VALUE(I_UPDMODE) TYPE SBIWA_S_INTERFACE-UPDMODE OPTIONAL
*"     VALUE(I_DATAPAKID) TYPE SBIWA_S_INTERFACE-DATAPAKID OPTIONAL
*"     VALUE(I_PRIVATE_MODE) OPTIONAL
*"     VALUE(I_CALLMODE) LIKE ROARCHD200-CALLMODE OPTIONAL
*" TABLES
*"      I_T_SELECT TYPE SBIWA_T_SELECT OPTIONAL
*"      I_T_FIELDS TYPE SBIWA_T_FIELDS OPTIONAL
*"      E_T_DATA STRUCTURE ZBW_SHPMNT_COND OPTIONAL
*"      E_T_SOURCE_STRUCTURE_NAME OPTIONAL
*" EXCEPTIONS
*"      NO_MORE_DATA
*"      ERROR_PASSED_TO_MESS_HANDLER
The input parameter I_DATAPAKID is not supported yet !
TABLES: KONV.
Auxiliary Selection criteria structure
DATA: l_s_select TYPE sbiwa_s_select.
Maximum number of lines for DB table
STATICS: l_maxsize TYPE sbiwa_s_interface-maxsize.
Maximum number of lines for DB table
STATICS: S_S_IF TYPE SRSC_S_IF_SIMPLE,
counter
          S_COUNTER_DATAPAKID LIKE SY-TABIX,
cursor
          S_CURSOR TYPE CURSOR.
Select ranges
RANGES: L_R_KNUMV FOR KONV-KNUMV,
          L_R_KSCHL FOR KONV-KSCHL,
          L_R_KDATU FOR KONV-KDATU.
Declaring internal tables
DATA : I_KONV LIKE KONV OCCURS 0 WITH HEADER LINE.
DATA : Begin of I_KONV occurs 0,
         MANDT LIKE konv-mandt,
         KNUMV LIKE konv-knumv,
         KPOSN LIKE konv-kposn,
         STUNR LIKE konv-stunr,
         ZAEHK LIKE konv-zaehk,
         KAPPL LIKE konv-kappl,
         KSCHL LIKE konv-kschl,
         KDATU LIKE konv-kdatu,
         KBETR LIKE konv-kbetr,
         WAERS LIKE konv-waers,
         END OF I_KONV.
Initialization mode (first call by SAPI) or data transfer mode
(following calls) ?
IF i_initflag = sbiwa_c_flag_on.
Initialization: check input parameters
                buffer input parameters
                prepare data selection
The input parameter I_DATAPAKID is not supported yet !
Invalid second initialization call -> error exit
    IF NOT g_flag_interface_initialized IS INITIAL.
      IF
        1 = 2.
        MESSAGE e008(r3).
      ENDIF.
      log_write 'E'                    "message type
                'R3'                   "message class
                '008'                  "message number
                ' '                    "message variable 1
                ' '.                   "message variable 2
      RAISE error_passed_to_mess_handler.
    ENDIF.
Check InfoSource validity
    CASE i_isource.
      WHEN 'X'.
     WHEN 'Y'.
     WHEN 'Z'.
      WHEN OTHERS.
       IF 1 = 2. MESSAGE e009(r3). ENDIF.
       log_write 'E'                  "message type
                 'R3'                 "message class
                 '009'                "message number
                 i_isource            "message variable 1
                 ' '.                 "message variable 2
       RAISE error_passed_to_mess_handler.
    ENDCASE.
Check for supported update mode
    CASE i_updmode.
For full upload
      WHEN 'F'.
      WHEN 'D'.
      WHEN OTHERS.
       IF 1 = 2. MESSAGE e011(r3). ENDIF.
       log_write 'E'                  "message type
                 'R3'                 "message class
                 '011'                "message number
                 i_updmode            "message variable 1
                 ' '.                 "message variable 2
       RAISE error_passed_to_mess_handler.
    ENDCASE.
    APPEND LINES OF i_t_select TO g_t_select.
Fill parameter buffer for data extraction calls
    g_s_interface-requnr    = i_requnr.
    g_s_interface-isource   = i_isource.
    g_s_interface-maxsize   = i_maxsize.
    g_s_interface-initflag = i_initflag.
    g_s_interface-updmode   = i_updmode.
    g_s_interface-datapakid = i_datapakid.
    g_flag_interface_initialized = sbiwa_c_flag_on.
Fill field list table for an optimized select statement
(in case that there is no 1:1 relation between InfoSource fields
and database table fields this may be far from beeing trivial)
    APPEND LINES OF i_t_fields TO g_t_fields.
Interpretation of date selection for generic extraktion
   CALL FUNCTION 'RSA3_DATE_RANGE_CONVERT'
     TABLES
       i_t_select = g_t_select.
ELSE.                 "Initialization mode or data extraction ?
   CASE g_s_interface-updmode.
     WHEN 'F' OR 'C' OR 'I'.
First data package -> OPEN CURSOR
    IF g_counter_datapakid = 0.
   L_MAXSIZE = G_S_INTERFACE-MAXSIZE.
      LOOP AT g_t_select INTO l_s_select WHERE fieldnm = 'KNUMV'.
        MOVE-CORRESPONDING l_s_select TO l_r_knumv.
        APPEND l_r_knumv.
      ENDLOOP.
      LOOP AT g_t_select INTO l_s_select WHERE fieldnm = 'KSCHL'.
        MOVE-CORRESPONDING l_s_select TO l_r_kschl.
        APPEND l_r_kschl.
      ENDLOOP.
      Loop AT g_t_select INTO l_s_select WHERE fieldnm = 'KDATU'.
        MOVE-CORRESPONDING l_s_select TO l_r_kdatu.
        APPEND l_r_kdatu.
      ENDLOOP.
*In case of full upload
Fill field list table for an optimized select statement
(in case that there is no 1:1 relation between InfoSource fields
and database table fields this may be far from beeing trivial)
   APPEND LINES OF I_T_FIELDS TO S_S_IF-T_FIELDS.
      OPEN CURSOR G_CURSOR FOR
        SELECT MANDT
               KNUMV
               KPOSN
               STUNR
               ZAEHK
               KAPPL
               KSCHL
               KDATU
               KBETR
               WAERS
        FROM   KONV
        WHERE KNUMV IN l_r_knumv
        AND   KSCHL IN l_r_kschl
        AND   KDATU IN l_r_kdatu
        AND   KAPPL EQ 'F'.
    ENDIF.
    Refresh I_KONV.
    FETCH NEXT CURSOR G_CURSOR
               APPENDING CORRESPONDING FIELDS OF TABLE I_KONV
               PACKAGE SIZE S_S_IF-MAXSIZE.
    IF SY-SUBRC <> 0.
      CLOSE CURSOR G_CURSOR.
      RAISE NO_MORE_DATA.
    ENDIF.
    LOOP AT I_KONV.
     IF I_KONV-KAPPL EQ 'F'.
      CLEAR :E_T_DATA.
      E_T_DATA-MANDT = I_KONV-MANDT.
      E_T_DATA-KNUMV = I_KONV-KNUMV.
      E_T_DATA-KPOSN = I_KONV-KPOSN.
      E_T_DATA-STUNR = I_KONV-STUNR.
      E_T_DATA-ZAEHK = I_KONV-ZAEHK.
      E_T_DATA-KAPPL = I_KONV-KAPPL.
      E_T_DATA-KSCHL = I_KONV-KSCHL.
      E_T_DATA-KDATU = I_KONV-KDATU.
      E_T_DATA-KBETR = I_KONV-KBETR.
      E_T_DATA-WAERS = I_KONV-WAERS.
      APPEND E_T_DATA.
   ENDIF.
    ENDLOOP.
    g_counter_datapakid = g_counter_datapakid + 1.
ENDIF.
ENDFUNCTION.
Thanks in Advance
Regards
Swapnil.

Hi,
one option to investigate is to select the data with a condition on KNUMV (primary IDX).
Since shipment costs are store in VFKP I would investigate if all your F condition records are used in this table (field VFKP-KNUMV).
If this is the case then something like
SELECT *
FROM KONV
WHERE KNUMV IN (SELECT DISTINCT KNUMV FROM VFKP)
or
SELECT DISTINCT KNUMV
INTO CORRESPONDING FIELD OF <itab>
FROM VFKP
and then
SELECT *
FROM KONV
FOR ALL ENTRIES IN <itab>
WHERE...
will definitively speed it up.
hope this helps....
Olivier

Huge Group by operation on Huge Table takes lot of time

Hi,
Pl find the below given process which takes of time in execution (approx 5-6 hrs)
The mailn reason for this is
1) It Fetch data from huge table partition (i.e 18GB data for per day)
2)Performs Group by operations
3)In the where clause Index is not there on destination_number so performs Full Table scan
I have some idea i.e I need to change the Some Parameter which will make the process faster ,
Can you please help on this
create or replace table tmp_kumar nologging as
SELECT c.series_num , subscriber_id , COUNT(1) cnt , SUM(NVL(total_currency_charge,0))total_currency_charge ,
TRUNC(disconnect_date) FROM
(select * from prepcdr.PREPCDR_MAR_P3_10 partition(disconnect_date_11) union all
select * from prepcdr.PREPCDR_MAR_P3_10 partition(disconnect_date_11_new)) b,
(SELECT series_num, des, created_dt, LENGTH (series_num) len
FROM PREPCDR.HSS_SERIES_MAST where home_ind ='Y'
UNION
SELECT cimd_number, des, created_dt, LENGTH (cimd_number)
FROM PREPCDR.HSS_CIMD_MASTER) c
WHERE b.cdr_call_type = '86'
AND SUBSTR (b.destination_number, 1, c.len) = c.series_num
AND c.len = (SELECT MAX(x.len) FROM (SELECT series_num, des, created_dt, LENGTH (series_num) len
FROM PREPCDR.HSS_SERIES_MAST where home_ind ='Y'
UNION
SELECT cimd_number, des, created_dt, LENGTH (cimd_number) len
FROM PREPCDR.HSS_CIMD_MASTER) x WHERE x.series_num = SUBSTR (b.destination_number, 1, x.len))
AND disconnect_date >= '11-MAR-2010'
AND disconnect_date < '12-MAR-2010'
GROUP BY c.series_num , TRUNC(disconnect_date) , suBscriber_id

This, most likely, will be more efficient:
SELECT c.series_num,
        subscriber_id,
        COUNT(1) cnt,
        SUM(NVL(total_currency_charge,0)) total_currency_charge,
        TRUNC(disconnect_date)
FROM (
          select *
            from prepcdr.PREPCDR_MAR_P3_10 partition(disconnect_date_11)
         union all
          select *
            from prepcdr.PREPCDR_MAR_P3_10 partition(disconnect_date_11_new)
        ) b,
         SELECT DISTINCT series_num,
                          des,
                          created_dt,
                          len
           FROM (
                  SELECT series_num,
                          des,
                          created_dt,
                          len,
                          RANK() OVER(ORDER BY len) rnk
                    FROM (
                            SELECT series_num,
                                    des,
                                    created_dt,
                                    LENGTH(series_num) len
                              FROM PREPCDR.HSS_SERIES_MAST
                              where home_ind ='Y'
                           UNION ALL
                            SELECT cimd_number,
                                    des,
                                    created_dt,
                                    LENGTH(cimd_number)
                              FROM PREPCDR.HSS_CIMD_MASTER
           WHERE rnk = 1
        ) c
WHERE b.cdr_call_type = '86'
    AND SUBSTR(b.destination_number,1,c.len) = c.series_num
   AND disconnect_date >= DATE '2010-03-11'
   AND disconnect_date < DATE '2010-03-12'
GROUP BY c.series_num,
            TRUNC(disconnect_date),
            suBscriber_id
/SY.

Inserting into a base table of a materialized view takes lot of time.......

Dear All,
I have created a materialized view which refreshes on commit.materialized view is enabled query rewrite.I have created a materialized view log on the base table also While inserting into the base table it takes lot of time................Can u please tell me why?

Dear Rahul,
Here is my materialized view..........
create materialized view mv_test on prebuilt table refresh force on commit
enable query rewrite as
SELECT P.PID,
SUM(HH_REGD) AS HH_REGD,
SUM(INPRO_WORKS) AS INPRO_WORKS,
SUM(COMP_WORKS) AS COMP_WORKS,
SUM(SKILL_WAGE) AS SKILL_WAGE,
SUM(UN_SKILL_WAGE) AS UN_SKILL_WAGE,
SUM(WAGE_ADVANCE) AS WAGE_ADVANCE,
SUM(MAT_AMT) AS MAT_AMT,
SUM(DAYS) AS DAYS,
P.INYYYYMM,P.FIN_YEAR
FROM PROG_MONTHLY P
WHERE SUBSTR(PID,5,2)<>'PP'
GROUP BY PID,P.INYYYYMM,P.FIN_YEAR;
Please help me if query enable rewrite does any performance degradation......
Thanks & Regards
Kris

Urgen!! Query takes lots of time to execute and the production is in effect

Hi,
We have some data loading script. This scripts takes lots of time to execute. As Iam new to tunning please do let me know what is the wrong with the query !!
Thanks In advance
Query:
=========
INSERT /*+ PARALLEL */ INTO ris.ris_pi_profile
(ID,COUNTRY_OF_CITIZENSHIP,IMMIGRATION_STATUS,SSN,DOB,GENDER,
ETHNICITY,RACE,DEPARTMENT,DIVISION,INSTITUTION_ID,INST_EMAIL,EFFECT_DATE,ACADEMIC_TITLE,ACADEMIC_POSITION,
OTH_PER_DATA,PCT_RESEARCH,PCT_TEACHING,PCT_CLINICAL,PCT_ADMIN,PCT_OTHER,PCT_TRAINING)
SELECT
ap.id,
p.citizen_cd,
decode(p.visa_cd,'CV',0,'F1',1,'H1',2,'H1B',3,'H2',4,'J1',5,'J2',6,'O1',7,'PR',8,'PRP',9,'TC',10,'TN',11,'TNN',12),
(select n.soc_sec_num from sa.name n where n.name_id = p.name_id),
(select n.birth_date from sa.name n where n.name_id = p.name_id),
(select decode(n.gender_cd,'F',1,'M',2,0) from sa.name n where n.name_id = p.name_id),
(select decode(n.ethnic_cd,'H',1) from sa.name n where n.name_id = p.name_id),
(select decode(n.ethnic_cd,'A',2,'B',3,'I',1,'P',4,'W',5) from sa.name n where n.name_id = p.name_id),
a.dept_name,
a.div_name,
a.inst_id,
(select n.email from sa.name n where n.name_id = p.name_id),
a.eff_date,
ac.acad_pos_desc,
p.acad_pos_cd,
0,
p.research_pct,
p.teach_pct,
p.patient_pct,
p.admin_pct,
p.other_pct,
p.course_pct
FROM
appl1 ap,
sa.personal_data p,
sa.address a,
sa.academic_pos_cd ac,
profile_pi f
WHERE
p.project_role_cd='PI'
and ap.appl_id=f.appl_id
and p.appl_id=f.appl_id
and p.name_id=f.name_id
and a.addr_id=f.addr_id
and p.acad_pos_cd=ac.acad_pos_cd
AND EXISTS (select 1 from ris.ris_institution i WHERE i.id = a.inst_id)
AND EXISTS (select 1 from sa.academic_pos_cd acp WHERE acp.acad_pos_cd = p.acad_pos_cd);
In the execution PLan I see lots of Nested loop, Hash Join
Index( Unique scan)
Table Access by ( Index rowid)
This query is fast in Test DB but ver very slow in prod DB. Need your help Urgent.
Minaz

When your query takes too long...
When your query takes too long ...

Infoobject F4 help in the Query takes lot of time and hangs

Hi All,
I have 0Material in the query and the F4 help for selection takes lot of time and hangs after some time.
The 0Material has 2 million records the Infoobject properties for Bex are as below:
Selection:No selection restriction
Query Def. Filter Value Selection: Values in Master Data Table
Query Execution Filter Val.Selectn:Only Posted Values for Navigation
We tried to alter some of the Properties but we have the same issue.
Suggest other options that can be be looked into to get the F4 help in the Query .
Thanks,
Mike

hi Mike,
check if helps
Note 817335 - Performance in F4 Help
Note 748623 - Input help (F4) has a very long runtime - recommendations
Note 581802 - Variable dialog boxes: performance of the F4 help
search oss note for f4 performance ......

Loading in infopackage takes lot of time

Hi Friends,
When i schedule and activate the process chain everyday, it takes lot of time to get loaded in the infopackages, around 5 to 6 hours.
in st13 when i click on the Log id name to see the process chain.
in the LOAD DATA infopackage it shows green, after double clicking on that, process moniter
i see request still running and its yellow but 0 from 0 records.
and this will be the same for hours
Its very slow.
need your guidence on this
Thanks for your help.

Hi,
I will suggest you to check a few places where you can see the status
1) SM37 job log (In source system if load is from R/3 or in BW if its a datamart load) (give request name) and it should give you the details about the request. If its active make sure that the job log is getting updated at frequent intervals.
Also see if there is any 'sysfail' for any datapacket in SM37.
2) SM66 get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. (In source system if load is from R/3 or in BW if its a datamart load). See if its accessing/updating some tables or is not doing anything at all.
3) RSMO see what is available in details tab. It may be in update rules.
4) ST22 check if any short dump has occured.(In source system if load is from R/3 or in BW if its a datamart load)
5) Check in SM58 and BD87 for pending tRFCs and IDOCS.
Once you identify you can rectify the error.
If all the records are in PSA you can pull it from the PSA to target. Else you may have to pull it again from source infoprovider.
If its running and if you are able to see it active in SM66 you can wait for some time to let it finish. You can also try SM50 / SM51 to see what is happening in the system level like reading/inserting tables etc.
If you feel its active and running you can verify by checking if the number of records has increased in the data tables.
SM21 - System log can also be helpful.
Regards,
Habeeb

Querry takes lot of time ---plz suggest

Hi oracle gurus
this querry takes lot of time ..pls suggest me
oracle version -Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
os version red hat enterprise linux ES release 4
Select * from (SELECT M.MAIL_ID, MAIL_FROM, M.SUBJECT AS S1, CEIL(M.MAIL_SIZE) AS MAIL_SIZE,
TO_CHAR(MAIL_DATE,'dd Mon yyyy hh:mi:ss am') AS MAIL_DATE1, M.ATTACHMENT_FLAG, M.MAIL_TYPE_ID,
M.PRIORITY_NO, M.TEXT, COALESCE(M.MAIL_STATUS_VALUE, M.MAIL_STATUS_VALUE, 0), 0 as email_address,
LOWER(M.MAIL_to) as Mail_to, M.Cc, M.MAIL_DATE AS MAIL_DATE, lower(subject) as subject, read_ipaddress,
read_datetime, Folder_Id,compose_type,interc_count,history_id,
pined_flag, rank() over (order by mail_date desc) as rnk from v$mail M WHERE M.USER_ID=6 AND M.FOLDER_ID =1)
where rnk between 1 and 10
Elapsed: 00:00:04.65
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=15270 Card=14316 B
ytes=203716680)
1 0 VIEW (Cost=15270 Card=14316 Bytes=203716680)
2 1 WINDOW (SORT PUSHED RANK) (Cost=15270 Card=14316 Bytes=8
890236)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'MAIL' (TABLE) (Cost=
13386 Card=14316 Bytes=8890236)
4 3 INDEX (RANGE SCAN) OF 'INDX_MAIL_ALL1' (INDEX) (Cost
=57 Card=14316)
Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed
thanks n regard

Hi Tuning gurus
i tuned the query as below ------
this querry works fine for lesser number of rows
eg :--
where ROWNUM <= 10 )
where rnum >=1;
but takes lot of time as we increase rownum ..
eg :--
where ROWNUM <= 10000 )
where rnum >=9990;
results are posted below
pls suggest me
oracle version -Oracle Database 10g Enterprise Edition
Release 10.2.0.1.0 - Prod
os version red hat enterprise linux ES release 4
also statistics differ when we use table
and its views
results of view v$mail
[select * from
( select a.*, ROWNUM rnum from
( SELECT M.MAIL_ID, MAIL_FROM, M.SUBJECT
AS S1,CEIL(M.MAIL_SIZE) AS MAIL_SIZE,
TO_CHAR(MAIL_DATE,'dd Mon yyyy hh:mi:ss
am') AS MAIL_DATE1, M.ATTACHMENT_FLAG,
M.MAIL_TYPE_ID, M.PRIORITY_NO, M.TEXT,
COALESCE(M.MAIL_STATUS_VALUE,0),
0 as email_address,LOWER(M.MAIL_to) as
Mail_to, M.Cc, M.MAIL_DATE AS MAIL_DATE,
lower(subject) as subject,read_ipaddress,
read_datetime,Folder_Id,compose_type,
interc_count,history_id,pined_flag,
rank() over (order by mail_date desc)
as rnk from v$mail M WHERE M.USER_ID=6 AND M.FOLDER_ID =1) a
where ROWNUM <= 10000 )
where rnum >=9990;]
result :
11 rows selected.
Elapsed: 00:00:03.84
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=14735 Card=10000 B
ytes=142430000)
1 0 VIEW (Cost=14735 Card=10000 Bytes=142430000)
2 1 COUNT (STOPKEY)
3 2 VIEW (Cost=14735 Card=14844 Bytes=211230120)
4 3 WINDOW (SORT) (Cost=14735 Card=14844 Bytes=9114216)
5 4 TABLE ACCESS (BY INDEX ROWID) OF 'MAIL' (TABLE) (C
ost=12805 Card=14844 Bytes=9114216)
6 5 INDEX (RANGE SCAN) OF 'FOLDER_USERID' (INDEX) (C
ost=43 Card=14844)
Statistics
294 recursive calls
0 db block gets
8715 consistent gets
8669 physical reads
0 redo size
7060 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
6 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> select count(*) from v$mail;
Elapsed: 00:00:00.17
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=494 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'FOLDER_USERID' (INDEX) (Cost=
494 Card=804661)
Statistics
8 recursive calls
0 db block gets
2171 consistent gets
2057 physical reads
260 redo size
352 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
results of original table mail
[select * from
( select a.*, ROWNUM rnum from
( SELECT M.MAIL_ID, MAIL_FROM, M.SUBJECT
AS S1,CEIL(M.MAIL_SIZE) AS MAIL_SIZE,
TO_CHAR(MAIL_DATE,'dd Mon yyyy hh:mi:ss
am') AS MAIL_DATE1, M.ATTACHMENT_FLAG,
M.MAIL_TYPE_ID, M.PRIORITY_NO, M.TEXT,
COALESCE(M.MAIL_STATUS_VALUE,0),
0 as email_address,LOWER(M.MAIL_to) as
Mail_to, M.Cc, M.MAIL_DATE AS MAIL_DATE,
lower(subject) as subject,read_ipaddress,
read_datetime,Folder_Id,compose_type,
interc_count,history_id,pined_flag,
rank() over (order by mail_date desc)
as rnk from mail M WHERE M.USER_ID=6 AND M.FOLDER_ID =1) a
where ROWNUM <= 10000 )
where rnum >=9990;]
result :
11 rows selected.
Elapsed: 00:00:03.21
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=14735 Card=10000 B
ytes=142430000)
1 0 VIEW (Cost=14735 Card=10000 Bytes=142430000)
2 1 COUNT (STOPKEY)
3 2 VIEW (Cost=14735 Card=14844 Bytes=211230120)
4 3 WINDOW (SORT) (Cost=14735 Card=14844 Bytes=9114216)
5 4 TABLE ACCESS (BY INDEX ROWID) OF 'MAIL' (TABLE) (C
ost=12805 Card=14844 Bytes=9114216)
6 5 INDEX (RANGE SCAN) OF 'FOLDER_USERID' (INDEX) (C
ost=43 Card=14844)
Statistics
1 recursive calls
119544 db block gets
8686 consistent gets
8648 physical reads
0 redo size
13510 bytes sent via SQL*Net to client
4084 bytes received via SQL*Net from client
41 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> select count(*) from mail;
Elapsed: 00:00:00.34
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=494 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'FOLDER_USERID' (INDEX) (Cost=
494 Card=804661)
Statistics
1 recursive calls
0 db block gets
2183 consistent gets
2062 physical reads
72 redo size
352 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Thanks n regards
ps : sorry i could not preserve the format plz
Message was edited by:
Cool_Jr.DBA

Execution of first request takes lot of time with JDBC OCI

Hi,
We are having an application which connects to Oracle server(10g Enterprise Edition Release 10.2.0.4.0 64bit) using Oracle JDBC OCI driver(10.2.0.1.0 production (10g R2)).
Everything works fine.
But what we observed is randomly the first request to the server vai JDBC driver in a day takes lot of time, varies from 5-15 minutes.
If we execute the request again it executed immediately
What we observed while debugging is preparedStatement.executeQuery() is taking time.
We enabled logging at the JDBC driver layer and a snapshot isgiven below. Between T2CPreparedStatement.doDefineExecuteFetch () and T2CPreparedStatement.execute_for_rows () it takes 5 minutes. Any idea why it takes this much time and reason for it? Oracle driver is not throwing any exceptions
*4-apr-2011 4:00:01* oracle.jdbc.driver.T2CPreparedStatement doDefineExecuteFetch
FINE: T2CPreparedStatement.doDefineExecuteFetch ()
*4-apr-2011 4:05:12* oracle.jdbc.driver.T2CPreparedStatement executeForRows
FINE: T2CPreparedStatement.execute_for_rows () returns: void
Detailed jdbc log is below
-apr-2011 4:00:01 oracle.jdbc.driver.OracleStatement doExecuteWithTimeout
FINE: OracleStatement.doExecuteWithTimeout() needToPrepareDefineBuffer = false
4-apr-2011 4:00:01 oracle.jdbc.driver.PhysicalConnection needLine
FINE: PhysicalConnection.needLine()--no return
4-apr-2011 4:00:01 oracle.jdbc.driver.PhysicalConnection registerHeartbeat
FINE: PhysicalConnection.registerHeartbeat()
4-apr-2011 4:00:01 oracle.jdbc.driver.OracleStatement executeMaybeDescribe
FINE: OracleStatement.execute_maybe_describe() rowPrefetchChanged = false, needToParse = false, needToPrepareDefineBuffer = false, columnsDefinedByUser = false
4-apr-2011 4:00:01 oracle.jdbc.driver.T2CPreparedStatement executeForRows
FINE: T2CPreparedStatement.execute_for_rows (executed_for_describe = false)
4-apr-2011 4:00:01 oracle.jdbc.driver.T2CPreparedStatement doDefineExecuteFetch
FINE: T2CPreparedStatement.doDefineExecuteFetch ()
4-apr-2011 4:05:12 oracle.jdbc.driver.T2CPreparedStatement executeForRows
FINE: T2CPreparedStatement.execute_for_rows () returns: void
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleStatement executeMaybeDescribe
FINE: OracleStatement.execute_maybe_describe():return validRows = 1, needToPrepareDefineBuffer = false
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleStatement doExecuteWithTimeout
FINE: OracleStatement.doExecuteWithTimeout():return validRows = 1, needToPrepareDefineBuffer = false
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl next
FINE: OracleResultSetImpl.next(): closed=false
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl next
FINER: closed=false, statement.currentRow=-1, statement.totalRowsVisited=0, statement.maxRows=0, statement.validRows=1, statement.gotLastBatch=true
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl getString
INFO: OracleResultSetImpl.getString(columnIndex=1)
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl getString
INFO: OracleResultSetImpl.getString(columnIndex=2)
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl getString
INFO: OracleResultSetImpl.getString(columnIndex=3)
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl getTimestamp
INFO: OracleResultSetImpl.getTimestamp(columnIndex=4)
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl wasNull
INFO: OracleResultSetImpl.wasNull()
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl next
FINE: OracleResultSetImpl.next(): closed=false
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl next
FINER: closed=false, statement.currentRow=0, statement.totalRowsVisited=1, statement.maxRows=0, statement.validRows=1, statement.gotLastBatch=true
4-apr-2011 4:05:12 oracle.jdbc.driver.PhysicalConnection needLine
FINE: PhysicalConnection.needLine()--no return
4-apr-2011 4:05:12 oracle.jdbc.driver.T2CPreparedStatement closeQuery
FINE: T2CPreparedStatement.closeQuery ()
4-apr-2011 4:05:12 oracle.jdbc.driver.T2CPreparedStatement closeQuery
FINE: T2CPreparedStatement.closeQuery () returns: void
4-apr-2011 4:05:12 oracle.jdbc.driver.OracleResultSetImpl close
INFO: OracleResultSetImpl.close()
Regards
Sunil

Hi,
Thanks for the reply
- SQL may vary. Its not the same query which takes time always. The same query executed immediately(using another connection from pool) works perfectly
- If there is a failover or stale connection getting closed or timeout, will JDBC driver thhrows exdeption? I didn't see any exceptions in the driver logs. Is there anyway to identify whether failover or timeout is happening?
Some other points
- The application uses connection pooling. This means that connections are created in the beginning and kept in the pool. And it may be in the pool for 72 hours or , before this issue happens
- Application uses prepared statements and the statements are preapred and kept and re used later. So the query which take s more time might be prepared before 48 hours or so.
- This is not happening every day. Many times the pattern is , it happens after 60-72 hours after application is started.
Sunil

Loading into the Infipackages takes lot of time

Hi Friends,
When i schedule and activate the process chain everyday, it takes lot of time to get loaded in the infopackages, around 5 to 6 hours.
in st13 when i click on the Log id name to see the process chain.
in the LOAD DATA infopackage it shows green, after double clicking on that, process moniter
i see request still running and its yellow but 0 from 0 records.
and this will be the same for hours
Its very slow.
need your guidence on this
Thanks for your help.

Hi,
What are you trying to load using this process chain? If it is cube, are you deleting the indexes on the cube before starting the load. If not, include that step as well in the process chain. This will help in getting improved performance.
Ideally it is always a good practice to delete the indexes before loading.
Regards,
Yogesh

Read cluster PCL4 .. takes lot of time

Hi guys,
Though I Know this is a functional related forum, i would want to post techincal question related HR ABAP.
I have a report that needs to read data from PCL4 cluster and display master data changes for an employee. Developed a big program to simulate "RPUAUD00" that displays the logged data.
My concenr is the program that i developed is taking minutes to execute. I am using the 2 function modules "HR_INFOTYPE_LOG_GET_LIST" and "HR_INFOTYPE_LOG_GET_DETAIL" for this purpose.
The function module "HR_INFOTYPE_LOG_GET_LIST" takes lot of time to get executed as it checks all the personnel number with hanges even if there was only one personnel number that was changed. Assuming that my personnel area and personnel sub area has 2000 employees, even if one employee's data is changed, the function module reads the cluster for all the employee and takes a few minutes to comeback, before the function module "HR_INFOTYPE_LOG_GET_DETAIL" is executed to get the exact details changerd. This is irritating the client. Any idea how to reduce the time as i am severely short of ideas as how to.
regards
Sam

Unless you pass the exact pernr, the function cannot determine without looking at all the pernrs for changes..If your program tied to PNP, you can improve the run time passing the pernr list to the function call HR_INFOTYPE_LOG_GET_LIST..
~Suresh

Hierarchical tree take lot of time to populate

Hello fellows
I have a form using hierarchical list. when populate it from the record group it take lot of time.
this record group is using four loops and outer loop range is from 1 to 3000 and all inner loops range is from 1 to 3,
Oracle.exe get time of 1 minute to populate record group and ifrun60.exe get time of 5 minutes to display tree.
have you any suggestion to improve the performance of this form

Hi all
In order to populate tree faster its better not to populate it using Record Group.
use the htree fucntions for parent and child nodes in the populate tree trigger or When node selected trigger.
Ahsan

Sun Studio 12 takes lot of time to startup

Hi,
When I try to use sunstudio 12 on a Solaris 10 U6 x86 box, it takes ages to open the UI window.
The window kind of hung state with out any messges showing in it until it comes up with full screen.
Debugging from sunstudio takes lot of time when we try step to the code.
Is this a known issue?. Any workaround?.
The Solaris system has 8GB RAM and plenty of disk space.
Thanks

Thank you for the report! No, it is not a known issue.
I use Sun Studio IDE on Solaris 10 x86 system with 2 Gb memory.
Its responsiveness is ok (though sometimes it parses my projects
for 10-20 seconds, but it happens only 2-3 times per day).
The "startup" time is about 20-30 seconds.
Let's try to find out what is the problem on your system.
Can you run "sunstudio" under "truss -d" and look at the log file?
Here is the command:
truss -d -a -e -f -o ss.tr sunstudio --userdir /tmp/newuserdir It will create a log file "ss.tr" in current directory. Open it in a text editor,
and look for long actions. Probably there is something in your HOME
directory, that causes these delays.
If you don't see anything suspicious, let me know. I'll take a look at the
log file (though it can be several Mb, so we have to find out how to send it).
Thanks,
Nik

FBL3N T-code takes lot of time to produced output.

Hi expert,
FBL3N T-code takes lot of time to produced output.
and many times accure TIME_OUT Runtime error.
REgards,

Hi Vivek,
When you run the T-code FBL3N , Monitor SM50 and check the tables and run the statistics on the specified tables using Db20 t-code.
Refer to below link for more information.
http://help.sap.com/saphelp_nwpi71/helpdata/en/45/d59f51b3735594e10000000a1553f7/content.htm
Also
Refer to Note 1135916 - Line items: Help for analysis for long runtime
Check whether a suitable database index has been created in the dictionary (transaction SE11 -> indexes). If no index has been created, create the corresponding index and activate it.
Possible fields may be:
BSIS/BSAS: MANDT, BUKRS, HKONT, BUDAT
BSIK/BSAK: MANDT, BUKRS, LIFNR, BUDAT
BSID/BSAD: MANDT, BUKRS, KUNNR, BUDAT
Regards,
Sravanthi
Edited by: Sravanthi.sap on Jan 9, 2012 10:17 PM

Application takes lot of time for first time..

Hai guys,
we made an application on a 3rd party software for use on a tool which connects to SAP with RFC.
the applicaiton updates ORACLE databse after getting relevant information from SAP.
Now,for information on SAP side we have RFC.
for updates on oracle we write SQL.
the unique problem is..this applicaiton takes lot of time when used the first time..
once the first use is over it takes much lesser time for any subsequent use(by any user)..
I DOUBT THE SQLS(ESP UPDATE) TAKE MUCH TIME THE FIRST TIME.

I DOUBT THE SQLS(ESP UPDATE) TAKE MUCH TIME THE FIRST TIME.
Why don't you trace the call and be sure? Don't guess.
once the first use is over it takes much lesser time for any subsequent use(by any user)..
Because the statement is in the cursor cache - clear the cache each time and the statement will run long every time. Again, trace the call and determine the issue - most likely you need an index or have an improperly coded SELECT statement.

Query from source table takes lots of time

Similar Messages

Maybe you are looking for