Language related performance issues in PS HRMS

Dear experts,
I was just verifying a PS HRMS application(enterprise 9.1) performance and I found out that the language I select while logging in is drastically affecting the end user performance.
The verification for all languages were done from same location(suspected the issue could be location\network specific).
      Any suggestions/recommendations/insights that would help me understand this issue better would be welcome!
     Best Regards,
A   Arun

I've heard this issue before. If you check the query being executed, you'll see that when you're working in a non-base language, that the related language records are joined in as well. If you're searching in a big record (PS_JOB e.g.), you can thus end up with a much more costly query. I don't have a solution just right away on how to force lookups etc. to not check unneeded language stuff, but knowing the base issue might point you in a good direction to look further.

Similar Messages

Cache-flush VM-related performance issue

Dear forum,
I've got a peculiar performance issue going on with the BDB pagecache being flushed to disk. I've managed to reproduce the issue perfectly on three out of three quite different systems that I've tried on, so it is at least quite well-defined.
My usage pattern for the database in question is such that I periodically (perhaps once every 10-60 seconds or so) need to read through an amount of values (around 500-2000 or so) from a database containing a rather large amount (in the millions, at least) of keys. There are a few writes for every such batch, but not very many (a couple of tens). The keys that are read each batch are quite random, and very likely to be completely different from batch to batch. The database is a DB_HASH.
When I do that, BDB seems to dirty a lot of pages in the page cache (which I have currently sized at 512 MB so that pages don't have to be forced out from it), from what I can tell by manipulating refcounts and stuff, so all in all, a single batch seems to dirty some 10-40 MB or so of the mmapped cache region. (I check this using pmap -x on Linux.) Note that when I speak of pages and the dirtying of them here, I mean at the VM level, not the BDB level.
A while after this has happened, the VM comes around and wants to flush the dirty pages to disk, so it batches writes of large portions (often the entire set of dirty pages, but sometimes it only does 10-20 MB or so at a time; this detail shouldn't matter) of the dirtied pages to the backing block device. Since the dirty pages are often rather interspersed in the region file, such a flush usually requires a couple of thousands of write ops, so it might sometimes take up to 10-20 seconds for the requests to complete.
If the program, then, again tries to dirty any of the pages while they are waiting to be flushed, which is often the case, the VM will block it until the page in question is flushed. This means that the thread in question might very well be blocked for up to 20 seconds, causing quite annoying wait times.
How to deal with this problem? I've considered trying to put the region files on tmpfs or so, but that seems like such an excessive measure for a problem which, from what I can tell, should be commonplace.
On a very related note, I've noticed a large discrepancy in the I/O performance between the systems I've tried this on. Two of the systems in question manage to carry out some 200-500 write ops per second on my test load, while the third manages closer to 2000-3000 write ops per second, which makes quite a difference. What makes it very weird is that the faster system uses the exact same hard drive as one of the slower systems. I know this isn't exactly a BDB-specific question, but I thought someone around here might have experience in the matter. All three systems use Linux and S-ATA hard disks (not SSDs), but they use different S-ATA host adapters, different kernel versions and are configured in quite different ways.
Thanks for reading my wall of text! I'm sorry for dragging on so long, but I didn't know how to describe the situation more briefly.
Edited by: Dolda2000 on Mar 23, 2013 8:08 AM

As a follow-up on this, it appears that the blocking behavior was introduced in Linux 3.0 to stabilize pages under writeback:
http://lwn.net/Articles/486311/
It seems that the commits that introduced the behavior can be safely patched away, and also that it is due to change in 3.9, but for now, this is not the route I took to solve it.
Rather, I wrote a patch to Berkeley DB to allow me to store the region files in another directory than the environment root directory, and used it to store them in /dev/shm -- that is, on tmpfs, which avoids writeback of the region files altogether.
If you want the patch, it is here for db4.8 (which what Debian Stable uses), and here for 5.1, which is what Debian Testing uses.
(For some reason, the hyperlink format suggested by the forum doesn't seem to be working?)

BW database related performance issue..

hi...
can anyone tell me how to improve the database performance??

Hi Nisha,
Welcome to SDN )
The Database performance increases by doing the following,
1. Partioning
2. Indexing
3. Archive unwanted data
4. Creating Aggregates ( Consider DB ratio and KPI ratio)
5. Check for parallelization options
6. deleting PSA requests
Please the below links
check this
http://help.sap.com/bp_biv235/BI_EN/documentation/Multi-dimensional_modeling_EN.doc
and
Business Intelligence Performance Tuning [original link is broken]
Thanks,
Sudhakar.
Saying thanks in SDN == Assigning Points.

BW Performance issue

Hi,
We have done reorge for four tablespaces PSAPBTABI, PSAPBTABD, PSAPODSD, PSAPODSI in our BW System 7.0. And we have created new tablespaces for above our tablespaces like PSAPODSINEW for all the above tablespaces and made the old tablespaces as offline. After doing this activity we are facing lot of performance problems.
For e.g while our BW guys are running one report for the portal it is executing but after a long time like after 2+ hours the page goes empty. The report is CL_SQL_RESULT_SET=============CP, not only this report but lot of reports. We have done statistics update for the tables that report uses using BRCONNECT and also rebuild the indexex for all the tables. But still no luck.
<< Moderator message - The answers given in this forum are by volunteers. Everyone's problem is important. Please do not ask for help quickly. >>
Regards,
Balaji Vedagiri
Edited by: Rob Burbank on Jan 9, 2011 10:40 PM

Hi,
For the BASIS related performance issues :
1. This is mostly DBA related : Keeping an eye on the DB space to monitor the growth of the database and look at space available and needed to prevent shutting down the BW server.
2. Making sure that backups don't consume a lot of time to interfere with daily operations.
3. Doing load balancing
4. Making sure IDocs are flowing freely.
5. Making sure that shared drives and servers don't overshoot the capacity.
6. Patching servers and server instances to improve performance.
The BW consultants can monitor the the space , etc using tcode DB02. The DBAs have their own tools to monitor these parameters.
Cheers,
Kedar

Performance Issue with PAY_BALANCE_VALUES_V View in Oracle R12

Dear all ,
We have recently upgraded from 11i(11.5.10.2) to R12(12.1.3). We are facing one Issue with slow performance of the queries where PAY_BALANCE_VALUES_V is used. We have so many reports & logic in Payroll which uses this View.
In 11i this works fine, however in R12 it takes very long time. There are no configuration changes we have done from 11i to R12.
Is there any way to optimize the performance or alternate way to retrieve the Balances Data in Payroll ?
Any heads up would be highly Appreciated.
Thanks,
Razi

Hi Razi,
The balance related performance issue is written in the following note.
Note:1494344.1 UK Payslip Generation - Self Service Program Takes Much Time To Complete (Performance Issue)
This issue was fixed in HR_PF.B RUP6 or patch:14376786. Did you apply this patch? If not, I suggest you apply it.
Also, HR_PF.B RUP6 has some balance related performance issues.
If you already have applied HR_PF.B RUP6, I suggest you log a SR with SQL trace.
Thanks,
Hideki

Performance issues related to logging (ForceSingleTraceFile option)

Dear SDN members,
I have a question about logging.
I like to place my logs/traces for every application in different log files. By doing this you have to set the ForceSingleTraceFile option to NO (in the config tool).
But in a presentation of SAP, named SAP Web Application Server 6.40; SAP Logging and Tracing API, is stated:
- All traces by default go to the default trace file.
- Good for performance
- On production systems, this is a must!!!
- Hard to find your trace messages
- Solution: Configure development systems to pipe traces and logs for applications to their own specific trace file
But I want the logs/traces also by our customers (production systems) in separate files. So my question is:
What are the performance issues we face, if we turn the ForceSingleTraceFile option to NO by our customers?
and
If we turn the ForceSingleTraceFile to NO will the logs/traces of the SAP applications also go to different files? If so, then I can imagine that it will be difficult to find the logs of the different SAP applications.
I hope that someone can clarify the working of the ForceSingleTraceFile setting.
Kind regards,
Marinus Geuze

Dear Marinus,
The performance issues with extensive logging are related to high memory usage (for concatenation/generation of the messages which are written to the log files) and as result increased garbare collection frequency, as well as high disk I/O and CPU overhead for the actual logging.
Writing to same trace file, if logging is extensive can become a bottleneck.
Anyway it is not related to if you should write the logs to the default trace of a standard location. I believe that the recommendation in the documentation is just about using the standard logging APIs of the SAP Java Server, because they are well optimized.
Best regards,
Sylvia

Performance issues -- related to printing

Hi All,
I am haviing production system performance issues related to printing. endusers are telling the printing is slow for almost printers. We are having more that 40 to 50 printers in landscape.
As per my primary investigation I didnt find any issues in TSP01 & TSP02 tables. But I can see the table TST01 and TST03 table having many number of entries (more that lakh). I dont have idead about this table. Is ther eany thing related to this table where the print causes slowness or any other factors also makes this printing issue .. Please advice ..
thanks in advance

Hai,
Check the below link...
http://help.sap.com/saphelp_nw70/helpdata/en/c1/1cca3bdcd73743e10000000a114084/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/fc/04ca3bb6f8c21de10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/86/1ccb3b560f194ce10000000a114084/content.htm
TemSe cannot administer objects that require more than two gigabytes of storage space, regardless of whether the objects are stored in the database or in the file system. Spool requests of a size greater than two gigabytes must therefore be split into several smaller requests.
It is enough if you perform the regular background jobs and Temse consistency checks for the tables.
This will help in controlling the capacity problems.
If you change the profile parameter rspo/store_location parameter value to 'G' this will make the performance better. The disadvantages are TemSe data must be backed up and restored separately from the database using operating system tools, In the event of problems, it can be difficult to restore consistency between the data held in files and the TemSeu2019s object management in the database. Also you have take care of the Hard disk requirements because in some cases, spool data may occupy several hundred megabytes of disk storage. If you use the G option, you must ensure that enough free disk space is available for spool data.
Regards,
Yoganand.V

Performance issue related to OWM? Oracle version is 10.2.0.4

The optimizer picks hash join instead of nested loop for the queries with OWM tables, which causes full table scan everywhere. I wonder if it happens in your databases as well, or just us. If you did and knew what to do to solve this, it would be great appriciated! I did log in a SR to Oracle but it usually takes months to reach the solution.
Thanks for any possible answers!

Ha, sounded like you knew what I was talking about :)
I thought the issue must've had something to do with OWM because some complicate queries have no performance issue while they're regular tables. There's a batch job which took an hour to run now it takes 4.5 hours. I just rewrote the job to move the queries from OWM to regular tables, it takes 20 minutes. However today when I tried to get explain plans for some queries involve regular tables with large amount of data, I got the same full table scan problem with hash join. So I'm convinced that it probably is not OWM. But the patch for removing bug fix didn't help with the situation here.
I was hoping that other companies might have this problem and had a way to work around. If it's not OWM, I'm surprised that this only happens in our system.
Thanks for the reply anyway!

Performance Issue's Related in Adance table in advance table

Hi,
Can anybody let me know what are the performance issues in advance table in advance table,because i am having big performance issue while implementing advance table in advance table, my inner table is rendering very slowly.
Thanks

Table in a table is a performance eating structure :), because ur VL will cache both parent and child VO rows in JVM.The only way to improve the performance is to tune your sql queries.
--Mukul

