厂商提供给用户的软件补丁的形式多为编译后的库函数，李芦亩所以安装软件补丁实际上就是把这些库函数拷贝到相应目录，并在需要时进行联接 *** 作。软件公司一般在一段时间后会把针对某一版本的所有补丁进行整理：合并融合，解决冲突，进行整体测试，并使文件拷贝和联接 *** 作自动执行，得到一个软件补丁“包”。不同的公司使用不同的名称，现在一般计算机用户都熟悉的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下生成了多个数据库，则每个数据库都必须更新数据字典。
. 实施 *** 作
制订一个详细的计划后，实施 *** 作就可以“照本宣科”，是一个简单的体力劳动。要认识到“忙中出错”的概率远比“急中生智”大得多， *** 作时尽量减少失误的可能性。例如，需要执行的复杂命令，尽可能从一个文件拷贝到终端执行，而不要现场输入。另外，在实施过程中，要记录各个阶段实际的执行时间，以供以后制订类似计划时参考。
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。
1. 检查数据库表空间和初始化参数是否需要调整。
System表空间要求有一定未使用空间:初始化参数SHARED_POOL_SIZE 和 JAVA_POOL_SIZE不能低于最小值150MB。
2. 关闭数据库，停止listener和agent等进程。
3. 解压缩下载文件至某一目录，执行oui。
在压缩文件中附带的oui的版本要比已经安装的版本高，应总是使用新版本的oui。在oui窗口中，要求选择本次安装的软件的位置，正确的位置是解压缩目录下的子目录Disk1/stage/， 选中products.xml即可开始文件拷贝。
要注意窗口中会出现本次安装的日志文件的文件路径和文件名。文件的位置是在Oracle的inventory所在目录的子目录logs中，文件名由前缀InstallActions和安装日期时间组成，如: InstallActions2006-08-30-11-32-48AM.log。
正常结束后，退出oui。打开日志文件，检索是否出现error 或“ORA-”的错误信息。本次安装产生的日志文件内，没有任何此类的信息，表明PSR软件安装成功。如果此时再次启动oui，点击“已安装软件”，则可以看到在原有的10.1.0.2软件之下，新出现了10.1.0.5一项，这也证实PSR软件安装成功。
4.更新数据库数据字典
更新数据字典时，必须以特殊的升级方式打开数据库。
$ sqlplus /nolog
SQL>CONNECT / AS SYSDBA
SQL>STARTUP UPGRADE
SQL>SPOOL patch.log
SQL>@?/rdbms/admin/catpatch.sql
执行结束后，关闭重定向：
SQL>SPOOL OFF
打开文件patch.log检查是否有错误“ORA-”。（这一文件在启动sqlplus时的当前目录中，当然也可以在“SPOOL patch.log”语句中显式指定文件路径。）如果出现错误要分析原因，在解决问题后，需要再次执行catpatch.sql程序。
更新数据字典时，由于对某些PL/SQL包删除后又重新生成，造成相关PL/SQL包的状态为异常（invalid）。在以后调用这些包时，检测到其状态为非法，会自动执行编译命令，使状态成为正常（valid）。虽然不会出错，但会造成个别处理第一次执行时变慢。显然，与其留到应用系统运行时再一个个编译，不如之前集中一次重编译所有异常包。
SQL>SHUTDOWN
SQL>STARTUP
SQL>@?/rdbms/admin/utlrp.sql
最后，根据Known Issues中的指示，完成与本系统有关的 *** 作。例如，修改Pro*C的配置文件。这里执行一个修改文件存取权限的“后 *** 作”，以便非同组用户和程序可以存取客户端工具和库函数。
$ cd $ORACLE_HOME/install
$ ./ changePerm.sh
个别补丁管理工具opatch
如前所述，在发布一个PSR后发现的新BUG，只能把其补丁收入到下一个PSR中。如果对数据库有实质性影响，则这一补丁以个别补丁的形式向用户提供。个别补丁是与某一个特定的PSR关联，是安装在这一PSR之上的。另外，如同其名字表明的，个别补丁只是单一Bug的补丁，不会包含其他个别补丁，即不是累积型的。
在9.2版之前，安装个别补丁的 *** 作完全是手工的。这种手工方式的缺点不仅在于加重DBA的负担，容易造成 *** 作失误，更严重的是无法对已安装的个别补丁进行管理。
为解决手工方式的缺陷，从9.2版开始，Oracle公司设计实现了个别补丁安装管理工具opatch。opatch使用一个称为 inventory的系统数据结构（严格说是与oui共享inventory）,集中管理所有已安装的个别补丁；个别补丁的安装和卸载都使用opatch 命令完成，冲突检测也由opatch在安装时自动完成；提供列表命令可以很方便得到已安装个别补丁的信息。
10g(10.1和10.2)版本中，opatch作为一个标准工具，在软件安装时自动安装。（安装在$ORACLE_HOME/OPatch 下。）而对于9.2版，需要从metalink下载opatch。无论数据库是哪一个版本，系统中是否已经安装opatch，在使用之前，应从 metalink下载最新版本的opatch。很遗憾，由于系统实现的问题，10.2使用的opatch与之前版本（10.1和9.2）使用的 opatch不兼容，不能混用，这一点必须注意。
opatch是使用perl编写的脚本程序（其中也使用JAVA API）。编程使用的perl版本是5.6版，虽然在5.6之前的版本中也可运行，但应尽可能安装5.6或以上的版本的perl。对于DBA来说一个好消息是，如果安装9.2版软件时保留了HTTP服务器，则在$ORACLE_HOME/Apache下会自动安装perl。（10g会自动安装配置perl 和opatch。）
opatch命令格式为：
opatch <command >[<command_options >] [ -h[elp] ]
命令有：apply（安装个别补丁）、rollback（卸载个别补丁）、lsinventory（对inventory进行列表）、query （显示某一个别补丁的详细信息）、version（显示opatch版本信息）。在opatch目录下，有用户使用指南文件（Users_Guide.txt），其中有详细的命令格式和使用示例，读者可以参考。Opatch执行 *** 作时，除在屏幕输出结果外，还生成日志文件。日志文件的路径和文件名格式如下：
$ORACLE_HOME/.patch_storage/<patch_id >/<action >-<patch_id >_<mm-dd-yyyy_hh-mi-ss >.log
其中“patch_id”是Oracle技术支持部门为个别补丁分配的编号。
4. 个别补丁安装实例
沿用安装PSR实例中的环境。在安装PSR10.1.0.5后，检索metalink，发现若干在其之上的个别补丁。选择其中之一安装。
个别补丁Patch 4518443修复BUG4518443，这一BUG的主要问题是TNS LISTENER在注册ONS（Oracle Notification Services）的同时如果创建子进程，那么LISTENER会挂起（HANGUP）。
安装时，首先，从metalink下载补丁的压缩文件p4518443_10105_LINUX.zip。将此文件解压缩至某一目录中。解压缩后，这一补丁的所有文件都在子目录4518443下，目录名就是个别补丁的补丁号，opatch依据目录名获得信息，所以一定不要重命名子目录。
然后，在终端窗口中，执行cd命令移动到4518443子目录中，执行以下命令：
$ $ORACLE_HOME/OPatch/opatch apply
对inventory列表，确认安装 *** 作：
$ $ORACLE_HOME/OPatch/opatch lsinventory
执行卸载命令时，也必须使4518443子目录成为当前目录。其中，Rollback命令需要两个参数：-id给出个别补丁号；-ph 给出个别补丁解压缩后的路径。
$ $ORACLE_HOME/OPatch/opatch rollback -id 4518443 -ph /…/4518443
随后再对inventory列表，则会看到这一个别补丁已经被移去。
4. 使用opatch显示已安装的版本信息
不需要启动数据库，执行加选项的对inventory的列表命令，可以得到已安装的软件的各个组件的详细版本信息。
$ $ORACLE_HOME/OPatch/opatch lsinventory -detail
安全补丁CPU
一个CPU内包含了对多个安全漏洞的修复，并且也包括相应必需的非安全漏洞的补丁。CPU是累积型的，只要安装最新发布的CPU即可，其中包括之前发布的所有CPU的内容。事实上，在CPU之前的安全漏洞修改除去个别例外也被包括在CPU中。Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新，对处于维持支持范围的产品不提供新的CPU。（对于9.2以前的版本，只对处于ECS和EMS期间的版本提供CPU更新。）一般对当前补丁发行版及前一个版本提供CPU，但也有只限于当前补丁发行版的例外情形。也就是说，一般需要先安装最新PSR后才可能安装CPU。由于是累积型的定期发布，所以对于某一平台的某一版本，如果两次CPU发布期间没有发现新的安全漏洞，则新发布的CPU与前一版本完全相同。
从 版开始 Oracle公司设计实现了个别补丁安装管理工具opatch opatch使用一
个称为inventory的系统数据结构（严格说是与oui共享inventory） 集中管理所有已安装的个别补丁 个别
补丁的安装和卸载都使用opatch命令完成 冲突检测也由opatch在安装时自动完成 提供列表命令可以很方
便得到已安装个别补丁的信息
g（ 和 ）版本中 opatch作为一个标准工具 在软件安装时自动安装 （安装在
$ORACLE_HOME/OPatch下 ）而对于 版 需要从metalink下载opatch 无论数据库是哪一个版本 系统中是
否已经安装opatch 在使用之前 应从metalink下载最新版本的opatch 很遗憾 由于系统实现的问题
使用的opatch与之前版本（ 和 ）使用的opatch不兼容 不能混用 这一点必须注意
opatch是使用perl编写的脚本程序（其中也使用JAVA API） 编程使用的perl版本是 版 虽然在
之前的版本中也可运行 但应尽可能安装 或以上的版本的perl 对于DBA来说一个好消息是 如果安装
版软件时保留了HTTP服务器 则在$ORACLE_HOME/Apache下会自动安装perl （ g会自动安装配置perl和
opatch ）
opatch命令格式为
opatch <mand >[<mand_options >] [ h[elp] ]
命令有 apply（安装个别补丁） rollback（卸载个别补丁） lsinventory（对inventory进行列表）
query（显示某一个别补丁的详细信息） version（显示opatch版本信息） 在opatch目录下 有用户使
用指南文件（Users_Guide txt） 其中有详细的命令格式和使用示例 读者可以参考 Opatch执行 *** 作时
除在屏幕输出结果外 还生成日志文件 日志文件的路径和文件名格式如下
$ORACLE_HOME/ patch_storage/<patch_id >/<action ><patch_id >_<mm dd yyyy_hh mi ss
>log
其中 patch_id 是Oracle技术支持部门为个别补丁分配的编号
* 个别补丁安装实例
沿用安装PSR实例中的环境 在安装PSR 后 检索metalink 发现若干在其之上的个别补丁 选
择其中之一安装
个别补丁Patch 修复BUG 这一BUG的主要问题是TNS LISTENER在注册ONS（Oracle
Notification Services）的同时如果创建子进程 那么LISTENER会挂起（HANGUP）
安装时 首先 从metalink下载补丁的压缩文件p _ _LINUX zip 将此文件解压缩至某一目录
中 解压缩后 这一补丁的所有文件都在子目录 下 目录含森名就是个别补丁的补丁号 opatch依据目录
名获得信息 所以一定不要重命名子目录
然后 在终端窗口中 执行cd命令移动到 子目录中 执行以下命令
$ $ORACLE_HOME/OPatch/opatch apply
对inventory列表 确认安装 *** 作
灶老瞎 $ $ORACLE_HOME/OPatch/opatch lsinventory
执行卸载命令时 也必须使 子目录成为当前目录 其中 Rollback命令需要两个参数 id给出
个别补丁号 ph 给出个别补丁解压缩后的路径
$ $ORACLE_HOME/OPatch/opatch rollback id ph /…/
随后再对inventory列表 则会看到这一个别补丁已经被移去
* 使用opatch显示已安装的版本信息
不需要启动数据库 执行加选项的对inventory的隐空列表命令 可以得到已安装的软件的各个组件的详细版
本信息
$ $ORACLE_HOME/OPatch/opatch lsinventory detail
安全补丁CPU
一个CPU内包含了对多个安全漏洞的修复 并且也包括相应必需的非安全漏洞的补丁 CPU是累积型的
只要安装最新发布的CPU即可 其中包括之前发布的所有CPU的内容 事实上 在CPU之前的安全漏洞修改除去
个别例外也被包括在CPU中 Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新 对处于
维持支持范围的产品不提供新的CPU （对于 以前的版本 只对处于ECS和EMS期间的版本提供CPU更新 ）
一般对当前补丁发行版及前一个版本提供CPU 但也有只限于当前补丁发行版的例外情形 也就是说 一般需
要先安装最新PSR后才可能安装CPU 由于是累积型的定期发布 所以对于某一平台的某一版本 如果两次CPU
发布期间没有发现新的安全漏洞 则新发布的CPU与前一版本完全相同
在以下网址中可以找到CPU发布的信息 但是很遗憾 只有技术支持签约用户才可以从metalink下载补丁
文件
Oracle公司制定的CPU的发布日期大约在一月 四月 七月和十月的最接近 的星期二
对于每一个CPU 附有相应的说明文档（Critical Patch Update Note） 其中介绍安装过程和注意事项
在安装之前应认真阅读此文档 同样也存在文档 Oracle Critical Patch Update MM YYYY Known Issues
for Oracle Database 其中列出了说明文档中没有给出的新信息
在安装时 首先下载压缩文件p _ _LINUX zip 解压缩到与其它个别补丁相同的目录下 检
查其发行说明时 发现要求opatch版本比现已安装版本要高 下载安装指定版本opatch 进入子目录
（这是此安全补丁的补丁号） 执行apply命令
$ $ORACLE_HOME/OPatch/opatch apply
打开此次安装生成的日志文件 其中没有错误信息出现 执行inventory列表命令确认安装
$ $ORACLE_HOME/opatch lsinventory
opatch作用
opatch是用于维护 个别 补丁的 有人称其为interim path或是one off patch
以解决TA ENQ AND US ENQ DEADLOCK DURING TRANSACTION RECOVERY IN RAC问题的interim patch 为例
安装及rollback的命令如下
install:
oracle>unzip p _ _HP zip
oracle>cd
oracle>opatch apply
rollback:
oracle>cd
oracle>opatch rollback id
查看
如下命令可以看到已经安装了哪些interim patch
[oracle@mysql ~]$ /u /app/oracle/product/ /db_ /OPatch/opatch lsinventory
不断的在opatch后面加 h可以看到这个命令更加详细的选项
看一下lsinventory后面有哪些选项
[oracle@mysql ~]$ /u /app/oracle/product/ /db_ /OPatch/opatch lsinventory h
环境介绍
XXXX综合管理信息系统主机放在XXXX 数据库平台硬件架构如下
数据库主机 两台IBMp （jcczxt jcczxt ）安装AIX L ML 通过IBM HACMP构成双机热备
数据库平台 Oracle Server Enterprise Edition Version:
故障描述
年 月 号上午 值班人员接到用户反应应用出错无法存盘 前台出现的错误信息如下
ORA IO error reading block from file (block # )
ORA : data file : /oradata/ *** is dbf
ORA : skgfqio :unable to quere I/O
ORA : skgfdisp : I/O error
IBM AIX RISC System/ Error : : I/O error
此时数据库管理员重新启动数据库 前台用户反应应用可能正常运行 问题解决 数据库管理员在检查主机日志时没有发现任何硬件故障问题 在检查数据库日志时也没有任何错误提示 用Oracle的实用程序DBV对数据库文件进行检查没有发现坏块
年 月 日下午 用户又报同样的错误 此时DBA重新启动数据库和应用 问题解决 : 用户又报同样的 DBA重新启动数据库和应用 问题解决
故障的定位
第一步 通过errpt检查主机的日志确认主机没有硬件问题 磁盘没有损坏 第二步 通过检查数据库的日志文件(alertSID log)也没有相关的错误提示 初步判定不是数据库的问题 第三步 通过Oracle的实用程序DBV对数据库文件进行检查没有发现坏块 此时可以确认不是硬件问题 是软件的问题 第四步 综合管理信息系统是 年 月 号上线 一直都稳定运行 没有出现过类似的情况 可以排除是应用程序的问题 第五步 通过上metalink网站查询与ORA 相关的信息 发现有大量的资讯 其中的故障描述与我们的情况一致 由于在AIX L的 *** 作系统上Oracle由于无法获取正确的data block头信息 从而导致DBWn进程写硬盘失败 Oracle数据库从 到 都有此问题 是由于Oracle的BUG导致 需要打一个Oracle的临时补丁 此时问题可以定位为oracle在AIX L平台上的BUG 需要加载一个Oracle的临时补丁patch
Oracle术语解释
什么叫interim patch ?
Interim patch是一次性的补丁针对特定的情况下触发的Bug 没有经过Oracle系统的认证 Oracle会根据Bug的严重性和需要在下一次的patch set中包含此Interim patch Interim patch对环境和版本有特定的要求 即不同 *** 作系统平台和数据库版本的会有不同的Interim patch 如Interim patch 会
什么叫Opatch?
Opatch是oracle支持的Oracle临时补丁的安装实用程序 是针对Oracle数据库第二版 后安装临时补丁 Opatch是一个基于Perl的程序
如何安装Opatch?
从metalink上选择补丁程序 选择简单搜索 输入patch号 选择相应的 *** 作系统平台 查询结果会显示所有可用版本的optach 下载版本号 就行 将下的压缩文件上传到数据库主机 将压缩文件复制到$ORACLE_HOME目录下 用unzip工具解压此压缩文件 具体命令如下
#cp /tmp/p _ _AIX L zip $ORACLE_HOME
#chown oracle:dba $ORACLE_HOME/p _ _AIX L zip
以oracle用户解压此文件
$ cd $ORACLE_HOME
$unzip p _ _AIX L zip
解决方法
)从metalink上选择补丁程序 选择简单搜索 输入patch号 选择平台为IBM AIX Based System( bit) 下载Oracle 对应的patch大小为 K
)将patch 上传到数据库主机(host )
)在jcczxt 主机上加载此patch
因综合管理信息系统采用双机热备方式 所以备机(host )没有数据库应用 所以我们可以在不停下数据库的情况下加载patch 详细步骤如上
以oracle数据库用户执行下面的命令
$cp /tmp/p _ _AIX L zip /oracle/patch
$cd /oracle/patch
$unzip p _ _AIX L zip
$cd
$$ORACLE_HOME/Opatch/opatch install
提示要求输入metalink的帐号和密码 可能随便输入
提示 Please shut down Oracle instances running out of this ORACLE_HOME 输入 Y
此时oracle会开始安装patch 因为要重新链接lib 所以要花几分钟时间 在安装完毕后会出现 OPatch succeeded 提示
)将数据库切换到jcczxt
lishixinzhi/Article/program/Oracle/201311/18781应该怎么样败雹宏安装数据库，从安装软件到创建数据库?对于这个问题肆悉，或许有的人不屑一顾，因为他们觉得这没有丝毫问题同时有另一部分人，觉得这是个大问题。
在察册安装Oracle上，通常会有几种类型的人：
完全抓不着头脑，不知道怎么安装，这通常是初学者，连Linux/Unix都不太熟悉。
很少安装Oracle的人，但是知道对照文档一步一步 *** 作，出了错也知道上google、baidu和metalink查找解决方案。
Oracle老手，安装数据库不需要任何文档，对每个步骤也很熟悉。
对Oracle的安装非常熟悉，但是在安装时仍然按文档一步一步 *** 作。
对我个人来说，我是最后一种类型的人。我也自认为安装了不少的数据库，覆盖了大部分的平台和 *** 作系统。但我安装的时候，仍然会不嫌麻烦的一步一步 *** 作按文档 *** 作。在安装数据库软件包括建库，基本上没有遇到过什么问题。因为我也见过
很多朋友，被安装这一问题折腾得焦头烂额，特别是在安装RAC的时候，这里只是写一写我自己的一些做法，仅供参考，毕竟每个人都有自己的习惯和做法。
本文主要描述Linux/Unix下的Oracle安装，不涉及Windows系统下的安装。
我的习惯做法：
平时注意收集安装文档，包括oracle online document(所谓的官方文档)，metalink上的，还有IBM、HP这些公司与Oracle合作部门提供的文档。oracle online document中安装部分没事看一遍就可以了，但是metalink上很多文档详细地记录了版本的兼容性，安装时可能出现的问题以及解决办法等等，比如很实用的文档：《Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) [ID 169706.1]》、《Linux OS Requirements Reference List for Database Server [ID 851598.1]》、《Status of Certification of Oracle Clusterware with HACMP [ID 404474.1]》。而其他厂商的文档包括：《CookBook_V3.2_Oracle_9i_RAC_AIX5L》、《COOKBOOK_Oracle CTC RAC10g R2 on HP-UX》、《COOKBOOK-V2.0-10gRAC R2 - ASM - AIX5L - SAN Storage》如此等等，还包括网上一些朋友自己撰写的安装文档。在参考这些文档时，需要注意的是，一定要明白每一个步骤其目的，有什么作用。
根据以上提到的文档，进行整理，形成自己的文档。我在前面说到，我安装时一步一步按文档 *** 作，是指的按我自己的文档，而不是去参考前面提到的若干文档。在自己的文档中，甚至提供了详细的命令，这样在安装的时候对某些不熟悉的命令不至于现查资料。
深入理解文档中提到的各个参数、各个命令的作用。这不光是对安装，而对于Oracle数据库的更深入理解也是大有好处的。
安装Oracle数据库时，在安装软件之前，通常有下面的 *** 作：
检查 *** 作系统版本、相应组件是否安装，是否有安装好文档中指定的补丁，也包括c编译器或c语行环境，这些对Linux下的安装来说犹为重要。
检查文件系统空间，特别是/tmp临时文件系统
检查memory大小，特别是swap的大小。特别是在HP-UX下，swap的管理方式与其他系统有些不一样(此处不再细述)，最
好能够达到物理内存大小，对于特别大的物理内存，至少也要达到一半。
检查主机时区，时间设置。这一步通常被很多人忽略。
检查主机名设置，有的安装系统相当不负责任，直接将主机取名localhost。
检查异步IO设置。
检查网络设置，包括/etc/hosts文件的设置，特别是对RAC数据库犹为重要。
检查内核参数，特别是共享内存、信号量、用户最多可运行进程数这些参数。
oracle用户创建后，注意编辑profile文件，设置相应的环境变量，注意不同的平台，相同意义的环境变量却有不同的名字，比如linux下的LD_LIBRARY_PATH和AIX下的LIBPATH。经常见到有的系统，oracle的PATH都没有设置，这样登录后 *** 作相当不方便。
对Oracle用户设置limit，通常是直接编辑/etc/security/limits.conf文件。
给Oracle用户一些特定的权限，比如HP-UX下修改/etc/privgroup文件，10.2.0.4 for AIX下给用户CAP_NUMA_ATTACH, CAP_BYPASS_RAC_VMM, CAP_PROPAGATE 这样的权限等等。
对于RAC，还需要设置rsh或ssh
至于安装的其他步骤，不是本文所要讲的主要内容，在此略过。
还要提及一点，安装的时候对于目录的选择，可以按照OFA的标准做法，也可以按照使用部门的习惯，建议使用OFA。经常有见到一些乱七八糟的目录，让人好找，这种做法不太好。
说到安装，不能不提到打补丁。在安装完成后，最好是打上较新的补丁包以及metlink上提到的一些建议打的补丁。而等到系统正式使用，发现问题再打补丁，其代价就昂贵得多。
由于安装Oracle软件以及升级版本和打补丁，比较耗时，有的朋友就喜欢下面的做法：安装好软件，打上补丁，然后tar成一个包，保存在自己的存储介质上，下次在其他主机上安装时，直接用这个tar包解开。这种做法可以省一些安装软件的时间，但是需要tar包的环境是否一致。我曾遇到过下面的问题：
某套新装9208的库，报ORA-600[504]错误，通过在metalink上搜索发现其最符合的一个BUG对应的补丁已经打上。其他类似环境下，包括有同样的补丁，却没有这样的错误。我找了一台 *** 作系统完全一样的测试主机，安装与有问题库的版本完全一样的版本和补丁，却也没有这样的错误接下来我将出问题的Oracle home 复制到测试主机上，结果问题重现了，看起来问题在Oracle软件上。我尝试执行relink *** 作，居然失败。发现这份Oracle在relink包括有HA代码，实际上这是一个单机的环境，也没有安装HACMP。最后，使用rac_off选项，再重新relink，新生成的oracle，不再出现这样的问题。在有问题的生产主机上重新relink后，问题解决。
出现问题的Oracle，就是通过解tar文件来安装的，在主机上我们也发现了以前安装时保留的tar文件。因此通过这种方式安装的，建议进行relink。
下面再谈谈创建数据库的一些个人经验：
尽量使用new database(9i)或者custom database(10g)这样的选项来创建库，建库时只安装必须的组件，这种做法有3个主要好处：更安全、更稳定、以后升级时所花的时间更少。
创建数据库时注意选择正确的字符集。
如果是选用模板创建数据库，注意模板有可能不与Oracle软件软件版本相匹配。同时在建库完成后需要运行相应的脚本，比如在安装了PSU的情况下，那么使用模板建库，得需要运行PSU带的脚本(具体参考PSU的README)。
在打完补丁之后，在创建数据库，避免在升级软件之后还要升级数据库。
建完库后，建议设置一下大体上合理的数据库参数。
希望本文能够对Oracle数据库的安装不太熟悉的朋友一些帮助。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）