Top Ten secret about Oracle Concurrent Manager and Types

Last updated on March 22nd, 2019 at 05:49 pm

Oracle Concurrent Manager is a important piece in Oracle E-Business Suite product. it helps in batch processing of many things.

I am here presenting the some details about it

It consists of several part. Explaining each of these in details .It gives u a glimpse of How an E-Business Suite Concurrent Manager Process Works

Types of Oracle Concurrent Manager

Internal Concurrent Manager (ICM)

The Internal Concurrent Manager (ICM) can be considered the “brain” of concurrent processing. It is responsible for the following functionality:

-Starts all other processes like Conflict resolution manager,standard manager
-Executes “control requests” submitted by the administrator.
-Activate/Deactivate/Abort Concurrent Manager
-Terminate Concurrent Request
-Monitors processes, restarting any that failed.
-Sets the target number of processes for each service based on the current work shift.

Starting the ICM

-adcmctl.sh script
-TNS Apps Listener must be started before starting ICM

Shutting down the ICM

-Shutting down the ICM will stop all other services like Conflict resolution manager,standard manager
– Normal shutdown signals processes to exit after completing their current tasks.
– Abort will terminate service processes.
– ICM will not exit until all other processes have exited.
-Use adcmctl.sh to shutdown ICM.

Service Managers(FNDSM)

Service Managers are spawned on the middle-tier nodes of a GSM enabled system in order to act as an agent of the ICM. When the ICM sees that it needs an service managers to perform some function, such as start a concurrent manager process, on a middle-tier node, it will make remote procedure control calls to the Apps listener on that node to start the Service manager. Once the Service Manager has been started and initialized, the ICM communicates directly to the Service manager through Remote Procedural call(RPC), giving it information to manage the services on that node.

-The Service manager is spawned from the APPS TNS Listener
– The APPS TNS Listener must be started on every middle-tier node in the system, and started by the user that starts ICM (e.g. applmgr)
-TNS Listener spawns Service Manager to run as agent of ICM for the local node
-The Service Manager is started by ICM on demand when needed. If no management actions are needed on a node a Service Manager will not be started by ICM until necessary. When ICM exits its Service Managers exit as well.
-The Service Manager environment is set by APPSORA.env as defined in listener.ora
-The listener.ora and tnsnames.ora files must be configured properly for the listener to be able to spawn the Service Manager and for the ICM to be able to check the status of the Service Manager.

Internal Monitors(FNDIMON)

Internal Monitors are used specifically in Parallel Concurrent Processing to allow for Internal concurrent manager fail over to other available middle tier nodes.

-Place an Internal Monitor on any node where the ICM can start in case of a failure.
-Internal Monitors are seeded on every registered node by default.
-If the ICM goes down, the Internal Monitor will attempt to start a new ICM on the local node.
-If multiple ICMs are started, only the first will stay active. The others will gracefully exit.

Oracle Concurrent Managers(FNDLIBR,INVLIBR)

Concurrent Managers provide asynchronous job processing by monitoring the FND_CONCURRENT_REQUESTS table on a continuous cycle. The job of a concurrent manager is to execute concurrent requests that are in Pending / Normal phase / status and that it is qualified to run according to its specialization rules.

Concurrent Manager Processes
– Act independently
– Select only requests that: (a) match the manager specialization rules, (b) are Pending/Normal, (c) have a requested start time

Description about important Concurrent Manager oracle tables

FND_CONCURRENT_QUEUES
TARGET_NODE
-Used to indicate where additional processes should be started
-Used by managers to determine if they should shut themselves down for migration
-Managers compare parameter value passed on startup to this value
-Used by UI to indicate where processes exist (not entirely accurate in migrating case)
-Assigned by ICM based on primary, secondary settings

NODE_NAME
-Indicates primary node for PCP – directed load
-Where processes should be started unless node is not online or has been determined to be unavailable
-If no node is specified ICM will assign target node by default to NODE_NAME2
-Indicates secondary node for PCP – directed load fail-over
-Only assigned as TARGET_NODE if primary node is unavailable

FND_CONCURRENT_PROCESSES
NODE_NAME
-Indicates where the manager process is running
-Also indicates where the manager’s files exist
-Populated using value from uname() (physical machine name)
-Used by ICM when terminating process
-Used when viewing log file in User Interface(UI)
-Used by Purge Program to delete process logfile
-Could be used for workload statistic calculations
-Will likely be used by RPMs to attempt to find a local OPP
-Similarly used in 11i.X to locate Reports Server

FND_CONCURRENT_REQUESTS
LOGFILE_NODE_NAME, OUTFILE_NODE_NAME
-Indicate where files exist
-Used in User Interface(UI) for File Viewing
-Used by Purge Program to delete files
-Value populated by mgr process, based on its own node