Concurrent program performance Issue

Hi,
We are currently experiencing performance issue in one of the concurrent program related
to the HR module. The concurrent request is currently completing in 3 hrs time.
We have obtained a trace for the concurrent program.
Please help me analyze the cause of the performance issue from the trace file.
Trace file below:
BEGIN SLC_PYINF_USMONACCROH_PKG.SLC_421_HANDLE_OUTBOUND(:errbuf,:rc,:A0,:A1,
:A2,:A3,:A4,:A5,:A6,:A7,:A8,:A9,:A10,:A11); END;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 76.08 9602.16 700828 1330818 663813 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 76.08 9602.16 700828 1330818 663813 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 3 0.00 0.00
SQL*Net message from client 3 0.00 0.00
PL/SQL lock timer 969 9.83 9485.16
UPDATE HRAPPS.SLC_PYINF_USMONACCRO_STG SET PROCESS_STATUS = 2
WHERE
CONC_REQUEST_ID = :B2 AND SET_SEQUENCE_NUM = :B1 AND PROCESS_STATUS = 1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 24.83 45.67 145127 695479 602714 560730
Fetch 0 0.00 0.00 0 0 0 0
total 2 24.83 45.67 145127 695479 602714 560730
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
0 UPDATE SLC_PYINF_USMONACCRO_STG (cr=684898 pr=134556 pw=0 time=44759708 us)
1135266 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=694708 pr=124937 pw=0 time=6874212 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 15622 1.43 13.94
db file sequential read 25578 0.52 14.30
latch: cache buffers lru chain 3 0.00 0.00
DELETE FROM SLC_PYINF_USMONACCRO_ARC
WHERE
EXTRACT_DATE<TRUNC(SYSDATE)-60
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 7.41 15.05 87598 87668 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 7.41 15.06 87598 87668 0 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
0 DELETE SLC_PYINF_USMONACCRO_ARC (cr=87668 pr=87598 pw=0 time=15053606 us)
0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_ARC (cr=87668 pr=87598 pw=0 time=15053595 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 3 0.00 0.00
db file scattered read 11025 0.61 13.21
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 10.14 10.23 116633 123540 0 2
total 6 10.14 10.23 116633 123540 0 2
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=58317 pw=0 time=5290475 us)
560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58317 pw=0 time=1689204 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 15646 0.27 6.24
db file sequential read 625 0.00 0.01
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
PROCESS_STATUS = 2
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.20 8.32 51482 69842 0 1
total 3 5.20 8.32 51482 69842 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=69842 pr=51482 pw=0 time=8323369 us)
560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=69842 pr=51482 pw=0 time=2811304 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 6514 0.30 6.09
db file sequential read 114 0.00 0.02
SELECT MAX(SET_SEQUENCE_NUM)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.34 6.63 58318 61770 0 1
total 3 5.34 6.63 58318 61770 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=58318 pw=0 time=6639527 us)
560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58318 pw=0 time=2250410 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 7820 0.30 4.46
db file sequential read 313 0.00 0.05
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B2 AND
SET_SEQUENCE_NUM = :B1 AND PROCESS_STATUS = 1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 4.99 4.88 58315 61770 0 1
total 3 4.99 4.88 58315 61770 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=58315 pw=0 time=4887337 us)
560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58315 pw=0 time=1688451 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 7824 0.00 3.02
db file sequential read 313 0.00 0.00
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
PROCESS_STATUS = 1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 4.98 4.87 58318 61770 0 1
total 3 4.98 4.87 58318 61770 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=58318 pw=0 time=4872548 us)
560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58318 pw=0 time=1688407 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 7821 0.00 2.98
db file sequential read 312 0.00 0.00
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
PROCESS_STATUS = -1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 4.45 4.36 58317 61770 0 1
total 3 4.45 4.36 58317 61770 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=58317 pw=0 time=4369473 us)
0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58317 pw=0 time=4369425 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 7823 0.00 2.98
db file sequential read 312 0.00 0.00
SELECT COUNT(*)
FROM
HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
PROCESS_STATUS < 0
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 4.14 4.24 51481 61770 0 1
total 3 4.14 4.24 51481 61770 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=61770 pr=51481 pw=0 time=4243020 us)
0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=51481 pw=0 time=4242968 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 6537 0.06 2.90
db file sequential read 104 0.00 0.00
DELETE FROM SLC_PYINF_USMONACCRO_GLI_ARC
WHERE
EXTRACT_DATE<TRUNC(SYSDATE)-60
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.63 2.52 7681 7689 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.63 2.52 7681 7689 0 0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
0 DELETE SLC_PYINF_USMONACCRO_GLI_ARC (cr=7689 pr=7681 pw=0 time=2521592 us)
0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_GLI_ARC (cr=7689 pr=7681 pw=0 time=2521583 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1 0.00 0.00
db file scattered read 976 1.00 2.36
UPDATE HRAPPS.SLC_PYINF_USMONACCRO_GLI_STG SET PROCESS_STATUS = 2
WHERE
CONC_REQUEST_ID = :B1 AND PROCESS_STATUS = 1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 1.89 2.25 5863 16125 60963 52309
Fetch 0 0.00 0.00 0 0 0 0
total 2 1.89 2.25 5863 16125 60963 52309
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
0 UPDATE SLC_PYINF_USMONACCRO_GLI_STG (cr=11787 pr=1273 pw=0 time=1332023 us)
122679 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_GLI_STG (cr=16291 pr=5859 pw=0 time=48501241 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 745 0.01 0.76
db file parallel read 1 0.00 0.00
db file sequential read 5 0.00 0.00
SELECT B.ATTRIBUTE1 ,B.ATTRIBUTE2 ,B.ATTRIBUTE3 ,T.FLEX_VALUE_MEANING ,
T.DESCRIPTION
FROM
FND_FLEX_VALUES_TL T ,FND_FLEX_VALUES B WHERE B.FLEX_VALUE_ID =
T.FLEX_VALUE_ID AND T.LANGUAGE = USERENV ('LANG') AND TRIM(UPPER
(B.FLEX_VALUE)) = TRIM(UPPER (:B1 )) AND B.ENABLED_FLAG = 'Y' AND UPPER
(B.VALUE_CATEGORY) = UPPER ('SLCHR_INTERFACE_CLEANUP')
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.25 0.86 1640 3286 0 2
total 5 0.25 0.86 1640 3286 0 2
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
2 NESTED LOOPS (cr=3286 pr=1640 pw=0 time=866461 us)
2 TABLE ACCESS FULL FND_FLEX_VALUES (cr=3280 pr=1637 pw=0 time=848331 us)
2 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUES_TL (cr=6 pr=3 pw=0 time=18101 us)
2 INDEX UNIQUE SCAN FND_FLEX_VALUES_TL_U1 (cr=4 pr=2 pw=0 time=9705 us)(object id 849241)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 4 0.00 0.02
db file scattered read 208 0.30 0.71
SELECT PHASE_CODE, STATUS_CODE, COMPLETION_TEXT, PHASE.LOOKUP_CODE,
STATUS.LOOKUP_CODE, PHASE.MEANING, STATUS.MEANING
FROM
FND_CONCURRENT_REQUESTS R, FND_CONCURRENT_PROGRAMS P, FND_LOOKUPS PHASE,
FND_LOOKUPS STATUS WHERE PHASE.LOOKUP_TYPE = :B3 AND PHASE.LOOKUP_CODE =
DECODE(STATUS.LOOKUP_CODE, 'H', 'I', 'S', 'I', 'U', 'I', 'M', 'I',
R.PHASE_CODE) AND STATUS.LOOKUP_TYPE = :B2 AND STATUS.LOOKUP_CODE =
DECODE(R.PHASE_CODE, 'P', DECODE(R.HOLD_FLAG, 'Y', 'H',
DECODE(P.ENABLED_FLAG, 'N', 'U', DECODE(SIGN(R.REQUESTED_START_DATE -
SYSDATE),1,'P', R.STATUS_CODE))), 'R', DECODE(R.HOLD_FLAG, 'Y', 'S',
DECODE(R.STATUS_CODE, 'Q', 'B', 'I', 'B', R.STATUS_CODE)), R.STATUS_CODE)
AND (R.CONCURRENT_PROGRAM_ID = P.CONCURRENT_PROGRAM_ID AND
R.PROGRAM_APPLICATION_ID= P.APPLICATION_ID ) AND REQUEST_ID = :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 971 0.25 0.16 0 0 0 0
Fetch 971 0.53 0.65 0 13605 0 971
total 1943 0.78 0.81 0 13605 0 971
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
971 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=17489 pr=0 pw=0 time=877481 us)
2913 NESTED LOOPS (cr=16518 pr=0 pw=0 time=1643550 us)
971 NESTED LOOPS (cr=11663 pr=0 pw=0 time=658551 us)
971 NESTED LOOPS (cr=5837 pr=0 pw=0 time=95374 us)
971 TABLE ACCESS BY INDEX ROWID FND_CONCURRENT_REQUESTS (cr=2924 pr=0 pw=0 time=63054 us)
971 INDEX UNIQUE SCAN FND_CONCURRENT_REQUESTS_U1 (cr=1953 pr=0 pw=0 time=43874 us)(object id 240792)
971 TABLE ACCESS BY INDEX ROWID FND_CONCURRENT_PROGRAMS (cr=2913 pr=0 pw=0 time=28198 us)
971 INDEX UNIQUE SCAN FND_CONCURRENT_PROGRAMS_U1 (cr=1942 pr=0 pw=0 time=17956 us)(object id 849182)
971 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=5826 pr=0 pw=0 time=558105 us)
971 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=4855 pr=0 pw=0 time=539171 us)(object id 906518)
971 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=4855 pr=0 pw=0 time=172115 us)(object id 906518)
SELECT MAX(LT.SECURITY_GROUP_ID)
FROM
FND_LOOKUP_TYPES LT WHERE LT.VIEW_APPLICATION_ID = :B2 AND LT.LOOKUP_TYPE =
:B1 AND LT.SECURITY_GROUP_ID IN (0,
TO_NUMBER(DECODE(SUBSTRB(USERENV('CLIENT_INFO'),55,1), ' ', '0', NULL, '0',
SUBSTRB(USERENV('CLIENT_INFO'),55,10))))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1945 0.11 0.11 0 0 0 0
Fetch 1945 0.18 0.10 0 3890 0 1945
total 3891 0.29 0.21 0 3890 0 1945
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Rows Row Source Operation
1945 SORT AGGREGATE (cr=3890 pr=0 pw=0 time=142954 us)
1945 FIRST ROW (cr=3890 pr=0 pw=0 time=96520 us)
1945 INDEX RANGE SCAN (MIN/MAX) FND_LOOKUP_TYPES_U1 (cr=3890 pr=0 pw=0 time=89938 us)(object id 906517)
INSERT INTO HRAPPS.SLC_HRINF_INT_SUMMARY (INT_SUMMARY_ID,
INT_SUMMARY_CREATE_DATE ,INT_SUMMARY_LAST_UPDATE_DATE, INTERFACE_NAME ,
HANDLER_CONC_REQUEST_ID, INT_CONC_REQUEST_ID ,SET_SEQUENCE_NUMBER,
SET_RECORD_COUNT, INT_FROM_DATE ,INT_TO_DATE, INT_STATUS_1_STATE,
INT_STATUS_1_MESSAGE ,INT_STATUS_1_STARTED, INT_STATUS_1_COMPLETED ,
INT_STATUS_1_SUCCESS_COUNT, INT_STATUS_1_ERROR_COUNT ,INT_STATUS_2_STATE,
INT_STATUS_2_MESSAGE ,INT_STATUS_2_STARTED, INT_STATUS_2_COMPLETED ,
INT_STATUS_2_SUCCESS_COUNT, INT_STATUS_2_ERROR_COUNT ,INT_STATUS_3_STATE,
INT_STATUS_3_MESSAGE ,INT_STATUS_3_STARTED, INT_STATUS_3_COMPLETED ,
INT_STATUS_3_SUCCESS_COUNT, INT_STATUS_3_ERROR_COUNT ,INT_STATUS_4_STATE,
INT_STATUS_4_MESSAGE ,INT_STATUS_4_STARTED, INT_STATUS_4_COMPLETED ,
INT_STATUS_4_SUCCESS_COUNT, INT_STATUS_4_ERROR_COUNT ,INT_STATUS_5_STATE,
INT_STATUS_5_MESSAGE ,INT_STATUS_5_STARTED, INT_STATUS_5_COMPLETED ,
INT_STATUS_5_SUCCESS_COUNT, INT_STATUS_5_ERROR_COUNT )
VALUES
(:B7 , :B6 , :B6 , :B5 , :B4 , NULL , NULL, NULL, :B3 , :B2 , :B1 , NULL ,
NULL, NULL , NULL, NULL , :B1 , NULL , NULL, NULL , NULL, NULL , :B1 , NULL
, NULL, NULL , NULL, NULL , :B1 , NULL , NULL, NULL , NULL, NULL , :B1 ,
NULL , NULL, NULL , NULL, NULL )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.12 12 1 12 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.01 0.12 12 1 12 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 70 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 12 0.02 0.12
Thanks & Regards,
Rup

