Performance issue in process lockbox

Hi all,
As per our client request, we customized process lockbox, splited validation and process lockbox seperately. We have 11 files to process daily.
Nowadays we are receiving huge files with more than 20K records. Process lockboxes is taking more than 8 hours to complete and also incompatibility is set for the process locbox by itself. SO we are unable to run parallelly also.
Our instance is 11.5 and no customization in process locbox concurrent program.
Is there any way to improve the performance of process lockbox?
Is there anyway to run in parallel?
Input will be very helpful for us..
Please post u r valuable inputs..
Thanks,
Sundar

Hussein/Srini
I am trying to get the trace and also regarding profile values.. Let me found out is there any change in improvement.
I have one more info to share.
From log file, we found that few blocks taking more time. For one file, 3 blocks take half of the execution time.
From log file,
entering arlpid
Current system time is 24-AUG-2010 08:25:29
exiting arlpid
Current system time is 24-AUG-2010 09:13:41
entering arlvcc
Current system time is 24-AUG-2010 09:19:19
exiting arlvcc
Current system time is 24-AUG-2010 10:20:55
entering arlvin-111
Current system time is 24-AUG-2010 10:23:42
exiting arlvin
Current system time is 24-AUG-2010 11:16:33
Total time taken to process 3211 file is ~ 350 minutes. But above three blocks were costing more. They have consumed ~170 minutes i.e. half of the execution time.
What is this blocks?
This there anyway to analyse this block and improve th performace?

Similar Messages

RKKBABS0 Performance Issues (Background Processing of CO99) for PM Orders

We are experiencing extremely long run times when batch processing through program RKKBABS0 in ECC 6.0 (just upgraded). The issue appears to be that the program is using the production order numbers to search against the EXKN table which contains no AUFNR or AUFPL information.
Has anyone experienced this same issue and how was it resolved?
Edited by: Ken Lundeen on Apr 9, 2010 9:17 PM
Edited by: Ken Lundeen on Apr 9, 2010 9:17 PM Table ESKN

(I'm sorry you've waited over a year for a reply.)
We also have performance issue. In our case we do not use Service Entry sheets with maintenance or production orders; AUFNR will not be populated in table ESKN. We are unable to 'complete business' our maintenance and production orders using batch processing because of performance.
We use Oracle database, which uses full table scan in this situation. But Secondary index (MANDT and AUFNR) is of no value anyway, we have about 12 million records with client and blank AUFNR field.
Our solution is a combination of a modification and a new index. OSS pilot note "1532483 - Performance of RKKBABS0 CHECK_ENTRYSHEET when reading ESKN" is a modification which introduces code improvements especially if running in background and closing several orders. Because we only have one client, we also created a new index consisting only of AUFNR. Oracle will not add a row to the secondary index of all fields of the index are null, making our new index very small. We then udpated Oracle stats to ensure Oracle would choose our new index.
We can now 'complete business' a single order online in under a minute, and the batch program runs much more efficiently.
This is not a perfect solution, but it has been a useful workaround for us. I hope this is useful to you.

Performance issues executing process flows after upgrading db to 10G

We have installed OWF 2.6.2, and initially our database was at 9.2. Last week we updated our database to 10g, and process flow executions are taking a lot longer, from 1 minute to 15 minutes.
Any ideas anyone what could be the cause of this performance issue?
Thanks,
Yanet

Hi,
Oracle10g database behaves differently on the statistics of tables and indexes. So check these and check wether the mappings are updating these statistics at the right moments with respect to the ETL-proces and with the right interval.
Also, check your generated sources on how statistics are gathered (dmbs_stats.gather....). Does the index that might play a vital role in Oracle9i get new statistics, or only the table? Or only the table where doubled in amount of rows by this mapping?
You can always take matter into your own hands, by letting OWB NOT generate the source for gathering statistics, and call your own procedure in a post-mapping.
Regards,
André

Performance issue in DB need help with analysing this ADDM report

