Below are several different possible solutions to the problem where concurrent requests are stuck in pending status:
1. When shutting down the concurrent managers are there any FNDLIBR processes still running at the OS level? If so, do a kill -9 on them,
then restart the concurrent managers.
2. Try Relinking $FND_TOP.
3. Rebuild the concurrent manager views. As applmgr run the following from the OS:
This is non-destructive.
Concurrent Manager views can be rebuilt by running the following command at the command line:
Ensure that concurrent managers are shutdown.
FNDLIBR FND FNDCPBWV apps/apps SYSADMIN 'System Administrator' SYSADMIN
Restart the concurrent managers.
4. The Profile Option 'Concurrent: OPS Request Partitioning' may be set incorrectly. This profile option should always be set to
OFF, regardless of whether you are running OPS(RAC) or not, because the profile is obsolete.
5. The System Profile Option: Concurrent Active Requests is possibly to 0.
a. Log into Oracle Applications as SYSADMIN.
b. Select System Administrator responsibility.
c. Navigate to PROFILE > SYSTEM.
d. Query for %CONC%ACTIVE%.
e. Change the profile option for 'Concurrent: Active Request Limit' to Null (blank).
f. Exit Oracle Applications and log in again for the change to take affect.
g. Run a new concurrent request.
6. The Concurrent managers were brought down, while an outstanding request was still running in the background. In which case, update the
FND_CONCURRENT_REQUESTS table as follows:
sql>
update fnd_concurrent_requests
set status_code='X', phase_code='C'
where status_code='T';
sql> commit;
7. The control_code for concurrent_queue_name = 'FNDCRM' is 'N' in the FND_CONCURRENT_QUEUES table, which means 'Target node/queue unavailable'.
This value should be NULL (CRM is running; target and actual process amount are the same), or 'A' ('Activate concurrent manager' control status).
Set the control_code to 'A' in fnd_concurrent_queues for the Conflict Resolution Manager:
a. Logon to Oracle Applications database server as 'applmgr'.
b. Verify the Applications environment is setup correctly ($ORACLE_HOME and $ORACLE_SID).
c. Logon to SQL*Plus as 'APPS' and run the following SQL statement:
update fnd_concurrent_queues
set control_code = 'A'
where concurrent_queue_name = 'FNDCRM';
commit;
d. Verify the status of the concurrent managers through the Concurrent -> Manager -> Administer form.
If the CRM is still not active, bounce (deactivate, activate) the Internal Concurrent Manager. This is done through the Concurrent > Manager > Administer form
from the 'System Administrator' responsibility. It can also be done through the CONCSUB command at the command level.
Setting the control_code to 'A' in the fnd_concurrent_queues table for the Conflict Resolution Manager indicates that this concurrent manager
is to be activated with the parameter values specified through this table for this manager (MAX_PROCESSES, CACHE_SIZE, etc).
8. What is the cache size? Try increasing the cache size then stop/restart the concurrent managers.
If concurrent requests are rarely prioritized and there are managers that service short-running requests, consider setting the cache size to
equal at least twice the number of target processes. This increases the throughput of the concurrent managers by attempting to avoid any sleep time.
For example:
If more than one manager or worker processes the same type of requests with only a small cache size, it may be unable to process any jobs in a
single processing cycle, because other processes have already run the cached requests.
When this happens, it is important to note that the manager will sleep before refreshing its cache. To increase manager throughput where there
are sufficient requests of the required type in the queue, increase the cache size to improve the chance of the manager finding work to process
and thus avoid having to enter a sleep phase.
TIP: Ensure that the system is not resource-constrained before attempting to increase the rate of concurrent processing in this way, otherwise,
these changes may actually reduce concurrent processing throughput because jobs take longer to run.
1. When shutting down the concurrent managers are there any FNDLIBR processes still running at the OS level? If so, do a kill -9 on them,
then restart the concurrent managers.
2. Try Relinking $FND_TOP.
3. Rebuild the concurrent manager views. As applmgr run the following from the OS:
This is non-destructive.
Concurrent Manager views can be rebuilt by running the following command at the command line:
Ensure that concurrent managers are shutdown.
FNDLIBR FND FNDCPBWV apps/apps SYSADMIN 'System Administrator' SYSADMIN
Restart the concurrent managers.
4. The Profile Option 'Concurrent: OPS Request Partitioning' may be set incorrectly. This profile option should always be set to
OFF, regardless of whether you are running OPS(RAC) or not, because the profile is obsolete.
5. The System Profile Option: Concurrent Active Requests is possibly to 0.
a. Log into Oracle Applications as SYSADMIN.
b. Select System Administrator responsibility.
c. Navigate to PROFILE > SYSTEM.
d. Query for %CONC%ACTIVE%.
e. Change the profile option for 'Concurrent: Active Request Limit' to Null (blank).
f. Exit Oracle Applications and log in again for the change to take affect.
g. Run a new concurrent request.
6. The Concurrent managers were brought down, while an outstanding request was still running in the background. In which case, update the
FND_CONCURRENT_REQUESTS table as follows:
sql>
update fnd_concurrent_requests
set status_code='X', phase_code='C'
where status_code='T';
sql> commit;
7. The control_code for concurrent_queue_name = 'FNDCRM' is 'N' in the FND_CONCURRENT_QUEUES table, which means 'Target node/queue unavailable'.
This value should be NULL (CRM is running; target and actual process amount are the same), or 'A' ('Activate concurrent manager' control status).
Set the control_code to 'A' in fnd_concurrent_queues for the Conflict Resolution Manager:
a. Logon to Oracle Applications database server as 'applmgr'.
b. Verify the Applications environment is setup correctly ($ORACLE_HOME and $ORACLE_SID).
c. Logon to SQL*Plus as 'APPS' and run the following SQL statement:
update fnd_concurrent_queues
set control_code = 'A'
where concurrent_queue_name = 'FNDCRM';
commit;
d. Verify the status of the concurrent managers through the Concurrent -> Manager -> Administer form.
If the CRM is still not active, bounce (deactivate, activate) the Internal Concurrent Manager. This is done through the Concurrent > Manager > Administer form
from the 'System Administrator' responsibility. It can also be done through the CONCSUB command at the command level.
Setting the control_code to 'A' in the fnd_concurrent_queues table for the Conflict Resolution Manager indicates that this concurrent manager
is to be activated with the parameter values specified through this table for this manager (MAX_PROCESSES, CACHE_SIZE, etc).
8. What is the cache size? Try increasing the cache size then stop/restart the concurrent managers.
If concurrent requests are rarely prioritized and there are managers that service short-running requests, consider setting the cache size to
equal at least twice the number of target processes. This increases the throughput of the concurrent managers by attempting to avoid any sleep time.
For example:
If more than one manager or worker processes the same type of requests with only a small cache size, it may be unable to process any jobs in a
single processing cycle, because other processes have already run the cached requests.
When this happens, it is important to note that the manager will sleep before refreshing its cache. To increase manager throughput where there
are sufficient requests of the required type in the queue, increase the cache size to improve the chance of the manager finding work to process
and thus avoid having to enter a sleep phase.
TIP: Ensure that the system is not resource-constrained before attempting to increase the rate of concurrent processing in this way, otherwise,
these changes may actually reduce concurrent processing throughput because jobs take longer to run.
No comments:
Post a Comment