FND_NODES

NODE_NAME
-Indicates node name where DBC file is located.
-Adgendbc.sh script creates DBC file.

SERVER_ID
-Will be used to authenticate connections from the node.
-Updated by adgendbc.sh which calls AdminAppServer API.

Concurrent Manager tables

FND_NODES: Contains all the nodes level information

FND_CONCURRENT_PROCESSES : Contains all the concurrent manager process information
FND_CONCURRENT_REQUESTS : Contains a complete history of all concurrent requests (both past history and those scheduled to run in the future).

FND_CONCURRENT_QUEUES : Contains the information for all the concurrent manager created in the system
FND_CONCURRENT_PROGRAMS : Contains the information for all the concurrent program available in the system
FND_EXECUTABLES
FND_CP_SERVICES
FND_CONCURRENT_QUEUE_SIZE
FND_CONCURRENT_QUEUE_CONTENT
FND_CONCURRENT_PROGRAM_SERIAL
FND_CONCURRENT_TIME_PERIODS
FND_CONCURRENT_PROCESSORS

FNDSVCRG
The FNDSVCRG executable is triggered from the control scripts before and after a script starts or stops the service. FNDSVCRG will connect to the database to verify the configuration of the Seeded GSM Service. If the service in question is not enabled to be managed under GSM, the FNDSVCRG executable will do nothing and exit. The script would then continue to perform its normal start/stop actions. If the service is enabled for GSM management, the FNDSVCRG executable will update service-related information in the database including the environment context, the current service log file location, and the current state of the service

Concurrent Request Phase status Description

PENDING/Normal -Request is waiting for the next available manager.
PENDING/Standby-Program to run request is incompatible with other program 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.

Stop/Start and status of Concurrent Manager

a) Start Concurrent Manager in R12
Connect to Application Tier user usually its applmgr

cd $ADMIN_SCRIPTS_HOME
./adcmctl.sh start apps/<apps-pass>

b) Stop Concurrent Manager in R12
Connect to Application Tier user usually its applmgr

cd $ADMIN_SCRIPTS_HOME
./adcmctl.sh stop apps/<apps-pass>

c) To check Status of Concurrent Manager
Connect to Application Tier user usually its applmgr

cd $ADMIN_SRCIPTS_HOME
./adcmctl.sh status apps/<apps-pass>

Concurrent Manager Log file location in R12

Concurrent Manager,ICM and concurrent request all generate the log files

A) Concurrent Request Log File – documents the execution of a particular request ( l.req )
B) Manager Log File – documents the performance of a concurrent manager process. ( W.mgr )
C) Internal Manager Log File – documents the performance of the ICM.(std.mgr). This log file displays the parameters used with the ’adcmctl’ command.

if $APPLCSF is set

Log files  are in the Folder  $APPLCSF/$APPLLOG.
Log files can also be viewed from within the applications from the View Concurrent Requests Form

R12.2  APPLCSF =$NE_BASE/inst/<CONTEXT_NAME>/logs/appl/conc/log

R12.1 APPLCSF= $INST_TOP//logs/appl/conc/log

If $APPLCSF is not set

Log files  are in the Folder  $PRODUCT_TOP/$APPLLOG.

Similarly for output files,

if $APPLCSF is set

R12.2 APPLCSF= $NE_BASE/inst/<CONTEXT_NAME>/logs/appl/conc/

R12.1 APPLCSF= $INST_TOP//logs/appl/conc/

Concurrent Manager troubleshooting

How do you check the status of the managers from the OS
Linux command:

$ ps -ef | grep LIB

-Note that the Internal Concurrent Manager can be spotted in this listing because its command is “FNDLIBR FND CPMGR …” whereas the others show more like “FNDLIBR FND Concurrent_Processor …”
-The Unix userid shown in the first column of this listing is crucial: these concurrent manager processes should be owned by the same Unix userid which owns the Applications code ($APPL_TOP and its subdirectories); this user is usually referred to as “applmgr”

Where do all the files generated by the concurrent managers go

-The ICM log file goes in the $FND_TOP/log directory and usually matches std.mgr.
-The workers’ log files go in $FND_TOP/log and match W.mgr
-The concurrent request log/out files go under the product top directory associated with the product running the request: for instance, log/out files for AR reports go under $AR_TOP.
-The log files for concurrent requests go in the $APPLLOG subdirectory under the appropriate product top directory and match l
.req
-The out files for concurrent requests go into the $APPLOUT subdirectory
-If APPLCSF is set, it should point to the complete path to a directory which has $APPLLOG and $APPLOUT subdirectories. This $APPLCSF directory will be used instead of the various product top directories to write
all the log/out files to.


