Current Applied Patch & Patch level status

Check Current Applied Patch & Patch level status of all modules in oracle

Check Current Applied Patch

set linesize 1000
set pages 9999
col patch_name format a10
col patch_type format a10
col maint_pack_level format a15
set colsep |

  SELECT   patch_name,           patch_type,           maint_pack_level,           creation_date    FROM   applsys.ad_applied_patches ORDER BY   creation_date DESC

Query used to view the patch level status of all modules

SELECT   a.application_name, DECODE (b.status, 'I', 'Installed', 'S', 'Shared', 'N/A') status,           patch_level  FROM   apps.fnd_application_vl a, apps.fnd_product_installations b WHERE   a.application_id = b.application_id;

Application Short Name of a module

Query to find Application Short Name of a module

The following query lists all the applications related information. This query can be used to find the APPLICATION_SHORT_NAME of a module (eg. Payables, Receivables, Order Management, etc.) that are often used for downloading FNDLOAD LDT files, adding responsibility to a user and many more.

You can uncomment the FAT.APPLICATION_NAME condition (very bottom line of the query) to learn about a particular module. In this case, I used "Payables".

SELECT fa.application_id           "Application ID",

       fat.application_name        "Application Name",

       fa.application_short_name   "Application Short Name",

       fa.basepath                 "Basepath"

  FROM fnd_application     fa,

       fnd_application_tl  fat

 WHERE fa.application_id = fat.application_id

   AND fat.language      = USERENV('LANG')

   -- AND fat.application_name = 'Payables'  -- <change it>

 ORDER BY fat.application_name;

 

ADOP CUTOVER (Reducing Time)

What can I do to reduce the time required for cutover?

It is important to distinguish between the time needed for the whole cutover phase, and the downtime period within the phase.

The actual downtime (during which users cannot log in) is significantly shorter than the whole phase.

To help reduce the overall time taken by cutover, you can do three things:

• Run the finalize phase explicitly, to obviate the need for cutover to do so.
• Shut down the concurrent managers before running cutover, to avoid having to wait for concurrent requests to complete. Alternatively, ensure no long-running concurrent jobs are submitted while a patching cycle is in progress.
• Ensure you are using the maximum number of parallel workers your system will support.

ADOP DOWNTIME MODE

What is downtime mode and when can it be used?

To optimize the process of upgrading to E-Business Suite Release 12.2, the AD Delta 5 Release Update Pack introduced downtime mode, which is used as follows:

• $ adop phase=apply patches=<patch_number> apply_mode=downtime

Downtime mode does not use an online patching cycle. 

The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime. 

When applying Oracle E-Business Suite patches in this mode, adop will first confirm that the application tier services are down, and will then proceed to apply the patch to the run edition of the Oracle E-Business Suite database and file system.

Downtime mode is supported for:

• All patching (including post-upgrade patching) that forms part of the Release 12.2 upgrade process and is completed before the system is scaled up, the application tier services are started, and users log in to the upgraded system.
• Single-node development or test environments, where production support and high availability are not required.

Downtime mode allows the 12.2 upgrade process to be completed as quickly as possible.

 Once the upgrade is complete and users are online, all subsequent patching on a production system should use online mode, not downtime mode, unless the patch readme states otherwise. 

Several restrictions apply to the use of downtime mode:

• You cannot validate successful patch application before cutover to the updated code takes place.
• There is no capability to abort a failed patch and return to the existing run edition.
• Release 12.2 patches are not normally tested in downtime mode.
• Use of downtime mode in a multi-node application tier environment is not tested or supported.

Note: Downtime mode is only supported for production use where explicitly documented, or otherwise directed by Oracle.

BACKUPSET DETAILS

Backupset Details

