Oracle 32bit 升級到64bit

   由於系統整體規劃需求，需將現有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的可能。

垃圾廣告.com/blog/538993