Hi,
My environment:
Os: RHEL5U3 / 11.1.0.7 64 bit / R12.1.1 64 bit
Issue:
Few days are am facing serious of performance problem in our Production instance. Normally the issue will occur 5 to 10 minutes occasionally per day. At the time of issue we not able to access the EBS application its taking time to load. But backend all the oracle, listener and apps services are up and running. No locks at table and session level. Cpu and memory usage is normal.
We have monitored using "Enterprise Manager" for this issue and we found the wait session present more in Active session tab. At this time EBS application is not able access its loading too time. After some time the in Active session tab the wait session came normal and when we try to access the EBS application its working fine.
We try to find the cause of the issue by running addm report. But am not able to understand what its says. Kindly suggests me
ADDM Report for Task 'TASK_42656'
Analysis Period
AWR snapshot range from 14754 to 14755.
Time period starts at 17-APR-12 11.00.22 AM
Time period ends at 17-APR-12 12.00.33 PM
Analysis Target
Database 'PRD' with DB ID 1789440879.
Database version 11.1.0.7.0.
ADDM performed an analysis of instance PRD, numbered 1 and hosted at
advgrpdb.advgroup.ae.
Activity During the Analysis Period
Total database time was 18674 seconds.
The average number of active sessions was 5.17.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Top SQL by DB Time 3.43 | 66.33 5
2 Buffer Busy 2.52 | 48.81 5
3 Buffer Busy 1.39 | 26.81 2
4 Log File Switches .91 | 17.56 1
5 Buffer Busy .56 | 10.87 2
6 Undersized SGA .38 | 7.37 1
7 Commits and Rollbacks .28 | 5.42 1
8 Undo I/O .18 | 3.53 0
9 CPU Usage .13 | 2.57 1
10 Top SQL By I/O .11 | 2.21 1
Findings and Recommendations
Finding 1: Top SQL by DB Time
Impact is 3.43 active sessions, 66.33% of total activity.
SQL statements consuming significant database time were found.
Recommendation 1: SQL Tuning
Estimated benefit is 1.59 active sessions, 30.8% of total activity.
Action
Investigate the SQL statement with SQL_ID "a49xsqhv0h31b" for possible
performance improvements.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
Rationale
SQL statement with SQL_ID "a49xsqhv0h31b" was executed 4686 times and
had an average elapsed time of 1.2 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 85% of the database time spent in processing the SQL
statement with SQL_ID "a49xsqhv0h31b".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 9% of the database time spent in
processing the SQL statement with SQL_ID "a49xsqhv0h31b".
Recommendation 3: SQL Tuning
Estimated benefit is .56 active sessions, 10.91% of total activity.
Action
Investigate the SQL statement with SQL_ID "5d7957yktf3nn" for possible
performance improvements.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
SQL statement with SQL_ID "5d7957yktf3nn" was executed 266 times and had
an average elapsed time of 7.6 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 86% of the database time spent in processing the SQL
statement with SQL_ID "5d7957yktf3nn".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 7% of the database time spent in
processing the SQL statement with SQL_ID "5d7957yktf3nn".
Finding 2: Buffer Busy
Impact is 2.52 active sessions, 48.81% of total activity.
Read and write contention on database blocks was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is 1.42 active sessions, 27.44% of total activity.
Action
Trace the cause of object contention due to SELECT statements in the
application using the information provided.
Related Object
Database object with ID 34562.
Rationale
The SELECT statement with SQL_ID "a49xsqhv0h31b" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 1: Schema Changes
Estimated benefit is .03 active sessions, .62% of total activity.
Action
Consider rebuilding the TABLE "APPLSYS.FND_LOGIN_RESP_FORMS" with object
ID 34651 using a higher value for PCTFREE.
Related Object
Database object with ID 34651.
Rationale
The UPDATE statement with SQL_ID "cqc5crhxxt36t" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID cqc5crhxxt36t.
UPDATE FND_LOGIN_RESP_FORMS FLRF SET END_TIME = SYSDATE WHERE
FLRF.LOGIN_ID = :B2 AND FLRF.LOGIN_RESP_ID = :B1 AND FLRF.END_TIME IS
NULL AND (FLRF.FORM_ID, FLRF.FORM_APPL_ID) = (SELECT F.FORM_ID,
F.APPLICATION_ID FROM FND_FORM F, FND_APPLICATION A WHERE F.FORM_NAME
= :B4 AND F.APPLICATION_ID = A.APPLICATION_ID AND
A.APPLICATION_SHORT_NAME = :B3 )
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 4: Log File Switches
Impact is .91 active sessions, 17.56% of total activity.
Log file switch operations were consuming significant database time while
waiting for checkpoint completion.
This problem can be caused by use of hot backup mode on tablespaces. DML to
tablespaces in hot backup mode causes generation of additional redo.
Recommendation 1: Database Configuration
Estimated benefit is .91 active sessions, 17.56% of total activity.
Action
Verify whether incremental shipping was used for standby databases.
Symptoms That Led to the Finding:
Wait class "Configuration" was consuming significant database time.
Impact is .91 active sessions, 17.63% of total activity.
Finding 5: Buffer Busy
Impact is .56 active sessions, 10.87% of total activity.
A hot data block with concurrent read and write activity was found. The block
belongs to segment "ICX.ICX_SESSIONS" and is block 243489 in file 36.
Recommendation 1: Application Analysis
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Investigate application logic to find the cause of high concurrent read
and write activity to the data present in this block.
Related Object
Database block with object number 37562, file number 36 and block
number 243489.
Rationale
The SQL statement with SQL_ID "5d7957yktf3nn" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
The SQL statement with SQL_ID "326up1aym56dd" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 326up1aym56dd.
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 2: Schema Changes
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Consider rebuilding the TABLE "ICX.ICX_SESSIONS" with object ID 37562
using a higher value for PCTFREE.
Related Object
Database object with ID 37562.
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 6: Undersized SGA
Impact is .38 active sessions, 7.37% of total activity.
The SGA was inadequately sized, causing additional I/O or hard parses.
The value of parameter "sga_target" was "4096 M" during the analysis period.
Recommendation 1: Database Configuration
Estimated benefit is .12 active sessions, 2.33% of total activity.
Action
Increase the size of the SGA by setting the parameter "sga_target" to
4608 M.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Hard parsing of SQL statements was consuming significant database time.
Impact is .13 active sessions, 2.51% of total activity.
Contention for latches related to the shared pool was consuming
significant database time.
Impact is 0 active sessions, .03% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 7: Commits and Rollbacks
Impact is .28 active sessions, 5.42% of total activity.
Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
were consuming significant database time.
Recommendation 1: Host Configuration
Estimated benefit is .28 active sessions, 5.42% of total activity.
Action
Investigate the possibility of improving the performance of I/O to the
online redo log files.
Rationale
The average size of writes to the online redo log files was 163 K and
the average time per write was 68 milliseconds.
Symptoms That Led to the Finding:
Wait class "Commit" was consuming significant database time.
Impact is .28 active sessions, 5.42% of total activity.
Finding 8: Undo I/O
Impact is .18 active sessions, 3.53% of total activity.
Undo I/O was a significant portion (26%) of the total database I/O.
No recommendations are available.
Symptoms That Led to the Finding:
The throughput of the I/O subsystem was significantly lower than
expected.
Impact is .08 active sessions, 1.46% of total activity.
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Finding 9: CPU Usage
Impact is .13 active sessions, 2.57% of total activity.
Time spent on the CPU by the instance was responsible for a substantial part
of database time.
Recommendation 1: SQL Tuning
Estimated benefit is .13 active sessions, 2.57% of total activity.
Finding 10: Top SQL By I/O
Impact is .11 active sessions, 2.21% of total activity.
Individual SQL statements responsible for significant user I/O wait were
found.
Recommendation 1: SQL Tuning
Estimated benefit is .11 active sessions, 2.22% of total activity.
Action
Run SQL Tuning Advisor on the SQL statement with SQL_ID "b3pnc5yctv2z5".
Related Object
SQL statement with SQL_ID b3pnc5yctv2z5.
INSERT INTO ZX_TRANSACTION_LINES_GT( APPLICATION_ID ,ENTITY_CODE
,EVENT_CLASS_CODE ,TRX_ID ,TRX_LEVEL_TYPE ,TRX_LINE_ID ,LINE_CLASS
,LINE_LEVEL_ACTION ,TRX_LINE_TYPE ,TRX_LINE_DATE
,LINE_AMT_INCLUDES_TAX_FLAG ,LINE_AMT ,TRX_LINE_QUANTITY ,UNIT_PRICE
,PRODUCT_ID ,PRODUCT_ORG_ID ,UOM_CODE ,PRODUCT_CODE ,SHIP_TO_PARTY_ID
,SHIP_FROM_PARTY_ID ,BILL_TO_PARTY_ID ,BILL_FROM_PARTY_ID
,SHIP_FROM_PARTY_SITE_ID ,BILL_FROM_PARTY_SITE_ID
,SHIP_TO_LOCATION_ID ,SHIP_FROM_LOCATION_ID ,BILL_TO_LOCATION_ID
,SHIP_THIRD_PTY_ACCT_ID ,SHIP_THIRD_PTY_ACCT_SITE_ID ,HISTORICAL_FLAG
,TRX_LINE_CURRENCY_CODE ,TRX_LINE_CURRENCY_CONV_DATE
,TRX_LINE_CURRENCY_CONV_RATE ,TRX_LINE_CURRENCY_CONV_TYPE
,TRX_LINE_MAU ,TRX_LINE_PRECISION ,HISTORICAL_TAX_CODE_ID
,TRX_BUSINESS_CATEGORY ,PRODUCT_CATEGORY ,PRODUCT_FISC_CLASSIFICATION
,LINE_INTENDED_USE ,PRODUCT_TYPE ,USER_DEFINED_FISC_CLASS
,ASSESSABLE_VALUE ,INPUT_TAX_CLASSIFICATION_CODE ,ACCOUNT_CCID
,BILL_THIRD_PTY_ACCT_ID ,BILL_THIRD_PTY_ACCT_SITE_ID ,TRX_LINE_NUMBER
,TRX_LINE_DESCRIPTION ,PRODUCT_DESCRIPTION ,USER_UPD_DET_FACTORS_FLAG
,DEFAULTING_ATTRIBUTE1 ) SELECT :B4 ,:B3 ,:B2
,PRL.REQUISITION_HEADER_ID ,:B1 ,PRL.REQUISITION_LINE_ID ,'INVOICE'
,NVL(PRL.TAX_ATTRIBUTE_UPDATE_CODE,'UPDATE') ,'ITEM'
,NVL(PRL.NEED_BY_DATE, SYSDATE) ,'N' ,NVL(PRL.AMOUNT,
PRL.UNIT_PRICE*PRL.QUANTITY) ,PRL.QUANTITY ,PRL.UNIT_PRICE
,PRL.ITEM_ID ,(SELECT FSP.INVENTORY_ORGANIZATION_ID FROM
FINANCIALS_SYSTEM_PARAMS_ALL FSP WHERE FSP.ORG_ID=PRL.ORG_ID)
,(SELECT MUM.UOM_CODE FROM MTL_UNITS_OF_MEASURE MUM WHERE
MUM.UNIT_OF_MEASURE=PRL.UNIT_MEAS_LOOKUP_CODE) ,MSIB.SEGMENT1
,PRL.DESTINATION_ORGANIZATION_ID ,PV.PARTY_ID ,PRH.ORG_ID
,PV.PARTY_ID ,PVS.PARTY_SITE_ID ,PVS.PARTY_SITE_ID
,PRL.DELIVER_TO_LOCATION_ID ,(SELECT HZPS.LOCATION_ID FROM
HZ_PARTY_SITES HZPS WHERE HZPS.PARTY_SITE_ID = PVS.PARTY_SITE_ID)
,(SELECT LOCATION_ID FROM HR_ALL_ORGANIZATION_UNITS WHERE
ORGANIZATION_ID=PRH.ORG_ID) ,PRL.VENDOR_ID ,PRL.VENDOR_SITE_ID ,NULL
,NVL(PRL.CURRENCY_CODE, :B9 ) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE_DATE,
SYSDATE) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE, :B8 )
,NVL2(PRL.CURRENCY_CODE, PRL.RATE_TYPE, :B7 )
,FC.MINIMUM_ACCOUNTABLE_UNIT ,NVL(FC.PRECISION, 2) ,NULL
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.TRX_BUSINESS_CATEGORY, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_CATEGORY, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_FISC_CLASSIFICATION,
NULL), NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.LINE_INTENDED_USE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_TYPE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.USER_DEFINED_FISC_CLASS, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.ASSESSABLE_VALUE, NULL), NULL )
,DECODE(:B6 , 'REQIMPORT', PRL.TAX_NAME,
DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.INPUT_TAX_CLASSIFICATION_CODE,
NULL), NULL ) ) ,NVL((SELECT PRD.CODE_COMBINATION_ID FROM
PO_REQ_DISTRIBUTIONS_ALL PRD WHERE PRD.REQUISITION_LINE_ID =
PRL.REQUISITION_LINE_ID AND ROWNUM = 1), MSIB.EXPENSE_ACCOUNT )
,PV.VENDOR_ID ,PVS.VENDOR_SITE_ID ,PRL.LINE_NUM ,PRL.ITEM_DESCRIPTION
,PRL.ITEM_DESCRIPTION ,(SELECT 'Y' FROM DUAL WHERE :B6 = 'REQIMPORT'
AND PRL.TAX_NAME IS NOT NULL) ,PRL.DESTINATION_ORGANIZATION_ID FROM
PO_REQUISITION_HEADERS_ALL PRH, PO_REQUISITION_LINES_ALL PRL,
ZX_LINES_DET_FACTORS ZXLDET, PO_VENDORS PV, PO_VENDOR_SITES_ALL PVS,
MTL_SYSTEM_ITEMS_B MSIB, FND_CURRENCIES FC WHERE
PRH.REQUISITION_HEADER_ID = :B5 AND PRH.REQUISITION_HEADER_ID =
PRL.REQUISITION_HEADER_ID AND ZXLDET.APPLICATION_ID(+) = :B4 AND
ZXLDET.ENTITY_CODE(+) = :B3 AND ZXLDET.EVENT_CLASS_CODE(+) = :B2 AND
ZXLDET.TRX_LEVEL_TYPE(+) = :B1 AND ZXLDET.TRX_LINE_ID(+) =
PRL.PARENT_REQ_LINE_ID AND PV.VENDOR_ID(+) = PRL.VENDOR_ID AND
PVS.VENDOR_SITE_ID(+) = PRL.VENDOR_SITE_ID AND
MSIB.INVENTORY_ITEM_ID(+) = PRL.ITEM_ID AND MSIB.ORGANIZATION_ID(+) =
PRL.ORG_ID AND FC.CURRENCY_CODE(+) = PRL.CURRENCY_CODE AND
NVL(PRL.MODIFIED_BY_AGENT_FLAG, 'N') = 'N' AND NVL(PRL.CANCEL_FLAG,
'N') = 'N' AND NVL(PRL.CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED' AND
PRL.LINE_LOCATION_ID IS NULL AND PRL.AT_SOURCING_FLAG IS NULL
Rationale
SQL statement with SQL_ID "b3pnc5yctv2z5" was executed 3 times and had
an average elapsed time of 138 seconds.
Rationale
Average time spent in User I/O wait events per execution was 137
seconds.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
Regards
Athish

Few days are am facing serious of performance problem in our Production instanceFor production issues, please log a SR.
Was this working before? If yes, any changes been done recently?
Do you have the statistics collected up to date?
Please see these docs.
AutoInvoice Performance Issue When Processing Tax [ID 1059275.1]
R12 : System Hangs When Attempting To Save Blanket Release After Applying Patch 11817843 [ID 1333336.1]
Thanks,
Hussein

Process flow/map performance issues

We have some issues with our OWB-based application and we're looking to find out if there are different ways we could be using the tool, or features/options we've missed.
We are trying to maintain a near real time feed of data from a front end system into our warehouse which was built using OWB 10.2.0.3 over a 10.2.0.4 database. The bulk of the application consists of OWB maps with a few hand-written PL/SQL objects, all executed in a series of hierachical OWB process flows. Maps/transformations are executed either sequentially or in parallel where the referential integrity of the model allows.
The problem is that we have around 150 tables in the datamart which could potentially require updating on each refresh cycle, although in practice only a few tables have any activity on a typical refresh cycle. The cycle consists of loading data into a set of staging tables, and from there the data is transformed into the main schema, often with multiple maps per target table.
On every cycle we run hundreds of maps, the vast majority of which process zero rows. Each map runs quickly and efficiently in its own right but collectively they add up to a 5 - 10 min cycle even if there is no data to process.
There are 2 avenues which we'd like to explore and would be grateful if anyone could provide any pointers/suggestions :-
1) It appears that each map opens and closes its own database session when it executes. I presume this was done because a single process flow could be constructed with maps executing in different target schemas, but we know that's not the case for us. We'd like to know if there is anyway to configure the database connection at a higher level (eg. process flow) so it opens a connection once and executes each of the maps (database packages) in that one session.
Our DBAs are experimenting with 'shared server' settings at a database level which may help to some degree but won't be the whole story.
2) Another option is simply to run less maps eg. load the staging area as now, collate stats on which staging tables contain new data, and then apply some logic such that subsequent maps only execute if the relevant staging table(s) contain(s) some new data, otherwise bypass that map.
We tried experimenting with the 'Pre Mapping Process' operator, but essentially that just generates another function call from the map package, so we still have the overhead of opening a database session for each map to run the package. Minimal gain.
We thought about adding a function call in the process flow before each map and then branching to either execute/bypass the map as approriate, but the function call still requires opening/closing of a database session each time so, once again, minimal gain.
What we really want is some way for a map or process flow to check without logging onto the database repeatedly.
Any ideas on the above, or other potential solutions anyone could suggest, would be greatly appreciated.

