今天我终于自己遇到了这个问题, PO form 打不开了, 看了下 trace 发现 SQL*Net message from client 等待时间太长. 但是这不可能是网络问题, 这个环境是在我电脑的虚拟机里面跑的, 网速很快, 而且其他 Form 都能正常很快打开. 真是崩溃; 我试了一下 Receipts form, 然后在 $PO_TOP/forms/US 下面把 RCVRCERC.fmx 文件删掉, 再打开 Receipts form 的时候报错, 说找不到文件; 然后我把 POXPOEPO.fmx 删掉, 打开 PO form 的时候报同样的问题, 说 form 找不到. 于是我 arcs out 了对应版本的 POXPOEPO.fmb 文件, 重新编译到 $PO_TOP/forms/US 目录下面, 再打开 PO form 就OK 了; 所以这个问题看似是网络问题, 实际上不是. 如果是某个 form 打不开, 重新编译就可以了, 因为从界面上是去对应目录下找对应的 fmx 文件的, 路径都正确. 如果打不开, 明显就是 fmx 本身的问题了.
数据库的性能问题, 有时是因为SQL 性能不好, 但有时候所有的SQL 都很快, 却浪费了很多时间在网络等待上面. 比如, 请求一个页面花了5 分钟. 这个问题可以在SQL trace 里面看出来. 收集10046 事件的trace 文件, 转换成tkprof 格式, 在文件的最后一段有总结:
- Elapsed times include waiting on following events:
- Event waited on Times Max. Wait Total Waited
- ---------------------------------------- Waited ---------- ------------
- SQL*Net message to client 727 0.00 0.00
- SQL*Net message from client 727 120.00 515.87
可以看出来在 SQL*Net message from client 等待了很久时间.
这个问题看起来似乎是网络问题, 但可以通过配置数据库解决. 解决方法:
1. 增加 SDU size, 这个要改配置文件, 在 TNSNAMES.ora 文件中一个参数
- TEST =
- (DESCRIPTION =
- (SDU=8192)
- (TDU=8192) <- 8.0 TDU position
- (ADDRESS =(PROTOCOL = TCP)(HOST = bill.johndoe.com)(PORT = 1521))
- (CONNECT_DATA = (SID = V920)))
在 LISTENER.ora 也增加一个参数
- SID_LIST_LISTENER =
- (SID_LIST =
- (SID_DESC =
- (SDU = 8192) <- Setting SDU to 8192 for this SID
- (TDU = 8192) <- 8.0 TDU position
- (SID_NAME = V920)
- (ORACLE_HOME = /oracle/product/9.2.0)))
2. 增加 Arraysize, 直接在 sql*plus 里面 set arraysize 1000
配置完这些参数, 应该可以改善上面等待时间太长的问题.