Apps DBA - Concurrent Managers

How to Create The Service Manager ‘FNDSM’ on Oracle Applications

Run below command to check if node is registered for FNDSM:-

select CONCURRENT_QUEUE_NAME from FND_CONCURRENT_QUEUES where CONCURRENT_QUEUE_NAME like ‘FNDSM%’;

if not then use Note.218893.1 :How to Create The Service Manager ‘FNDSM’ on Oracle Applications

Solution

From the Application tier:

1. Log in as applmgr

2. cd to $FND_TOP/patch/115/sql

3. Run the script: afdcm037.sql

4. This script will create libraries for FNDSM and create Managers for

Preexisting Nodes.

Note: Service Manager “FNDSM” can not be created from form:

Concurrent> Manager> Define under Sysadmin Responsibility.

Reference <bug:6085070 FNDSM TRIGGER CAUSES SERVICE MANAGER NOT TO BE CREATED AFTER CLONING SINGLE NODE>

Check Concurrent Manager Status from the Back end?How to check Concurrent Managers Status from the Back End?select CONCURRENT_QUEUE_NAME,max_processes,running_processes,decode(control_code,

'A','Activating',

'B','Activated',

'D','Deactivating',

'E','Deactivated',

'N','Target node/queue unavailable',

'O','Suspending concurrent manager',

'P','Suspended',

'Q','Resuming concurrent manager',

'R','Restarting',

'T','Terminating',

'U','Updating environment information',

'V','Verifying',

'X','Terminated')

from apps.fnd_concurrent_queues

where

MAX_PROCESSES <> RUNNING_PROCESSES or

(control_code is not null and control_code not in ('B','E'));

Tuning the Concurrent Manager

All successful Oracle Apps DBAs must understand how to monitor and tune each of the Concurrent Managers. This article will explore some of the important techniques for monitoring and tuning the Oracle Apps Concurrent Manager processes. The topics will include:

* Tuning the Concurrent Manager

- Tuning the Internal Concurrent Manager

- Purging Concurrent Requests

- Troubleshooting Oracle Apps performance problems

- Adjusting the Concurrent Manager Cache Size

- Analyzing the Oracle Apps Dictionary Tables

* Monitoring Pending Requests in the Concurrent Manager

* Changing the dispatching priority within the Concurrent Manager

Tuning the Internal Concurrent Manager (ICM)

The ICM performance is affected by the three important Oracle parameters PMON cycle, queue size, and sleep time.

* PMON cycle — This is the number of sleep cycles that the ICM waits between the time it checks for concurrent managers failures, which defaults to 20. You should change the PMON cycle to a number lower than 20 if your concurrent managers are having problems with abnormal terminations.

* Queue Size — The queue size is the number of PMON cycles that the ICM waits between checking for disabled or new concurrent managers. The default for queue size of 1 PMON cycle should be used.

* Sleep Time — The sleep time parameter indicates the seconds that the ICM should wait between checking for requests that are waiting to run. The default sleep time is 60, but you can lower this number if you see you have a lot of request waiting (Pending/Normal). However, reducing this number to a very low value many cause excessive cpu utilization.

All of the concurrent managers, with the exception of the ICM and CRM, can be configured to run as many processes as needed, as well as the time and days a manager can process requests. However, the number of processes needed is dependent on each organization's environment.

An Applications DBA must monitor the concurrent processing in order to decide how to configure each manager. For a fresh install of the applications, initially configure the standard manager to run with five processes, and all the other managers with two processes. After the applications have been in operation for a while, the concurrent managers should be monitored to determine is more operating system process should be allocated.

Purging Concurrent Requests

One important area of Concurrent Manager tuning is monitoring the space usage for the subsets within each concurrent manager. When the space in FND_CONCURRENT_PROCESSES and FND_CONCURRENT_REQUESTS exceed 50K, you can start to experience serious performance problems within your Oracle Applications.

When you experience these space problems, a specific request called "Purge Concurrent Requests And/Or Manager Data" should be scheduled to run on a regular basis. This request can be configured to purge the request data from the FND tables as well as the log files and output files on accumulate on disk.

Adjusting the Concurrent Manager Cache Size

Concurrent manager performance can also be enhanced by increasing the manager cache size to be at lease twice the number of target processes. The cache size specifies the number of requests that will be cached each time the concurrent manager reads from the FND_CONCURRENT_REQUESTS table. Increasing the cache size will boost the throughput of the managers by attempting to avoid sleep time.

