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