Take more time while running report on live

report takes more time to open on live. while running manually by connecting to live it run (means first pages generate with in 4 sec) but when i click to next page it tooks 3-4 sec.
thers's only two formula column.
please advice me to make it run smooth. waiting for ur response.
Regards

May i know which version u are using
and hw many records does it has to fetch.?

Similar Messages

Oracle9i reports take longer time while running in web

Hi,
I have developed few reports in Oracle9i and I am trying to run the reports in web. Running a report through report builder takes lesser time compare to running the same report in web using web.show_document. This also depends on the file size. If my report file size(.jsp file) is less than 100KB then it takes 1 minute to show the parameter form and another 1 minute to show the report output. If my file size is around 190KB then the system takes atleast 15 minutes to show the parameter form. Another 10 to 15 minutes to show the report output. I don't understand why the system takes long time to show the parameter form.
I have a similar problem while opening the file in reports builder also. If my file size is more than 150KB then it takes more than 15 minutes to open the file.
Could anyone please help me on this.
Thanks, Radha

This problem exists only with .jsp reports. I saved the reports in .rdf format and they run faster on web now. Opening a .jsp report takes longer time(file with 600KB takes atleast 2 hours) but the same report in .rdf format takes few seconds to get opened in reports builder.

Threaded program takes more time than running serially!

Hello All
Ive converted my program into a threaded application so as to improve speed. However i found that after converting the execution time is more than it was when the program was non threaded. Im not having any synchronised methods. Any idea what could be the reason ?
Thanx in advance.

First, if you are doing I/O, then maybe that's what's taking the time and not the threads. One question that hasn't been asked about your problem:
How much is the time difference? If it takes like 10 seconds to run the one and 10 minutes to run the threaded version, then that's a big difference. But if it is like 10 seconds vs 11 seconds, I think you should reconsider if it matters so much.
One analogy that comes to mind about multiple threads vs. sequential code is this:
With sequentially run code, all the code segments are lined up in order and they all go thru the door one after the other. As one goes thru they all move up closer, thus they know who's going first.
With multi-threaded code, all the code segments sorta pile up around the door in a big crowd. Some push go thru one at a time while others let them (priority), while other times 2 go for the door at the same time and there might be a few moments of "oh, after you", "no, after you", "oh no, I insist, after you" before one goes thru. So that could introduce some delay.

Function returning query takes more time to run in Apex4.0

Hi All,
I created a report using function returning query. The function returns query based the parameters which returns dynamic columns. When I run the query in sql developer the query generates and returns the result in 3mins. But in apex it takes maximum of 35mins to return.
The query will return around 10000 rows.
Is it a performance issue in the query or in Apex?can anyone please help
Regards
Raj

RajEndiran wrote:
Hi Roel,
Thanks much for your suggestion. I run in TOAD and got the result as
Row 1 of 500 fetched so far in 3.31 minutes which means it queried for 500 records alone ? is that not the actual time taken to run the fulll query?That reflects the time to return the first 500 records...
Please suggest.With all the best will in the world, if I was your user and I had to wait 3 minutes for the page to refresh, I'd steadily lose the will to live!
As this is primarily an SQL tuning question, have a look at this message in the FAQ thread in the {forum:id=75} forum:
{message:id=9360003}
That should give you some pointers on the right approach.

Reports take more time

hello experts,
i am using report builder(10g).i am working on a report.the report is ok but it takes more time to run.
.i already created indexing in columns but yet not its sufficient to improve the performance
so pls help me to improve the performance of my report.
Thanks And Regards]
Ravi

964900 wrote:
hello experts,
i am using report builder(10g).i am working on a report.the report is ok but it takes more time to run.
.i already created indexing in columns but yet not its sufficient to improve the performance
so pls help me to improve the performance of my report.
Hi Ravi
NO one can help you without giving idea.
first idea you already done.
secondly test your query with explain plan. How to run ?
explain plan for <your query>;
select * from table(dbms_xplan.display);more read SQL and PL/SQL FAQ
Lastly you can not get very good help from this forum. Better close it and post @ PL/SQL
Hope this helps
Hamid
Mark correct/helpful to help others to get right answer(s).*

