Last updated on May 28th, 2019 at 03:44 am
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
-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 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 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
-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
-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
-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
-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
-Indicates node name where DBC file is located.
-Adgendbc.sh script creates DBC file.
-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
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
$ 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
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:
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.