随着Oracle软件越来越庞大，内部结构越来越'精密， 每个版本推出来的新特性,新功能总是有各种各样的缺陷；而新版本中对上一个版本中遗留问题的修复又会引入新的问题。老DBA总结出来的：只使用2-3年之前发布的'稳定版本，对于新装系统的Oracle版本选型虽然仍具有指导意义。建议选择较新的版本，虽然不敢用最新推出的版本，至少要选择"次新"的版本。因为最新版本的用户群小，那么只有自己遇到某个问题（而不是很多人遇到同样/类似问题）的概率就大，那么希望从用户社区获得帮助的可能性就小，这样不利于快速解决问题。

        PSU即 Patch Set Update，即对于'补丁集'的更新；举例：Oracle Database 11g：11.1.0.6.0 --> 是11gR1的基础版本，Oracle Database 11g Patch Set 1 11.1.0.7.0 --> 11gR1的第一个补丁集，Patch  9352179  : applied on Wed May 12 15:40:48 CST 2010 --> PSU3。这个PSU3即可以在11.1.0.7.0上打，也可以在11.1.0.7.1或11.1.0.7.2上打，因为11.1.0.7.1实际上就是在11.1.0.7.0上打了PSU1，11.1.0.7.2实际上就是在11.1.0.7.0或者11.1.0.7.1上打了PSU2；而每个PSU总是包含了在它之前发布的那个PSU的内容； 即PSU3是PSU2/PSU3的超集，PSU2是PSU1的超集。并且，每个PSU还包含自上个PSU发布以来另外解决的一些缺陷（以one off patch形式存在）。

        PSU发布规范：Oracle以季度为单位来发布PSU，每年的1.1、4.1、7.1、10.1都会发布关键补丁更新。

        如何打PSU：

1. 检查readme.htm，列出主要注意事项，及打补丁的大致步骤。比如RAC中，一般会要求停止nodeapps、instance、asm；为了安全起见，也建议停止crs。
   
2. 执行prereq CheckConflictAgainstOHWithDetail  检查补丁冲突：一般有两个情况，subset与conflict 都会在打补丁时回滚掉。subset不用关心，这说明这次要打的补丁包含了这个subset；而conflict的补丁则要事先下载下来。如果暂时没有，则提交SR申请补丁。
3. 整理好打补丁的详细步骤，反复check，并在测试环境运行通过。
4. 开始打补丁，打完后检查log，检查补丁是否已经成功写入inventory，这一步是可以rolling的。
5. 更新数据字典/编译非法对象，这一步因为需要open db来操作，无法rolling。有些PSU需要修改数据字典。、

RAC中的Rolling Upgrade
      这个地方的Rolling仅仅只是指Update 文件，Make、Relink阶段可以rolling；而不是指更新数据字典阶段。一定要注意这个区别。老汤曾遇到过几个异常情况：

1. 在一个8节点的rac中，在update 库文件阶段非常慢，cpu很空，iowait严重 25%以上，发现是tar进程( 解压jar文件) 需要等io；而在同样配置的另一个8节点rac中打同样的psu，update库文件则很快，猜测可能是cpu有缺陷。
2. 在一个24节点rac上，更新字典数据阶段非常慢，执行dbms_registry.loaded('AMD'); 时花了将近2小时，发现session在执行各种数据字典表的统计信息收集任务，包括对ASH、AWR的一些的操作，而这个库是个数据仓库系统，有几百万个分区,，对象非常多，所以字典表非常大，那么每一个收集sql都需要跑较长的时间，加在一块时间就比较可观了。
3. 在24节点的RAC上打psu3时，由于整个过程不用打crs的补丁，所以没有停crs进程。在执行update库阶段，发现有个节点僵死了，等了一个多小时才启动成功。这个节点错过了打patch的时间（执行patch的进程无法远程cp文件到它上面），而在随后打其它one off 补丁时，由于那台机器已经ok，最后一个one off 补丁成功打上去了。
   

这里有2个问题

1. 就是这个死掉的节点只打了一个补丁, 如何给它加上其它的?
2. $ORACLE_HOME/inventory/ContentsXML/comps.xml 被执行补丁进程的那个机器的comps.xml覆盖了。所以，当在这个节点上执行opatch脚本时会失败，因为它无法读取不存在的补丁记录

打psu3时，先回滚psu2，而psu2中包含了某个patch，它解决了ORA-00600 [3619]。因为这个bug，DB不能open，必须recover database之后才能open（虽然gV$RECOVER_FILE中无任何文件需要恢复）。因为回滚了psu2，而在这个点上psu3还没有打上（要更新完字典了才算打上），在这样一个'缺口'期，这个bug会死灰复燃，当进行到后面需要open db来更新字典( catbundle.sql)时，会报 ORA-00600 [3619]，这个时候需要recover database。