Oracle Concurrent Manager Secrets Part -I



Last updated on August 25th, 2016 at 04:34 am

Description about important Concurrent Manager 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 failover
-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 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

Concurrent Request log/Out:
FND_CONCURRENT_REQUESTS
LOGFILE_NODE_NAME, OUTFILE_NODE_NAME
-Indicate where files exist
-Used in 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

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.

How do you check the status of the managers from the OS
-Unix 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 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.

 

More Oracle Concurrent Manager related articles

Delivery Option while submitting concurrent request

Core files in Applications concurrent Manager

Concurrent Manager Secrets -II


Leave a Reply