Export of instance takes long time

Hi,
we're exporting an instance of a 10g database and it takes incredible long time. The dba told me, he sees wait/io on db file sequential read.
I've tried to break the issue down on the OS side (Solaris 10 U09 Sparc,Generic_147440-09 ). The process ora_dw01_testinstance is doing all the work reading the source.
It uses 8k preads. Between 500 - 700 iops are transferred to the storage and replied, with a transfer rate from 5 - 8 mb/sec. Disk latency is around 4 - 10 ms.
When looking on the microstats of the process it's mainly on sleep (over 90 %) . I've started 3 dd calls with different blocksizes on different db files in the same filesystem. Although the files have not been in any cache, the storage delivered around 70 - 85 mb/sek, even with a 8k blocksize. Well, the latency was much more higher when the dd processes were running. But I'm still wondering why the export is working that poor.
Are there ways to get the read phase of the export improved?
thank you,
solst_ice
Edited by: 892620 on Nov 17, 2012 5:49 AM
Edited by: 892620 on Nov 17, 2012 6:00 AM

First off, which export utility are you using: expdp or exp? What parameters have been specified? Also 10g is a marketing lable and not a version of Oracle so what is the exact version of Oracle in use? There are more than 60 reports on Oracle support about datapump performance issues but most are Oracle version and feature specific.
If using datapump the following support document should be of interest:
Checklist For Slow Performance Of DataPump Export (expdp) And Import (impdp) [ID 453895.1]
If using exp then did you provide a buffer= parameter?
HTH -- Mark D Powell --

