从Oracle 9i开始，oracle standby就开始可以实现“滚动”升级，如升级一个小的补丁(patch）或者是一个补丁集(patch set)，如图：
如果升级小的补丁，并不涉及到数据字典的升级，这个方式问题不大，但是，一旦涉及到升级数据字典，就存在一些问题了
1、在oracle 10gR2以前，如果存在一个或多个物理standby，因为物理Standby是只读的，只有升级软件的时候是可以在线升级的，升级standby数据字典的时候必须要switch over或者是failover之后，在停机时间来进行，这个过程耗费的时间可能也比较长。
2、在oracle 11gR1以前，主备库之间最多只能是跨小版本的补丁集，而不能是主版本的跨越，如9i到10g的standby，导致这个升级的功能也很有限。
至于问题1，在Oracle 10gR2以后，推出了一个全新的方法，如果主库存在一个或者多个物理Standby，可以先把其中一个物理Standby转换为逻辑Standby，执行升级操作，升级完成以后再转换为物理Standby。这个过程不会影响到其它的物理standby，完全可以平滑进行，这样的话，连升级数据字典的时间也可以在线完成了。
至于问题2，在Oracle 11gR1以后，可以跨大版本做Standby，如从Oracle 10gR2到Oracle 11g，所以，如果Standby升级到11g，依然可以接受Oracle 10gR2的日志，并应用，这个对大版本的数据库升级非常有用。
所以，有了以上的一些技术，就可以完全实现在线安装新版本的软件，在线升级了，整个升级过程最终仅仅是Standby切换的时间那么长而已。
最后，如果再结合如下2个技术点，整个过程就非常完美了
1、SQL重演（SQL replay）技术，可以在升级以后的standby目标数据库上，运行主库的完全的负载压力，看看目标数据库是否符合现在负载压力的要求，特别是SQL语句的执行计划，在新的数据库版本中，是否有所变化。
2、结合前面结束到的falsh database或者是slapshot database技术，可以在升级以后的standby目标数据库上做完压力测试，或者是SQL replay之后，继续回到Standby恢复状态，对整个系统不造成任何影响。
上一篇： « 闪回数据归档(flashback data archive)
下一篇： 宝宝拉肚子了 »
- 发表评论