Analyzing Oracle Apps Dictionary Tables for High Performance

It is also very important to run the request Gather Table Statistics on these tables:

* FND_CONCURRENT_PROCESSES

* FND_CONCURRENT_PROGRAMS

* FND_CONCURRENT_REQUESTS

* FND_CONCURRENT_QUEUES.

Run the request "Analyze All Index Column Statistics" on the indexes of these tables. Since the APPLSYS user is the owner of these tables, so you can also just run the request Analyze Schema Statistics for APPLSYS.

To troubleshoot performance, a DBA can use three types of trace.

A module trace, such as PO or AR, can be set by enabling the module's profile option Debug Trace from within the applications.

Second, most concurrent requests can be set to generate a trace file by changing the request parameters. To enable trace for a specific request, log in as a user with the System Administrator responsibility. Navigate to Concurrent -> Program -> Define. Query for the request that you want to enable trace.

Another popular way to troubleshoot the Concurrent Managers is to generate a trace file. This is done by setting the OS environment variable FNDSQLCHK to FULL, and running the request from the command line.

Monitoring Pending Requests in the Concurrent Managers

Occasionally, you may find that requests are stacking up in the concurrent managers with a status of "pending". This can be caused by any of these conditions:

1. The concurrent managers were brought down will a request was running.

2. The database was shutdown before shutting down the concurrent managers.

3. There is a shortage of RAM memory or CPU resources.

When you get a backlog of pending requests, you can first allocate more processes to the manager that is having the problem in order to allow most of the requests to process, and then make a list of the requests that will not complete so they can be resubmitted, and cancel them.

To allocate more processes to a manager, log in as a user with the System Administrator responsibility. Navigate to Concurrent -> Manager -> Define. Increase the number in the Processes column. Also, you may not need all the concurrent managers that Oracle supplies with an Oracle Applications install, so you can save resources by identifying the unneeded managers and disabling them.

However, you can still have problems. If the request remains in a phase of RUNNING and a status of TERMINATING after allocating more processes to the manager, then shutdown the concurrent managers, kill any processes from the operating system that won't terminate, and execute the following sqlplus statement as the APPLSYS user to reset the managers in the FND_CONCURRENT_REQUESTS table:

update fnd_concurrent_requestsset status_code='X', phase_code='C'where status_code='T';

Changing Dispatching Priority within the Concurrent Manager

If there are requests that have a higher priority to run over other requests, you can navigate to Concurrent --> Program --> Define to change the priority of a request. If a priority is not set for a request, it will have the same priority as all other requests, or it will be set to the value specified in the user's profile option Concurrent:Priority. Also, you can specify that a request run using an SQL optimizer mode of FIRST_ROWS, ALL_ROWS, RULE, or CHOOSE, and this can radically effect the performance of the SQL inside the Concurrent request.

If several long running requests are submitted together, they can cause fast running requests to have to wait unnecessarily. If this is occurring, try to schedule as many long running requests to run after peak business hours. Additionally, a concurrent manager can be created to run only fast running requests.

Oracle supplies several useful scripts, (located in $FND_TOP/sql directory), for monitoring the concurrent managers:

afcmstat.sql : Displays all the defined managers, their maximum capacity, pids, and their status.

afimchk.sql : Displays the status of ICM and PMON method in effect, the ICM's log file, and determines if the concurrent manger monitor is running.

afcmcreq.sql : Displays the concurrent manager and the name of its log file that processed a request.

afrqwait.sql : Displays the requests that are pending, held, and scheduled.

afrqstat.sql : Displays of summary of concurrent request execution time and status since a particular date.

afqpmrid.sql : Displays the operating system process id of the FNDLIBR process based on a concurrent request id. The process id can then be used with the ORADEBUG utility.

afimlock.sql : Displays the process id, terminal, and process id that may be causing locks that the ICM and CRM are waiting to get. You should run this script if there are long delays when submitting jobs, or if you suspect the ICM is in a gridlock with another oracle 

Something about Concurrent Managers

Concurrent Managers

The concurrent managers in the Oracle e-Business suite serve several important administrative functions. Foremost, the concurrent managers ensure that the applications are not overwhelmed with requests, and the second areas of functions are the management of batch processing and report generation.

This article will explore tools that are used by experienced administrators to gain insight and improved control over the concurrent management functions. We will explore how the concurrent managers can be configured via the GUI, and also explore scripts and dictionary queries that are used to improve the functionality of concurrent management.

