问：我的客户规定我们不能出现任何停机时间以便Oracle 9.2.0.4升级到Oracle 9.2.0.6。我在F15K硬件的Sun Cluster 3环境上运行4路Oracle RAC。我们同时还在另外一个站点上有一个物理的备用数据库。由于各种原因，我们无法使用逻辑备用，同时，我们也无法提供所需额外的20到30兆兆字节存储。

　　由于Oracle并不提供补丁集的滚动更新，因此我们被迫停机。我们的计划是在一个单独的Oracle Home上安装Oracle，并将集群的每一个节点升级到Oracle 9.2.0.6。然后，我们将关闭激活的实例，将Oracle Home切换到9.2.0.6并启动移植。我的问题是是否有办法加速启动我们移植过程，比如去掉补丁集脚本上某些不必要的步骤?又如从SYS模式上删除统计信息。除此之外，我们目前仍没有想到其它可以加速过程的方法。

　　答：当升级高可用性系统时，总是需要进行权衡。你需要加速更新，并且还必须是安全的方式。你的方法是有效的——我个人也倾向于这种逐步升级的方法。需要注意的是你这样做不会破坏Oracle目录。如果在这个过程中你的目录受到破坏，那么可以肯定的是将来打补丁和升级将变得更加麻烦。

　　另外一种可以考虑的方法是在oraInst.loc文件中重新命名你的oraInventory子目录和/或修改oraInventory的位置。将Oracle 9.2.0.4安装到另一个ORACLE_HOME上，并将它保留在这个版本中。在短暂的停用中，只需要简单地将现有的数据库指向这个ORACLE_HOME。其它的都不会发生更改，数据库也仍然在版本9.2.0.4上。

　　恢复你的oraInst.loc文件和/或将你的oraInventory子目录的重命名为原来的名称。升级原先的9.2.0.4二进制文件为9.2.0.6。在下次停用期间，将数据库指向这个新升级的ORACLE_HOME，从而在数据库上完成升级过程。

　　这将意味着你的生产系统发生两次停机，但是它同样能使你的目录保留完整和精确，因此未来的安全性补丁（或其它一次性补丁）都将是可以读取和更新目录的。同时，最好保持常见命名的ORACLE_HOME，比如/oracle/product/920而非/oracle/product/9206。

　　当你在生产系统上执行这些操作之前，在非生产系统上进行几次测试是很重要的。这样，你就可以知道是否你将遇到目录问题，以及是否你的方法会如期运作。

　　关于修改catpatch.sql这个问题，我建议还是不要这样做。虽然它可能（或者不可能）加速你的更新，但是你可能会遇到数周或者数月都无法解决的问题，因此不值得这样做。