Hi,
Please see if these documents help.
Note: 554635.1 - Create Accounting Process Performs Poorly When 100K + Distributions are Passed for an Event
Note: 954273.1 - Multiple Create Accounting Requests Result In Poor Performance For Online Accruals
Note: 763500.1 - R12: Performance Issue with Create Accounting
Note: 733637.1 - R12:Performance Issue When Running Accounting Program Xlaaccup
Note: 781311.1 - Create Accounting Process Taking A Long Time To Complete After Appying Critical Patches
Note: 557869.1 - EBS: R12 Oracle Financials Critical Patches
Regards,
Hussein

Info Package in Process Chain - Performance Issue

Dear All,
We have some Info Package in Process Chain which when triggered initially turns red, then again yellow, after sometime red/green. These status keeps changing and finally results in green status. These infopackage takes 15-30 mins to complete.
And the info package error message shows "Processing time overdue". The chain runs daily and this issue also occurs on a daily basis.
Does anyone one of you have an idea of how to deal with this performance issue?
Regards.

Hi
As you said--
"initially time out time was set to 10 mins, so it was turning red at 10 mins. Later i changed it to 30 mins, then it is turning red at 30 mins, this info package takes maximum 20 mins to complete.
thatsy i asked whether there will be any problem if we remove this time out time."
I guess, its not mandatory to include the timeout value. Just try to execute the IP without entering the timeout value.
It should work.
Let me know if this helps.
Regards
SaiPrasad

