方法1, EBS trace工具
参考: 我的另一篇日志《EBS trace生成数据库跟踪文件》
此方法本质是使用的是oracle数据库的trace功能, 通过tkprof工具可以得到当前EBS会话中执行的sql, sql执行计划以及其他的统计信息等.
[更新9/12/2012] tkprof生成的结果文件通常更适合于性能的诊断, 而对于bug的诊断往往没有太大的帮助. 这时候需要使用原始的.trc文件, 该文件会具体到哪一个sql语句执行出错以及sql的绑定值, 并且会记录一些plsql的调用.
方法2, EBS AFLOG日志框架
EBS系统本身包含了AFLOG日志框架, 用于记录系统运行时各个级别的日志信息. 通过profile设置的方式, 用户可以决定是否启用该日志功能以及日志级别, 设置如下:
Step 1: 应用开发员职责, Profile ==> System
Step 2: 用户level设置FND: Debug Log Enabled为Yes, 设置FND: Debug Log Level为Statement. 关于日志级别的说明:
1, Statement 包含EBS执行的所有动作, 最详细级别.
2, Procedure 记录数据库存储过程的执行动作.
3, Event 记录EBS系统事件.
4, Exception 记录Exception.
5, Error 记录Error.
6, Unexpected 记录严重错误信息.
日志级别越高记录的日志信息越少, 但对系统性能的影响也越小. 使用低日志级别尤其是statement会对系统性能产生严重的影响.
[更新9/12/2012] 另外可以设置FND: Debug Log Module, 以限制记录debug信息的模块. %表示所有模块, 多个模块使用逗号分开比如"GME%, PO%".
Step 3: 退出当前session重新登录, 此时就可以在apps/fnd_log_messages表中找到相应的日志记录了.eg: 查询procedure级别的日志信息
select * from fnd_log_messages where jvm_id is null and log_level=2[更新9/12/2012] 另外有些模块的日志信息是记录在文本文件里面的,比如对于OPM相关模块的日志就记录在环境上的$APPLPTMP目录下面.比方说, 以某个用户user1在GME中完成一个batch就会在该目录下面生成一个名称为user1CompleteBatch的日志文件.
方法3: FRD(Forms Runtime Diagnostics)诊断信息
设置当前用户的profile "ICX: Forms Laucher", 在URL后面增加参数"?record=collect", 重新登录之后可以在浏览器的URL栏看到相应的变化. 日志文件可以登录EBS服务器在$FORMS_TRACE_DIR目录下面找到.
另外还有一些EBS模块有自己专有的诊断方法, 比如INV, PO等模块. 个人认为出现这种情况的原因是EBS本身就是一个大杂烩, 把很多来自不同厂商的产品糅合在一起, 从而导致了这种不一致性.
--EOF--
没有评论:
发表评论