The Master Concurrent Managers

There is a lot of talk about "the" concurrent manager in Oracle Applications. Actually, there are many Concurrent Managers, each governing flow within each Oracle Apps areas. In addition there are "super" Concurrent Managers whose job is to govern the behavior of the slave Concurrent Managers. The Oracle e-Business suite has three important master Concurrent Managers:

* Internal Concurrent Manager — The master manager is called the Internal Concurrent Manager (ICM) because it controls the behavior of all of the other managers, and because the ICM is the boss, it must be running before any other managers can be activated. The main functions of the ICM are to start up and shutdown the individual concurrent managers, and reset the other managers after one them has a failure.

* Standard Manager — Another important master Concurrent Manager is called the Standard Manager (SM). The SM functions to run any reports and batch jobs that have not been defined to run in any specific product manager. Examples of specific concurrent managers include the Inventory Manager, CRP Inquiry Manager, and the Receivables Tax Manager.

* Conflict Resolution Manager — The Conflict Resolution Manager (CRM) functions to check concurrent program definitions for incompatibility rules. However, the ICM can be configured to take over the CRM's job to resolve incompatibilities.

Now that we understand the functions of the master Concurrent Managers, let's take a quick look at techniques that are used by Oracle Apps DBAs to monitor the tune the behavior of the Concurrent Manager.

Oracle Apps DBA - Concurrent Managers

Oracle Apps DBA - Concurrent Managers

1. How do you start/stop/check Concurrent Managers?

Solution:

cd $COMMON_TOP/admin/scripts/context_name/

-> adcmctl.sh start apps/appspwd

-> adcmctl.sh stop apps/appspwd

-> adcmctl.sh status apps/appspwd

-> ps -ef grep FNDLIBR grep applmgr

2. How do you create custom concurrent manager?

Solution:

1. Login to System Administrator Responsibility

2. Navigate to Concurrent > Manager > Define

Manager Field: Custom Manager-

Short Name: CUSTOMCM-

Type: Concurrent Manager-

Program Library: FNDLIBR-

Enter desired Cache-

Work Shifts: Standard-

Enter number of Processes-

Provide Specialization Rules- Save

3. Navigate to Concurrent > Manager > Administer- Activate the Custom Manager

3. How to Start the Concurrent Manager from the Operating system?

solution:

startmgr [parameters]

Example: startmgr sysmgr="applsys/fnd" mgrname="std" printer="hqseq1"mailto="jsmith" restart="N" logfile="mgrlog" sleep="90" pmon="5" quesiz="10"

Parameters:

[sysmgr="fnd_usernamd/fnd_password"] [mgrname="mgrname"]

[printer=printer]

[mailto="userid1 userid2...]

[restart="Nminutes"]

[logfile="log_file_name"]

[sleep="new_check"]

[pmon="manager_check"]

[quesiz="number_check"]

[diag="YN"]

4. EachConcurrent Request Phase and Status Meaning?

Solution:

Phase Status Description

PENDING Normal Request is waiting for the next available manager.

PENDING Standby Program to run request is incompatible with other program(s) currently running.

PENDING Scheduled Request is scheduled to start at a future time or date.

PENDING Waiting A child request is waiting for its Parent request to mark it ready to run. For example, a request in a request set that runs sequentially must wait for a prior request to complete.

RUNNING Normal Request is running normally.

RUNNING Paused Parent request pauses for all its child requests to finish running. For example, a request set pauses for all requests in the set to complete.

RUNNING Resuming All requests submitted by the same parent request have completed running. The Parent request resumes running.

RUNNING Terminating Request is terminated by choosing the Cancel Request button in Requests window.

COMPLETED Normal Request completed successfully.

COMPLETED Error Request failed to complete successfully.

COMPLETED Warning Request completed with warnings. For example, a request is generated successfully but fails to print.

COMPLETED Cancelled Pending or Inactive request is cancelled by choosing the Cancel Request button in the Requests window.

COMPLETED Terminated Request is terminated by choosing the Cancel Request button in the Requests window.

INACTIVE Disabled Program to run request is not enabled. Contact your system administrator.

INACTIVE On Hold Pending request is placed on hold by choosing the Hold Request button in the Requests window.

INACTIVE No Manager No manager is defined to run the request. Check with your system administrator. A status of No Manager is also given when all managers are locked by run-alone requests.