Oracle高可用迁移升级场景与实战(一)

       较大型的系统环境往往因各种原因，将数据库部署到不同平台或者不同版本上。随着系统的后期调整，必然涉及到数据库方面的相关改造（比如平台迁移，版本升级等）。对于这类整改工作，需要考虑的因素比较多，但核心问题无外乎以下几点：

① 风险与可控性

    风险与可控不单单指的是迁移升级过程中，更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。

    一个良好的迁移工程，需要强有力的迁移控制过程，完善的模拟验证机制以及快速有效的回退方案。

②停机维护窗口

      大部分迁移都需要在指定的停机时间内完成，以避免对业务造成更多的中断和影响。对于高可用环境，需要有良好的迁移方案来尽可能压缩停机时间。

       本文重点讨论各种常见场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移工具。

       先简单列举一下各种迁移手段及其特点。

(1). EXP/IMP

      逻辑导入导出工具，优点是可以跨平台跨版本，可以实现数据重组，但是对大规模的DB不适合，停机时间长且不可控。

(2). EXPDP/IMPDP

      10g以上版本可用；优点是可以跨平台跨版本，可以实现数据重组，虽然处理速度上较exp/imp有了大幅提升，但仍然不适合短时间的海量数据迁移。

(3).Transport Tablespace 表空间搬移

       9i以上版本可用, 可跨版本。9i上不能进行跨平台迁移，10g以上可以实现跨平台迁移，处理办法因字节高低位顺序有所不同。停机窗口一般。

(4).高级复制

      该方案可以跨平台跨版本，可大大缩短停机时间，但操作复杂，可控性差，且迁移过程对源环境有影响，非必要不建议使用。

(5).物理Dataguard/备份恢复

      物理Dataguard就是一个自动化的异库恢复过程，与手工的异库recover archivelog并无异样，二者实际是一体的。优点是可控性强，停机时间短，一般不应该超过半小时。但是不支持异构平台，10g以上版本可以支持一定的异构环境，可参考metalink id 413484.1

(6).逻辑Dataguard

      从10.1.0.3版开始，Oracle可以利用SQL apply进行rolling upgrade，这无疑进一步降低了升级带来的停机时间。一般我们可以利用logical standby来配合做一些版本滚动升级。

(7).Streams

        Streams灵活多变，可以作为我们迁移升级的一个强力工具，尤其是跨平台升级或者迁移。缺点是配置略显繁杂，注意点比较多，还需要一些逻辑对象的支持和数据支持，9i以上适用。

       以上是常见的一些Oracle自身迁移升级手段，实际的案例中，可能并不单单局限于其中某种，交叉使用是必要的。

        下面就同平台和异构平台两种大情况，列举一些常见的高可用迁移方案，当然，实际迁移过程中情况不尽相同，方案无所谓最优，做到灵活处理，满足需求为佳。

<1> 同平台下的迁移/升级

(1) 版本升级

常见案例情况： 9i/10g/11g之间的小版本升级、大版本升级。（以9.2.0.8升级10.2.0.4为例）

可采用方案:

Dataguard + 升级数据字典

       实际过程中如果条件允许，应该尽量避免在原始库上做升级操作以避免升级失败带来一系列问题。

简单步骤：

①备机装2套db软件，一套9.2.0.8用来与原始库做物理dataguard，另外一套10.2.0.4用来做升级数据库版本。

② 同步dataguard，业务不受影响

③ 停止业务，Standby库failover成主库

④ dbua或者脚本方式进行库版本升级

评点：停机时间比较短，顺利2小时之内可完成操作，检查点比较少，失败后可重新启用原始库。

Dataguard + Transport tablespace

简单步骤：

①备机建2套db软件，一套9.2.0.8用来与原始库做物理dataguard，利用另外一套10.2.0.4创建一个新库以便进行空间搬移

② 同步dataguard，业务不受影响

③停止业务，Standby库failover成主库

④利用Transport tablespace技术将9208库表空间搬移到10204库

⑤处理表空间搬移无法操作的逻辑对象等

评点：停机时间很短，30分钟内可以完成，需要注意检查一些逻辑对象的状态和同步情况，失败后可重新启用原始库。

（2）位数升级

常见案例情况：DB版本位数转换(以linux 32bit 10.2.0.1转换到linux 64bit 10.2.0.1为例)

可采用方案：

Dataguard + 位数转换脚本

简单步骤：

①备机安装1套64bit的Oracle 10.2.0.1，与原始库形成物理Dataguard .

②同步dataguard。

③停止业务，Standby库failover成主库

④利用Oracle提供的32bit<->64bit转换脚本utlirp进行位数转换(双向)。

评点：停机时间很短，30分钟内可以完成，失败后可重新启用原始库。

     可能实际碰到的情况看起来更复杂一些，比如位数和版本都需要同时升级，这就是个如何打组合拳的问题，本质处理方法都是类似的。可以参考一个实际案例：
记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit

       当然，以上这些案例都可以使用streams或者其他方法来完成迁移升级。大多数的同平台数据库迁移，Dataguard/备份恢复是个优选工具，结合其他的一些手段，停机时间都不需要太长，而无需过度关心数据库的数据量问题。

Oracle高可用迁移升级场景与实战(二)