set lines 220
set pages 1000
col backup_type for a4 heading "TYPE"
col controlfile_included heading "CF?"
col incremental_level heading "INCR LVL"
col pieces for 999 heading "PCS"
col elapsed_seconds heading "ELAPSED|SECONDS"
col device_type for a10 trunc heading "DEVICE|TYPE"
col compressed for a4 heading "ZIP?"
col output_mbytes for 9,999,999 heading "OUTPUT|MBYTES"
col input_file_scan_only for a4 heading "SCAN|ONLY"
select
  d.bs_key, d.backup_type, d.controlfile_included, d.incremental_level, d.pieces,
  to_char(d.start_time, 'yyyy-mm-dd hh24:mi:ss') start_time,
  to_char(d.completion_time, 'yyyy-mm-dd hh24:mi:ss') completion_time,
  d.elapsed_seconds, d.device_type, d.compressed, (d.output_bytes/1024/1024) output_mbytes, s.input_file_scan_only
from V$BACKUP_SET_DETAILS d
  join V$BACKUP_SET s on s.set_stamp = d.set_stamp and s.set_count = d.set_count
where session_recid = &SESSION_RECID
  and session_stamp = &SESSION_STAMP
order by d.start_time;

BACKUP JOB STATUS

 Backup jobs’ status and metadata

set lines 220

set pages 1000

col cf for 9,999

col df for 9,999

col elapsed_seconds heading "ELAPSED|SECONDS"

col i0 for 9,999

col i1 for 9,999

col l for 9,999

col output_mbytes for 9,999,999 heading "OUTPUT|MBYTES"

col session_recid for 999999 heading "SESSION|RECID"

col session_stamp for 99999999999 heading "SESSION|STAMP"

col status for a10 trunc

col time_taken_display for a10 heading "TIME|TAKEN"

col output_instance for 9999 heading "OUT|INST"

select

  j.session_recid, j.session_stamp,

  to_char(j.start_time, 'yyyy-mm-dd hh24:mi:ss') start_time,

  to_char(j.end_time, 'yyyy-mm-dd hh24:mi:ss') end_time,

  (j.output_bytes/1024/1024) output_mbytes, j.status, j.input_type,

  decode(to_char(j.start_time, 'd'), 1, 'Sunday', 2, 'Monday',

                                     3, 'Tuesday', 4, 'Wednesday',

                                     5, 'Thursday', 6, 'Friday',

                                     7, 'Saturday') dow,

  j.elapsed_seconds, j.time_taken_display,

  x.cf, x.df, x.i0, x.i1, x.l,

  ro.inst_id output_instance

from V$RMAN_BACKUP_JOB_DETAILS j

  left outer join (select

                     d.session_recid, d.session_stamp,

                     sum(case when d.controlfile_included = 'YES' then d.pieces else 0 end) CF,

                     sum(case when d.controlfile_included = 'NO'

                               and d.backup_type||d.incremental_level = 'D' then d.pieces else 0 end) DF,

                     sum(case when d.backup_type||d.incremental_level = 'D0' then d.pieces else 0 end) I0,

                     sum(case when d.backup_type||d.incremental_level = 'I1' then d.pieces else 0 end) I1,

                     sum(case when d.backup_type = 'L' then d.pieces else 0 end) L

                   from

                     V$BACKUP_SET_DETAILS d

                     join V$BACKUP_SET s on s.set_stamp = d.set_stamp and s.set_count = d.set_count

                   where s.input_file_scan_only = 'NO'

                   group by d.session_recid, d.session_stamp) x

    on x.session_recid = j.session_recid and x.session_stamp = j.session_stamp

  left outer join (select o.session_recid, o.session_stamp, min(inst_id) inst_id

                   from GV$RMAN_OUTPUT o

                   group by o.session_recid, o.session_stamp)

    ro on ro.session_recid = j.session_recid and ro.session_stamp = j.session_stamp

where j.start_time > trunc(sysdate)-&NUMBER_OF_DAYS

order by j.start_time;

CF:

Number of controlfile backups included in the backup set

DF:

Number of datafile full backups included in the backup set

I0:

Number of datafile incremental level-0 backups included in the backup set

I1:

Number of datafile incremental level-1 backups included in the backup set

L:

Number of archived log backups included in the backup set

OUT INST:

BACKUP REPORT SCRIPTS

Script will report on all backups – full, incremental and archivelog backups -