Annotation process tools build performance issue

Annotation process tools is taking 85 minutes to compile page flow files. Is there any suggestion to improve performance.

As you probably already have gathered, you have different execution plans in the two environments. There could be different reason why this happens, for instance different profiles of the data. But more likely it is due to that in the slow environment, the
plan was built from some atypical set of input parameters, which causes a performance issue when the procedure is run in a normal fashion.
When you say that the query has a lot of isnull and convert functions I get a little worried. If it is only in the SELECT list, it's not evil, but if functions are used in the WHERE or ON clauses, the query might benefit from a review, and possibly also
the data model. But this is pure speculation at this point.
I would suggest more than one course of action. As a short-term solution, you run UPDATE STATISTICS WITH FULLSCAN on all tables involved, as out-dated statistics can also be explanation for why you got a bad plan. New statistics should trigger a recompilation.
But even if this resolves the issue, it may not be feasible in the long run, because the events indicate that the query is sensitive to something and the bad plan could come back any day. For this reason, it might be a good idea to make sure that the query
does include inappropriate constructs, and you also need to review that there are good indexes in place.
Erland Sommarskog, SQL Server MVP, [email protected]

Interested by performance issue ? Read this ! If you can explain, you're a master Jedi !

This is the question we will try to answer...
What si the bottle neck (hardware) of Adobe Premiere Pro CS6
I used PPBM5 as a benchmark testing template.
All the data and log as been collected using performance counter
First of all, describe my computer...
Operating System
Microsoft Windows 8 Pro 64-bit
CPU
Intel Xeon E5 2687W @ 3.10GHz
Sandy Bridge-EP/EX 32nm Technology
RAM
Corsair Dominator Platinum 64.0 GB DDR3
Motherboard
EVGA Corporation Classified SR-X
Graphics
PNY Nvidia Quadro 6000
EVGA Nvidia GTX 680 // Yes, I created bench stats for both card
Hard Drives
16.0GB Romex RAMDISK (RAID)
556GB LSI MegaRAID 9260-8i SATA3 6GB/s 5 disks with Fastpath Chip Installed (RAID 0)
I have other RAID installed, but not relevant for the present post...
PSU
Cosair 1000 Watts
After many days of tests, I wanna share my results with community and comment them.
CPU Introduction
I tested my cpu and pushed it at maximum speed to understand where is the limit, can I reach this limit and I've logged precisely all result in graph (See pictures 1).
Intro : I tested my E5-XEON 2687W (8 Cores Hyperthread - 16 threads) to know if programs can use the maximum of it. I used Prime 95 to get the result. // I know this seem to be ordinary, but you will understand soon...
The result : Yes, I can get 100% of my CPU with 1 program using 20 threads in parallel. The CPU gives everything it can !
Comment : I put 3 IO (cpu, disk, ram) on the graph of my computer during the test...
(picture 1)
Disk Introduction
I tested my disk and pushed it at maximum speed to understand where is the limit and I've logged precisely all result in graph (See pictures 2).
Intro : I tested my RAID 0 556GB (LSI MegaRAID 9260-8i SATA3 6GB/s 5 disks with Fastpath Chip Installed) to know if I can reach the maximum % disk usage (0% idle Time)
The result : As you can see in picture 2, yes, I can get the max of my drive at ~ 1.2 Gb/sec read/write steady !
Comment : I put 3 IO (cpu, disk, ram) on the graph of my computer during the test to see the impact of transfering many Go of data during ~10 sec...
(picture 2)
Now, I know my limits ! It's time to enter deeper in the subject !
PPBM5 (H.264) Result
I rendered the sequence (H.264) using Adobe Media Encoder.
The result :
My CPU is not used at 100%, the turn around 50%
My Disk is totally idle !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate seem to be a wave (up and down). Probably caused by (Encrypt time.... write.... Encrypt time.... write...) // It's ok, ~5Mb/sec during transfert rate !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 39 Go RAM free after the test ! // Excellent
~65 thread opened by Adobe Media Encoder (Good, thread is the sign that program try to using many cores !)
GPU Load on card seem to be a wave also ! (up and down) ~40% usage of GPU during the process of encoding.
GPU Ram get 1.2Go of RAM (But with GTX 680, no problem and Quadro 6000 with 6 GB RAM, no problem !)
Comment/Question : CPU is free (50%), disks are free (99%), GPU is free (60%), RAM is free (62%), my computer is not pushed at limit during the encoding process. Why ???? Is there some time delay in the encoding process ?
Other : Quadro 6000 & GTX 680 gives the same result !
(picture 3)
PPBM5 (Disk Test) Result (RAID LSI)
I rendered the sequence (Disk Test) using Adobe Media Encoder on my RAID 0 LSI disk.
The result :
My CPU is not used at 100%
My Disk wave and wave again, but far far from the limit !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate wave and wave again (up and down). Probably caused by (Buffering time.... write.... Buffering time.... write...) // It's ok, ~375Mb/sec peak during transfert rate ! Easy !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 40.5 Go RAM free after the test ! // Excellent
~48 thread opened by Adobe Media Encoder (Good, thread is the sign that program try to using many cores !)
GPU Load on card = 0 (This kind of encoding is GPU irrelevant)
GPU Ram get 400Mb of RAM (No usage for encoding)
Comment/Question : CPU is free (65%), disks are free (60%), GPU is free (100%), RAM is free (63%), my computer is not pushed at limit during the encoding process. Why ???? Is there some time delay in the encoding process ?
(picture 4)
PPBM5 (Disk Test) Result (Direct in RAMDrive)
I rendered the same sequence (Disk Test) using Adobe Media Encoder directly in my RamDrive
Comment/Question : Look at the transfert rate under (picture 5). It's exactly the same speed than with my RAID 0 LSI controller. Impossible ! Look in the same picture the transfert rate I can reach with the ramdrive (> 3.0 Gb/sec steady) and I don't go under 30% of disk usage. CPU is idle (70%), Disk is idle (100%), GPU is idle (100%) and RAM is free (63%). // This kind of results let me REALLY confused. It's smell bug and big problem with hardware and IO usage in CS6 !
(picture 5)
PPBM5 (MPEG-DVD) Result
I rendered the sequence (MPEG-DVD) using Adobe Media Encoder.
The result :
My CPU is not used at 100%
My Disk is totally idle !
All the process usage are idle except process of (Adobe Media Encoder)
The transfert rate wave and wave again (up and down). Probably caused by (Encoding time.... write.... Encoding time.... write...) // It's ok, ~2Mb/sec during transfert rate ! Real Joke !
CPU Power management give 100% of clock to CPU during the encoding process (it's ok, the clock is stable during process).
RAM, more than enough ! 40 Go RAM free after the test ! // Excellent
~80 thread opened by Adobe Media Encoder (Lot of thread, but it's ok in multi-thread apps!)
GPU Load on card = 100 (This use the maximum of my GPU)
GPU Ram get 1Gb of RAM
Comment/Question : CPU is free (70%), disks are free (98%), GPU is loaded (MAX), RAM is free (63%), my computer is pushed at limit during the encoding process for GPU only. Now, for this kind of encoding, the speed limit is affected by the slower IO (Video Card GPU)
Other : Quadro 6000 is slower than GTX 680 for this kind of encoding (~20 s slower than GTX).
(picture 6)
Encoding single clip FULL HD AVCHD to H.264 Result (Premiere Pro CS6)
You can look the result in the picture.
Comment/Question : CPU is free (55%), disks are free (99%), GPU is free (90%), RAM is free (65%), my computer is not pushed at limit during the encoding process. Why ???? Adobe Premiere seem to have some bug with thread management. My hardware is idle ! I understand AVCHD can be very difficult to decode, but where is the waste ? My computer want, but the software not !
(picture 7)
Render composition using 3D Raytracer in After Effects CS6
You can look the result in the picture.
Comment : GPU seems to be the bottle neck when using After Effects. CPU is free (99%), Disks are free (98%), Memory is free (60%) and it depend of the setting and type of project.
Other : Quadro 6000 & GTX 680 gives the same result in time for rendering the composition.
(picture 8)
Conclusion
There is nothing you can do (I thing) with CS6 to get better performance actually. GTX 680 is the best (Consumer grade card) and the Quadro 6000 is the best (Profressional card). Both of card give really similar result (I will probably return my GTX 680 since I not really get any better performance). I not used Tesla card with my Quadro, but actually, both, Premiere Pro & After Effects doesn't use multi GPU. I tried to used both card together (GTX & Quadro), but After Effects gives priority to the slower card (In this case, the GTX 680)
Premiere Pro, I'm speechless ! Premiere Pro is not able to get max performance of my computer. Not just 10% or 20%, but average 60%. I'm a programmor, multi-threadling apps are difficult to manage and I can understand Adobe's programmor. But actually, if anybody have comment about this post, tricks or any kind of solution, you can comment this post. It's seem to be a bug...
Thank you.

Patrick,
I can't explain everything, but let me give you some background as I understand it.
The first issue is that CS6 has a far less efficient internal buffering or caching system than CS5/5.5. That is why the MPEG encoding in CS6 is roughly 2-3 times slower than the same test with CS5. There is some 'under-the-hood' processing going on that causes this significant performance loss.
The second issue is that AME does not handle regular memory and inter-process memory very well. I have described this here: Latest News
As to your test results, there are some other noteworthy things to mention. 3D Ray tracing in AE is not very good in using all CUDA cores. In fact it is lousy, it only uses very few cores and the threading is pretty bad and does not use the video card's capabilities effectively. Whether that is a driver issue with nVidia or an Adobe issue, I don't know, but whichever way you turn it, the end result is disappointing.
The overhead AME carries in our tests is something we are looking into and the next test will only use direct export and no longer the AME queue, to avoid some of the problems you saw. That entails other problems for us, since we lose the capability to check encoding logs, but a solution is in the works.
You see very low GPU usage during the H.264 test, since there are only very few accelerated parts in the timeline, in contrast to the MPEG2-DVD test, where there is rescaling going on and that is CUDA accelerated. The disk I/O test suffers from the problems mentioned above and is the reason that my own Disk I/O results are only 33 seconds with the current test, but when I extend the duration of that timeline to 3 hours, the direct export method gives me 22 seconds, although the amount of data to be written, 37,092 MB has increased threefold. An effective write speed of 1,686 MB/s.
There are a number of performance issues with CS6 that Adobe is aware of, but whether they can be solved and in what time, I haven't the faintest idea.
Just my $ 0.02

Performance Issue for BI system

Hello,
We are facing performance issues for BI System. Its a preproductive system and its performance is degrading badly everyday. I was checking system came to know program buffer hit ratio is increaasing everyday due to high Swaps. So asked to change the parameter abap/buffersize which was 300Mb to 500Mb. But still no major improvement is found in the system.
There is 16GB Ram available and Server is HP-UX and with Netweaver2004s with Oracle 10.2.0.4.0 installed in it.
The Main problem is while running a report or creating a query is taking way too long time.
Kindly help me.

Hello SIva,
Thanks for your reply but i have checked ST02 and ST03 and also SM50 and its normal
we are having 9 dialog processes, 3 Background , 2 Update and 1 spool.
No one is using the system currently but in ST02 i can see the swaps are in red.
Buffer                 HitRatio   % Alloc. KB Freesp. KB   % Free Sp.   Dir. Size FreeDirEnt   % Free Dir    Swaps    DB Accs
Nametab (NTAB)                                                                                0
   Table definition     99,60     6.798                                                   20.000                                            29.532    153.221
   Field definition     99,82      31.562        784                 2,61           20.000      6.222          31,11          17.246     41.248
   Short NTAB           99,94     3.625      2.446                81,53          5.000        2.801          56,02             0            2.254
   Initial records      73,95        6.625        998                 16,63          5.000        690             13,80             40.069     49.528
                                                                                0
boldprogram                97,66     300.000     1.074                 0,38           75.000     67.177        89,57           219.665    725.703bold
CUA                    99,75         3.000        875                   36,29          1.500      1.401          93,40            55.277      2.497
Screen                 99,80         4.297      1.365                 33,35          2.000      1.811          90,55              119         3.214
Calendar              100,00       488            361                  75,52            200         42              21,00               0            158
OTR                   100,00         4.096      3.313                  100,00        2.000      2.000          100,00              0
                                                                                0
Tables                                                                                0
   Generic Key          99,17    29.297      1.450                  5,23           5.000        350             7,00             2.219      3.085.633
   Single record        99,43    10.000      1.907                  19,41           500         344            68,80              39          467.978
                                                                                0
Export/import          82,75     4.096         43                      1,30            2.000        662          33,10            137.208
Exp./ Imp. SHM         89,83     4.096        438                    13,22         2.000      1.482          74,10               0
SAP Memory      Curr.Use %    CurUse[KB]    MaxUse[KB]    In Mem[KB]    OnDisk[KB]    SAPCurCach      HitRatio %
Roll area               2,22                5.832               22.856             131.072     131.072                   IDs           96,61
Page area              1,08              2.832                24.144               65.536    196.608              Statement     79,00
Extended memory     22,90       958.464           1.929.216          4.186.112          0                                         0,00
Heap memory                                    0                  0                    1.473.767          0                                         0,00
Call Stati             HitRatio %     ABAP/4 Req      ABAP Fails     DBTotCalls         AvTime[ms]      DBRowsAff.
Select single     88,59               63.073.369        5.817.659      4.322.263             0                         57.255.710
Select               72,68               284.080.387          0               13.718.442             0                        32.199.124
Insert                 0,00                  151.955             5.458             166.159               0                           323.725
Update               0,00                    378.161           97.884           395.814               0                            486.880
Delete                 0,00                    389.398          332.619          415.562              0                             244.495
Edited by: Srikanth Sunkara on May 12, 2011 11:50 AM

RE: Case 59063: performance issues w/ C TLIB and Forte3M

Hi James,
Could you give me a call, I am at my desk.
I had meetings all day and couldn't respond to your calls earlier.
-----Original Message-----
From: James Min [mailto:jminbrio.forte.com]
Sent: Thursday, March 30, 2000 2:50 PM
To: Sharma, Sandeep; Pyatetskiy, Alexander
Cc: sophiaforte.com; kenlforte.com; Tenerelli, Mike
Subject: Re: Case 59063: performance issues w/ C TLIB and Forte 3M
Hello,
I just want to reiterate that we are very committed to working on
this issue, and that our goal is to find out the root of the problem. But
first I'd like to narrow down the avenues by process of elimination.
Open Cursor is something that is commonly used in today's RDBMS. I
know that you must test your query in ISQL using some kind of execute
immediate, but Sybase should be able to handle an open cursor. I was
wondering if your Sybase expert commented on the fact that the server is
not responding to commonly used command like 'open cursor'. According to
our developer, we are merely following the API from Sybase, and open cursor
is not something that particularly slows down a query for several minutes
(except maybe the very first time). The logs show that Forte is waiting for
a status from the DB server. Actually, using prepared statements and open
cursor ends up being more efficient in the long run.
Some questions:
1) Have you tried to do a prepared statement with open cursor in your ISQL
session? If so, did it have the same slowness?
2) How big is the table you are querying? How many rows are there? How many
are returned?
3) When there is a hang in Forte, is there disk-spinning or CPU usage in
the database server side? On the Forte side? Absolutely no activity at all?
We actually have a Sybase set-up here, and if you wish, we could test out
your database and Forte PEX here. Since your queries seems to be running
off of only one table, this might be the best option, as we could look at
everything here, in house. To do this:
a) BCP out the data into a flat file. (character format to make it portable)
b) we need a script to create the table and indexes.
c) the Forte PEX file of the app to test this out.
d) the SQL staement that you issue in ISQL for comparison.
If the situation warrants, we can give a concrete example of
possible errors/bugs to a developer. Dial-in is still an option, but to be
able to look at the TOOL code, database setup, etc. without the limitations
of dial-up may be faster and more efficient. Please let me know if you can
provide this, as well as the answers to the above questions, or if you have
any questions.
Regards,
At 08:05 AM 3/30/00 -0500, Sharma, Sandeep wrote:
James, Ken:
FYI, see attached response from our Sybase expert, Dani Sasmita. She has
already tried what you suggested and results are enclosed.
++
Sandeep
-----Original Message-----
From: SASMITA, DANIAR
Sent: Wednesday, March 29, 2000 6:43 PM
To: Pyatetskiy, Alexander
Cc: Sharma, Sandeep; Tenerelli, Mike
Subject: Re: FW: Case 59063: Select using LIKE has performance
issues
w/ CTLIB and Forte 3M
We did that trick already.
When it is hanging, I can see what is doing.
It is doing OPEN CURSOR. But not clear the exact statement of the cursor
it is trying to open.
When we run the query directly to Sybase, not using Forte, it is clearly
not opening any cursor.
And running it directly to Sybase many times, the response is always
consistently fast.
It is just when the query runs from Forte to Sybase, it opens a cursor.
But again, in the Forte code, Alex is not using any cursor.
In trying to capture the query,we even tried to audit any statementcoming
to Sybase. Same thing, just open cursor. No cursor declaration anywhere.==============================================
James Min
Technical Support Engineer - Forte Tools
Sun Microsystems, Inc.
1800 Harrison St., 17th Fl.
Oakland, CA 94612
james.minsun.com
510.869.2056
==============================================
Support Hotline: 510-451-5400
CUSTOMERS open a NEW CASE with Technical Support:
http://www.forte.com/support/case_entry.html
CUSTOMERS view your cases and enter follow-up transactions:
http://www.forte.com/support/view_calls.html

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

