平凡的幸福: OracleERP

顯示具有 OracleERP 標籤的文章。顯示所有文章

FRM-40654: Record has been updated. Requery block to see change

Oracle的ERP在客戶基本檔的from出現一個錯誤： FRM-40654: Record has been updated. Requery block to see change

一開始以為是有 Table Lock，但是查了一下，並沒有發現有Table Lock的現象，而且只有單一客戶的資料會有這個問題，最後發現是相關的 Table中，有一個欄位的資料前後有空白造成的，更新資料就解決了。

簡單紀錄一下，下次再出現時就知道如何解決了。

EBS 11i帳號登入正常，但是無法開啟Forms

今天突然遇到一個很奇怪的現象，已經開啟Form的使用者沒有異樣，但是重新於瀏覽器中成功登入後，在開啟Forms時卻出現無法連線資料庫的訊息。

因為自己並沒有對EBS做任何設定，也沒有異動DB設定，難道被使用者或其他的資訊人員弄壞了。

不過就在檢查DB的Log之後，發現是ORA-00020: maximum number of processes (1000) exceeded

這個錯誤就是超過了DB設定的process的值，所以後來的連線當然會失敗。

既然知道了原因，可依下列步驟來修改process的設定值
SQL> alter system set processes=25 scope=spfile;

由於processes參數是靜態參數，必需重啟資料庫使參數調整生效
SQL> shutdown immediate;
SQL> startup;

可執行下列的SQL來檢查process、session目前使用量、最大使用量、限制量
SQL> SELECT RESOURCE_NAME,
CURRENT_UTILIZATION, MAX_UTILIZATION, LIMIT_VALUE
FROM V$RESOURCE_LIMIT
WHERE RESOURCE_NAME IN ( 'sessions', 'processes');

利用下列的SQL來找出inactive大於24小時的session，last_call_et是指最後一個SQL執行完後到sysdate的時間，單位為秒
SQL> select 'alter system kill session ''' || sid || ',' || serial# || ''';' ,status,schemaname,osuser,process,
machine,program,sql_id,module,action,logon_time,last_call_et
          from v$session where status = 'INACTIVE'
          and last_call_et > 86400
          order by last_call_et desc;

Oracle EBS 11i找出ICM（Internal Manager掛掉）的log與問題

今天遇到Concurrent Program無法運行，經檢查後，發現是Internal Manager掛掉了。

Internal Manager是管理所有Concurrent Manager的管理程序，不會影響到EBS的Forms，所以它掛掉並不會影響EBS的操作，有時候會沒有發現掛掉了。

進入System Adminisrator，查看Concurent -> Manager -> Administer，檢查Internal Manager的Autual是否>=1 ，如果為0則表示沒有正常運行。

我的作法是先登入到EBS的作業系統，例如我的是Solaris，先執行下列的指令後再手動把這些process刪掉。

$ ps -ef |grep FNDLIBR

$ kill -9 <Process ID>

或是執行adcmctl.sh把相關的service停下來並手動把無法停用的process刪掉

$ adcmctl.sh stop apps/XXXXX

$ ps -ef |grep FNDLIBR

$ kill -9 <Process ID>

接著重啟Concurrent Manager：

$ adcmctl.sh start apps/XXXXX

經過上述的步驟，我的ICM終於恢復了，也不用重開整個EBS，接下來要查詢log，以便找出問題。

有三個方式可以找到ICM的log：

1、以apps User登入到系統，並執行下列指令如下，例如找到log file：TEST_0826.mgr

$ cd $APPLCSF/$APPLLOG

$ ls -lrt *$TWO_TASK*.mgr

-rw-r--r-- 1 testmgr dba 5900612 Sep 12 10:40 TEST_0826.mgr

2、執行下列的SQL，以找出log file

SELECT fp.logfile_name as "ICM_LOG_NAME"

FROM fnd_concurrent_processes fp, fnd_concurrent_queues fq

WHERE fp.concurrent_queue_id = fq.concurrent_queue_id

AND fp.queue_application_id = fq.application_id

AND fq.manager_type = '0'

AND fp.process_status_code = 'S';

3、在EBS內登入到Sysadmin Administor Responsibility

Go to ->Concurrent -> Manager -> Administer -Processes -> Click button Internal Manager Log.如下圖

找到log後，查到的問題是ORA-04030: out of process memory，是一支concurrent request造成的。

EBS：啟用Request的Debug Options

今天遇到一個任務，要開啟Request的Debug Options功能，經一番查詢之後，找到開啟的方式，致於如何使用，待下次再來測試。