Hi;
Please check our previous topic
Concurrent manager real time tune
Oracle apps database
tune concurrent manager
Oracle apps database
Concurrent Manager very slow
Concurrent Manager very slow........
Regard
Helios

Report Performance Issue - Activity

Hi gurus,
I'm developing an Activity report using Transactional database (Online real time object).
the purpose of the report is to list down all contacts related activities and activities NOT related to Contact by activity owner (user id).
In order to fullfill that requirment I've created 2 report
1) All Activities related to Contact -- Report A
pull in Acitivity ID , Activity Type, Status, Contact ID
2) All Activities not related to Contact UNION All Activities related to Contact (Base report) -- Report B
to get the list of activities not related to contact i'm using Advanced filter based on result of another request which is I think is the part that slow down the query.
<Activity ID not equal to any Activity ID in Report B>
Anyone encountered performance issue due to the advanced filter in analytic before?
any input is really appriciated
Thanks in advanced,
Fina

Fina,
Union is always the last option. If you can get all record in one report, do not use union.
since all records, which you are targeting, are in the activity subject area, it is not nessecery to combine reports. add a column with the following logic
if contact id is null (or = 'Unspecified') then owner name else contact name
Hopefully, this is helping.

Performance issues with class loader on Windows server

We are observing some performance issues in our application. We are Using weblogic 11g with Java6 on a windows 2003 server
The thread dumps indicate many threads are waiting in queue for the native file methods:
"[ACTIVE] ExecuteThread: '106' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE
     java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
     java.io.File.exists(Unknown Source)
     weblogic.utils.classloaders.ClasspathClassFinder.getFileSource(ClasspathClassFinder.java:398)
     weblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:347)
     weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:316)
     weblogic.application.io.ManifestFinder.getSource(ManifestFinder.java:75)
     weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
     weblogic.application.utils.CompositeWebAppFinder.getSource(CompositeWebAppFinder.java:71)
     weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
     weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:67)
     weblogic.utils.classloaders.CodeGenClassFinder.getSource(CodeGenClassFinder.java:33)
     weblogic.utils.classloaders.GenericClassLoader.findResource(GenericClassLoader.java:210)
     weblogic.utils.classloaders.GenericClassLoader.getResourceInternal(GenericClassLoader.java:160)
     weblogic.utils.classloaders.GenericClassLoader.getResource(GenericClassLoader.java:182)
     java.lang.ClassLoader.getResourceAsStream(Unknown Source)
     javax.xml.parsers.SecuritySupport$4.run(Unknown Source)
     java.security.AccessController.doPrivileged(Native Method)
     javax.xml.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
     javax.xml.parsers.FactoryFinder.findJarServiceProvider(Unknown Source)
     javax.xml.parsers.FactoryFinder.find(Unknown Source)
     javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
     org.ajax4jsf.context.ResponseWriterContentHandler.<init>(ResponseWriterContentHandler.java:48)
     org.ajax4jsf.context.ViewResources$HeadResponseWriter.<init>(ViewResources.java:259)
     org.ajax4jsf.context.ViewResources.processHeadResources(ViewResources.java:445)
     org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:193)
     org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
     org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