Performance Issues with Debugging even in Display Mode

Hi not certain if this would sit in Security, ABAP or Basis, but lets start here as it is security related.
S_DEVELOP with any activity on DEBUG on a production system is a concern, but what are the performance related issues when a super user has to go into debug in display only on a production system because of a really complex issue?
I've heard in the past of a scenario where system performance was impacted, and we have notes around the allocation of S_DEVELOP display DEBUG access to this point. (I've summarised these below)
The risk with debug is associated with the length of time that the actual debugging process is being performed.
u2022 Work processes are dedicated solely to the users for the duration of the debug. If these are being performed for a long time, these can cause issues with not enough work processes being available.
u2022 It can cause DB2 locks. If the debug session last awhile, DB2 locks are not released. This impacts the availability of tablespaces, thus, affecting various transactions running across the system.
Even with these concerns, security will often get asked for debug display access.
As security is about risk identification, assessment and then controlled access what do other organisations do?
Options (not exhaustive) are "No Debug ever" or "Debug display only via a fire fight or super user on a time limited basis".
We are currently in the "debug display only via fire fight" camp, but would like to canvas opinion on this.
As one of the concepts of security is Availability of data (and to an extent ensuring the systems are up and running) do the performance risks push the security function to the "No Debug Ever" stance.

If you need to debug in production, then 9 times out of 10 you need to do root-cause analysis: The developer is the problem.
Writing sloppy code and not testing properly should not be an excuse for debugging in production.
But of course, there are exceptions even when you do try to keep them to a minimum.
To add to Jurjen's comments, also note that the debugger only has a limited capability of doing a rollback. So you can quite easily and unintentionally create inconsistencies in the system - also in display mode - which is an integrity problem, and typically more critical than availability problems or even potential confidentiality concerns.
Cheers,
Julius
Edited by: Julius Bussche on May 15, 2009 10:50 AM