啟用後，Debug Options按鈕為可點選狀態

System Profile名稱： Concurrent: Allow Debugging，設定完後需重新登入EBS才能生效

EBS。找出指定的TABLE在哪些Fomrs中有使用到

今天程式開發人員有一個需求，想找出一個客製的TABLE：WP_TIMES，有在哪一個EBS forms中使用

因為手動一個一個找實在太花費時間了，所以就寫了一個簡易版的比對shell script，在此記錄一下，未來應該還有機會用到。

我的想法是由特定的目錄，如：ap，自動抓取底下指定條件的檔案，再以比對字串的方式將檔案名稱output到螢幕上，其中 -n 是用來判斷變值是否為空值

#!/bin/bash
for f in ap/*.fmb
do
   a=`grep 'WP_TIMES' $f`
   if [ -n "$a" ]
   then
      echo $f
   fi
done

Oracle ERP : 刪除使用者的Folder

有一位使用者在設定Folder時，不小心設定錯誤，導致Form一直在轉圈圈，無法正常運作。

因為Form一直在圈圈，所以使用者無法自行刪除這個錯誤的Folder。

此時可以用管理者權限來刪除使用者的Folder，路徑：System Administrator -> Application -> Administer Folders

有三個選項可以找出Folder，找到之後在工具列上按下刪除鍵即可

啟用Windows 11內Edge的IE模式與企業模式網站清單

為了讓EBS 11i還可以再延續使用，所以需要測試Edge的IE Mode模式。

先參考這篇文章：https://blog.twtnn.com/2021/06/edgeie.html

Edge的版本是：98.0.1108.56

在網路上搜尋到的方式是直接在Edge的設定內指定，不過好像有預設30天的限制，群組原則內可以修改限制。

預設Edge會以IE 11來開啟IE Mode的網頁，但是EBS 11i需要設定相容性，用更低的IE版才能正常開啟，如下圖：

而且我們希望用企業模式網站清單的方式來統一管理需要用IE Mode開啟的網站，所以改用以下的方式。

先到微軟的網站上依Edge的版本來下載相應的群組原則

開啟群組原則gpedit.msc，並新增原則

原則新增完成後，在「系統管理範本」->「傳統系統管理範本(ADM)」->「Microsoft Edge」就可以找到兩個相關的設定

在清單的XML檔內，要指定使用的IE版本，指定在<compat-mode>，注意<open-in>不是指定版本，而是表示要用IE Mode來開啟。

<compat-mode>IE5</compat-mode>

<open-in>IE11</open-in>

</site>

如果指定如下，則以IE Mode開啟網站，預設是IE 11

<compat-mode>Default</compat-mode>

<open-in>IE11</open-in>

</site>

如果要把網站加入安全性清單內，可至控制台 -> 網路和網際網路 -> 網路和網際網路選項，在「安全性」的頁簽內加入

EBS 11i AP Tier CPU使用率偏高（Solaris系統）

今天在觀察Oracle ERP的效能時，發現AP Tier的CPU有偏高的現象，而且持續了好幾天。

因為之前發生時，曾用過兩種方案，一個是重開ERP就可以恢復正常；另一個是強制刪掉可能的zombie process

以下記錄我自己參考Document 1330392.1後的操作，非官方正式的SOP

我們AP Tier的作業系統是Solaris，首先執行下列的指令來觀察Process（依使用率來排序）

# prstat -avm

結果如下圖，有兩個f60webmx的CPU使用率偏高，f60webmx就是EBS的Forms

將上面兩個PID記錄下來，以下列的SQL來反查是哪一個Sessions

SQL> select * from v$session where process in ( <PID> );

再將上面的PID以下列的SQL來查詢相關資料

SQL> select * from FND_LOGIN_RESP_FORMS WHERE audsid in ( <PID)> );

如果FND_LOGIN_RESP_FORMS的end_time的值不是null，則表示該session已經結束並且可以手動刪除。

我是會再看v$session的status是否為inactive，如果是，也是可以手動刪除。

上述步驟查詢可能沒有相關的Session或 FND_LOGIN_RESP_FORMS WHERE audsid，則直接刪掉pid

把找到的session記錄SID、SERIAL#後，再以下列的SQL來強制kill session

SQL> alter system kill session '<SID>,<SERIAL#>';

接著在再刪掉作業系統的pid

# kill -9 <PID>

另外我會特別注意查詢到的v$session欄位ACTION是不是像FRM:<USER_NAME>:<RESPONSIBILITY_NAME>，

或是Concurrnet Request，如果是，通常都是使用者開啟的程式，刪掉就比較不用擔心；

如果不是，就要特別注意是否是Oracle的背景程式或特殊程式。

EBS更換guest帳號密碼（11i）

為了安全性，所以更改了一些EBS帳號的預設密碼，但是遇到guest帳號密碼卻無法更改

原本以為只是一個Guest帳號，於是把它停用，結果造成EBS無法登入，這下可糗了。

這表示guest帳號並不是單純的帳號，所以到網路上搜尋一下。

找到的一份文件提到System Administrator -> System profile中也有guest password的參數，當然也是無法修改

而且Oracle的這篇文件上有提到不能停用guest帳號：

Do not disable the GUEST user account.

Do not disable the SYSADMIN user account until you have created other accounts with similar privilege.

所以只好再找一下文件，看看是否有其他的方式可以更改，最後找到的步驟如下，先記錄下來，以備之後使用。

「注意密碼必須要大寫」

1、在Unix上以AP帳號登入，如applmgr

2、修改AutoConfig的context file的value，變數名稱是「s_guest_pass」

路徑：<INST_TOP>/appl/admin/<CONTEXT_NAME>.xml

3、重跑AP上的AutoConfig

4、檢查密碼是已更新，執行下列SQL，回傳值應該要是「Y」

SQL> select fnd_web_sec.validate_login(‘GUEST’,”) from dual;

5、以sysadmin登入EBS，選擇「CRM HTML Administration」 responsibility，並依下列路徑點選

Setup -> Settings -> System -> Properties -> Self Service User

6、Self Service User網頁開啟，再點選Properties -> Advanced -> JTF，並檢查參數guest_password的密碼是否正確

7、重啟AP

Oracle EBS 11i查詢使用的Port

因為要知道EBS 11i有使用到哪些Port，以便網路的設定，故記錄一下。

EBS 清除 FND_LOBS 過大的附件空間

測試的DB是9.2.0.7，而EBS則是11i，因為上傳檔案佔用太多空間，而且都只是使用一次就不再更新，
因此想縮小FND_LOBS的大小

找出 FND_LOBS 的欄位 FILE_DATA 的 Segment Name
select * from dba_lobs where table_name = 'FND_LOBS';

FND_LOBS 與 FILE_DATA 的大小並一樣，上傳的文件資料顯然是放在SYS_LOB0000066009C00004$$
select round(sum(bytes)/1024/1024) Mb from dba_segments where segment_name='FND_LOBS';
select round(sum(bytes)/1024/1024) Mb from dba_segments where segment_name='SYS_LOB0000066009C00004$$';

因為這次想要清除的是上傳的csv檔，所以先找出符合條件的資料來確認。
select * from fnd_lobs where program_name <> 'FND_HELP'
and (file_name like '%.csv' or file_name like '%.CSV' );

填上這些資料的過期日，在下一個步驟就可以只刪除過期的資料
update fnd_lobs set expiration_date = to_date('20060101','yyyyMMdd') where file_id in
( select file_id from fnd_lobs where program_name <> 'FND_HELP'
and (file_name like '%.csv' or file_name like '%.CSV' ));

接著以sysadmin登入到EBS，執行Request「Purge Obsolete Generic File Manager Data」，
參數的部份只要在「expired」選擇 YES

如找不到 Purge Obsolete Generic File Manager Data，依下列方式加入：
System Administrator -> Security -> Request

Request完成後，重新查詢 FND_LOBS ，發現資料已經刪除。
select * from fnd_lobs where program_name <> 'FND_HELP'
and (file_name like '%.csv' or file_name like '%.CSV' );

再次查詢FND_LOBS 與 FILE_DATA 的大小，發現SYS_LOB0000066009C00004$$空間並未清除。

接著執行下列SQL，讓FND_LOBS在原表空間內move。
alter table applsys.FND_LOBS move lob (FILE_DATA)
store as SYS_LOB0000066009C00004$$;

再重新查詢SYS_LOB0000066009C00004$$的大小，發現它的容量減少了。
搜尋到文件提到最後再將APPS_TS_MEDIA Tablespace内所有objects都移轉到新的Tablespace後再移回來就可以了。
但是我沒有將它移到新的Tablespace，我利用另一份文件提到的方式來做。

先觀察相依的FND_LOBS的物件，FND_LOBS_U1、FND_LOBS_CTX這兩個INDEX已經是INVALID，EBS也無法上傳檔案了

FND_LOBS_U1比較簡單，重建一下就好了。
ALTER INDEX APPLSYS.FND_LOBS_U1 REBUILD TABLESPACE APPS_TS_MEDIA ;

FND_LOBS_CTX就必須用aflobbld.sql來重建，以AP帳號（非ORACLE DB帳號）登入主機
$ sqlplus /nolog
SQL> connect apps/appspassword
SQL> @$FND_TOP/sql/aflobbld.sql applsys apps --這裡要輸入applsys、apps這兩個Schema Name

在資料章更新到11g之後，利用了下列的方式來縮減SYS_LOB0000066009C00004$$，就不用重建Index，但是系統的大小並沒有改變。
SQL> ALTER TABLE applsys.fnd_lobs MODIFY LOB (file_data) (SHRINK SPACE);

完成後，再次操作上傳檔案的作業就成功了。後續再持續觀察看看有無其他問題。

EBS 11i。Concurrent Manager狀態及Log查詢

有一台EBS 11i 的測試機，有時候會遇到Concurrent Manager掛掉，因為Concurrent Manager是Request的管理程序，所以掛掉後所有待執行的Request狀態都變成Pending。

到 System Administrator -> Concurrent -> Manager -> Administer
查看 Internal Manager 的 Actual 是否 >0 ，Internal Manager就是管理程序。

如果發生問題，則可以按上 Processes，再按下Internal Manager Log查看訊息

查詢Log後發現問題，加大空間就解決了

EBS。停用Form Personalize

開發程式時，因為有時候會遇到客製程式只能讓限定的使用者使用，而擁有相同Responsibility的其他使用者不能使用，此時可以利用Custom Personalize來達成。

開啟客製程式後，再開啟 Personalize

下面是我的 Personalize 設定，因為我指定了自己的帳號TEST001，
但是卻強制執行DO_KEY => EXIT_FORM
所以這支客製程式我就無法使用了，而且每次一開這支程式就會自動關掉。

此時只要先將 Personalize停用，就可以開啟這支客製程式，再修改Personalize

EBS。無法取消Request，error:Could not lock request

今天的RPM Remote Print Manager突然卡住，把Windows重開後恢復正常，但是EBS上的Request卻發生問題。

手動取消Request時出現下圖的錯誤：Could not lock request

無法取消就只能執行SQL來取消Request，因為該Request的Session已經完成，於是執行下列的SQL來修改狀態：
update fnd_concurrent_requests set phase_code='C',status_code='X' where request_id in (186153,186133);

等了三分多鐘還沒有完成，只updtae兩筆資料不應該會等這麼久，於是再開另一個Toad並執行下列檢查Lock的SQL：
select distinct vs.sid,vs.serial#, vs.username,vs.status,vs.osuser,vs.process,vs.machine,vs.terminal,vs.program,vs.sql_address,
vs.module, vs.logon_time,vs.blocking_session,vl.block as "Lock BLOCK",vq.sql_text
from v$session vs,v$lock vl ,v$sql vq
where vl.sid=vs.sid
and vq.sql_id=vs.sql_id
and vs.blocking_session in (select sid from v$lock where block>0)
union
select distinct vs.sid,vs.serial#,vs.username,vs.status,vs.osuser,
vs.process,vs.machine,vs.terminal,vs.program,vs.sql_address,vs.module,
vs.logon_time,vs.blocking_session,
vl.block as "Lock BLOCK",
vq.sql_text
from v$session vs,v$lock vl,v$sql vq
where vl.sid=vs.sid
and vq.sql_id=vs.sql_id
and vl.block>0
order by logon_time;

發現update的session被另一個session卡住，等待事件是SQL*Net message from client，猜測應該是當時RPM程式卡住造成沒有回應。

所以Request被卡住無法更新訊息，把Lock的Session kill掉之後，本來想由EBS來取消Request，結果出現下列的錯誤：

只好重新執行update Request的SQL，來更新狀態就成功了。
update fnd_concurrent_requests set phase_code='C',status_code='X' where request_id in (186153,186133);

後續補充：

因為系統是Solarix 10，所以後續有發現還有系統的process需要刪除，如下圖可以發現有兩個相關的process，一個是FNDLIBR（Concurrent的Processor），另一個是由FNDLIBR延伸出來有zut8zht語系轉換程式，並且可以知道使用者與Request ID，如下圖的110024.41412619。

接著在搜尋Request ID：41412619，可以發現還有lp的Solaris列印程式，所以要將這些process也一併刪掉

EBS。找出180天內新增Form的使用次數

找出180天內新增Form的使用次數，記錄一下SQL：

select ffv.form_id,
to_char(ffv.creation_date,'yyyy/mm/dd') "建檔日",
to_char(ffv.last_update_date,'yyyy/mm/dd') "最後修改日",
ffv.form_name,
ffv.user_form_name,
count(1) "次數"
from FND_LOGIN_RESP_FORMS flrf,
fnd_form_vl ffv
where flrf.form_id=ffv.form_id
and ( ffv.creation_date >= (sysdate -180) or FFV.LAST_UPDATE_DATE >= (sysdate-180))
group by ffv.form_id,ffv.creation_date,ffv.last_update_date ,ffv.form_name,ffv.user_form_name
order by count(1),form_name;

刪除EBS AP Tier上的記錄檔、暫存檔

EBS在運行期間，會增加許多的記錄檔、暫存檔等，之前一直沒注意，所以產生超過50G的無用檔案。

為了怕之後忘記，所以記錄一下。
主要是清除下列路徑的檔案：
$COMMON_TOP/admin/log/SID_HOST/*
$COMMON_TOP/admin/out/SID_HOST/*
$APPL_TOP/admin/SID/log
$APPL_TOP/admin/SID/out
/usr/tmp
$IAS_ORACLE_HOME/Apache/Apache/logs
$IAS_ORACLE_HOME/Apache/Jserv/logs
$OA_HTML/cabo/images/cache/en （依據ERP使用的語言）

Oracle EBS。無法追蹤Forms的使用記錄（二）

在 PRE-FORM 修改完FND_STANDARD.FORM_INFO的參數值之後，依舊無法讓EBS記錄到 Forms 的使用。

這次的修改也注意到了 Form Name 與 FND_STANDARD.FORM_INFO 中一致，以免發生錯誤，請參考：Oracle EBS。無法追蹤Form的使用記錄

Oracle EBS。無法追蹤Form的使用記錄

在開發Oracle EBS 的 Form 時，已在 PRE-FORM 中設定好 FND_STANDARD.FORM_INFO 的參數，但是實際測試之後發現還是無法追蹤 Form 的使用記錄。

反覆測試之後發現是Forms的名稱與程式的參數不一致，將兩邊改為一樣之後，就解決了。

EBS 11i複製資料夾apputil到新DB Tier的方法

如果是直接安裝新的Oracle DB到EBS的環境時，會缺少一些與EBS相關的檔案，所以在網路上找了一下，發現有下列的方法。
$ cd $AD_TOP/bin

產生appsutil的zip檔
$ perl admkappsutil.pl

產生的appsutil.zip預設會放在$APPL_TOP/admin/out的資料夾內

將appsutil.zip以sftp或ftp等方式複製到目的資料庫（新的Oracle DB）的$ORACLE_HOM內

將zip檔解壓
$ cd $ORACLE_HOME
$ unzip -o appsutil.zip

執行Script以產生Context File
$ cd $ORACLE_HOME
$ . <SID>_<HOST>.env
$ cd $ORACLE_HOME/appsutil/bin
$ perl adbldxml.pl tier=db appsuser=<APPS_USER> appspasswd=<APPS_PASSWORD>

重新執行Configure Script
$ adconfig.sh contextfile=<CONTEXT_FILE> appspass=<APPS_PASSWORD>

完成上面的步驟後，就會有相關的Script及資料夾

參考文件：377495.1

EBS FNDCPASS指令的使用

EBS AP端有一個作業系統的指令（FNDCPASS）可以協助我們修改EBS上各類型帳號的密碼。

語法：
FNDCPASS <APPS username>/<APPS password> 0 Y <SYSTEM username>/<SYSTEM password> <token> <username> <new_password>

1、更改APPS與APPLSYS Schema的密碼：
APPS的密碼不宜用DB的Alter user指令來更變密碼，應該以FNDCPASS來修改它。
修改APPLSYS的密碼會一併修改APPS，token為SYSTEM，所以指令如下：
$ FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS 12345

2、更改非APPS與APPLSYS的其他AP Schema的密碼：
token為SYSTEM，例如：
$ FNDCPASS apps/apps 0 Y system/manager ORACLE INV 12345

3、更改所有AP Schema的密碼：
指令如下（token為ALLORACLE）：
$ FNDCPASS apps/apps 0 Y system/manager ALLORACLE 12345

4、更改AP User的密碼，例如：
$ FNDCPASS apps/apps 0 Y system/manager USER VISION 12345

在改變任一個Schema的密碼時，最好將AP Server給關閉。

另外，為避免過程中出現無法預期的錯誤，導致AP無法開啟，請先備份Tables：FND_USER、FND_ORACLE_USERID

如有問題時，可以將這兩個Tables還原回去。

訂閱：文章 (Atom)

平凡的幸福