ERP常見問題分析

 ERP常見問題分析

1. IE登錄系統頁面時非常緩慢或失敗
2. TSM備份應用文件系統后，無法啟動ERP應用服務
3. 數據庫無法正常訪問
4. 並發管理器無法正常啟動
5. 並發管理器“堵塞”，大批請求待定
6. ERP系統某部分功能無法正常使用
7. 用戶無法收到審批郵件或者預警郵件
8. 某用戶登錄后看不到任何職責
9. 在form中無法正常導出數據。
10. LTO2備份出錯，找不到設備
11. 生產環境請求運行報錯，日志提示無法創建tmp文件
12. /tmp空間無法釋放問題
13. 通用上傳工具頁面亂碼問題
14. 登陸discoverer plus,提示：invalid username/password 顯示驗證錯誤,
15. ORA-01631:table xxx.xx reached max #extents 
16. ORA-01555: snapshot too old
17. oracle ebs 查看請求輸出或者日志報錯：無法連接上misdb1的TNS

1、IE登錄系統頁面時非常緩慢或失敗

如果是個別用戶，則要檢查客戶端

網絡是否正常

用戶是否已經失效，或者口令錯誤

IE版本參考文檔“Windows 7 + Internet Explorer 8 下使用 Oracle EBS 11i (非Oracle官方方式)”進行設置

jinit安裝問題

如果是共性的問題，則做下面檢查

檢查Apache所在服務器空間如果/app/xxprd滿，Apache無法寫日志會引起服務異常；解決空間問題后，重啟服務；

Apache日志是否過大（比如超出3G左右）停止Apache服務，清理日志空間后，重啟Apache；登錄速度正常；    

檢查數據庫訪問是否正常；解決數據庫問題后，重啟服務；         

檢查Apache日志文件，分析異常警告；

2、TSM備份應用文件系統后，無法啟動ERP應用服務

檢查/app/xxprd文件系統，訪問是否正常到 /app/xxprd下，新建一個文件(touch filename）檢查是否可正常讀寫文件，如果失敗，則重新mount文件系統：

如果仍有異常，查看errpt是否有報錯信息，聯系中央組或IBM支持；文件系統正常后，啟用應用服務即可；

其它異常，找中央組支持；

3、數據庫無法正常訪問

排除網絡問題

檢查數據庫監聽服務是否正常

檢查數據庫服務器空間： 如果ORACLE HOME所在文件系統/ora/xxprd滿了，無法寫日志，數據庫掛起； 如果歸檔日志所在卷/arch/xxprd滿了，無法歸檔，數據庫掛起； 如果/data/xxprd滿了，數據庫無法寫數據文件；

檢查數據庫相關屬主是否被修改過；

檢查數據庫日志文件，分析異常警告

4、並發管理器無法正常啟動

檢查並發管理器所在應用服務器的空間   如果/pub/xxx文件系統滿，並發管理器會由於無法寫日志文件而停止服務；

檢查apps密碼是否正確，以及從應用服務器是否可正常訪問數據庫

重啟前檢查是否還有FNDLIBR進程未退出  停止並發管理器服務后，檢查全部FNDLIBR進程是否都退出，如果長時間不能退出， kill -9 FNDLIBR進程，再啟並發服務器服務；

檢查並發管理器日志，根據錯誤提示處理，或遞交中央組處理

5、並發管理器“堵塞”，大批請求待定 

5.1 檢查並發管理器狀態是否正常
5.2 檢查沖突管理器中是否大量不兼容的請求排隊比如大批“過賬”之類的不兼容請求集中遞交，告知操作用戶，並且取消后面等待的不兼容請求，等前面的完成后，再遞交下一個；
5.3 檢查是否有大批“暫掛”請求可以跟相關業務部門操作人員了解，盡量不要手工設置請求為暫掛狀態，或者以其它方式設置成此狀態，以免忘記再設置請求繼續運行，影響系統正常處理請求； 可以設置“取消”，再重新遞交；
5.4 如果發生頻繁，考慮為部分常用且易集中遞交的不兼容的請求增加專用的並發管理器, 需要提請中央組分析按具體情況處理

6. ERP系統某部分功能無法正常使用

6.1 某生產環境PO部分功能突然無法正常使用，檢查數據庫中無效對象個數，大約有1萬多個。
     打補丁后沒有重新編譯無效對象，重新編譯后，PO部分功能使用正常

 注：盡量使用adadmin工具編譯無效對象

7、用戶無法收到審批郵件或者預警郵件

檢查用戶郵件地址是否有效地址；
查看wf_notifications表里面的郵件發送狀態
檢查用戶首選項是否配置正確
查看工作流計划請求是否定時運行；
檢查工作流組件服務是否正常
檢查省OA系統或者郵件服務器上此用戶郵件配置是否正常；
如仍不能解決，遞交中央DBA組；

8、某用戶登錄后看不到任何職責

用系統管理員登錄，安全性-》用戶-》查詢該用戶所分配的職責是否過期

系統管理員運行“工作流目錄服務用戶/職責驗證”請求后，重新登錄查看是否解決

9、在form中無法正常導出數據。

在form中無法正常導出數據提示HTTP Error404錯誤

檢查首選項設置，將客戶機字符編碼更改為： Chinese Simplified(Windows)  即可；

檢查表空間大小，表空間APPS_TS_MEDIA不足也會引起導出失敗；

10、LTO2備份出錯，找不到設備

主機磁帶設備更換（rmt0 -> rmt1），而備份腳本里面一直使用的是rmt0

更改主機磁帶設備為rmt0，或者修改備份腳本里設備名稱為/dev/rmt1

11、生產環境請求運行報錯，日志提示無法創建tmp文件

處理：/tmp滿了，清理即可；

12、/tmp空間無法釋放問題

在清理/tmp下的大批臨時文件后，空間仍沒釋放，在急速增長；

由於在生成臨時文件的進程沒有結束時，刪除了臨時文件造成無法釋放；

重啟應用后，空間回收正常；

13、通用上傳工具頁面亂碼問題

通常是緩存滿了還沒及時刷新，可手工清理頁面緩存：

停止Apache服務，清理 $OAD_TOP/_pages/_oa__html下對應的緩存文件，重啟Apache服務

或者：登錄職責：功能管理員-->核心服務-->高速緩存結構-->全局配置-->清除所有高速緩存

14、登陸discoverer plus,提示：invalid username/password 顯示驗證錯誤

症狀描述：

     登錄discoverer plus,提示：invalid username/password 顯示驗證錯誤

     問題處理：

   檢查discoverer日志，在locator.log里提示：

     Locator: No IP address given.  Bind directly to server name =   misapp1.xx.cmcc_11500OracleDiscovererSession4

    重啟discoverer,並且重新注冊registerall,再登陸成功；

     （applprd:$ORACLE_HOME/discwb4/util/registerall.sh）

15、ORA-01631:table xxx.xx reached max #extents

從數據字典dba_segments中查找extents個數達到或接近max_extents值的對象select  owner, segment_type,extents,max_extentsfrom dba_segments where max_extents – extents < 10

增加table/index的maxextents個數

     a)TABLE:

     語法：ALTER TABLE owner.table_name STORAGE(MAXEXTENTS n)

     例如：

     ALTER TABLE pa.QPATASKCHECK storage (MAXEXTENTS 200);

     b)INDEX

     語法：ALTER INDEX owner.index_name STORAGE(MAXEXTENTS n)

     例如：

     ALTER INDEX GL.GL_BALANCES_N4 storage (MAXEXTENTS 200);