Performance issues with pipelined table functions

I am testing pipelined table functions to be able to re-use the base_query function. Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? The processor function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
 TYPE resultset_typ IS REF CURSOR;
 TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
 TYPE table_typ IS TABLE OF row_typ;
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ;
 c_default_limit CONSTANT PLS_INTEGER := 100;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
 FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
 RETURN resultset_typ
 IS
 o_resultset resultset_typ;
 BEGIN
 OPEN o_resultset FOR
 SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB;
 RETURN o_resultset;
 END base_query;
 FUNCTION processor (
 p_source_data IN resultset_typ,
 p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
 RETURN table_typ
 PIPELINED
 PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
 IS
 aa_source_data table_typ;-- := table_typ ();
 BEGIN
 LOOP
 FETCH p_source_data
 BULK COLLECT INTO aa_source_data
 LIMIT p_limit_size;
 EXIT WHEN aa_source_data.COUNT = 0;
 /* Process the batch of (p_limit_size) records... */
 FOR i IN 1 .. aa_source_data.COUNT
 LOOP
 PIPE ROW (aa_source_data (i));
 END LOOP;
 END LOOP;
 CLOSE p_source_data;
 RETURN;
 END processor;
 PROCEDURE with_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT /*+ PARALLEL(t, 5) */ colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM TABLE (processor (base_query (argA, argB),100)) t
 GROUP BY colC
 ORDER BY colC
 END with_pipeline;
 PROCEDURE no_pipeline (argA IN VARCHAR2,
 argB IN VARCHAR2,
 o_resultset OUT resultset_typ)
 IS
 BEGIN
 OPEN o_resultset FOR
 SELECT colC,
 SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
 SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
 SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
 SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
 FROM (SELECT colC, colD, colE
 FROM some_table
 WHERE colA = ArgA AND colB = argB)
 GROUP BY colC
 ORDER BY colC;
 END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PM

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

Performance issues with Homesharing?

I have a Time Capsule as the base station for my wireless network, then 2 Airport Express setup to extend the network around the house, an iMac i7 as the main iTunes Library and couple of iPads, and a couple of Apple TVs. Everything has the latest software, but I have several performance issues with Home sharing. I've done several tests making sure nothing is taking additional bandwidth, so here are the list of issues:
1) With nothing else running, trying playing a movie via home sharing in an iPad 2 which is located on my iMac, it stops and I have to keep pressing the play button over and over again. I typically see that the iPad tries to download part of the movie first and then starts playing so that it deals with the bandwidth, but in many cases it doesn't.
2) When trying to play any iTunes content (movies, music, photos, etc) from my Apple TV I can see my computer library, but when I go in on any of the menus, it says there's no content. I have to reboot the Apple TV and then problem fixed. I's just annoying that I have to reboot.
3) When watching a Netflix movie on my iPad and with Airplay I send the sound to some speakers via Airplay through an Airport Express. At time I lose the connection to the speakers.
I've complained about Wifi's instability, but here I tried to keep everything with Apples products to avoid any compatibility issues and stay within N wireless technology, which I understood it was much more stable.
Has anyone some suggestions?