SET LINESIZE 125

COL start_time FORMAT A25

COL END_TIME FORMAT A25

SET PAGES 9999

col STATUS format a25

col hrs format 999.99

select

SESSION_KEY, INPUT_TYPE, STATUS,

to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,

to_char(END_TIME,'mm/dd/yy hh24:mi')   end_time,

elapsed_seconds/3600                   hrs

from V$RMAN_BACKUP_JOB_DETAILS

order by session_key;

script will report all on full and incremental backups, not archivelog backups -

col STATUS format a9

col hrs format 999.99

select

SESSION_KEY, INPUT_TYPE, STATUS,

to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,

to_char(END_TIME,'mm/dd/yy hh24:mi')   end_time,

elapsed_seconds/3600                   hrs

from V$RMAN_BACKUP_JOB_DETAILS

where input_type='DB FULL'

order by session_key;

col STATUS format a9

col hrs format 999.99

select

SESSION_KEY, INPUT_TYPE, STATUS,

to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,

to_char(END_TIME,'mm/dd/yy hh24:mi')   end_time,

elapsed_seconds/3600                   hrs

from V$RMAN_BACKUP_JOB_DETAILS

where input_type like '%DB%'

order by session_key;

ARCHIVE LOG GENERATION

Archive log generation per day 

SELECT SUM_ARCH.DAY,
         SUM_ARCH.GENERATED_MB,
         SUM_ARCH_DEL.DELETED_MB,
         SUM_ARCH.GENERATED_MB - SUM_ARCH_DEL.DELETED_MB "REMAINING_MB"
    FROM (  SELECT TO_CHAR (COMPLETION_TIME, 'DD/MM/YYYY') DAY,
                   SUM (ROUND ( (blocks * block_size) / (1024 * 1024), 2))
                      GENERATED_MB
              FROM V$ARCHIVED_LOG
             WHERE ARCHIVED = 'YES'
          GROUP BY TO_CHAR (COMPLETION_TIME, 'DD/MM/YYYY')) SUM_ARCH,
         (  SELECT TO_CHAR (COMPLETION_TIME, 'DD/MM/YYYY') DAY,
                   SUM (ROUND ( (blocks * block_size) / (1024 * 1024), 2))
                      DELETED_MB
              FROM V$ARCHIVED_LOG
             WHERE ARCHIVED = 'YES' AND DELETED = 'YES'
          GROUP BY TO_CHAR (COMPLETION_TIME, 'DD/MM/YYYY')) SUM_ARCH_DEL
   WHERE SUM_ARCH.DAY = SUM_ARCH_DEL.DAY(+)
ORDER BY TO_DATE (DAY, 'DD/MM/YYYY');

How To Tell If Concurrent Managers For A Particular SID Are Running

 Doc ID 2089560.6

PROBLEM DESCRIPTION
-------------------

You are logged on to a server running multiple Oracle Applications instances, 
and you want to know if there are any concurrent managers processes running
for a particular instance running.

The following command:

     ps -ef | grep FNDLIBR

shows all FNDLIBR processes running on the server.  However, how can you tell 
which processes are associated with which instance?  How can you find all other 
concurrent manager processes and System PIDs?


SOLUTION DESCRIPTION
--------------------

You need to run $FND_TOP/sql/afcmstat.sql as the APPS user in the 
APPL_TOP/instance you are interested in.
 
The section labeled:  "Managers with their corresponding Oracle and System 
Process Id's" contains the information you are looking for.  If the internal 
manager is not running, you will not get a list under the heading.


These SQL scripts are useful in diagnosing concurrent manager related 
problems.  The names are listed below (located in $FND_TOP/sql): 
 
NAME              DESCRIPTION 
-----------------------------------------------------------------
 
afcmstat.sql    Lists active manager processes along with 
                defined max capacity to be in effect at the 
                present time.  Note: could be slow if table 
                FND_CONCURRENT_PROCESSES is large (since 
                history is maintained in it). 

afimchk.sql     Tells the status of ICM and PMON method in effect.
 
  
afrqrun.sql     Lists all the running, waiting (waiting to be 
                registered after sub requests completed) and 
                terminating requests. 
 
