防患于未然 给Oracle数据库打补丁

核心提示： 5. 检查操作结果并记录备案执行一个操作，操作是否成功，防患于未然 给Oracle数据库打补丁(6)，一定要进行检查，不能简单认为没有出错信息就是成功，而这一Bug可以通过设置事件（event）关闭FIRST ROW优化而避免，最后的结论是这一BUG不会对本系统有影响，要知道验证的方法，除

5. 检查操作结果并记录备案

执行一个操作，操作是否成功，一定要进行检查，不能简单认为没有出错信息就是成功。要知道验证的方法。除去极个别极费时间的验证（分区备份的内容是否可以成功恢复系统，必须恢复分区，启动数据库，测试应用系统后才能确认），其余操作都应进行验证。所有屏幕输出信息和日志文件都应保留，作为安装报告的附件提交给上级或客户。

在屏幕输出或日志文件中出现异常/错误信息时，应即时分析，决定马上采取的措施。出现严重错误时，可能需要重新执行某一SQL程序，或者重新安装PSR.所以在制订实施计划时应在时间上留出异常情况处理的时间。

下面给出一个在Linux平台上安装10.1的PSR的实例，给从未安装PSR的读者有一个感性认识。

操作系统是RHEL AS4.0 Update3，Oracle的当前版本是10.1.2.在metalink中检索，找到10.1版的最新PSR10.1.0.5.下载压缩文件。在压缩文件中找到Patch Set Notes，该文档的完成日期是2006年1月。而按照文档内的提示在metalink中检索得到的此文档的最新版本完成日期是2006年4月。使用文件比较工具进行比较，两个版本没有实质性差别，只有语句措词的修改，但是养成总是检索最新文档的习惯有益无害。

根据Patch Set Notes中的说明，有一些特殊系统构成需要额外的步骤，本例中由于全部没有涉及到，所以可以按标准步骤执行。

另外，检查“Known issues and alerts affecting 10.1.0.5”文档后，发现10.1.0.5引入的影响最大的一个Bug是执行SELECT MAX（）在某些特定条件下结果不正确。而这一Bug可以通过设置事件（event）关闭FIRST ROW优化而避免。最后的结论是这一BUG不会对本系统有影响，可以安装PSR10.1.0.5。