EBS 的 concurrent manager 進程，ebsconcurrent

EBS 的 concurrent manager 進程，ebsconcurrent

首先我們用sqlplus 連上資料庫, 查看一下這個串連的 session

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

查看當前 APPS 使用者用 sqlplus 串連資料庫的session 資訊; 可以看到 SID = 38, SERIAL# = 28631, 

然後查出這個session 的進程:

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

看到 PID = 28, SPID = 5010. SERIAL# = 233.

這時我們設定 10046 trace 事件

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

重新查 v$process 表, 發現 TRACEID = 123456, 並且 TRACEFILE = "DIR.../VID_ora_5010_123456.trc", 這就設定了SQL trace, 這一次串連的所有資料庫操作都會被記錄到這個檔案中, 檔案名稱以進程 id 和一個標識符組成, 如果標識符為空白, 就只有進程號.

現在我們來看 Form 的資料庫連接進程號, 開啟 Form 之後點 help -> about Oracle Applications, 裡面可以查到 Database Server PID : 5762 (串連方式 frmweb@erik-lnx.oracle.com (TNS V1-V3), 這可以關聯v$process 和 v$session 表查到), 於是在 Form 介面上所有資料庫操作都會被記錄到進程號 5762 的 trace 檔案當中.

現在問題來了, Form 上提交的 concurrent request 進行的資料庫操作會被記錄到哪裡的 trace 檔案中呢?

在 Form 服務和 concurrent manager 服務都開啟的情況下, 查看後台進程 ps -aef, 可以看到 oracle 使用者下面有一些進程, 大概可以分下類:

1. oracleVID (LOCAL=NO) 這類表示資料庫連接, 例如上面的 sqlplus 和 Form 串連, 都是這種, 他們的 PPID = 1, 說明都是由主進程啟動的;

2. ora_w000_VID 這種屬於資料庫自己的進程, 可以不管

3. 我們要關注的是這些

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 

這裡有好幾個進程的 PPID = 7686, 然後看下 PID = 7686 的進程叫 FNDSM, 這個就是 concurrent manager 進程了. 由這個進程啟動了其他好多進程, 例如 RCVOLTM (RCV 模組的 online manager), FFTM INCTM... 等等.

這時如果我們去提交一個 RTP 請求,再查看後台進程, 發現多了一個進程叫 RVCTP

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

進程 id PID = 6161, PPID = 7885, PID = 7885 的一個進程是 FNDLIBR,  是由 PID = 7686 FNDSM 產生的, 所以總結一下, 就是 FNDSM 產生了FNDLIBR, 然後再產生了RVCTP, 當我們提交請求, 其實就是調用了下面的函數

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

於是就建立了RVCTP 這個進程. 但是RVCTP 進程並沒有真正去做資料庫操作, 而是會產生另一個進程, 進程號比RVCTP 的 PID 增加 2 (6163), 去做實際的資料處理, 因此資料庫的訪問會被記錄在 VID_ora_6163_123456.trc 裡面. 查看 VID_ora_6163_123456.trc 就可以看到下面一句話, SQL trace 檔案已經告訴你這是由哪個進程產生的 trace 檔案.

*** MODULE NAME:(RVCTP@erik-lnx.oracle.com (TNS V1-V3)) 2015-01-26 19:54:06.518

RVCTP 進程在處理完之後自動消失.

RCVOLTM 和 RVCTP 不一樣, 這是 on-line transaction manager, 負責處理 online 的請求. 比如我們用 online 模式接收一個PO (實際上是調用 fnd_transaction.synchronous(l_timeout,l_outcome,l_msg,'PO','RCVTPO','ONLINE',p_group_id,...)), 可以看到下面的進程:

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

於是產生的trace 檔案是 VID_ora_7762_123456.trc, 這也是因為 RCVOLTM 進程並不真正去做資料處理的工作, 而是產生一個子進程處理. 開啟這個trace 檔案看一下: MODULE NAME:(e:PO:cp:RCVOLTM14), 確實是由 RCVOLTM14 產生的;

這基本上是一個 manager - worker 的結構, 不管是 Form 裡面提交請求, 產生一個 RVCTP 進程, 還是online 模式下運行早已存在的RCVOLTM14 進程, 都會由此產生一個新的子進程, 子進程的 PID = 父進程的 PID + 2. 至於為什麼 +2 而不是 +1, 這就要問寫代碼的人了. 在 Immediate 和 Batch 模式下, 產生的是 RVCTP 進程, 這個進程在調用fnd_request.submit_request() 後產生, 運行結束後進程消失. online 模式下, 會在原本就存在的進程RCVOLTM14 裡運行, 結束後進程不會消失, 依然存在.

RVCTP 和 RCVOLTM 這兩個進程實際上是兩個可執行程式, 我們到 $PO_TOP 下看,

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

就可以看到最後兩個檔案, 就是上面我們說的產生上面那兩個進程的程式.

strings RVCTP |grep '$Header'

可以看到裡面有很多檔案, 例如 rvtii.lpc rvtuq.lpc 等等, 這些都是原始碼檔案, 因為 RVCTP 的原始碼是用 C 寫的, 所以要把這些檔案編譯完串連起來才能變成可執行檔 RVCTP/RCVOLTM. 例如 rvtii.lpc 編譯完產生的 rvtii.o 檔案在 $PO_TOP/lib 目錄下, 再用adrelink.sh 命令把所有的 .o 檔案串連成可執行檔.

所以說, concurrent manager 是有層級關係的, 一個進程由另一個進程產生, 有的進程運行完就消失, 有的會一直存在. 所有上面提到的這些進程都有一個父進程, 就是FNDSM (standard manager), 由它產生其他的 concurrent manager, 而FNDSM (PID=7686)  這個進程和 Form 進程(PID = 5762)是處於相同地位的, 也就是說, Form 和 FNDSM 是相同地位的兩個進程, 有時候我們啟動了 Form 服務, 但是沒有啟動 concurrent manager 服務, 那麼提交請求的時候就會報 "no manager" 的警告.

最後說一下怎樣啟動 FNDSM 進程. 在 $ADMIN_SCRIPTS_HOME 目錄下有一些很好用的指令碼, adcmctl.sh 用於管理 concurrent manager 的啟動與停止, adcmctl.sh stop/start apps/apps 可以用來停止/開始 concurrent manager 服務.

[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

發現 FNDSM 進程已經消失了. 這時提交任何請求都會報 "no manager" 的警告. 重新啟動之後提交的請求就會繼續被處理了.

最後的最後, 說下由不同進程產生的SQL trace 的特點, 開啟 .trc 檔案, 在檔案開頭尋找 MODULE, 就可以看到產生 trace 的進程是哪個了. 例如:

*** 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 進程*** MODULE NAME:(fnd.framework.service.lookups.server.LookUpAM:R) --OAF 進程