针对使用DATABASE,RAC, EM, 以及Perl Script 中的出现的各类错误谈谈自己一些具体的体会.
1. 最最重要的: 日志 (LOG)
说的玄乎一些，你可以将日志看成是一个罪犯在犯罪现场留下的蛛丝马迹.有了这些蛛丝马迹，公安人员才能开展下一步的调查取证工作...程序中出现的错误或者是Exception, 只要有日志，就能进行下一步的分析和诊断。Windows系统本身不是还有dump文件吗,微软的内核开发人员肯定是基于这些dump文件来诊断系统内核中的问题。 Oracle的各种产品也不例外，从OUI 到 Database, CRS, RAC, EM, IAS 甚至Oracle Applications, 都毫无例外的提供日志作为诊断程序bug的重要辅助工具。
大部分日志文件都是随着程序的运行而产生的，但是有些日志需要用户自行指定,或者是加上一些自定义的参数，才能被记录。例如: 我们一般使用dbca来创建/删除数据库或者更改数据库的配置，如果在运行过程中出错了, 得到的有价值的日志信息很少，这种情况我们就可以加上trace,让dbca dump 更多的trace:
runInstaller -J-DTRACING.ENABLED=true -J-DTRACING.LEVEL=2
同理, 这些JAVA BASE 的工具: NETCA, VIPCA, SRVCTL都可以相同的方式激活tracing.
由日志说开去: 养成良好的监控习惯,防患于未然
数据库实例运行时的日志alert.log 大家肯定都看过, 不过大家有没有写过一些定期运行的监控脚本来定期purge 这个文件中一些不需要的或者说是垃圾信息呢?
有些时候，由于数据库本身的bug, 或者是自己配置的问题(例如 最常见的flash recovery 区域设置的太小，而此时的归档文件已经满了而无法写入目的区域;或者说是rman的备份策略有问题，没有定期删除过期的日志文件),都会导致这个文件急剧膨胀. 我曾见到过一个4G 大小的alert.log, 里面估计有上百万行，但是大部分行的信息其实都是没太大意义，无非是告诉你赶快清理不需要的文件,腾出点地方 让arc 进程继续工作 ... 因此，非常有必要写一个脚本来监控数据库实例的trace 文件,定期清理不需要的文件，备份重要的文件.(用Shell 或者Perl,JAVA, C++ 都能实现)
还有，如果启用了OS或者DB级别的审计功能，也会产生大量的,细小的audit文件,这些文件也需要进行定期的监控.
第三, 我们为了诊断某个ORA 错误或者是想发现 某个复杂sql的执行计划, 成本代价，就来激活相应的event trace , 可是有时都是开了不关, 这样也会产生大量的trace 文件.
2. 文档是利器，搜索引擎是佐料
不光是Oracle, 我相信大多数正规的软件厂商都会将文档看的很重要。用中国人的观点来看，文档就如同一件衣服的面料，好的文档就好比上等的面料，让人爱不释手.但是考虑到资源的问题，很多软件厂商的文档都没有本地化的文档。微软的MSDN就是一个典型的例子: 前两年开始微软开始重视这个问题，投入大量的资金和人力来实施本地化的翻译，因此我感觉现在微软的MSDN中文网站相比VB6,VC6时代已经很不错了。
Oracle的技术网OTN在这方面要差一点，但是也比以前提高了不少。官方文档的本地化方面则欠缺很多，这和公司的市场定位有密不可分的关系。谁让中国市场的份额少，再加上很多中小公司用的都是D版 ...
说了一段题外话，让我们来评估一下Oracle 官方文档的质量。我感觉所有的Oracle 官方文档中质量最高的应该是OCP的几十本自学材料(Student Guide), 只要静下心来细细地读读英文文档，绝对比看中文版的强。接下来就是 "Concept", 我曾经记得Tom曾经推荐过自学Oracle的过程中重点需要阅读的文档之一就是它，因为只有你对基本的构架清楚了，实验/自学/开发/安装... 才能继续往下进行. 我推荐的三个手头必备的文档是:
"Error Message"
"SQL Reference"
" Admin Guide".
第一个和第三个主要是针对DBA的，第二个则是任何用户都需要的。大部分文档中都有附录，例如RAC 的管理文档的附录就详细列出了怎样使用srvctl, 而这个工具几乎是所有使用 10G RAC的人都需要掌握的。
不可否认，有些文档的质量差一点, 我个人感觉上面推荐的"SQL Reference" 其实质量很一般,只不过经常需要使用, 要求就不用那么严格了。
再说网络,搜索引擎已经成为大多数人每天都要使用的的工具了，在你面对一些错误许久没有良策时, 用用网络,往往会事半功倍。我个人主要用Google和Baidu. 感觉百度对于常见的oracle 错误整理的非常好, 而Google中搜索出的信息往往更有价值，往往是一击中地...
2