Timeout error while running Report

Hi
All,
Windows 2000
Oracle Report builder 10g
Oracle developer suite 10g
when I had OLD computer i was able to run report more than 10 minutes. Now, I got NEW computer and i am getting TIMEOUT error while running report more than 10 minutes.
Any clue?
Thanks,
Vishal

As Fs says it depends on how you're running the report.
If you're running via a server then you need to make the change on that server or amend the URL you are using to run the report to add the enginereponsetimeout parameter.
You can amend this parameter on the server either by using the Application Server Control as I described in my last post or by directly editing the config file. This file will be called <reportservername>.conf and can be found in the oracle_home/reports/conf directory.
In this file look for the engine tag and see if the engineResponseTimeOut property is set.
E.g:
<engine id="rwEng" class="oracle.reports.engine.EngineImpl" initEngine="1" maxEngine="4" minEngine="1" engLife="50" maxIdle="20" callbackTimeOut="90000" engineResponseTimeOut="5">
</engine>
This value is in minutes so increase to a time larger than that it takes to run the report.
If instead you're running the report via Report Builder on your own PC then look for a file called rwbuilder.conf in the same location on your PC and make the same change as described above.
If this property isn't in the file then the engine isn't supposed to time out at all so the problem may well be something different. But to discount it try setting to a large value like 30.

Automatic DOP take more time to execute query

