厂商提供给用户的软件补丁的形式多为编译后的库函数，所以安装软件补丁实际上就是把这些库函数拷贝到相应目录，并在需要时进行联接操作。软件公司一般在一段时间后会把针对某一版本的所有补丁进行整理：合并融合，解决冲突，进行整体测试，并使文件拷贝和联接操作自动执行，得到一个软件补丁“包 ”。不同的公司使用不同的名称，现在一般计算机用户都熟悉的Windows Service Pack就是这样的补丁包。Oracle公司给出的补丁包的名称是Patch Set，安装Patch Set后的版本称Patch Set Release（PSR）。

　　Oracle公司对处于标准技术支持的产品不定期地提供PSR，例如在完成本文时，版本10.2的最新PSR是10.2.0.2；版本10.1的最新PSR是10.1.0.5；版本9.2的最新（也极可能是最终）PSR是9.2.0.8.

　　在安装最新PSR后新发现的Bug，其相应补丁当然会收录到下一个PSR中。PSR是累积型的，即下一个PSR中会包括当前PSR中所有补丁和新发现Bug的补丁。同时存在几个PSR时，只需安装最新版本一次就可以了。但是由于PSR的发行有一定间隔，如果这些Bug对用户有比较大的影响，那么Oracle公司也会向用户公开和提供这些补丁，这些补丁被称为个别补丁（Interim Patch，one-off patch 或 Patch Set Exception）。而对于最终补丁发行版而言，由于不再有下一个PSR，所以当发现影响系统的新Bug时，个别补丁成为惟一选择。

　　此外，Oracle公司还定期发布安全补丁，称之为CPU（Critical Patch updates）。安全补丁用来修复软件的易受攻击性（vulnerability）或通常说的安全漏洞。这类问题本来不属于软件错误，在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码，绕过数据库系统的安全管理机制，达到非授权存取的目的。
　　
　　另外还存在一类补丁：诊断用补丁（diagnostic patch）。顾名思义，这类补丁不是用来解决问题的，而是用来寻找问题的原因的。这类补丁只在Oracle技术支持部门要求安装时，才需要安装。在得到需要的诊断信息后，应立即卸载这一补丁。

　　利弊及时机选择

　　负责管理支撑大型应用系统的数据库的DBA会容易理解安装软件补丁的代价。安装PSR需要停止数据库服务，关闭数据库，对于许多应用系统安排这样的停机时间本身就是一件比较困难的事情。事实上，更为严重的是由于安装PSR可能“引入”新的Bug，反而影响应用系统的正常运行。软件补丁本来是修正Bug，怎么会带来新的Bug？虽然有些让人匪夷所思，但很不幸这是现实存在的。

　　对于每一个PSR，其中都包括了少则几百多则上千个严重Bug的修正。即便是如此，在PSR发布后，很快就又会在安装PSR后的数据库中发现一些新问题。其中一部分Bug是以前就一直存在的只是以前没有发现，而现在偶尔被发现，或者是由于PSR修正了某一错误从而将其“激活”或容易发现。但是确实有一些Bug是由这一PSR造成的，Oracle技术支持部门称其为倒退（Regression）。对于每一PSR，在metalink中有两个重要的与之有关的文档，一个是“List of fixes added in XXXX”，是这一PSR修复的Bug的清单，是一本“功德簿”；另一个是“Known issues and alerts affecting XXXX”，是安装PSR后发现的问题，可以称其为“悔过簿”。由于大型软件的复杂性，Bug几乎是不可避免的。重要的是能够及时提供信息，DBA可以结合自己系统的情况做出正确的判断。读者不必因为知道还存在着Bug，就对Oracle数据库产品失去信心。PSR修复的上千个Bug中绝大多数是在一些很少见的环境中，或者是若干个组件的复杂组合使用的情形中发生的。

　　如果系统在运行中出现过某种问题，由Oracle技术支持部门或第三方的专家确认原因是PSR中的某一Bug，这样就必须尽早安装；如果系统一直运行正常，并且在PSR已发现的问题中涉及的组件或功能（如Logical Standby， JVM，RAC等）在系统中并不使用，此时可以选择安装也可以选择不安装。

　　另一个需要考虑的因素是安装补丁的时机。上述这些考虑的一个重要前提是系统已经投入运行，担心“倒退”的Bug影响系统。如果系统还处在开发和测试阶段，不需要有任何犹豫，安装最新的PSR，并在此基础上测试应用系统是否工作正常。如果发现异常，要及时请Oracle技术支持部门确认是否新Bug，如果是请其提供个别补丁。目的就是在一个尽可能完善稳定的数据库平台上测试应用系统。我们可以把这种安装补丁的策略概括为“补丁补新不补旧”。

　　以上都是针对PSR的安装，对于个别补丁，由于补丁修复的Bug单一，容易判断是否需要安装。需要注意的是，如果在当前PSR之上安装了若干个个别补丁，那么在下一个PSR发布后，在安装下一个PSR之前，需要卸载所有个别补丁。为便于管理，现在Oracle技术支持部门要求必须使用工具opatch安装管理个别工具，而尽量避免手动拷贝文件等操作。