Similar Messages

  • Problem Export to Excel it takes long time and Takes more space.

    Hello All,
    when we export to Excel in portal(reports), it takes long time and it takes more space.
    how to overcome this problem please any one knows provide the proper solution for this issues
    Regards,
    Ch.

    Hi Chetans,
    I have had the same problem, and I had to create a OSS message to SAP in order to solve this issue, until now I don't have an answer. They made me to change a lot of configuration in Java and BW without luck. To tell you more, when we try to export to excel the java instance restarts aumotatically.
    But we have this problem, when we try to export a huge quantity of data, so I found a note which says the limitation of exporting to excel. Take a special attention to the Performance section.
    Note 1178857
    [https://service.sap.com/sap/support/notes/1178857|https://service.sap.com/sap/support/notes/1178857]
    I recomend you that you create a message to SAP. If you find a solution, please let me know.
    Regards, Federico

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

  • Normal is takes long time

    Dear Experts, i tried to enable audit option in oracle 10.2 .0 database which is running on windows box, after set this command , i tried to restart the DB with shutdown (only) option.
    ALTER SYSTEM SET audit_trail=db SCOPE=SPFILE;
    but its takes long time to complete i checked the alert log file , its showing
    ALTER SYSTEM SET audit_trail='DB' SCOPE=SPFILE;
    Wed Feb 01 12:23:48 2012
    Starting background process EMN0
    EMN0 started with pid=29, OS id=4836
    Wed Feb 01 12:23:49 2012
    Shutting down instance: further logons disabled
    Wed Feb 01 12:23:50 2012
    Stopping background process QMNC
    Streams Apply Server P001 pid=16 OS id=3708 stopped
    Wed Feb 01 12:23:51 2012
    Stopping background process CJQ0
    Streams Apply Reader P000 pid=15 OS id=3660 stopped
    Wed Feb 01 12:23:52 2012
    Errors in file e:\oracle\product\10.2.0\admin\std\bdump\psacc_p000_3660.trc:
    ORA-10388: parallel query server interrupt (failure)
    Streams Apply Server P004 pid=25 OS id=2124 stopped
    Wed Feb 01 12:23:52 2012
    Errors in file e:\oracle\product\10.2.0\admin\std\bdump\psacc_p004_2124.trc:
    ORA-10388: parallel query server interrupt (failure)
    Wed Feb 01 12:23:53 2012
    Errors in file e:\oracle\product\10.2.0\admin\std\bdump\psacc_p001_3708.trc:
    ORA-10388: parallel query server interrupt (failure)
    Streams Apply Server P002 pid=23 OS id=2404 stopped
    Wed Feb 01 12:23:53 2012
    Errors in file e:\oracle\product\10.2.0\admin\std\bdump\psacc_p002_2404.trc:
    ORA-10388: parallel query server interrupt (failure)
    Streams Apply Server P003 pid=24 OS id=1372 stopped
    Wed Feb 01 12:23:54 2012
    Errors in file e:\oracle\product\10.2.0\admin\std\bdump\psacc_p003_1372.trc:
    ORA-10388: parallel query server interrupt (failure)
    Wed Feb 01 12:23:54 2012
    Stopping background process MMNL
    Wed Feb 01 12:23:54 2012
    Streams APPLY A001 with pid=17, OS id=3400 stopped
    Wed Feb 01 12:23:55 2012
    Stopping background process MMON
    Wed Feb 01 12:23:57 2012
    Shutting down instance (normal)
    License high water mark = 21
    Wed Feb 01 12:23:57 2012
    Stopping Job queue slave processes
    Wed Feb 01 12:23:57 2012
    Job queue slave processes stopped
    Wed Feb 01 12:28:57 2012
    Active process 2572 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    Active process 3156 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    Active process 3416 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    Active process 5596 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    Active process 5200 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    Active process 5980 user 'SYSTEM' program 'ORACLE.EXE (SHAD)'
    SHUTDOWN: waiting for logins to complete.
    Wed Feb 01 12:43:28 2012
    MMNL absent for 1203 secs; Foregrounds taking over
    there is no more info after this line..... can any one please help on this , how to solve this issue... waiting for morethan 40 mins stil is running... guide me to proceed next step to complete this.... thanks in advance

    Use anothe command prompt and type sqlplus.
    For e.g in my system.
    C:\Documents and Settings\ranjit>sqlplus
    SQLPlus: Release 11.2.0.1.0 Production on Wed Feb 1 13:46:33 2012*
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    Enter user-name: sys as sysdba
    Enter password:
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    *SQL>
    Once you saw this.. type "shu abort;"
    This will abruptly shutdown the database. It is safe to run in non production databases however. And while starting up, it will to the recovery(which may take some time again to startup database).
    Regards

  • Restoration take long time

    hi,
    can any one help me for some issue..
    in my UAT daily restration is happen for 5 schemas but while droping one of schema it take lot of time from last three days can any one suggest me what i have to do to resolved the same issue.
    and also statustics gathering take long time
    please suggest.
    Thanks !!!
    Vishal Hande.

    >
    in my UAT daily restration is happen for 5 schemas but while droping one of schema it take lot of time from last three days can any one suggest me what i have to do to resolved the same issue.
    >
    Do you mean you are doing the export and import? If so, check the session and see what it's waiting on (V$SESSION_WAIT). Or put a trace and see where it's hanging. It may be doing the statistics gathering or waiting on something
    You need to give us all information. When you mean restore, we will think of database restore (RMAN or user-managed restore). So please supply all details in relation to what you are doing along with the database version and OS.

  • 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 Application Takes long time to Start

    Hello All,
    We ar eon Unix->64 Bit-> Essbase 11.1.1.3.
    Problem Description : The application is taking long to start up. around 5 to 6 minutes. This is very first time it is happening.
    There were no specific changes done to the application in the recent releases.
    I have tried all options 1. Compacating outline, 2. Purging the application log etc. all other applications respond good on this host except this. Usually any application should not take more than 1 to 2 minutes to start up.
    There are no specific errors or XCP files recorded in the logs and folders.
    Appreciate your suggestions
    MS

    Thanks Jitendra and Prabhas,
    I know i have posted this thread sometime back and later I had to jump on a New release, so did not get time to check your inputs.
    Well I am back on this issue again. I have been working on various option to get this issues solved " start of App takes long time"
    Here are some Details. We are on SunOs 64 Bit, has 12CU with dual core,  with Essbase 11.1.1.3 running on it. This is an ASO application and has just 7 dimensions, Out of which the ORGANIZATION Dimension is pretty huge with Multiple Hierarchies enabled ( Both Stored and Dynamic ) and has more than 20,00,000 members including the alternate hierarchies ( Shared members)
    I did a smoke test by building dimension by dimension the app was startiung up in just *40* seconds. and when i reached the ORG dimension and added more than 70,000 memebrs . there i fall sick. the app now gets back to its old issue ( Takes more than 10 mainutes to start).
    CPU Usage ranges between 3.1 % to 4 %
    PID USER NLWP PRI NI VSZ RSS S STIME ELAPSED %CPU COMMAND
    4424 user1 1 59 20 1608 1032 S 18:13:33 00:00 0.0 grep COMMAND
    4428 user1 1 59 20 1608 1032 S 18:13:33 00:00 0.0 grep ESS
    4766 user1 88 55 20 6814168 5684200 O 17:37:48 35:45 3.1 /path/xyz/masked/ASO_APP hgfedc NOCREAT.
    But My question here is, in the last moth cube i still similar number of members in the cube and nothing really had changed.
    Essbase GURU's Please give me some Hint to think out of box now.
    Thanks
    MS

  • Report takes long time for few records

    hi frends,
    I m facing one problem with my Web based erp application which is developed in .net , in my application when i open the  report from my applicaiton , in my temp folder there one file gets created name is "rpt conmgr cache"
    bcoz of this for few records also my report takes too much time and opens very slow and it takes long time, and it happens in some of the reports only , other reports are working cool and its not creating any file in temp folder,,, so can u guide me whats this file and what can be the solution for it,
    Thanks
    Mithun

    hi sabhajit,
    i have already checked the sql query it is taking less then seconds.
    any other steps u want me to check then pls let me know?
    thanks mithun

  • Photo both takes long time to open, what can i do?

    photo both takes long time to open, what can i do?

    SO do you think we can get a aunser? i just bout my imac u know!!

  • 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).

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

  • 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

  • Database Connectivity takes long time if one of the Node is down .. ??

    Hello All,
    Env: 10.2.0.4 on Solaris 10
    I have 2 nodes.
    When Node1 server is down, it takes long time to connec to the database.
    tnsping would give "OK(2050ms)". Below is the tnsalias.
    RAC_test  =
      (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST=20.268.169.123)(PORT= 1521))
         (ADDRESS = (PROTOCOL = TCP)(HOST=20.268.169.127)(PORT= 1521))
         (LOAD_BALANCE = yes)
              (CONNECT_DATA =
            (SERVICE_NAME = DK.com)
          (FAILOVER_MODE =
            (TYPE = SELECT)
            (METHOD = BASIC)
            (RETRIES = 180)
            (DELAY = 5)
    )I put the trace on sqlnet.ora and found that first it pings to the "20.268.169.123",
    since the Server is down there will not be any reply and this consumes the delay and
    later it would ping "20.268.169.127" and connect to it.
    If i keep "20.268.169.127" above "20.268.169.123" in tnsalias, and keep "LOAD_BALANCE=no",
    it gets connected very fast, as its directly connecting to Node2. In tnsping i get Ok(40ms).
    How do i reduce the connect timing if i use the first step. Why does it take long time for
    Oracle Client to understand that the Node1 Server is down ?
    TIA,
    J J

    I hope the IP's you are using in the TNS are Virtual IP's.
    You must use Virtual IP's / hostnames for the failover to be quick. If Node 1 is not available then then it's (Node 1's) virtual IP would also get assigned to Node 2 hence all client connections are still able to get a response from the Node Virtual IP address without needing to wait for TCP/IP timeouts. This helps clients to get notified immediately that node 1 is unavailable and the connection tries the 2nd ip/host in the connect descriptor.
    Hope this helps.
    - Siba

  • SSRS 2012. ReportServer takes long time to be up.

    SSRS 2012 Sp1
    Hi guys,
    I am using SSRS as my reporting platform, but I have always got the following issue.
    SSRS ReportServer takes time to load.
    The first time takes long, then less time but only if the ReprotServer web page is continuosly retrived.
    HERE the problem:
    If the ReprotServer page is not used after a short time (let me say 10 min), the page takes long time to be up again.
    I have checked the configuration that is set as for default 12 hours.
    Is there a way to speed up the ReportServer opening page time?
    Thanks for your help 

    Hi Fasttrack2,
    According to your description, you want to optimize the performance of your report. Right?
    In this scenario, when your report page is not active for a short time, it will take long time to render again. This is because the you have the report timeout. You can select "Do not timeout report" in Processing. Please refer to the link below:
    SQL Server Reporting Services – Timeout Settings
    For the performance issue, it can be many reason cause the report running slowly. Please refer to the articles below to optimize the report:
    More tips to improve performance of SSRS reports.
    Reporting Services Performance and Optimization
    Troubleshooting Reports: Report Performance
    If you have any question, please feel free to ask.
    Best Regards,
    Simon Hou

Maybe you are looking for