We upgraded database to oracle 11gR2. While testing Automatic DOP feature with our existing query it takes more time than with parallel.
Note: No constrains or Index created on table to gain performance while loading data (5000records / sec)
Os : Sun Solaris 64bit
CPU = 8
RAM = 7456M
Default parameter settings:
parallel_degree_policy               string      MANUAL
parallel_degree_limit                string      CPU
parallel_threads_per_cpu             integer     2
arallel_degree_limit                 string      CPU
cpu_count                            integer     8
parallel_threads_per_cpu             integer     2
resource_manager_cpu_allocation      integer     8
Query:
SELECT COUNT(*)
from (
SELECT
/*+ FIRST_ROWS(50), PARALLEL */
Query gets executed in 22minutes : execution plan
COUNT(*)
      9600
Elapsed: 00:22:10.71
Execution Plan
Plan hash value: 3765539975
| Id | Operation           | Name             | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |                  |     1 |    21 | 2164K (1)| 07:12:52 |       |   |
|   1 | SORT AGGREGATE     |                  |     1 |    21 |            |          |       |   |
|   2 |   PARTITION RANGE OR|                  | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|
|* 3 |    TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|Automatic DOP Query: parameters set
alter session set PARALLEL_DEGREE_POLICY = limited;
alter session force parallel query ;Query:
SELECT COUNT(*)
from (
SELECT /*+ FIRST_ROWS(50), PARALLEL*/
This query takes more than 2hrs to execute
COUNT(*)
      9600
Elapsed: 02:07:48.81
Execution Plan
Plan hash value: 127536830
| Id | Operation              | Name             | Rows | Bytes | Cost (%CPU)| Time     | Pstart|Pstop |    TQ   |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT       |                  |     1 |    21 |   150K (1)| 00:30:01 |       |      |         |      |            |
|   1 | SORT AGGREGATE        |                  |     1 |    21 |            |          |       |      |         |      |            |
|   2 |   PX COORDINATOR       |                  |       |       |            |          |       |      |         |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |    21 |            |          |       |      | Q1,00 | P->S | QC (RAND) |
|   4 |     SORT AGGREGATE     |                  |     1 |    21 |            |          |       |      | Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |                  | 89030 | 1825K|   150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWC |            |
|* 6 |       TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K|   150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWP |            |
Note
- automatic DOP: Computed Degree of Parallelism is 16 because of degree limitcan some one help us to find out where we did wrong or any pointer will really helpful to resolve an issue.
Edited by: Sachin B on May 11, 2010 4:05 AM

Generated AWR report for ADOP
Foreground Wait Events                       DB/Inst: HDB/hdb Snaps: 158-161
-> s - second, ms - millisecond -    1000th of a second
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by wait time desc, waits desc (idle events last)
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
direct path read                522,173     0    125,051     239    628.4   99.3
db file sequential read             663     0        156     235      0.8     .1
log file sync                       165     0        117     712      0.2     .1
Disk file operations I/O            267     0         63     236      0.3     .1
db file scattered read              251     0         36     145      0.3     .0
control file sequential re          217     0         32     149      0.3     .0
library cache load lock               2     0         10    4797      0.0     .0
cursor: pin S wait on X               3     0          9    3149      0.0     .0
read by other session                 5     0          2     429      0.0     .0
kfk: async disk IO              613,170     0          2       0    737.9     .0
sort segment request                  1   100          1    1007      0.0     .0
os thread startup                    16     0          1      43      0.0     .0
direct path write temp                1     0          1     527      0.0     .0
latch free                           51     0          0       2      0.1     .0
kksfbc child completion               1   100          0      59      0.0     .0
latch: cache buffers chain           19     0          0       2      0.0     .0
latch: shared pool                   36     0          0       1      0.0     .0
PX Deq: Slave Session Stat           21     0          0       1      0.0     .0
library cache: mutex X               45     0          0       1      0.1     .0
CSS initialization                    2     0          0       6      0.0     .0
enq: KO - fast object chec            1     0          0      11      0.0     .0
buffer busy waits                     3     0          0       1      0.0     .0
cursor: pin S                         9     0          0       0      0.0     .0
CSS operation: action                 2     0          0       1      0.0     .0
direct path write                     1     0          0       2      0.0     .0
jobq slave wait                  17,554   100      8,942     509     21.1
PX Deq: Execute Reply             4,060    95      7,870    1938      4.9
SQL*Net message from clien           96     0      5,756   59962      0.1
PX Deq: Execution Msg               618    56        712    1152      0.7
KSV master wait                      11     0          0       2      0.0
PX Deq: Join ACK                     16     0          0       1      0.0
PX Deq: Parse Reply                  14     0          0       1      0.0
Background Wait Events                       DB/Inst: HDB/hdb Snaps: 158-161
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % bg
Event                             Waits -outs   Time (s)    (ms)     /txn   time
control file sequential re        6,249     0      2,375     380      7.5   55.6
control file parallel writ        2,003     0        744     371      2.4   17.4
db file parallel write            1,604     0        503     313      1.9   11.8
log file parallel write             861     0        320     371      1.0    7.5
db file sequential read             363     0        151     415      0.4    3.5
db file scattered read              152     0         64     421      0.2    1.5
Disk file operations I/O            276     0         21      77      0.3     .5
os thread startup                   316     0         15      48      0.4     .4
ADR block file read                  24     0         11     450      0.0     .3
rdbms ipc reply                      17    12          7     403      0.0     .2
Data file init write                  6     0          6    1016      0.0     .1
direct path write                    21     0          6     287      0.0     .1
log file sync                         7     0          6     796      0.0     .1
ADR block file write                 10     0          4     414      0.0     .1
enq: JS - queue lock                  1     0          3    2535      0.0     .1
ASM file metadata operatio        1,801     0          2       1      2.2     .0
db file parallel read                30     0          1      40      0.0     .0
kfk: async disk IO                  955     0          1       1      1.1     .0
db file single write                  1     0          0     415      0.0     .0
reliable message                     10     0          0      23      0.0     .0
latch: shared pool                   75     0          0       2      0.1     .0
latch: call allocation               26     0          0       2      0.0     .0
CSS initialization                    7     0          0       6      0.0     .0
asynch descriptor resize            352   100          0       0      0.4     .0
undo segment extension                2   100          0       5      0.0     .0
CSS operation: action                 9     0          0       1      0.0     .0
CSS operation: query                 42     0          0       0      0.1     .0
latch: parallel query allo            4     0          0       0      0.0     .0
rdbms ipc message                37,948    97    104,599    2756     45.7
DIAG idle wait                   16,762   100     16,927    1010     20.2
ASM background timer              1,724     0      8,467    4912      2.1
shared server idle wait             282   100      8,465   30019      0.3
pmon timer                        3,123    90      8,465    2711      3.8
wait for unread message on        8,381   100      8,465    1010     10.1
dispatcher timer                    141   100      8,463   60019      0.2
Streams AQ: qmn coordinato          604    50      8,462   14010      0.7
Streams AQ: qmn slave idle          304     0      8,462   27836      0.4
smon timer                           35    71      8,382 239496      0.0
Space Manager: slave idle         1,621    99      8,083    4986      2.0
PX Idle Wait                      2,392    99      4,739    1981      2.9
class slave wait                     46     0        623   13546      0.1
KSV master wait                       2     0          0      27      0.0
SQL*Net message from clien            7     0          0       1      0.0
Wait Event Histogram                         DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)
                                                    % of Waits
                           Total
Event                      Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s   >1s
ADR block file read           24                                     100.0
ADR block file write          10                                     100.0
ADR file lock                 12 100.0
ASM file metadata operatio 1812 99.0    .3    .4                      .2    .1
CSS initialization             9                   100.0
CSS operation: action         11 90.9   9.1
CSS operation: query          54 100.0
Data file init write           6        16.7 16.7                    16.7 50.0
Disk file operations I/O     533 88.7   2.6    .6               1.5    .2   6.4
PX Deq: Signal ACK EXT         4 100.0
PX Deq: Signal ACK RSG         2 100.0
PX Deq: Slave Session Stat    21 42.9 28.6 28.6
SQL*Net break/reset to cli     6 100.0
SQL*Net message to client    102 100.0
SQL*Net more data to clien     4 100.0
asynch descriptor resize     527 100.0
buffer busy waits              4 75.0        25.0
control file parallel writ 2003   9.3    .5          .0    .1        90.0
control file sequential re 6466 10.6    .0    .0    .0    .1    .2 89.0
cursor: pin S                  9 100.0
cursor: pin S wait on X        3                          33.3 33.3        33.3
db file parallel read         30                           6.7 30.0 63.3
db file parallel write      1604   7.4    .1                .6 16.5 75.5
db file scattered read       403   3.7    .2   2.5 13.6 14.9   3.5 61.5
db file sequential read     1017 12.3    .8   2.3   7.3   6.6   2.0 68.8
db file single write           1                                     100.0
direct path read           522.2   2.2   2.1    .1    .0   1.8 17.9 75.9
direct path write             22         4.5                     4.5 90.9
direct path write temp         1                                     100.0
enq: JS - queue lock           1                                           100.0
enq: KO - fast object chec     1                         100.0
enq: PS - contention           1 100.0
kfk: async disk IO         614.1 100.0                                  .0
kksfbc child completion        1                                     100.0
latch free                    58 46.6 27.6 15.5 10.3
latch: cache buffers chain    19 36.8 10.5 52.6
latch: call allocation        26 76.9 11.5         7.7         3.8
latch: parallel query allo     4 100.0
latch: shared pool           111 44.1 28.8 27.0
library cache load lock        2                                           100.0
library cache: mutex X        45 84.4   8.9   4.4   2.2
log file parallel write      861 10.0          .1    .1              89.5    .2
log file sync                172   6.4                                90.1   3.5
os thread startup            332                                     100.0
rdbms ipc reply               18 72.2                                11.1 16.7
read by other session          5                                     100.0
reliable message              11 81.8   9.1                           9.1
sort segment request           1                                     100.0
undo segment extension         2 50.0                    50.0
ASM background timer        1724    .8    .6    .1                      .6 97.9
DIAG idle wait             16.8K                                     100.0
KSV master wait               13   7.7 23.1 61.5                     7.7
PX Deq: Execute Reply       4060    .4          .0    .0          .1   3.4 96.0
PX Deq: Execution Msg        617 34.7   1.5   2.4   1.5   1.5    .2    .8 57.5
PX Deq: Join ACK              16 93.8                     6.3
PX Deq: Parse Reply           14 71.4   7.1 14.3   7.1
PX Idle Wait                2384    .0                                  .6 99.3
SQL*Net message from clien   103 82.5         1.0   1.9               1.0 13.6
Space Manager: slave idle   1621                                        .2 99.8
Streams AQ: qmn coordinato   604 50.0                                      50.0
Wait Event Histogram                         DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)Edited by: Sachin B on May 11, 2010 4:52 AM

