今天又遇到了一个 Oracle Bug . 数据库版本为10gR2, 详细的版本号为 10.2.0.1.0 , Oracle 之外的操作系统用户调用命令会报告:
sqlplus: error while loading shared libraries: libsqlplus.so:
cannot open shared object file: No such file or directory
检查 $ORACLE_HOME / $LD_LIBRARY_PATH 等可能引发问题的环境变量，都是正常的．莫非又是 Bug ? 果然，Bug 4516865!．
错误日志如下：
IMP-00020: long column too large for column buffer size (7)
Oracle手册中的错误信息参考大致是这样的:
IMP-00020long column too large for column buffer size num(x)
Cause: The column buffer is too small. This usually occurs when importing LONG data.
Action: Increase the insert buffer size 10,000 bytes at a time (for example)
up to 66,000 or greater. Use this step-by-step approach because a buffer size
that is too large may cause a similar problem.
测试了几次 buffer size 调整还是报告同样的错误, 怀疑是 export dmp 文件坏掉了. 重新 export , imp 还是有问题. 逼得我没有办法, 不得不跑到 Metalink 上搜索(访问 Metalink 速度那叫一个慢啊! 好半天，总算看到结果了, 居然我是遇到了 Bug 2417643!
最近观察到数据库服务器 $BDUMP 目录下频繁出现 Trace 文件,内容大致为:
Warning: lio_listio returned EAGAIN Performance degradation may be seen. Warning: lio_listio returned EAGAIN Performance degradation may be seen. Warning: lio_listio returned EAGAIN
搜索了一下, IBM 给的官方解释为:
If the maxreqs value is too low, then the following Oracle warning message might be returned:
Warning: lio_listio returned EAGAIN.
This warning message indicates a need to increase the maxreqs value. When performing file system I/O, a maxservers value that is too low can also indirectly cause this warning message
同事中的几位大侠翻译了《Spring in Action》, 今天公司组织买了一些，”抢”到了一本。书是刚刚上市不久的–还热乎的呢 :)
有的同事看我也看 Java 方面的书，可能觉得比较好笑。其实，作为一个 DBA，如果要有效地与开发人员的沟通, 不熟悉系统中所用的框架, 就会吃力许多, 刚开始到目前的团队中工作的时候也偶尔会闹笑话. 自己想了解一些 J2EE 框架基本概念的念头也有好久了，正好趁着有资料，学习学习。
今天匆忙读了第四章”征服数据库”, 有几点给我留下了比较深的印象.
1) 数据访问异常的划分很清晰; 应用排错的时候很容易定位到具体问题;
2) 通过一定的设置, 任何一个 SQL 都能够输出到 Log 里, 对于 DBA 的优化调试非常有帮助;
3) 对 DAO 层数据库访问很容易隔离; 一部分程序员可以不用太关心数据库层, 而把这一部分的诸如效率、稳定性交给 DBA 处理; 也的确如书中所说简化了应用系统的复杂度并能提高开发效率;
4) 可重用的 DAO. 对于 DBA 来说, 应该注意因为 DAO 重用有的时候可能会带来一些多余的 SQL 解析. 在 Tuning 的时候需要注意。
我对 Java 一窍不通, 有理解不对的地方请读者指正!