In this Post i am Explaining about Concurrent Processing issues & How to resolve them.
Introduction:
This Paper describes the day-to-day administrative like performance issues with concurrent processing etc. at Aurobindo Pharma Ltd., a leading pharmaceutical manufacturer, and the solutions to resolve those problem regarding performance of E-Business Suite. you may visit Aurobindo at http://www.aurobindo.com/.
Introduction:
This Paper describes the day-to-day administrative like performance issues with concurrent processing etc. at Aurobindo Pharma Ltd., a leading pharmaceutical manufacturer, and the solutions to resolve those problem regarding performance of E-Business Suite. you may visit Aurobindo at http://www.aurobindo.com/.
The Goal of this Document is to assist existing Oracle Applications DBA’s and Administrators in identifying the hidden features of Oracle Applications 11i that will affect how they accomplish their day-to-day administrative tasks like managing concurrent processing.
Abstract:
This paper flourishes possible ways to speed up & utilize the processing capacity of Oracle Applications as per it’s maximum extent.
Concurrent Processing:
Concurrent Processing:
Before heading into the details of how to manage the concurrent processing, the following are definitions of key terms:
Concurrent Manager: Concurrent manager is a mechanism that runs concurrent programs. A manager operates during the time and days defined by a work shift. A manager can run any concurrent program, or be specialized to run any concurrent program, or be specialized to run only certain kinds of programs.
Concurrent Program: A program that runs concurrently (at the same time) as other programs. Concurrent programs run as background processes, while you continue to work at your terminal.
Note : Oracle’s guidelines for CPU suggested that Estimate the number of users who will use Oracle Applications simultaneously under normal circumstances.
For example We have 500+ end users. This number included multiple open sessions as well browses.
For example We have 500+ end users. This number included multiple open sessions as well browses.
Users opened multiple sessions on their desktops, either to do work through two different applications at the same time, or because performance was so slow that they felt they could get more done with more screens open. As users became increasingly upset about performance, they opened more windows, causing the performance problem to increase because every log-in to Oracle costs about 2.5 MB of memory (2.5*500 users = 1.2GB Approximately).
Note-1: if we lower the number in the Priority field in the Navigate/Concurrent/Requests screen, then the concurrent request’s position in the queue will change and it will run sooner. Sooner, I always caution users, does not mean faster. Changing the priority does not cause the concurrent request to get more resources from the computer when it runs, so if the computer is already overloaded, you will still have performance problems.
Note-1: if we lower the number in the Priority field in the Navigate/Concurrent/Requests screen, then the concurrent request’s position in the queue will change and it will run sooner. Sooner, I always caution users, does not mean faster. Changing the priority does not cause the concurrent request to get more resources from the computer when it runs, so if the computer is already overloaded, you will still have performance problems.
Note-2: If we increasing the number of requests, that could run in the concurrent manager didn’t help either. If we plan to use this in Brake sessions with proper planning, it is the best option.
Note-3: if we decreased the size of the SGA. This freed up additional memory for the users to log on, but decreased the amount of memory available for the database, causing it’s own set of performance issues.
Note-3: if we decreased the size of the SGA. This freed up additional memory for the users to log on, but decreased the amount of memory available for the database, causing it’s own set of performance issues.
Note-4: When we calculated memory requirements, it’s better to assess the impact of Zooms on memory. Zoom- Zooms allow end users to suspend processing in one form, make a side trip to work or view details in another form, then return to the original form and resume processing. If a user zooms, it’s nothing but another login. It’ costs another 2.5 MB memory & it’s not release the memory until the user logoff.
To resolve the performance issues
To resolve the performance issues
Actions :
1. asses how many users will use the applications. even if they aren’t doing anything, the memory will be utilized.
2. Many users will log on at least twice.
3. Zooms didn’t release the memory until the user log-off.
4. Count the Concurrent managers themselves as users of memory & CPU.
5. The SGA also requires considerable memory.
3. Zooms didn’t release the memory until the user log-off.
4. Count the Concurrent managers themselves as users of memory & CPU.
5. The SGA also requires considerable memory.
Solutions:
1. From Unix, limit the users to logging in two times.
2. Implement a process @ the unix level to automatically kill sessions of users who were idle for more than an hour.
2. Implement a process @ the unix level to automatically kill sessions of users who were idle for more than an hour.
3. Set the correct balance of concurrent managers versus online user performance.
4. Using the scripts, asses the high frequency, high impact, average time & importance of the concurrent request.
6. Give the access on this output data to all users & give the choice to them for scheduling the job.
7. Encourage the users to schedule the requests (means long running & repeatable) to run in the evening.
8. Report the performance problems with forms & reports to the developers.
9. Check the parameters of running open-ended reports.
10. Monitor for locks on tables. Locks affect both online & batch operations.
11. Check for runaway requests mean long running requests, displays CPU clock time increasing & had a unix process id of 1 with no other processes referencing it. In this case, the process may not be cleaned automatically. Use the kill command to terminate the run-away requests.
12. Use the Apps Status Scan scripts & verify the performance issues.
13. Give instructions for users immediately close the database backend, ftp, front end sessions if they are not using.
14. During the Business hours give the preference for Online users & run atleast two processes per manager.
15. Sugests the users to close all sessions with Oracle Applications @ Brake times (lunch time).
16. Working with the above Step, A lot of memory will be released. Use it efficiently with increasing the target processes.
17. Workshifts:
Define workshifts like Business Hours, evening, weekends & End of the Month workshifts.
Business Hours : During the business hours, we had a workshift for 9AM – 6PM.
That minimized the no. of concurrent requests in favor of online users.
Evening Hours: At 6PM, change the workshift to Evening workshift & increase the no. of concurrent requests that could run. As performance improved, we gradually increased the no. of jobs that could run @ once.
Weekend: As per the company holidays, define this workshift & give the primary priority for concurrent requests.
If we properly manage these workshifts, there is no need Maintain any workshifts like Monthend shifts, quarterly shifts etc.
18. Run the purge concurrent requests & manager data programs nightly to delete old files.
19. Remove the older files if the /var/tmp is getting full.
20. Run the Oracle-seeded report User Profile Options periodically to catch users who have left debug or trace options turned on.
21. Monitor file system spaces frequently.
22. Avoid enabling an excessive number of standard or specialized managers.
23. Use specialization rules and work shifts to bind specific jobs to specific time windows.
24. Helps avoid scheduling resource intensive batch requests during peak activity.
25. For jobs, which spawn parallel workers such as Auto Invoice or Payroll, set the sleep time of the Conflict Resolution Manager (CRM) to null (i.e. 10 seconds). The default value is 60 seconds.
26. Transaction Managers:
1. Set the profile “Concurrent:Wait for Available TM” to 1 (second).
2. Set “TP:INV Transaction processing mode” to “On-line processing” for small inventory requests from the UI.
3. Set the sleep time on the transaction managers to a high number (e.g. 10 minutes).
4. Enable tracing if required.
27. Implementation of PCP(parallel concurrent processing) is the another solution to improve performance.
...........................................................................................
...........................................................................................
--
Srinivas Ramineni
Apps DBA