afrqwait.sql    Lists requests that are constrained and thus 
                waiting for the ICM to release them. 
 
afrqscm.sql     Prints log file name of managers that can run a 
                given request.  Helpful when a runnable request 
                stays pending to check for possible error 
                messages in manager log file. 
 
afcmcreq.sql    Prints the log file name of the manager that 
                processed the request (takes request id as 
                argument). 
  
afrqstat.sql    Summary of completed concurrent requests 
                grouped by completion status and execution type. 
 
afimlock.sql    Lists locks that the ICM is waiting to get. 
 
afcmrrq.sql     Lists managers that are currently running a 
                request (username, request id, program name, 
                start date, etc).

How To Change The Log And Output Location For Concurrent Managers?

A) The Logs and Output are located in $APPLCSF/$APPLLOG and  
$APPLCSF.

cd $APPLCSF/log
cd $APPLCSF/out

You can change the value of APPLCSF, APPLLOG and APPLOUT from the context file or
 you can do it from OAM. 

 The $APPLCSF/$APPLLOG and $APPLCSF/$APPLOUT directories should exist 
  and be accessible from the concurrent node.

B. Run autoconfig and bounce the concurrent managers for the changes to be implemented.

Cocurrent request run per week

Script to calculate number of requests run per week for performance gauging: 

SELECT COUNT(*) Total, sum(decode(greatest(0,ceil (sysdate - actual_completion_date)),
    least(7,ceil(sysdate-actual_completion_date) ),1,0)) Week4, sum(decode(greatest(8,ceil (sysdate - actual_completion_date)),
    least(14,ceil(sysdate-actual_completion_date) ),1,0)) Week3, sum(decode(greatest(15,ceil (sysdate -  actual_completion_date)),
    least(21,ceil(sysdate-actual_completion_date) ),1,0)) Week2,
    sum(decode(greatest(22,ceil (sysdate - actual_completion_date)), least(28,ceil(sysdate-actual_completion_date) ),1,0))
    Week1 FROM FND_CONCURRENT_REQUESTS WHERE ACTUAL_COMPLETION_DATE is not null;

Concurrent manager in Oracle APPS

 Concurrent Manager in Oracle Apps

Concurrent Processing = This is a batch processing job which runs in background while user works on front end transaction.

Concurrent Request = When user asks to run a program that request is
called Concurrent request.

Concurrent Manager = Concurrent Manager is the program which runs the concurrent requests.

There are three types of concurrent managers.

1.           Internal Concurrent Manager [ICM]

ICM ensures that all the concurrent manager is running. It starts and stops all concurrent managers. It also controls service managers in each node. Internal Monitor monitors the ICM and restarts ICM if ICM fails.

2.           Conflict Resolution Manager [CRM]

It checks concurrent program incompatibility.

3.           Standard Managaer

It takes care of processing any concurrent request. This manager runs always in 24x7 mode.

Now when a concurrent program is written, it needs to be executed daily at particular time.

If we do it manual, there might be chances of delays or it might happen that two different people run the same program at the same time which might lead problems.

 So we need a manager which can do all this tasks for us.

The responsibility for execution of concurrent programs is given to Concurrent Manager, which ensures that each concurrent program can run successfully without any conflicts.

They also ensures that the applications are not overwhelmed with requests.

They also manages the batch processing and report generation.

The default installation of Oracle Applications comes with a number of pre defined concurrent managers however you can create your custom concurrent managers to spread out the load of your job processing.

 Apart from taking care of the load of your jobs the concurrent managers can also schedule the jobs periodically.

Also we can assign specific priority and specific times to the different programs,

so that the concurrent managers can run them in specific workshifts.

Concurrent managers also allows you to tweak the number of concurrent process that it can handle concurrently.

 If any request exceed this prescribed limit they are automatically put on pending state.

 The processing of a request takes place based on the time of request submission and priority of the request submitted.

There are many pre-configured 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.