On googling this seems to be an issue with java file handling on windows servers and I couldn't find a solution yet. Any recommendation or pointer is appreciated

Hi shubhu,
I just analyzed your partial Thread Dump data, the problem is that the ajax4jsf framework ResponseWriterContentHandler triggers internally a new instance of the DocumentBuilderFactory; every time; triggering heavy IO contention because of Class loader / JAR file search operations.
Too many of these IO operations under heavy load will create excessive contention and severe performance degradation; regardless of the OS you are running your JVM on.
Please review the link below and see if this is related to your problem.. This is a known issue in JBOSS JIRA when using RichFaces / ajaxJSF.
https://issues.jboss.org/browse/JBPAPP-6166
Regards,
P-H
http://javaeesupportpatterns.blogspot.com/

Performance Issues with 10.6.7 and External USB Drives

I've had a few performance issues come up with the latest 10.6.7 that seem to be related to external USB drives. I have a 2TB USB drive tha I have my iMovie content on this drive and after 10.6.7 update, iMovie is almost unusable. Finder even seems slow when browsing files on this drive as well. It seems like any access to the drive is delayed in all applications. Before the update, the performance was acceptable, but now it almost unusable. Most of the files on this drive are large dv files.
Anyone else experience this?

Matt,
If you want help, please start your own thread here:
http://discussions.apple.com/forum.jspa?forumID=1339&start=0
And if your previous thread you aren't getting sufficient help for your iPhone, post a new topic here:
http://discussions.apple.com/forum.jspa?forumID=1139
You'll get a wider audience, and won't confuse the original poster. Performance issues can be caused by numerous issues as outlined in my FAQ*
http://www.macmaps.com/Macosxspeed.html
If every person who had a performance issue posted to this thread, we'd never find a solution for the initial poster. Let's isolate each case one by one. It is NOT necessarily the same issue, even if the symptoms are the same. There are numerous contributing factors at work with computers, and if we don't isolate them, we'll never get to the root cause.

