Inserting data takes long time

Hi,
when I am insterting data in my application it's took very long time. can anybody tell me where is the problem why it's taking very long time.
Thanks in advance

What kind of replication r u using?
if it is streams then below metalink docs will help u.
goodluck
Subject:      Streams Performance Recommendations
     Doc ID:      Note:335516.1
REFERENCES
Note 298877.1 10g Streams Recommended Configuration
Note 259609.1 Script to Prevent Excessive Spill of Message From
the Streams Buffer Queue To Disk
Note 273674.1 Streams Configuration Report and Health Check Script
Note 290605.1 Oracle Streams STRMMON Monitoring Utility
Note 238455.1 Streams Supported and Unsupported Datatyp

Similar Messages

  • Insert query takes long time

    Hi,
    I have written a procedure that does the following :
    1- Creates a temp table
    2- INSERT /*+ append */ INTO <temp table>
    (Select ......,
    (select sum(amt)
    from tbl1 b
    where b.col1=a.col2 and b.col3=a.col3 and (b.col4=a.col4 OR b.col5=a.col5) ...
    grp by col1,col2,col3),
    from tbl1 a
    where a.col1=.................
    3- Query to delete the duplicate rows from the temp table....
    4- Populate summarized data from TEMP TABLE to tbl1
    5- drops the temp table.
    Now this procedure takes around 2-3 mins for 2lakh records on local db, but when executed on production db takes 4 hours, when called from the application.
    When the log was reviewed it took 4 hours just to insert the data into TEMP TABLE.
    (*Note: this problem occurs only after executing the procedure for continuously 1 week or so. When the bea server is restarted and the application is run, it works fine. but after few days again the performance detiorates.
    What could be the reason for this weird problem?!!! Please give me some tips, which can help me to figure out the problem.
    Thanks
    Shruts.

    **I have renamed the cols and table.
    CREATE OR REPLACE PROCEDURE PROC_TEST(p_1 IN number,p_2 IN number,p_3 IN varchar2)
    is
    vsql varchar2(5000);
    Error_Message varchar2(200);
    vcalc varchar2(150);
    v_rec_present number;
    begin
         SELECT nvl(count(*),0) into v_rec_present
         FROM USER_TABLES
         WHERE upper(TABLE_NAME)=upper('TMP_TEST');
         if v_rec_present>0 then
         EXECUTE IMMEDIATE 'DROP table TMP_TEST';
         end if;
         EXECUTE IMMEDIATE 'CREATE TABLE TMP_TEST as select * from TBL1 where 1=2';
         vsql:= 'select distinct NULL as col1,a.scol2,a.ncol3,a.scol4, a.ncol5,a.scol6,a.dcol7,a.dcol8,null as dcol9,a.scol10,';
         vsql:=vsql||' nvl((select sum(t.amount) as TOTAL_AMT ';
         vsql:=vsql||' from TBL1 t';
         vsql:=vsql||' where t.ncol3='||p_1;
         vsql:=vsql||' and t.ncol3=a.ncol3';
         vsql:=vsql||' and t.scol4=a.scol4 and t.scol10=a.scol10 ';
         vsql:=vsql||' and (t.ncol5=a.ncol5 OR t.scol6=a.scol6)';
         vsql:=vsql||' and t.ncol11=a.ncol11      and t.ccol12=a.ccol12';
         vsql:=vsql||' and t.dcol7=a.dcol7 and t.dcol8=a.dcol8';     
         vsql:=vsql||' group by t.ncol3,t.scol4,';
         vsql:=vsql||' t.dcol7,t.dcol8, t.scol10,t.ncol11, t.ccol12),0) as amount,';
         vsql:=vsql||' a.ccol12,a.ncol11,';
         vsql:=vsql||' a.ncol13, null as ncol14, null as scol15, null as dcol16, null as scol17, null as scol18,';
         vsql:=vsql||' a.scol19, a.ccol20,a.sUser, sysdate as date_ins, a.site_ins,null as description';
         vsql:=vsql||' from TBL1 a';
         vsql:=vsql||' where a.ncol3='||p_1;
         if p_2=1 then
         vcalc:=' SYSDATE ';
         else
              vcalc:='to_date((to_char(to_date('''||p_3||''',''dd-mon-yyyy hh:mi:ss am''),''mm/dd/yyyy'') ) ,''mm/dd/yyyy'')' ;
         end if;
         vsql:=vsql||' and (case when a.ccol20=''TC'' and a.ccol12=''R''';
         vsql:=vsql||' then (case when '||p_2||'=0 and to_date(to_char(a.dcol9,''mm/dd/yyyy''),''mm/dd/yyyy'')='||vcalc;
         vsql:=vsql||' then ''TRUE'' ELSE ''FALSE'' END)';
         vsql:=vsql||' else ''TRUE'' END)=''TRUE''';
         /* if accrual flag=0 and calcenddt<>NULL then */
         if p_2=0 and p_3 is not NULL then
              vsql:=vsql||' and (a.dcol9 is null oR     (to_char(a.dcol9,''YYYY'')<=to_char(sysdate,''YYYY'') and';
              vsql:=vsql||' to_date(to_char(a.dcol9,''mm/dd/yyyy hh24:mi:ss''),''mm/dd/yyyy hh24:mi:ss'')<=to_date((to_char(to_date('''||p_3||''',''dd-mon-yyyy hh:mi:ss am''),''mm/dd/yyyy'') || ''23:59:59'') ,''mm/dd/yyyy hh24:mi:ss'')))';
         elsif p_2=1 then
              vsql:=vsql||' and (a.dcol9 is null oR     ((to_char(a.dcol9,''YYYY'')<=to_char(sysdate,''YYYY'') or';
              vsql:=vsql||' to_char(a.dcol9,''YYYY'')>to_char(sysdate,''YYYY''))))';
    end if;
    vsql:= 'INSERT /*+ append */ INTO TMP_TEST '|| vsql;
    EXECUTE IMMEDIATE vsql;
    EXECUTE IMMEDIATE 'truncate table TBL1';
    EXECUTE IMMEDIATE 'INSERT INTO TBL1 SELECT * FROM TMP_TEST';
    EXECUTE IMMEDIATE 'DROP table TMP_TEST';
    vsql:='DELETE from TBL1 a';
    vsql:=vsql||' where a.ncol3='||p_1;
    vsql:=vsql||' and ROWID<>(select min(ROWID)';
    vsql:=vsql||' from TBL1 b';
    vsql:=vsql||' where (a.scol6=b.scol6 OR a.ncol5=b.ncol5)';
    vsql:=vsql||' AND b.ncol3='||p_1;
    vsql:=vsql||' and a.ncol3=b.ncol3 and a.scol4=b.scol4 and a.scol10=b.scol10';
    vsql:=vsql||' and a.dcol7=b.dcol7';
    vsql:=vsql||' and a.dcol8=b.dcol8';
    vsql:=vsql||' and a.ccol12=b.ccol12 and a.ncol11=b.ncol11';
    vsql:=vsql||' group by a.scol4,a.dcol7,a.dcol8,a.scol10,a.ccol12,a.ccol20)';
    EXECUTE IMMEDIATE vsql;
    EXCEPTION
         WHEN OTHERS THEN
              Error_Message := 'Error in executing SP "PROC_TEST" '|| chr(10) ||'Error Code is ' || SQLCODE || Chr(10) || 'Error Message is ' || SQLERRM;
              dbms_output.put_line ('ERROR:-'||Error_message);
              raise;
    end;
    ******************************************************************************************

  • Takes Long time for Data Loading.

    Hi All,
    Good Morning.. I am new to SDN.
    Currently i am using the datasource 0CRM_SRV_PROCESS_H and it contains 225 fields. Currently i am using around 40 fields in my report.
    Can i hide the remaining fields in the datasource level itself (TCODE : RSA6)
    Currently data loading takes more time to load the data from PSA to ODS (ODS 1).
    And also right now i am pulling some data from another ODS(ODS 2)(LookUP). It takes long time to update the data in Active data table of the ODS.
    Can you please suggest how to improve the performance of dataloading on this Case.
    Thanks & Regards,
    Siva.

    Hi....
    Yes...u can hide..........just Check the hide box for those fields.......R u in BI 7.0 or BW...........whatever ........is the no of records is huge?
    If so u can split the records and execute............I mean use the same IP...........just execute it with different selections.........
    Check in ST04............is there are any locks or lockwaits..........if so...........Go to SM37 >> Check whether any Long running job is there or not.........then check whether that job is progressing or not............double click on the Job >> From the Job details copy the PID..............go to ST04 .....expand the node............and check whether u r able to find that PID there or not.........
    Also check System log in SM21............and shortdumps in ST04........
    Now to improve performance...........u can try to increase the virtual memory or servers.........if possiblr........it will increase the number of work process..........since if many jobs run at a time .then there will be no free Work prrocesses to proceed........
    Regards,
    Debjani......

  • INSERT INTO TABLE using SELECT takes long time

    Hello Friends,
    --- Oracle version 10.2.0.4.0
    --- I am trying to insert around 2.5 lakhs records in a table using INSERT ..SELECT. The insert takes long time and seems to be hung.
    --- When i try to SELECT the query fetches the rows in 10 seconds.
    --- Any clue why it is taking so much time

    vishalrs wrote:
    Hello Friends,hello
    >
    >
    --- Oracle version 10.2.0.4.0
    alright
    --- I am trying to insert around 2.5 lakhs records in a table using INSERT ..SELECT. The insert takes long time and seems to be hung.
    I don't know how a lakh is, but it sounds like a lot...
    --- When i try to SELECT the query fetches the rows in 10 seconds.
    how did you test this? and did you fetch the last record, or just the first couple of hundred.
    --- Any clue why it is taking so much timeWithout seeing anything, it's impossible to tell the reason.
    Search the forum for "When your query takes too long"

  • HT4759 Hello .. I've been subscribed for ic;oud for 20$ per year and I found it useless for many reasons: that I can not disconnect my mobile while the uploading process and it takes long time for uploading my data .. Its not a reliable system that's why

    Hello .. I've been subscribed for ic;oud for 20$ per year and I found it useless for many reasons: that I can not disconnect my mobile while the uploading process and it takes long time for uploading my data .. Its not a reliable system that's why I need to deactivate the space service and take my money back .. Thanks

    The "issues" you've raised are nothing to do with the iCloud service.
    No service that uploads data allows you to disconnect the device you are uploading from while uploading data. Doing so would prevent the upload from completing. It is a basic requirement for any uploading service that you remain connected to it for uploading to be possible.
    The time it takes to upload data to iCloud is entirely dependent on how fast your Internet connection is, and how much data you are uploading. Both of these things are completely out of Apple's control. Whichever upload service you use will be affected by the speed of your Internet connection.

  • MVIEW refresh takes long time

    Materialized view takes long time to refresh but when i tried select & insert into table it's very fast.
    i executed SQL and it takes ust 1min ( total rows is 447 )
    but while i refresh the MVIEW it takes 1.5 hrs ( total rows is 447 )
    MVIEW configration :-
    CREATE MATERIALIZED VIEW EVAL.EVALSEARCH_PRV_LWC
    TABLESPACE EVAL_T_S_01
    NOCACHE
    NOLOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD DEFERRED
    REFRESH FORCE ON DEMAND
    WITH PRIMARY KEY
    Not sure why so much diffrence

    infant_raj wrote:
    Materialized view takes long time to refresh but when i tried select & insert into table it's very fast.
    i executed SQL and it takes ust 1min ( total rows is 447 )
    but while i refresh the MVIEW it takes 1.5 hrs ( total rows is 447 )A SELECT does a consistent read.
    A MV refresh does that and also writes database data.
    These are not the same thing and cannot be directly compared.
    So instead of pointing at the SELECT execution time and asking why the MV refresh is not as fast, look instead WHAT the refresh is doing and HOW it is doing that.
    Is the execution plan sane? What events are the top ones for the MV refresh? What are the wait states that contributes most to the processing time of the refresh?
    You cannot use the SELECT statement's execution time as a direct comparison metric. The work done by the refresh is more than the work done by the SELECT. You need to determine exactly what work is done by the refresh and whether that work is done in a reasonable time, and how other sessions are impacting the refresh (it could very well be blocked by another session).

  • BPM Process chain takes long time to process

    We have BI7, Netweaver 2004s on Oracle and SUN Solaris
    There is a process chain (BPM) which pulls data from the CRM system into BW. The scheduled time to run this chain is 0034 hrs. This chain should ideally complete before / around 0830 Hrs. <b>Now the problem is that every alternate day this chain behaves normally and gets completed well before 0830 hrs but every alternate day this chain fails…</b> there are almost 40 chains running daily. Some are event triggered (dependent with each other) or some run in parallel. In this, (BPM) process chain, usually there are 5 requests with 3 Delta and 2 full uploads (Master Data). The delta uploads finishes in 30 minutes without any issues with very few record transfers. The first full upload is from 0034 hrs to approximately 0130 hrs and the 2nd upload is from 0130 hrs to 0230 hrs. Now if the 1st upload gets delayed then the people who are initiating these chains, stop the 2nd full upload and continue it after all the process chains are completed. Now this entire BPM process chain sometimes takes 17 -18 hrs to complete!!!!!
    No other loads in CRM or BW when these process chains are running
    CRM has background jobs to push IDOCS to BW which run every 2 minutes which runs successfully
    Yesterday this chain got completed successfully (well within stipulated time) with over 33,00,000 records transferred but sometimes it has failed to transfer even 12,00,000 records!!
    Attaching a zip file, please refer the “21 to 26 Analysis screen shot.doc” from the zip file
    Within the zip file, attaching “Normal timings of daily process chains.xls” – the name explains it….
    Also within the zip file refer “BPM Infoprovider and data source screen shot.doc” please refer this file as the infopackage (page 2) which was used in the process chain is not displayed later on in page number 6 BUT CHAIN GOT SUCESSFULLY COMPLETED
    We have analyzed:--
    1)     The PSA data for BPM process chain for past few days
    2)     The info providers for BPM process chain for past few days
    3)     The ODS entries for BPM process chain for past few days
    4)     The point of failure of BPM process chain for past few days
    5)     The overall performance of all the process chains for past few days
    6)     The number of requests in BW for this process chain
    7)     The load on CRM system for past few days when this process chain ran on BW system
    As per our analysis, there are couple of things which can be fixed in the BW system:--
    1)     The partner agreement (transaction WE20) defined for the partner LS/BP3CLNT475 mentions both message types RSSEND and RSINFO: -- collect IDOCs and pack size = 1 Since the pack size = 1 will generate 1 TRFC call per IDOC, it should be changed to 10 so that less number of TRFCs will be generated thus less overhead for the BW server resulting in the increase in performance
    2)     In the definition of destination for the concerned RFC in BW (SM59), the “Technical Setting” tab says the “Load balancing” option = “No”. We are planning to make it “Yes”
    But we believe that though these changes will bring some increase in performance, this is not the root cause of the abnormal behavior of this chain as this chain runs successfully on every alternate day with approximately the same amount of load in it.
    I was not able to attach the many screen shots or the info which I had gathered during my analysis. Please advice how do I attach these files
    Best Regards,

    Hi,
    Normally  index  creation or deletion can take long time in case  your database statistics are not updated properly, so can check  stat  after your data loading is completed and index generation is done,  Do creation of database statistics.
    Then try to recheck ...
    Regards,
    Satya

  • The 0co_om_opa_6 ip in the process chains takes long time to run

    Hi experts,
    The 0co_om_opa_6 ip in the process chains takes long time to run around 5 hours in production
    I have checked the note 382329,
    -> where the indexes 1 and 4 are active
    -> index 4 was not "Index does not exist in database system ORACLE"- i have assgined to " Indexes on all database systems and ran the delta load in development system, but guess there are not much data in dev it took 2-1/2 hrs to run as it was taking earlier. so didnt find much differnce in performance.
    As per the note Note 549552 - CO line item extractors: performance, i have checked in the table BWOM_SETTINGS these are the settings that are there in the ECC system.
    -> OLTPSOURCE -  is blank
       PARAM_NAME - OBJSELSIZE
       PARAM_VALUE- is blank
    -> OLTPSOURCE - is blank
       PARAM_NAME - NOTSSELECT
       PARAM_VALUE- is blank
    -> OLTPSOURCE- 0CO_OM_OPA_6
       PARAM_NAME - NOBLOCKING
       PARAM_VALUE- is blank.
    Could you please check if any other settings needs to be done .
    Also for the IP there is selction criteris for FISCALYEAR/PERIOD from 2004-2099, also an inti is done for the same period as a result it becoming difficult for me to load for a single year.
    Please suggest.

    The problem was the index 4 was not active in the database level..it was recommended by the SAP team to activate it in se14..however while doing so we face few issues se14 is a very sensitive transaction should be handled carefully ... it should be activate not created.
    The OBJSELSIZE in the table BWOM_SETTINGS has to be Marked 'X' to improve the quality as well as the indexe 4 should be activate at the abap level i.e in the table COEP -> INDEXES-> INDEX 4 -> Select the  u201Cindex on all database systemu201D in place of u201CNo database indexu201D, once it is activated in the table abap level you can activate the same indexes in the database level.
    Be very carefull while you execute it in se14 best is to use db02 to do the same , basis tend to make less mistake there.
    Thanks Hope this helps ..

  • Delete Index in Process Chain Takes long time after SAP BI 7.0 SP 27

    After upgrading to SAP BI 7.0 SP 27 Delete index Process & Create index process in Process chain takes long time.
    For example : Delete index for 0SD_C03 takes around 55 minutes.
    Before SP upgrade it takes around 2 minutes to delete index from 0SD_C03.
    Regards
    Madhu P Menon

    Hi,
    Normally  index  creation or deletion can take long time in case  your database statistics are not updated properly, so can check  stat  after your data loading is completed and index generation is done,  Do creation of database statistics.
    Then try to recheck ...
    Regards,
    Satya

  • SELECT statement takes long time

    Hi All,
    In the following code, if the T_QMIH-EQUNR contains blank or space values ,SELECT statement takes longer time to acess the data from OBJK table. If it T_QMIH-EQUNR contains values other than blank, performance is good and it fetches data very fast.
    Already we have indexes for EQUNR in OBJK table.
    Only for blank entries , it takes much time.Can anybody tell why it behaves for balnk entries?
    if not T_QMIH[] IS INITIAL.
            SORT T_QMIH BY EQUNR.
            REFRESH T_OBJK.
            SELECT EQUNR OBKNR
              FROM OBJK INTO TABLE T_OBJK
              FOR ALL ENTRIES IN T_QMIH
              WHERE OBJK~TASER = 'SER01' AND
             OBJK~EQUNR = T_QMIH-EQUNR.
    Thanks
    Ajay

    Hi
    You can use the field QMIH-QMNUM with OBJK-IHNUM
    in QMIH table, EQUNR is not primary key, it will have multiple entries
    so to improve the performance use one dummy internal table for QMIH  and sort it on EQUNR
    delete adjacent duplicates from d_qmih and use the same in for all entries
    this will improve the performance.
    Also use the fields in sequence of the index and primary keys also in select
    if not T_QMIH[] IS INITIAL.
    SORT T_QMIH BY EQUNR.
    REFRESH T_OBJK.
    SELECT EQUNR OBKNR
    FROM OBJK INTO TABLE T_OBJK
    FOR ALL ENTRIES IN T_QMIH
    WHERE  IHNUM =  T_QMIH-QMNUM
    OBJK~TASER = 'SER01' AND
    OBJK~EQUNR = T_QMIH-EQUNR.
    try this and let me know
    regards
    Shiva

  • Oracle report formatting takes long time

    hi
    i am using oracle 10g Application Server 9.0.4.0.0 on Red hat linux AS 3
    oracle reports are run thru JSP's
    some reports take long time to execute though query in it if executed on sql plus are fast.
    it is fond that that formatting is going on for those reports
    what might be the reason for this??
    is the data fetched first and then formatting takes place as per data??
    waiting for reply
    Avinash

    hi
    i am using oracle 10g Application Server 9.0.4.0.0 on Red hat linux AS 3
    oracle reports are run thru JSP's
    some reports take long time to execute though query in it if executed on sql plus are fast.
    it is fond that that formatting is going on for those reports
    what might be the reason for this??
    is the data fetched first and then formatting takes place as per data??
    waiting for reply
    Avinash

  • Runbook takes long time to complete

    Hi,
    I created a customized flow to get the data from MS SQL. The runbook is working fine but it takes long time to complete. Is there any option to increase speed or something like that..?
    Regards,
    Soundarajan.

    If you look on the Log tab you can see which activity that took the longest. What does you runbook looks like? If you have for example a Run .NET script activity you can do some tuning on the runbook server. But I think a good start is to share a
    figure of your runbook.
    Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se

  • Procedure takes long time to execute...

    Hi all
    i wrote the proxcedure but it takes long time to execute.
    The INterdata table contains 300 records.
    Here is the procedure:
    create or replace procedure inter_filter
    is
         /*v_sessionid interdata.sessionid%type;
         v_clientip interdata.clientip%type;
         v_userid interdata.userid%type;
         v_logindate interdata%type;
         v_createddate interdata%type;
         v_sourceurl interdata%type;
         v_destinationurl interdata%type;*/
         v_sessionid filter.sessionid%type;
         v_filterid filter.filterid%type;
         cursor c1 is
         select sessionid,clientip,browsertype,userid,logindate,createddate,sourceurl,destinationurl
         from interdata;
         cursor c2 is
         select sessionid,filterid
         from filter;
    begin
         open c2;
         loop
              fetch c2 into v_sessionid,v_filterid;
              for i in c1 loop
                   if i.sessionid = v_sessionid then
                        insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                        values (filterdetail_seq.nextval,v_filterid,i.sourceurl,i.destinationurl,i.createddate);
                   else
                        insert into filter (filterid,sessionid,clientip,browsertype,userid,logindate,createddate)
                        values (filter_seq.nextval,i.sessionid,i.clientip,i.browsertype,i.userid,i.logindate,i.createddate);
                        insert into filterdetail(filterdetailid,filterid,sourceurl,destinationurl,createddate)
                        values (filterdetail_seq.nextval,filter_seq.currval,i.sourceurl,i.destinationurl,i.createddate);
                   end if;
              end loop;
         end loop;
         commit;
    end
    Please Help!
    Prathamesh

    i wrote the proxcedure but it takes long time to execute.Please define "long time". How long does it take? What are you expecting it to take?
    The INterdata table contains 300 records.But how many records are there in the FILTER table? As this is the one you are driving off this is going to determine the length of time it takes to complete. Also, this solution inserts every row in the INTERDATA table for each row in the FILTER table - in other words, if the FILTER table has twenty rows to start with you are going to end up with 6000 rows in FILTERDETAIL. No wonder it takes a long time. Is that want you want?
    Also of course, you are using PL/SQL cursors when you ought to be using set operations. Did you try the solution I posted in Re: Confusion in this  scenario>>>>>>> on this topic?
    Cheers, APC

  • Full GC takes long time

    Hello,
    Since the last two weeks, we're experiencing Full GCs that take long time and block our application.
    Our platform is:
    Windows 2003 Server 64 bit
    Tomcat 6.0.18
    Java 1.6.0_u13.
    Total memory: 8Gb.
    -Xms4096m
    -Xmx6144m
    -Xss256k
    Old generation: min 2,66Gb max 4,0G
    Eden generation: min 1,5Gb max 2,0G
    Perm generation: min 57Mb max 84Mb
    Here a piece of our gc.log:
    21601.266: [GC [PSYoungGen: 2009225K->6206K(1942528K)] 3913618K->1913365K(4738752K), 0.0992347 secs] [Times: user=0.16 sys=0.03, real=0.11 secs]
    21611.268: [GC [PSYoungGen: 1942485K->5485K(1879040K)] 3849645K->1914490K(4675264K), 0.0986129 secs] [Times: user=0.11 sys=0.00, real=0.11 secs]
    21618.350: [GC [PSYoungGen: 1879021K->12392K(2060928K)] 3788026K->1930794K(4857152K), 0.2036000 secs] [Times: user=0.14 sys=0.02, real=0.20 secs]
    21624.869: [GC [PSYoungGen: 1935116K->8545K(2065600K)] 3853519K->1930702K(4861824K), 0.0924182 secs] [Times: user=0.05 sys=0.00, real=0.09 secs]
    21624.961: [Full GC (System) [PSYoungGen: 8545K->0K(2065600K)] [PSOldGen: 1922156K->635750K(2796224K)] 1930702K->635750K(4861824K) [PSPermGen: 38643K->38643K(60992K)], 1.3719842 secs] [Times: user=1.09 sys=0.00, real=1.36 secs]
    21634.887: [GC [PSYoungGen: 2048500K->10395K(2078912K)] 2684250K->646145K(4875136K), 0.0180670 secs] [Times: user=0.02 sys=0.05, real=0.01 secs]
    21645.165: [GC [PSYoungGen: 2074007K->8120K(2003392K)] 2709758K->648930K(4799616K), 0.0176943 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
    25209.938: [GC [PSYoungGen: 1760190K->7344K(1707072K)] 4127764K->2376892K(4503296K), 0.0760053 secs] [Times: user=0.11 sys=0.03, real=0.06 secs]
    25218.120: [GC [PSYoungGen: 1707056K->10511K(1657728K)] 4076604K->2382964K(4453952K), 0.0704081 secs] [Times: user=0.13 sys=0.00, real=0.08 secs]
    25221.680: [GC [PSYoungGen: 1657679K->5731K(1982400K)] 4030132K->2385544K(4778624K), 0.0985384 secs] [Times: user=0.20 sys=0.00, real=0.09 secs]
    25226.968: [GC [PSYoungGen: 993426K->6083K(1982784K)] 3373239K->2389543K(4779008K), 0.5147901 secs] [Times: user=0.08 sys=0.00, real=0.52 secs]
    25227.483: [Full GC (System) [PSYoungGen: 6083K->0K(1982784K)] [PSOldGen: 2383460K->536034K(2796224K)] 2389543K->536034K(4779008K) [PSPermGen: 39765K->38756K(58816K)], 155.4030025 secs] [Times: user=1.34 sys=0.64, real=155.39 secs]
    25389.833: [GC [PSYoungGen: 1976624K->12915K(2023616K)] 2512658K->566671K(4819840K), 13.1263397 secs] [Times: user=0.11 sys=0.03, real=13.13 secs]
    25405.871: [GC [PSYoungGen: 2023579K->13857K(2031552K)] 2577335K->583736K(4827776K), 3.5796784 secs] [Times: user=0.03 sys=0.00, real=3.58 secs]
    25416.490: [GC [PSYoungGen: 2024544K->9059K(2074944K)] 2594423K->587581K(4871168K), 0.1184355 secs] [Times: user=0.06 sys=0.00, real=0.13 secs]
    25425.393: [GC [PSYoungGen: 2064144K->7415K(2075456K)] 2642665K->590222K(4871680K), 0.0441002 secs] [Times: user=0.02 sys=0.00, real=0.05 secs]
    25438.547: [GC [PSYoungGen: 2062519K->8857K(2075264K)] 2645326K->594735K(4871488K), 0.0301620 secs] [Times: user=0.01 sys=0.00, real=0.03 secs]
    The minor collections go perfect.
    The first full GC in this piece of log takes 1,36s, and the old generation passes from 1922156K->635750K
    But the second full GC (1 hour later) blocks the server for 155.39s, and the old generation pases from 2383460K->536034K
    The server load between execution of full GC was similar. Any differences I saw in this two moments:
    first full gc: number of Tomcat http threads : 230. The full gc provokes that Tomcat start new threads until get 500 (maxThreads)
    second full gc: number of Tomcat http threads : 500.
    I'm not an expert in tunning jvm. If somebody could help me, these pauses are killing the app and it's unacceptable for my client (for 2 min. the app does not work).
    If you need more information (threads stack, histograms, ... I have ...)
    Maybe I need to reduce the size of the old generation? Or change the garbage collector for old generation? The server cpu is going well, I prefer to consume more cpu in gc and avoid this pauses.
    Any help will be very very appreciated.
    Thanks in advance,
    Joan.

    Hello,
    Sorry for my continuous replies. Another full gc has occurred. This is the trace:
    262631.531: [GC [PSYoungGen: 2071685K->10889K(2078464K)] 4711353K->2652961K(4874688K), 0.3392037 secs] [Times: user=0.08 sys=0.00, real=0.34 secs]
    262640.608: [GC [PSYoungGen: 2071978K->11055K(2078784K)] 4714051K->2656136K(4875008K), 1.3267436 secs] [Times: user=0.06 sys=0.00, real=1.33 secs]
    262649.880: [GC [PSYoungGen: 2072165K->17337K(2071872K)] 4717246K->2669454K(4868096K), 3.0493937 secs] [Times: user=0.16 sys=0.00, real=3.05 secs]
    262658.069: [GC [PSYoungGen: 2071865K->14678K(2075840K)] 4723982K->2676078K(4872064K), 5.4598301 secs] [Times: user=0.08 sys=0.03, real=5.45 secs]
    262666.592: [GC [PSYoungGen: 2069183K->15835K(2075776K)] 4730583K->2682691K(4872000K), 1.6894894 secs] [Times: user=0.11 sys=0.05, real=1.70 secs]
    262673.352: [GC [PSYoungGen: 2070620K->14122K(2068992K)] 4737476K->2687230K(4865216K), 2.9711981 secs] [Times: user=0.06 sys=0.03, real=2.97 secs]
    262682.891: [GC [PSYoungGen: 2068909K->10709K(2075712K)] 4742017K->2686673K(4871936K), 1.1160323 secs] [Times: user=0.19 sys=0.00, real=1.13 secs]
    262691.733: [GC [PSYoungGen: 2065941K->10683K(2075584K)] 4741905K->2689212K(4871808K), 1.4898942 secs] [Times: user=0.05 sys=0.00, real=1.50 secs]
    262701.512: [GC [PSYoungGen: 2065888K->9341K(2076480K)] 4744418K->2690073K(4872704K), 1.3835846 secs] [Times: user=0.13 sys=0.00, real=1.39 secs]
    262709.896: [GC [PSYoungGen: 2065601K->10718K(2076480K)] 4746334K->2693212K(4872704K), 0.7815897 secs] [Times: user=0.05 sys=0.01, real=0.78 secs]
    262718.681: [GC [PSYoungGen: 2067028K->10199K(2076672K)] 4749523K->2695508K(4872896K), 1.2951014 secs] [Times: user=0.06 sys=0.00, real=1.30 secs]
    262727.940: [GC [PSYoungGen: 2067345K->10112K(2076608K)] 4752654K->2698129K(4872832K), 1.6785345 secs] [Times: user=0.08 sys=0.00, real=1.69 secs]
    262736.092: [GC [PSYoungGen: 2067264K->10886K(2077184K)] 4755281K->2702237K(4873408K), 1.1985764 secs] [Times: user=0.06 sys=0.02, real=1.20 secs]
    262744.626: [GC [PSYoungGen: 2069382K->11366K(2077248K)] 4760733K->2705795K(4873472K), 1.4323653 secs] [Times: user=0.13 sys=0.00, real=1.44 secs]
    262754.913: [GC [PSYoungGen: 2069912K->11945K(2077824K)] 4764342K->2708689K(4874048K), 0.8340946 secs] [Times: user=0.03 sys=0.00, real=0.84 secs]
    262765.038: [GC [PSYoungGen: 2072283K->11669K(2077888K)] 4769028K->2711204K(4874112K), 1.3040060 secs] [Times: user=0.09 sys=0.02, real=1.31 secs]
    262776.885: [GC [PSYoungGen: 2072021K->9940K(2079360K)] 4771556K->2711919K(4875584K), 0.8646772 secs] [Times: user=0.09 sys=0.00, real=0.88 secs]
    262783.713: [GC [PSYoungGen: 1173115K->8659K(2079168K)] 3875094K->2713127K(4875392K), 1.4434465 secs] [Times: user=0.09 sys=0.00, real=1.45 secs]
    262785.157: [Full GC (System) [PSYoungGen: 8659K->0K(2079168K)] [PSOldGen: 2704467K->655075K(2796224K)] 2713127K->655075K(4875392K) [PSPermGen: 41376K->40988K(42048K)], 132.6088125 secs] [Times: user=1.47 sys=0.39, real=132.58 secs]
    262925.100: [GC [PSYoungGen: 2062280K->16892K(2068992K)] 2717355K->683188K(4865216K), 8.9491611 secs] [Times: user=0.13 sys=0.00, real=8.94 secs]
    262971.183: [GC [PSYoungGen: 2068978K->8052K(2074624K)] 2735273K->692990K(4870848K), 7.7833800 secs]
    When a "bad" full GC occurs, I can see that just before it the minor collections start to perform bad. Normal values for minor collections are 0,0x seconds, and before a "bad" full GC these minor collections take seconds (1, 2, ... up to 5 seconds).
    I can show an histogram of the first 25 entries before and after the full GC:
    BEFORE
    num #instances #bytes class name
    1: 226135 718455272 [I
    2: 1905686 637239584 [C
    3: 122775 621626112 [B
    4: 8218 538714736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
    5: 160974 445403288 [Ljava.lang.Object;
    6: 1759928 70397120 java.lang.String
    7: 334672 42838016 com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl
    8: 103592 42699248 [[I
    9: 227966 41945744 java.net.SocksSocketImpl
    10: 629974 35278544 com.vpfw.proxy.cache.data.B
    11: 636515 30552720 java.util.concurrent.ConcurrentHashMap$HashEntry
    12: 555354 26656992 java.util.HashMap$Entry
    13: 89059 18034280 [Ljava.util.HashMap$Entry;
    14: 230432 16591104 com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
    15: 225401 14425664 java.lang.ref.Finalizer
    16: 222588 14245632 java.net.SocketInputStream
    17: 334644 13385760 com.sun.org.apache.xerces.internal.dom.AttributeMap
    18: 386837 12378784 java.util.concurrent.ConcurrentLinkedQueue$Node
    19: 40226 11263504 [[Ljava.lang.Object;
    20: 21646 11246112 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
    21: 684613 10953808 java.lang.Object
    22: 227958 9118320 java.net.Socket
    23: 218591 8743640 java.net.Inet4Address
    24: 57810 8730528 <constMethodKlass>
    25: 230658 7381056 java.io.FileDescriptor
    AFTER
    num #instances #bytes class name
    1: 91917 650028776 [B
    2: 1767088 612264368 [C
    3: 176313 581838552 [I
    4: 141278 322132688 [Ljava.lang.Object;
    5: 1762956 70518240 java.lang.String
    6: 367122 46991616 com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl
    7: 239506 44069104 java.net.SocksSocketImpl
    8: 633882 35497392 com.vpfw.proxy.cache.data.B
    9: 639797 30710256 java.util.concurrent.ConcurrentHashMap$HashEntry
    10: 606366 29105568 java.util.HashMap$Entry
    11: 72730 20521256 [[I
    12: 89136 18497696 [Ljava.util.HashMap$Entry;
    13: 252946 18212112 com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
    14: 236339 15125696 java.lang.ref.Finalizer
    15: 233891 14969024 java.net.SocketInputStream
    16: 366906 14676240 com.sun.org.apache.xerces.internal.dom.AttributeMap
    17: 429913 13757216 java.util.concurrent.ConcurrentLinkedQueue$Node
    18: 43319 12129544 [[Ljava.lang.Object;
    19: 719233 11507728 java.lang.Object
    20: 21649 11246408 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
    21: 239498 9579920 java.net.Socket
    22: 143 9317736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
    23: 229531 9181240 java.net.Inet4Address
    24: 57817 8735944 <constMethodKlass>
    25: 242443 7758176 java.io.FileDescriptor
    The big differencies is the "com.sun.org.apache.xpath.internal.objects.XObject;".
    Before and after, the values are:
    4: 8218 538714736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
    22: 143 9317736 [Lcom.sun.org.apache.xpath.internal.objects.XObject;
    Could this the cause of the full GC that takes long time?
    Thanks,
    Joan.

  • Report execution takes long time

    Dear all,
    we have a report which takes long time to exceute due to select statement.. here is the code..
    SELECT vkorg vtweg spart kunnr kunn2 AS division FROM knvp
        INTO CORRESPONDING FIELDS OF TABLE hier
        WHERE kunn2 IN s_kunnr
        AND   vkorg EQ '0001'
        AND   parvw EQ 'ZV'.
        l_parvw = 'WE'.
    SORT hier.
    * select all invoices within the specified invoice creation dates.
      CHECK NOT hier[] IS INITIAL.
      SELECT vbrk~vbeln vbrk~fkart vbrk~waerk vbrk~vkorg vbrk~vtweg vbrk~spart vbrk~knumv
             vbrk~konda vbrk~bzirk vbrk~pltyp vbrk~kunag vbrp~vbeln vbrp~aubel vbrp~posnr
             vbrp~fkimg vbrp~matnr vbrp~prctr vbpa~kunnr
             vbrp~pstyv vbrp~uepos
             vbrp~kvgr4  vbrp~ean11          
        INTO CORRESPONDING FIELDS OF TABLE it_bill
        FROM vbrk INNER JOIN vbrp ON vbrp~vbeln = vbrk~vbeln
                  INNER JOIN vbpa ON vbpa~vbeln = vbrk~vbeln
        FOR ALL entries IN hier
        WHERE (lt_syntax)
        AND   vbrk~vbeln IN s_vbeln
    *    AND   vbrk~erdat IN r_period
        AND   vbrk~fkdat IN r_period       
        AND   vbrk~rfbsk EQ 'C'
        AND   vbrk~vkorg EQ hier-vkorg
        AND   vbrk~vtweg EQ hier-vtweg
        AND   vbrk~spart EQ hier-spart.
    Can anyone say about how to reduce the execution time.?
    Edited by: Thomas Zloch on Sep 22, 2010 2:46 PM - please use code tags

    Hi
    first of all never use move corressponding.
    Rather you should declare a work area for table hier.
    select values into the work area and then append that workarea into the table hier.
    In case of for all entries include all the primary keys in the selection and for the keys which are of no use declare constants with initial valules like:
    'prmkey' is a primary field for table 'tab1' .
    Constants: field1 type tab1-prmkey value initial.
    and then in your where condition write.
    prmkey GE field1.
    I hope it is clear to you now.
    Thanks
    lalit Gupta

Maybe you are looking for

  • Mini Won't Boot - 2006 Core Duo 1.83GHz

    After 3.5 trouble free years and about 1 year after upgrading the RAM to 2 GB my Mac mini (Snow Leopard with latest update) has been playing up at startup. The problem started with the revolving 'gear' stopping and nothing else happening forcing me t

  • Creation of Outbound delivery with respect to sales order

    Hi Gurus, I am an Abaper. I have a requirement to create outbound delivery with respect to sales order. Currently I have the purchase order details.   My coordinator has given me a logic. From the Purchase order, we have to get the Purchase requisiti

  • SO_OBJECT_SEND??

    HI I want to know that what exactly is the purpose of the function module --> SO_OBJECT_SEND. And how can I test this FM in my server? Also where to check the e-mails of a person in SAP? Thanks

  • Syncing pictures question

    Since I switched to the iPhone 4, when I do a sync, it does not sync pictures from my camera roll to my PC. It syncs every other folder that I have in "Pictures", but it does not sync Camera Roll to my PC. This may be obvious but not to me. What am I

  • How to call java files from different directories

    hi, how do i call java files from a different directory?? let say i got partA.java, and i need to include functions from partB.java which is in a different folder. how can i do that?