Oracle跨平臺遷移的簡單總結

前段時間測試了一下GoldenGate，結合我之前的一些嘗試，對於小機環境的遷移，思路是逐步清晰了起來。

需求的核心是跨平臺遷移資料庫，最好能夠升級到新的版本，對於一個核心繫統的一主兩備，需要保證資料完整性的前提，同時能夠儘可能保持在一個較短的維護時間，對此自己也琢磨了很多方案。

想了NFS的方案，在備庫端建立一個NFS掛載點，源端指向Linux環境，然後直接Failover，這樣資料就能夠直接到Linux端，然後做一個跨平臺的convert操作

這樣就可以儘可能快的切換資料到了Linux端，然後在Linux端轉換檔案後直接利用TTS的方式匯入，如果準備充分，這個過程應該不超過半個小時。

自己還為這種方案而沾沾自喜，最後試了一遍，發現其實不是那麼回事。問題的瓶頸在哪裡呢，就是跨平臺的系統呼叫介面。

如果在Solaris端使用NFS共享的檔案，嘗試啟動資料庫，那麼就會沒有響應，會丟擲一個比較奇怪的問題。

當然自己也堅持不懈查了一些資料，發現真不能這麼玩，同時Solaris還可以，跨平臺的情況下，還是有很多大大的不同。所以NFS這個方案就點到為止，pass了。

而對於大資料量的資料庫做跨平臺遷移，還有什麼其他的思路嗎，XTTS是一種方式，但是這種方案就比較糾結了，幾乎是不可實現的，源端的資料庫的網路卡過舊，IO能力不足，複製基本上就是7M每秒的速度，對於一個近1T資料量的資料庫做檔案複製，簡直不敢想象。方案雖然可行，但是不可接受。

那麼使用Datapump呢，這個方案想比XTTS就更糾結了，傳輸，匯入都更加耗時。如果保守估計，匯出，傳輸，匯入，整個過程估計得10多個小時，那我就可以直接下班回家了。

還有什麼方案呢，其實還有不少，如果裡面的表不多的話，可以直接使用物化檢視的增量重新整理來玩等。

最後到了我不大擅長的GoldenGate了，最後發現還是這種方式是一種可持續性的，維護時間最短的方案。

首先是全量同步，這個過程可以透過Datapump來完成，為什麼選擇Datapump呢，就因為是邏輯的，而物理的方式有一定的侷限性，可以很輕鬆實現資料的跨版本匯入。

那麼問題來了，備庫怎麼datapump匯出，這個不可行啊，我如果直接Failover了，備庫就不可用了，還得重搭，這個還是有風險的。

如果你這麼想，那就對了，其實可以充分利用閃回資料庫的原理，先Failover，然後Datapump匯出，完成這個工作之後，閃回繼續接受歸檔，就是這個套路。

這個匯入的過程持續10個小時，還是5個小時，都影響不大，因為都是新主庫的操作。

而接下來的事情就需要注意了，那就是主庫端的增量同步。

使用GoldenGate的意義就在於此。

怎麼做增量同步呢，我們在備庫端全量同步的時候需要標記一個檢查點SCN，後續做增量同步就可以基於這個點來做了。

比如在目標端使用OGG同步，指定基於SCN 1887488就可以選擇性同步了。

GGSCI (newtest.oracle.com) 3> start rep_tlbb, aftercsn 1887488

整個過程會保證資料的一致性，而且是一個持續性的同步過程，如果說誇張一些，是零維護時間的遷移式升級。總之，維護時間很短，對於業務端來說是透明的而且完全無感知。