Hi,
you should analyze the db after you have loaded the tables.
Do you use sequences to generate PKs? Do you have a lot of indexex and/or triggers on the tables?
If yes:
make sure your sequence caches (alter sequence s cache 10000)
Drop all unneeded indexes while loading and disable trigger if possible.
How big is your Redo Log Buffer? When loading a large amount of data it may be an option to enlarge this buffer.
Do you have more then one DBWR Process? Writing parallel can speed up things when a checkpoint is needed.
Is it possible using a direct load? Or do you already direct load?
Dim

Performance issues with the Vouchers index build in SES

Hi All,
We are currently performing an upgrade for: PS FSCM 9.1 to PS FSCM 9.2.
As a part of the upgrade, Client wants Oracle SES to be deployed for some modules including, Purchasing, Payables (Vouchers)
We are facing severe performance issues with the Vouchers index build. (Volume of data = approx. 8.5 million rows of data)
The index creation process runs for over 5 days.
Can you please share any information or issues that you may have faced on your project and how they were addressed?

Check the following logs for errors:
1. The message log from the process scheduler
2. search_server1-diagnostic.log in /search_server1/logs directory
If the build is getting stuck while crawling then we typically have to increase the Java Heap size for the Weblogic instance for SES>

Performance issues with Bapi BAPI_MATERIAL_AVAILABILITY...

Hello,
I have a Z program to check ATP which is working with Bapi BAPI_MATERIAL_AVAILABILITY....
As I am in the retail system we have performance issues with this bapi due the huge amount of articles in the system we need to calculate the ATP.
any way to improve the performance?
Thanks and best regards
L

The BAPI appears to execute for only one plant/material, etc., at a time, so I would have to concentrate on making data retrieval and post-bapi processing as efficient as possible. In your trace output, how much of your overall time is consumed by the BAPI? How much by the other code? You might find improvements there...

Performance issue in process lockbox

Similar Messages

Maybe you are looking for