Performance issues with LOV bindings in 3-tier BC4J architecture

We are running BC4J and JClient (Jdeveloper 9.0.3.4/9iAS 9.0.2) in a 3-tier architecture, and have problems with the performance.
One of our problems are comboboxes with LOV bindings. The view objects that provides data for the LOV bindings contains simple queries from tables with only 4-10 rows, and there are no view links or entity objects to these views.
To create the LOV binding and to set the model for the combobox takes about 1 second for each combobox.
We have tried most of tips in http://otn.oracle.com/products/jdev/tips/muench/jclientperf/index.html, but they do not seem to help on our problem.
The performance is OK (if not great) when the same code is running as 2-tier.
Does anyone have any good suggestions?

I can recommend that you look at the following two bugs in Metalink: Bug 2640945 and Bug 3621502
They are related to the disabling of the TCP socket-level acknowledgement which slows down remote communications for EJB components using ORMI (the protocol used by Oracle OC4J) to communicate between remote EJB client and server.
A BC4J Application Module deployed as an EJB suffers this same network latency penalty due to the TCP acknowledgement.
A customer sent me information (that you'll see there as a part of Bug# 3621502) like this on a related issue:
We found our application runs very slow in 3-Tier mode (JClient, BC4J deployed
as EJB Session Bean on 9iAS server 9.0.2 enterprise edition). We spent a lot
of time to tune up our codes but that helped very little. Eventually, we found
the problem seemed to happen on TCP level. There is a 200ms delay in TCP
level. After we read some documents about Nagle Algorithm, we disabled a
registry key (TcpDelAckTicks) in windows2000 on both client and server. This
makes our program a lot faster.
Anyway, we think we should provide our clients a better solution other than
changing windows registry for them, for example, there may be a way to disable
that Nagle's algorithm through java.net.Socket.setTcpNoDelay(true), in BC4J,
or anywhere in our codes. We have not figured out yet.
Bug 2640945 was fixed in Oracle Application Server 10g (v9.0.4) and it now disables this TCP Acknowledgement on the server side in that release. In the BugDB, I see backport patches available for earlier 9.0.3 and 9.0.2 releases of IAS as well.
Bug 3621502 is requesting that that same disabling also be performed on the client side by the ORMI code. I have received a test patch from development to try out, but haven't had the chance yet.
The customer's workaround in the interim was to disable this TCP Acknowledgement at the OS level by modifying a Windows registry setting as noted above.
See Also http://support.microsoft.com/default.aspx?kbid=328890
"New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003" which documents that the registry entry to change disable this acknowledgement has a different name in Windows XP and Windows 2003.
Hope this info helps. It would be useful to hear back from you on whether this helps your performance issue.

Performance Issues with large XML (1-1.5MB) files

Hi,
I'm using an XML Schema based Object relational storage for my XML documents which are typically 1-1.5 MB in size and having serious performance issues with XPath Query.
When I do XPath query against an element of SQLType varchar2, I get a good performance. But when I do a similar XPath query against an element of SQLType Collection (Varray of varchar2), I get a very ordinary performance.
I have also created indexes on extract() and analyzed my XMLType table and indexes, but I have no performance gain. Also, I have tried all sorts of storage options available for Collections ie. Varray's, Nested Tables, IOT's, LOB's, Inline, etc... and all these gave me same bad performance.
I even tried creating XMLType views based on XPath queries but the performance didn't improve much.
I guess I'm running out of options and patience as well.;)
I would appreciate any ideas/suggestions, please help.....
Thanks;
Ramakrishna Chinta

Are you having similar symptoms as I am? http://discussions.apple.com/thread.jspa?threadID=2234792&tstart=0

Language related performance issues in PS HRMS

Similar Messages

Maybe you are looking for