Apart from these three concurrent manages there is another type of concurrent manager known as the Transaction Manager also exists. The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.

The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.

From the front end you could view the status of your concurrent manager by logging with the System Administration responsibility and going to the Concurrent Manager administer screen.

From the front end you could view the status of your concurrent manager by logging with the System Administration responsibility and going to the Concurrent Manager administer screen.

The status of concurrent managers and the nodes on which they are configured can also be known from the Oracle Applications manager.

How to start Concurrent Manager in R12

There are two ways to start concurrents manager.

1. $INST_TOP/admin/scripts/adcmctl.sh start apps/<apps password>

2. strtmgr.sh utility

A sample command is as follows.

$FND_TOP/bin/strtmgr sysmgr=apps/apps logfile=/tmp/log

some important parameters of strtmgr is as follows.

a. Mgrname = The name of manager. Default is "Internal Manager".

b. Sleep = The number of seconds ICM waits before checking new request from table FND_CONCURRENT_REQUEST.

c. Diag = Deault is N. Diag=Y means full diagionistic output will be written in log file.

d. Pmon = The number of sleep cycle ICM will wait before checking failed manager.

e. Quesiz

Location of Concurrent Manager Log file

For R12 

$INST_TOP/logs/appl

How to check the status of the concurrent manager

There are 3 ways to find the status.

1. Operating system level

If process FNDLIBR is running that means that concurrent manager is up and running.

$ ps -ef | grep FNDLIBR | grep appl*

2. From Forms

Go to System Administrator > Cocurrent > Manager > Administrator. If concurrent manager is running then the value of Actual and Target should be greater than or equal to 1.

3. Sql script

Run the following sql script to check the concurrent manager status.

$ cd $FND_TOP/sql

$ sqlplus -s apps/apps @afimchk.sql

How to Stop Concurrent Manager

1. $ADMIN_SCRIPTS_HOME/adcmctl.sh stop apps/<apps pw>

2. By killing FNDLIBR process issue -9 (kill -9 pid)

3. Individual concurrent manager can be stopped by navigating to Concurrent > Manager > Administrator.

4. Using CONCSUB Utility

$ CONCSUB username/pw SYSADMIN 'System Administrator' SYSADMIN WAIT=Y CONCURRENT FND ABORTs

What is CONCSUB Utility

CONCSUB Utility allows user to submit concurrent request from operating system level.

An example of that request is as follows.

CONCSUB <ORACLE ID WITH PASSWORD> <Responsibility Application Short Name> <Responsibility Name> [WAIT=<Wait Flag>] CONCURRENT <Concurrent Program Application Short Name> <Concurrent Program Name> [START=<Requested Start Date>] [REPEAT_DAYS=<Repeat Interval>] [REPEAT_END=<>] <Concurrent Program Argument>

Wait parameter = whether CONCSUB waits till request completes. W=Y means it return to Unix prompt immediately.

Flow of a Concurrent Request

Once Concurrent Request is submitted the following things happen ->

A. FND_CONCURRENT_REQUESTS table is updated with the request with scheduled time.

B. Once request is scheduled the concurrent manager checks the table FND_CONCURRENT_TABLES to find out if there is any incompatibility in program.

C. If there is any incompatibility CRM [Conflict Resolution Manager] takes care.

D. For no incompatibility it first checks whether there is any special manager who can take care the request else standard manager takes care.

E. Once completed FND_CONCURRENT_REQUEST table is updated with status.

Some Important phases of concurrent manager

A. Standby = Request is put in standby mode while CRM is resolving the incompatibility.

B. No Manager = CM is down or no manager was defined.

C. Disabled = Concurrent Program is disabled.

How to add or define a new Concurrent Manager

Go to System Administrator > Concurrent > Manager > Define.

The important parameters of the above screen is as follows.

a. Manager = Name of the concurrent manager

b. Type = What type of concurrent manager we are going to define. The options are Concurrent manager, Transactional Manager, internal Monitor etc..

c. Cache Size = If cache size is 5, CM reads 5 requests at a time from quesue and waits until those are completed before reading new records.