16、ORA-01555: snapshot too old

ORA-01555: snapshot too old: rollback segment number 9 with name “_SYSSMU9$” too small

     如果只是偶爾出現一次，並且引發警告的SQL是臨時性遞交的，則可以忽略，在系統非繁忙時間再次遞交；

     如果此警告頻繁出現，則需要調整UNDO配置；

 

1、觀察UNDO的狀態下面的SQL可以觀察自數據庫啟動以后的UNDO狀態

select inst_id, to_char(begin_time,'MM/DD/YYYY HH24:MI') begin_time, UNXPSTEALCNT, EXPSTEALCNT , SSOLDERRCNT, NOSPACEERRCNT, MAXQUERYLEN

       from gv$undostat

     where begin_time between to_date('08/28/2006 10:20:00','MM/DD/YYYY HH24:MI:SS')

                       and to_date('08/28/2006 11:00:00','MM/DD/YYYY HH24:MI:SS')

     order by inst_id, begin_time; --比如查詢2006年6月28日10點20到11點之間的UNDO狀態

2、   情況一: undo_retention的值設置太短   

     在initSID.ora中,undo_retention的值為7200秒。 所以當某個查詢運行大於這個時間，部分查詢需要的數據在UNDO空間里已經期滿，空間被重新使用了，這時候系統會報告ORA-1555錯誤。
     解決這種情況，需要增加undo_retention，高於最長的“Query Duration”

     情況二、undo tablespace、undo表空間不足

由於undo tablespace不足，無法滿足在undo_retention 所定的時間段內，保證未到期的數據不被覆蓋，所以就會釋放一些還沒達到undo_retention時間的extents空間，叫”stolen”. 解決這種情況，需要擴展UNDO tablespace的大小；

17、oracle ebs 查看請求輸出或者日志報錯：無法連接上misdb1的TNS

　　１、檢查服務器上的監聽進程是否存在。監聽進程：ps -ef|grep tns

         2、應該是存在兩個用戶的監聽進程 第一：oraprd  第二：xxprd

         3、監聽進程不存在的話，進入路徑啟動監聽，若是oraprd則協調數據庫組處理監聽異常的問題。

        浙江移動的路徑是/app/zjprd/zjprdcomn/admin/scripts/ZJPRD_misapp1($OAD_TOP/admin)   ./adalnctl.sh  start