　　最后是安全补丁安装的判断。虽然安全漏洞这个词看上去让人觉得非常严重，但是还要冷静综合分析这些漏洞在系统中的危害程度。事实上，不安装安全补丁的危险性可能远远小于始终不渝地使用scott/tiger这样人人都知道的用户名和口令的“标准缺省”做法。

　　安装PSR

　　使用oui工具安装PSR时只需要用鼠标做几个选择就可以进入自动执行的阶段，操作过程本身非常简单。但是如果要求必须一次安装成功；要求必须在凌晨2点到4点这个有限的停机时间段完成操作；要求安装过程不出差错，以后出现问题时能够完全排除此次操作失误的可能性，那么就需要在启动oui之前做一些准备工作。

　　1.收集信息

有关PSR的信息中，一个最重要的文档就是软件补丁说明，这个文件相当于技术手册中的安装指南和发行说明。文件本身包含在下载的软件补丁文件之中，文件名是patchnote.htm或README.html.需要注意的一个问题是在软件补丁文件之中找到的这一Patch Set Notes可能不是最新版，可以根据文件内的提示信息在metalink中检索最新版。

　　另外两个重要文件就是前面已经提及的“功德簿”和“悔过簿”，相对于“功德簿”更应该仔细阅读“悔过簿”中的每一项内容。另外，在Patch Set Notes的已知问题（Known Issues）一节内列出了安装PSR后出现的一些问题。

　　除去这三个主要文件外，还应在metalink中检索，寻找是否还有其他涉及这一PSR的技术文章，寻找其他用户在安装这一PSR时或安装后遇到问题时所发的救助的帖子，前车之鉴更应重视。

　　2.做出判断

　　在认真阅读收集到的文章之后，根据自己系统的实际情况，做出是立即安装PSR，或是等待下一PSR的决定。如果是暂缓安装，则要记录原因，以便以后跟踪Bug的修复进程。

　　3.制订实施计划

　　在决定安装PSR后，需要制订一个实施计划。在计划中不仅要包括正常的操作步骤，更要考虑在出现意外时的应急处理（如果安装PSR失败，则在正常应用开始时间之前，要恢复系统到安装之前的状态）。如果可能，在对正式系统开始实施之前，应在测试系统中进行演练和应用处理的测试，保证在安装PSR后不会影响应用系统的运行。

　　安装PSR的计划大致有以下几个部分：停止数据库服务关闭数据库；备份DBMS软件和数据库以备恢复之用；安装PSR软件；更新数据库数据字典升级PSR版本；正常启动数据库开始数据库服务。

　　看似简单的关闭数据库的操作，在系统构成复杂时也会变得不容易。另外，如果夜间作业时间不允许在完成数据库完全备份之后再安装PSR，则安装PSR的日期应该选择在例行的数据库完全备份的下一个晚上，只备份重做日志。

　　在安装PSR之前备份DBMS软件的目的是，由于安装PSR会对许多程序和库函数进行更新，如果安装PSR中途失败（虽然可能性非常小），有可能造成DBMS软件出现不一致。另外一种可能的情形是，在安装PSR，更新数据字典后，测试应用系统时，出现了某种异常，原因不明，最终决定放弃PSR.如果操作之前没有备份，则此时只有重新安装软件一种选择（PSR不同于完整软件安装，在oui中无法单独卸载PSR软件）。

　　对文件、目录和文件系统的备份，最简单的方式可以使用cp、tar、dump等命令完成。如果希望缩短文件拷贝时间，可以考虑分区备份的方法。分区备份常用的命令是dd.但是，分区拷贝比文件拷贝速度快的前提是良好的分区设计：Oracle软件单独占一个大小适中（如4GB）的分区，这样扇区拷贝才会体现优势，这也就是为什么在安装软件时，Oracle建议单独使用一个分区安装软件的原因之一。

　　在制定实施计划时，应认真阅读Patch Set Notes中有关操作前准备工作一节。在这节内会介绍对于一些特殊系统构成，如果你的系统属于文档中提到的构成，一定要首先阅读文内提示的相关技术文章，找到正确的安装步骤。

　　使用oui， PSR软件安装完成后，一定不要忘记更新数据字典这一步骤。如果在这一ORACLE_HOME下生成了多个数据库，则每个数据库都必须更新数据字典。

　　4.实施操作

　　制订一个详细的计划后，实施操作就可以“照本宣科”，是一个简单的体力劳动。要认识到“忙中出错”的概率远比“急中生智”大得多，操作时尽量减少失误的可能性。例如，需要执行的复杂命令，尽可能从一个文件拷贝到终端执行，而不要现场输入。另外，在实施过程中， 要记录各个阶段实际的执行时间，以供以后制订类似计划时参考。

　　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月。使用文件比较工具进行比较，两个版本没有实质性差别，只有语句措词的修改，但是养成总是检索最新文档的习惯有益无害。