MRP job takes more time (Duration / Sec)

Hello PP Guru’s,
I have below situation in production environment,
MRP job for plant – A (Takes more time – 14.650)
MRP job for plant – B (Takes less time – 4.512)
When I compare the variant / attributes with plant A and B, I observe only difference in attribute is scheduling (2 - Lead Time Scheduling and Capacity Planning) for plant A.
For plant B scheduling (1- Determination of Basic Dates for Planned) it was updated.
So in my observation this scheduling is playing a major role for MRB job which takes more time in plant – A.
I am in process of changing the variant attribute for plant – A from scheduling 2 to scheduling 1.
I wanted to know from experts whether if I change any impact / problem will happen in future for plant A or not.
Please let me know what all the hidden impacts are there if I change the scheduling in variant attribute.
I look forward to your valuable input to reduce time for my MRP related job.
Regards,
Kumar S

Hi Kumar,
You have no need to change the inhouse production time you just need to update the Lot size dependent inhouse production time in work scheduling view of material master. That you can do by scheduling the routing/recipe.
Transactions CA97 or CA97N can be used to update the in-house production time with the information from the routing.
If business don't want to have the capacity planning for planned orders then you change the scheduling from 2 to 1 basic date scheduling.
Expert Caetano already answer you query
The reports listed below can be used to compare the MRP past executions regarding the runtime:
RMMDMONI: This report compares the runtime of the MRP execution and also provides the total of planning elements (planned orders, purchase requisitions, etc) changed, created or deleted. It also shows which planning parameters where used and how much time MRP spent on each step (database read, BOM explosion, MRP calculation, scheduling, BAdIs, etc). With this information is possible to observe the relation of runtime and number of elements changed/created/deleted and also to see on which step MRP is taking more time.
RMMDPERF: This report shows the "material hit list", that means, which materials had the highest runtime during the MRP execution and also on which step MRP is taking more time. Knowing which materials have the highest runtime, allow you to isolate the problem and reproduce it on MD03, where it is possible to run an ABAP or SQL trace for a more detailed analysis.
Regards,
R.Brahmankar

