The concurrent manager Process of EBS, ebsconcurrent

The concurrent manager Process of EBS, ebsconcurrent

First, use sqlplus to connect to the database and check the connection session.

select * from v$session where username='APPS' and program like 'sqlplus%';

View the session information of the current APPS user using sqlplus to connect to the database. We can see SID = 38, SERIAL # = 28631,

Then find out the process of this session:

select p.* from v$process p,v$session s where p.addr = s.paddr and s.sid = 38;

See PID = 28, SPID = 5010. SERIAL # = 233.

In this case, we set the 10046 trace event.

alter session set tracefile_identifier='123456';  alter session set events '10046 trace name context forever, level 12';  

Re-query the v $ process table and find TRACEID = 123456, and TRACEFILE = "DIR... /VID_ora_5010_123456.trc ", which sets SQL trace. All database operations connected this time are recorded in this file. The file name is composed of a process id and an identifier. If the identifier is empty, only the process number is available.

Now let's look at Form Database connection process number, open Form after point help-> about Oracle Applications, which can find the Database Server PID: 5762 (connection mode frmweb@erik-lnx.oracle.com (TNS V1-V3 ), this can be associated with the v $ process and v $ session tables). Therefore, all database operations on the Form interface will be recorded in the trace file of process 5762.

Now the question is, where will the database operations performed by the concurrent request submitted on Form be recorded in the trace file?

When both the Form service and the concurrent manager Service are enabled, view the background process ps-aef. You can see that the oracle user has some processes, which can be divided into the following categories:

1. oracleVID (LOCAL = NO) indicates a database connection. For example, the above sqlplus and Form connections are like this. Their PPID = 1 indicates that they are all started by the main process;

2. The process ora_w000_VID belongs to the database.

3. What we need to pay attention to is

oracle    7451     1  0 Jan25 pts/1    00:00:00 shoracle    7456  7451  0 Jan25 pts/1    00:00:25 FNDLIBR                                                                                                                      oracle    7686     1  0 Jan25 ?        00:00:03 FNDSMoracle    7744  7686  0 Jan25 ?        00:00:00 RCVOLTM14 oracle    7749  7686  0 Jan25 ?        00:00:00 FFTM oracle    7750  7686  0 Jan25 ?        00:00:01 INCTM oracle    7751  7686  0 Jan25 ?        00:00:00 CYQLIB 

Here there are several processes of PPID = 7686, and then see the PID = 7686 process called FNDSM, This is the concurrent manager process. many other processes are started by this process, such as RCVOLTM (online manager of RCV module) and fftm inctm... and so on.

At this time, if we submit an RTP request and check the background process, we find that another process is called RVCTP.

oracle    6161  7885  0 18:43 ?        00:00:00 RVCTP

A process with process id PID = 6161, PPID = 7885, PID = 7885 is FNDLIBR, which is generated by PID = 7686 FNDSM. To sum up, FNDSM generates FNDLIBR, then RVCTP is generated. When we submit a request, the following function is actually called.

fnd_request.submit_request('PO','RVCTP',NULL,NULL,FALSE,'IMMEDIATE',p_group_id,...)

The RVCTP process is created. however, the RVCTP process does not actually perform database operations, but generates another process. The process number is 2 (6163) higher than the rvctp pid for actual data processing, therefore, database access is recorded in VID_ora_6163_123456.trc. check VID_ora_6163_123456.trc and you will see the following statement. The SQL trace file tells you which process generates the trace file.

* Module name :( RVCTP@erik-lnx.oracle.com (TNS V1-V3) 19:54:06. 518

The RVCTP process automatically disappears after processing.

RCVOLTM and RVCTP are different. This is on-line transaction manager, which processes online requests. for example, we use the online mode to receive a PO (actually calling fnd_transaction.synchronous (l_timeout, l_outcome, l_msg, 'po', 'rcvtpo', 'online', p_group_id ,...)), the following process is displayed:

oracle    7760  7686  0 Jan25 ?        00:00:00 RCVOLTM14 oracle    7762     1  0 Jan25 ?        00:00:03 oracleVID (LOCAL=NO)

The generated trace file is VID_ora_7762_123456.trc. This is also because the RCVOLTM process does not actually process data, but generates a subprocess for processing. open the trace file and check that module name :( e: PO: cp: RCVOLTM14) is indeed generated by RCVOLTM14;

This is basically a manager-worker structure. Whether it is submitting a request in Form, generating an RVCTP process, or running an existing RCVOLTM14 process in online mode, A new sub-process is generated. The PID of the sub-process is the PID of the parent process + 2. as for why + 2 instead of + 1, you need to ask the person who writes the code. in Immediate and Batch modes, the RVCTP process is generated. This process is generated after fnd_request.submit_request () is called. After the operation, the process disappears. in online mode, it will run in the existing RCVOLTM14 process. After the process ends, it will not disappear and will still exist.

The RVCTP and RCVOLTM processes are actually two executable programs. Let's look at $ PO_TOP,

[oracle@erik-lnx bin]$ ls $PO_TOP/binlibpo.a  POCDMC  POCFH  POCIRM  POCISO  POCRMC  POXCON  POXRAF  POXRSR  RCVOLTM  RVCTP 

We can see that the last two files are the programs we mentioned above that generate the above two processes.

strings RVCTP |grep '$Header'

We can see that there are many files, such as rvtii. lpc rvtuq. lpc and so on. These are all source code files. Because the source code of RVCTP is written in C, it is necessary to compile and connect these files to become executable files RVCTP/RCVOLTM. for example, rvtii. rvtii generated after lpc compilation. the o file is in the $ PO_TOP/lib directory, and then uses adrelink. sh command to put all. o files are connected to executable files.

Therefore, concurrent manager has a hierarchical relationship. A process is generated by another process, and some processes disappear after running. all the processes mentioned above have a parent process, FNDSM (standard manager), which generates other concurrent managers, while FNDSM (PID = 7686) this process is in the same status as the Form process (PID = 5762). That is to say, Form and FNDSM are two processes in the same status. Sometimes we start the Form service, however, if the concurrent manager service is not started, a warning "no manager" is reported when a request is submitted.

Finally, let's talk about how to start the FNDSM process. there are some useful scripts in the $ ADMIN_SCRIPTS_HOME directory, adcmctl. sh is used to manage the start and stop of concurrent manager, adcmctl. sh stop/start apps/apps can be used to stop/start the concurrent manager Service.

[oracle@erik-lnx scripts]$ adcmctl.sh stop apps/appsYou are running adcmctl.sh version 120.17.12010000.5Shutting down concurrent managers for VID ...

[oracle@erik-lnx scripts]$ ps -aef |grep 'FNDLIBR'oracle    8576  6181  0 20:27 pts/1    00:00:00 grep FNDLIBR[oracle@erik-lnx scripts]$ ps -aef |grep 'FNDSM'oracle    8578  6181  0 20:27 pts/1    00:00:00 grep FNDSM

The FNDSM process has disappeared. A warning "no manager" is reported when any request is submitted. The request will be processed after the restart.

Finally, let's talk about the features of SQL trace generated by different processes. Open the. trc file and search for the MODULE at the beginning of the file to see which process generates the trace. For example:

* ** Module name :( SQL * Plus) *** MODULE NAME :( e: PO: cp: RCVOLTM14) *** MODULE NAME :( RVCTP@erik-lnx.oracle.com (TNS V1-V3 )) * ** module name :( frmweb@erik-lnx.oracle.com (TNS V1-V3) -- Form process *** module name :( fnd. framework. service. lookups. server. lookUpAM: R) -- OAF Process