The most common concurrent manager problems are caused by file protection problems at the Unix/linux  level.

-Are you starting the concurrent managers as applmgr?
-Can applmgr do the following to create a file in the
$FND_TOP/$APPLLOG directory?
$FND_TOP/$APPLOUT directory?
Unix: $ touch $FND_TOP/$APPLLOG/a
-If this fails, who owns the directory?
Unix: $ ls -ld $FND_TOP/$APPLLOG
-Is this directory a symbolic link? if so, what are the protections on the directory it points to?
-Are you running out of disk space on this partition? i-nodes?
Unix: $ df -k
Unix (on some systems) to check i-nodes: $ df -i
-Is APPLCSF set?
-If so, can applmgr do this?
Unix: $ touch $APPLCSF/$APPLLOG/a
-Check $APPLOUT (usually “out”) directories just like log directories.

If a PL/SQL Concurrent Program can’t write to an external file, you will receive an error message similar to:

MSG-00102: Error Message :ORA-20100: File o0000071.tmp creation for FND_FILE failed.
You will find more information on the cause of the error in request log.
ORA-06512: at "APPS.FND_FILE", line 378
ORA-06512: at "APPS.FND_FILE", line 473
ORA-06512: at "APPS.AP_XXXX", line 192
REP-1419: 'beforereport': PL/SQL program aborted.

NOTE: Applications also produces temporary PL/SQL output files used in concurrent processing. These files are written to a location on the database server node specified by the APPLPTMP environment setting. The APPLPTMP directory must be the same directory as specified by the utl_file_dir parameter in your database initialization file.
.
Rapid Install sets both APPLPTMP and the utl_file_dir parameter to the same default directory. As the temporary files placed in this directory may contain context sensitive information, it should be a secure directory on the database server node with read and write access for the database server owner. In a multi-node system, the directory defined by APPLPTMP does not need to exist on the application tier servers. During an upgrade with AutoUpgrade, you must provide the utl_file_dir parameter value for the APPLPTMP environment setting.

To isolate where the problem is, verify the following:

1) Make sure that the name of the file is valid (the file name should not include characters like “^”)

2) Make sure that APPLPTMP is set to a valid directory and that BOTH the applmgr user and the database user have read and write permissions on that directory (normally, it can be set to the same directory as APPLTMP)

3) Make sure that the file does not exit on the directory pointed by APPLPTMP

4) Make sure the directory pointed by APPLPTMP is the first entry on the utl_file_dir. Also, verify that all the entries on the utl_file_dir are valid and that the applmgr has read/write permissions.

If using an spfile, verify the proper syntax to set utl_file_dir:

Ex.

ALTER SYSTEM SET UTL_FILE_DIR='directory1','directory2' scope=spfile;

5) If still having problems, check if you can write a file directly using FND_FILE, which is the package used by the Application. From SQLPLUS, connected as the apps user, run:

SQL> exec FND_FILE.PUT_LINE(FND_FILE.LOG, 'THIS IS A TEST');

This should dump a file on APPLPTMP.

If this test works, it would indicate that FND_FILE is OK and the problem is possibly with the Application.

You may want to leave only one entry on utl_file_dir for this test.

6) If still having problems, check if you can write a file using UTL_FILE, which is used by FND_FILE.

Run the PL/SQL below, changing to the first entry on utl_file_dir (you may want to leave just one entry on utl_file_dir for this test).

set serveroutput on
DECLARE file_location VARCHAR2(256) := '';
file_name VARCHAR2(256) := 'utlfile1.lst';
file_text VARCHAR2(256) := 'THIS IS A TEST';
file_id UTL_FILE.file_type;
BEGIN
file_id := UTL_FILE.fopen(file_Location,file_name, 'W');
UTL_FILE.put_line(file_id, file_text);
UTL_FILE.fclose(file_id);
EXCEPTION
WHEN UTL_FILE.INVALID_PATH
THEN
dbms_output.put_line('Invalid path ' || SQLERRM);
WHEN OTHERS
THEN
dbms_output.put_line('Others '|| SQLCODE || ' ' || SQLERRM);
END;
/

This program should dump a file on the requested directory. If the test fails, the problem is probably on the Database side.

Related Articles

Top 30 Most Useful Concurrent Manager Queries

Concurrent Manager:cleanup_node failed due to ORA-01427

Request set in Concurrent Manager

Awesome 24 Concurrent Manager Interview questions

Parallel Concurrent Processing

Core file for oracle concurrent manager

Concurrent Request Phase and Status

Leave a Reply