A block of code takes more time in JRE 6_20 but less in the previous versio

while (entries.hasMoreElements()) {
ZipEntry zipEntry = (ZipEntry) entries.nextElement();
is = zipFile.getInputStream(zipEntry);
File file = new File(unzipDir, zipEntry.getName());
if (is.available() == 0) {
file.mkdir();
is.close();
} else {
file.createNewFile();
fos = new FileOutputStream(file);
CommonUtils.connectIO(is, fos, -1, true);
}

Sorry a type,. The above code takes more time when I run withJDK 6_20. But its less time if the previous version is used. Cannot figure whats wrong. Here is the full method.
* Unzips the specified file into the specified directory. The optional file names list allows the caller
* to specify the actual files that get unzipped.
* @param srcFile the file to unzip
* @param unzipDir the directory where the unzipped files will be put
* @param fileNames the optional list of name strings for the zip entries to unzip or <code>null</code> to unzip
* all entries
* @throws NullPointerException if either the source file or the unzip directory is <code>null</code>
* @throws javax.faces.FacesException if the
public static void unzipFile(File srcFile, File unzipDir, List fileNames) {
if (srcFile == null) {
throw new NullPointerException("The zip file argument is null");
if (unzipDir == null) {
throw new NullPointerException("The unzip directory argument is null");
ZipFile zipFile = null;
InputStream is = null;
FileOutputStream fos = null;
try {
zipFile = new ZipFile(srcFile);
Enumeration entries = null;
if (fileNames != null) {
// Use a vector only so we can abstract away the zip entries enumeration...
Vector v = new Vector();
Iterator it = fileNames.iterator();
while (it.hasNext()) {
String name = (String) it.next();
v.add(new ZipEntry(name));
entries = v.elements();
} else {
entries = zipFile.entries();
while (entries.hasMoreElements()) {
ZipEntry zipEntry = (ZipEntry) entries.nextElement();
is = zipFile.getInputStream(zipEntry);
File file = new File(unzipDir, zipEntry.getName());
if (is.available() == 0) {
file.mkdir();
is.close();
} else {
file.createNewFile();
fos = new FileOutputStream(file);
CommonUtils.connectIO(is, fos, -1, true);
catch (IOException e) {
throw new FacesException("Problem unzipping file " + srcFile.getAbsolutePath(), e);
finally {
try {
if (is != null) {
is.close();
if (fos != null) {
fos.close();
if (zipFile != null) {
zipFile.close();
catch (IOException e) {
throw new FacesException("Problem closing resources when unzipping file " + srcFile.getAbsolutePath(), e);
}

Multithreaded File Copy takes more time 1.5 times than single thread.

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.channels.FileChannel;
public class TestMulti implements Runnable {
     public static Thread Th1;
     public static Thread Th2;
     String str = null;
     static int seqNumber = 1000000000;
     public static void main(String args[]) {
          Th1 = new Thread(new TestMulti("1_1"));
          Th2 = new Thread(new TestMulti("1_2"));
          Th1.start();
          Th2.start();
          try {
               Th1.join();
               Th2.join();
          } catch (Exception e) {
               e.printStackTrace();
     public TestMulti(String str) {
          this.str = str;
     public void run() {
          File f = new File("C:/Songs2/" + str);
          File files[] = f.listFiles();
          String fileName = "";
          String seqName = "";
          String seq = "";
          int sequenceNo = 0;
          try {
               for (int j = 0; j < files.length; j++) {
                    File musicFiles[] = files[j].listFiles();
                    for (int k = 0; k < musicFiles.length; k++) {
                         seq = "18072006";
                         seqName = seq + seqNumber;
                         sequenceNo = 10000 + seqNumber % 100;
                         seqNumber = seqNumber + 1;
                         fileName = musicFiles[k].getName();
                         String fileExt = fileName.substring(fileName.length() - 3,fileName.length());
                         String targetFile = "C:/Songs1/" + sequenceNo;
                         File fi = new File(targetFile);
                         if (!fi.exists()) { fi.mkdir(); }
                         targetFile = "C:/Songs1/" + sequenceNo + "/" + seqName+ "." + fileExt;
                         FileInputStream fin = new FileInputStream(musicFiles[k]);
                         FileChannel fcin = fin.getChannel();
                         FileOutputStream fout = new FileOutputStream(targetFile);
                         FileChannel fcout = fout.getChannel();
                         fcin.transferTo(0, fcin.size(), fcout);
                         fout.flush();
                         fcout.close();
                         fcin.close();
                         fout.close();
                         fin.close();
          } catch (Exception e) {
               e.printStackTrace();
Multithreaded File Copy takes more time 1.5 times than single thread.
Is there any issue with this code. Please help me.

If all of your threads are doing CPU-intensive work, or all are doing I/O to the same interface (for example, writing to the same physical disk), then multithreading would not be expected to help you.
Multithreading does not magically make your CPU able to do more work per unit time than it could otherwise.
Multithreading does not magically make your network interface or disk controller able to pump more bytes through than it could otherwise.
Where multithreading helps (some or all of this has already been mentioned):
* When you have multiple, independent CPU-bound tasks AND multiple CPUs available on which to execute them.
* When you have tasks that involve a mix of CPU-bound and I/O-bound work. The CPU-bound stuff can crank while the I/O-bound stuff waits for bytes to be written or read, thus making use of what would otherwise be CPU "dead time."
What you're doing does not fit either of those scenarios. Copying a file is pure I/O. If the source and destination file are on the same phsyical disk or controller, adding threads only adds overhead with no real possibility to do more work per unit time.
If your source and destination are on different disks or controllers, then it's possible that you could get some benefit from multithreading. While one thread is waiting for bytes to be written to the target disk, the other thread can be reading from the source disk.

Auto message restart job take long time to run

Dear all,
I have configre the auto message restart job in sdoe_bg_job_monitor
but it take long time to run.
i have execute the report i have find out that it is faching records from smmw_msg_hdr .
in the table present 67 laks records are there.
actually it is taking a lot of time while getting data from the table
is there any report or tcode for clearing data in the table.
I need ur valiuble help to resolve the issue.
Regards
lakshman balanagu

HI,
If you are using oracle database you may need to run table statistics report (RSOANARA) to update the index. The system admin should be able to this.
Regards,
Vikas
Edited by: Vikas Lamba on Aug 3, 2010 1:20 PM

Takes more time to start & shutdown the database

Hi All,
I have created a database in oracle9i by following manual steps. Every thing was created successfully and am able to start the database and shutdown also.
but the problem is while giving the startup command it takes more time to start the database and the same during the shutdown. So anyone help me..
the follwing are the pfile specifications:
db_name=practice
instance_name=practice
control_files= 'E:\practice\control\control1.ctl',
'D:\practice\control\control2.ctl'
db_block_size=2048
db_cache_size=20m
shared_pool_size=20m
background_dump_dest='E:\practice\bdump'
user_dump_dest='E:\practice\udump'
Thanks in Advance

Every thing was created successfully and am able to start the database and > shutdown also.Please restate the above.
problem is while giving the startup command it takes more time to start the >database and the same during the shutdownHow have you compared? Could it be O/S resources, installation of additional software; you have not mentioned the O/S and complete version of your database.
You can review the following although I am bit unclear;
http://download.oracle.com/docs/cd/B10501_01/server.920/a96533/instreco.htm#440322
Adith

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

'BAPI_GOODSMVT_CREATE' takes more time for creating material document

Hi Experts,
I m using 'BAPI_GOODSMVT_CREATE' in my custom report, it takes more time for creating Material documents.
Please let me know if there is any option to overcome this issue.
Thanks in advance
Regards,
Leo

Hi,
please check if some of following OSS notes are not valid for your problem:
[Note 838036 - AFS: Performance issues during GR with ref. to PO|https://service.sap.com/sap/support/notes/838036]
[Note 391142 - Performance: Goods receipt for inbound delivery|https://service.sap.com/sap/support/notes/391142]
[Note 1414418 - Goods receipt for customer returns: Various corrections|https://service.sap.com/sap/support/notes/1414418]
The other idea is not to commit each call, but executing commit of packages e.g. after 1000 BAPI calls.
But otherwise, I am afraid you can not do a lot about performance of standard BAPI. Maybe there is some customer enhancement which is taking too long inside the BAPI, but this has to be analysed by you. To analyse performance, just execute your program via tr. SE30.
Regards
Adrian

'BAPI_GOODSMVT_CREATE' takes more time for creating material document for the 1st time

Hi Experts,
I am doing goods movement using BAPI_GOODSMVT_CREATE in my custom code.
Then there is some functional configuration such that, material documents and TR and TO are getting created.
Now I need to get TO and TR numbers from LTAK table passing material documnt number and year, which I got from above used BAPI.
The problem I am facing is very strange.
Only for the 1st time, I am not finding TR and TO values in LTAK table. And subsequent runs I get entries in LTAK in there is a wait time of 5 seconds after bapi call.
I have found 'BAPI_GOODSMVT_CREATE' takes more time for creating material document with similar issue, but no solution or explanation.
Note 838036 says something similar, but it seems obsolete.
Kindly share your expertise and opinions.
Thanks,
Anil

Hi,
please check if some of following OSS notes are not valid for your problem:
[Note 838036 - AFS: Performance issues during GR with ref. to PO|https://service.sap.com/sap/support/notes/838036]
[Note 391142 - Performance: Goods receipt for inbound delivery|https://service.sap.com/sap/support/notes/391142]
[Note 1414418 - Goods receipt for customer returns: Various corrections|https://service.sap.com/sap/support/notes/1414418]
The other idea is not to commit each call, but executing commit of packages e.g. after 1000 BAPI calls.
But otherwise, I am afraid you can not do a lot about performance of standard BAPI. Maybe there is some customer enhancement which is taking too long inside the BAPI, but this has to be analysed by you. To analyse performance, just execute your program via tr. SE30.
Regards
Adrian

Take more time while running report on live

Similar Messages

Maybe you are looking for