d. Consumer Group = A Resource Consumer Group is a group of users who has similar resource usage requirements. Like we can create LOW_GROUP, HIGH_RESOURCE_GROUP consumer group and assign it here.

Parallel Concurrent Processing Details

1. Node

This is only applicable if parallel conc processing is enabled. The node must be registered with EBS and it must be there in FND_NODES table.

2. System Queue

This is used only if we want to use OS queue instead of default conc manager queue.

Program Library

CM only runs those programs which is listed in program libraries.

Specialization Rules

If we want to run certain types of request only and include and exclude some Cons Request the this screen is used.

Work Shifts

It defines the time for which the concurrent manager will be active. To define workshifts go to Concurrent > Manager > Work Shifts.

Concurrent Manager Administration

Go to System Administrator > Cocurrent > Manager > Administrator.

Some important description and functionality of this screen.

Process Actual

The number of actual process running on that CM.

Process Target

The maximum number of process that can be active. Process Target >= Process Actual.

Running

The number of request currently running.

Controlling Parameter ->

Terminate

Immediately abort all running request and particular manager terminates. If we terminate IM then all the cns manager stops.

Deactivate

Here before stopping the manager all the requests get completed. This is the difference between shut down and terminate.

Restart

Verify

This is available only for IM. The process monitoring of othere concurrent manager by IM is known as PMON Cycle. Verify forces to PMON cycle to occur immediately.

Parallel Concurrent Processing

Parallel concurrent helps to distribute load across various nodes to utilize full hardware resources. The following are some of the architecture of parrallel concurrent processing.

1. Cluster Env

In a cluster environment, multiple computer/CPU, each representing a single node, share a common pool of disks. Oracle Database resides in that common disk whereas multiple instances of RAC run simultaneously on multiple nodes of cluster. CM is also divided in multiple nodes.

2. Massively Parallel env

Here, multiple nodes are housed in a single computer and all nodes share a common pool of disk. Separate RAC instances run simultaneously on multiple node.

3. Networked Env

Multiple computers of same type are connected via LAN to a single DB or a RAC DB.

How Parallel Concurrent Processing happens

Each conc manager is assigned a primary and secondary node. The CM starts in primary node by default. It changes to the secondary node once there are some faults in primary node. ICM can run on any of the node. It can activate and deactivate any CM. Due to heavy fault tolerance of ICM it is monitored by Internal Monitor [IM]. IM starts ICM if it will fail in any time.

Generic Service Management [GSM]

GSM is a new concept and powerful framework to manage services in different host machines. Some services such as oracle forms listener, reports server, apache web listener, workflow mailer can be integrated in this framework. With GSM, the ICM will manage these services in each hosts. And each hosts has a service manager which acts on behalf of ICM in that hosts. This service manager monitor and controls the services in that host and send the end result to ICM.

Concurrent Manager Processes

The concurrent managers are like other process which run on the oracle applications executable FNDLIBR. The FNDLIBR executable is located at $FND_TOP/bin.

You could also grep the FNDLIBR executable to check if any concurrent manager process are running
$ ps -ef|grep FNDLIBR

The $FND_TOP/sql/afcmstat.sql script gives you a list of concurrent managers and their respective status.
Below is the list of Most of the Concurrent manager processes.

FNDLIBR
manages following Managers

·       Marketing Data Mining Manager

·       Transportation Manager

·       Session History Cleanup

·       UWQ Worklist Items Release for Crashed session

·       Collections Manager

·       OAM Metrics Collection Manager

·       Contracts Core Concurrent Manager

·       Standard Manager

·       WMS Task Archiving Manager

·       Oracle Provisioning Manager

INVLIBR
manages following Managers

·       Inventory Manager

MRCLIB
manages following Managers

·       MRP Manager

PALIBR manages following Managers

·       PA Streamline Manager

FNDSM
The Generic Service Management Framework Process

·       FNDSM is executable and core component in GSM ( Generic Service Management Framework discussed above). You start FNDSM services via application listener on all Nodes in Application Tier in E-Business Suite.

Concurrent Manager Scripts

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 process.