问：我的客户规定为了从Oracle 9.2.0.4升级到Oracle 9.2.0.6，不能出现任何宕机时间。我们现在正在运行4-way Oracle RAC，运行环境为Sun Cluster 3，硬件为F15K。在另一个站点上我们还有另一台物理备用数据库（standby database）。由于某些原因，我们不能使用逻辑备用数据库，也不能提供它需要的另外20-30TB的存储空间。

　　如果Oracle不提供补丁的滚动升级，我们就一定会有宕机。我们打算在单独的Oracle Home里安装Oracle，并在集群里每个节点上将它修复到Oracle 9.2.0.6。然后我们会关闭激活的实例，然后从Oracle Home转换到9.2.0.6并开始迁移。我的问题就是：你能给我们介绍一种能加快启动迁移程序，也许还能从catpatch脚本里清除一些不必要步骤的方法吗？另外，从SYS schema中删除统计，我们现在还没有想到加快迁移程序的办法。

　　答：在升级高可用性系统时这是一个配平操作（balancing act）。你需要加快升级速度，同时又要保证安全。你所说的方法其实是正确的，我个人比较喜欢这种阶段性的升级方法。要注意的一点就是不要损坏Oracle Inventory。如果在这个过程中它被损坏，那对于以后应用补丁和升级就会更加头痛。

　　另外一种方法就是重新命名oraInventory子目录或者在oraInst.loc文件里更改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的问题，我并不赞成你这样做。它也许能够加快你的升级速度，但是如果你在几周或几个月之后遇到了很难解释的问题，那就不值得了。