记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit

   由于系统整体规划需求，需将现有9iR2数据库统一升级到10gR2版本，由于涉及到机房内多套业务系统，因此作为明年的迁移项目，需要做前期迁移方案规划和测试。

    情况大致如此

	迁移前	迁移后
OS 版本	Linux AS4( 32bit)	Linux AS4( 64bit)
Oracle 版本	9iR2(9.2.0.6/9.2.0.8)	10.2.0 .4

    由于涉及的业务数据库容量动辄几百G，且停机时间有限(不超过4小时),因此迁移方案的核心在于如何用最短的时间和最安全可控的步骤来完成这次迁移。

    在高可用迁移案例中，最糟糕的情况莫过于跨OS的数据库迁移(非异构,排除字符集不同的情况,比如 Linux->UNiX,Windows->Unix),除了可借助一些oracle AQ和Streams来完成高可用同步和迁移外，并没有更好的处理办法(Dataguard无从发挥作用,诸如transport tablespace等手段对一个跨os的大容量的迁移项目也几乎鸡肋,实际中根本无法承受转换数据文件类型所带来的时间损耗)。但Streams等方案 太过于繁琐,需要有审慎周密的迁移步骤和考虑。当然，借助于三方工具可以完成诸多海量迁移(如DSG/SharePlex等),但出于成本和其他因素,并 不是每个迁移用户都有选择的余地.

    话题转到开篇的迁移情况，由于只是OS位数和Oracle版本/位数的转换，所以情况并非那么悲观。Oracle本身也提供了脚本,用来支 持在32位和64位之间做互相转换(rdbms/admin/utlirp.sql,这种转换是双向的).那么重点问题在于如何在停机之前将32位os上 的32位db与64位os上的64位db做同步,因为不可能停库以后才去将32bit os上datafile文件copy到64bit os上，如此数据量,光copy文件的时间就无法接受。能想到的最简单的同步办法，莫过于dataguard了.

    因此整个迁移方案雏形形成,新增一台设备，安装linux 64bit的os，部署2套Oracle版本，一套Oracle 9i(版本对应待升级源库版本,作为待升级源库的standby端做日志同步),另一套Oracle 64bit 10.2.0.4(用来做最终的升级版本).

    如此一来,整个迁移步骤就比较明了了。停库升级之前,做好主备的dataguard同步.待升级时刻，停主库，备库做failove切换，然后在新主库上做一系列数据字典升级和位数转换工作.跨版本的升级和位数转换过程，可以参考Metalink ID 62290.1 (该文档并没有提及跨大版本升级的位数转换，但实际测试中9i 32bit 升级到10g 64bit依然可行)

    特别提出：Metalink ID 62290.1提出32bit与64bit区别仅仅在于PL/SQL的编译格式不同，而且，一般的版本升级/降级过程会自动进行位数的转换。

The on-disk format for database data, redo, and undo is identical for the 32-bit and 64-bit installations of Oracle. The only internal structural differences between the 32-bit and 64-bit Oracle installations are the following:
The compiled format of PL/SQL is different. The instructions for how and when to recompile PL/SQL are provided in the appropriate chapters of the Migration book. The storage format of user-defined types is based on the release of Oracle that created the database. The existing storage format will be converted to the correct format transparently when necessary. User-defined types include object types, REFs, varrays, and nested tables.

If you are changing word-size during a migration, upgrade, or downgrade operation then no additional action is required. The word-size is changed automatically during any of these operations

    问题到此为止远没有结束,当我提出这个方案的时候，同事持有诸多疑虑。在Linux 64bit的OS上，用来做standby同步的9i版本,装的是32bit的还是64bit的呢，且是否能够与32bit OS上的32bit db形成dataguard体系呢?

    早前我曾做过测试案例，无论位数32还是64,dataguard体系都不存在任何问题.但要害在于,无论装32bit和64bit，看似Oracle官方都有不支持的地方且有明确的文档说明。

1.linux 64bit OS上安装oracle 32bit 9iR2

    按照常规办法，这种组合根本就无法正常安装成功。Oracle不支持在linux 64bit OS上安装oracle 32bit 9iR2,见metalink ID 416530.1

     实际中从主库上tar一个安装好的Oracle 32bit 9iR2放到linux 64bit的OS上，数据库依然能够正常运行并与主库形成dataguard体系.

    Dataguard failover后，利用10gR2的软件，直接进行数据字典升级(或者用dbua).

2.linux 64bit OS上安装oracle 64bit 9iR2

    这种办法等同于64bit的db与32bit的db做dataguard，metalink ID 413484.1 给出了异构平台下的dataguard组合列表，只有在10g以后，Oracle才支持linux 64bit与 Linux 32bit之间做dataguard.

    但实际测试说明，这种dataguard组合模式在9iR2下依然成立.

     Dataguard failover后，利用9iR2 64bit的软件，执行utlirp脚本将32bit 9iR2转换成64bit .接下来利用10g R2 64bit的软件，做常规的9i->10g数据库升级(手工升级数据字典或者使用dbua).

    两种方案在测试中皆可行，个人倾向于后者。

    实际测试中按照Dataguard+升级数据字典和转换位数的方法测试，整个升级过程没有任何问题,检查数据库各组件状态，均正常(注意 OLAP组件，如果库使用了该组件，32bit->64bit的转换会造成该组件的不可用，需要单独处理。另外，升级到10204需要注意Time Zone Definitions的问题)。升级过程在3小时之内可以完成.回顾整个迁移方案，唯一没有文档有力支撑的方便是Dataguard的组合模式,实际 standby端也无非是做了block级别的recover，既然dataguard能启用且日志能够被Recover，那就不存在由于该步骤引发其他 的bug的可能。