一
企業面臨的困境
當前it系統的軟硬體迭代越來越頻繁，特別是軟體產品，客戶生產系統中採用的軟體都面臨原廠的eos風險。eos即end of support，這是每個客戶的it部門都要面臨的運維風險。當生產系統出現問題卻又得不到原廠售後服務支援的時候，是乙個多麼悲催的事情，其中的麻煩誰遇誰知道，所以說跟著原廠的步伐進行大版本更新公升級乃上上策。這是乙個軟體生命週期管理的課題，軟體大版本的公升級遷移是客戶it運維部門都要接受的重大挑戰，同時也是it運維服務廠商的重大挑戰，當然如果it運維服務廠商有合適的解決方案，那將是重大機遇。
簡而言之，促使客戶進行大版本公升級遷移的兩個根本原因：
eos風險，如果不公升級將得不到原廠官方的技術支援。
新功能新特性的應用，對最新大版本中的某些新特性非常有興趣。
二 行業解決方案
大部分的金融行業客戶使用得最多的是ibm db2資料庫。在網路上關於db2大版本公升級遷移方面的資料並不多，或者說具有指導性建議的文章不多。本文簡單介紹乙個基於cdc複製技術實現db2大版本平穩公升級的案例，希望能夠起到拋磚引玉的作用，達到**交流的目的。
眾所周知，金融行業的客戶對系統要求是7*24小時，對於系統可用性要求非常高，客戶對系統公升級遷移一般會提出以下三個要求：
公升級遷移時間視窗要求在分鐘級別，新舊系統切換時間盡可能短，如5分鐘至10分鐘。
公升級過程中對源資料庫（原生產系統）的效能無影響，要保障原系統不會因為公升級而導致業務影響。
公升級失敗後要求在分鐘級別的時間視窗內回退至原版本執行，並且保障在新系統的變更資料同步回原系統。
如果要滿足以上所有要求，傳統的公升級過程肯定是無法做到的，原因如下：
時間視窗無法滿足，傳統公升級過程至少是30分鐘，甚至更長。
低版本公升級到高版本後不可回退，過程是不可逆的。
一旦應用切到新版本而且有資料入庫，當要切回舊系統版本執行時新資料不能追平。
基於以上原因，那麼只能採用ibm的資料複製方案。將常用的ibm資料複製/同步方案比較如下：
資料複製方案
可靠性/可行性分析 備註
hadr
不適用公升級遷移，源和目標的版本跨度太大時無法搭建hadr
sql replication
無法滿足上述要求，需要在源庫上建立相應的cd表；首次全量複製對源庫有效能影響
q replication
無法滿足上述要求,首次全量複製對源庫有效能影響，即使使用備份還原至目標伺服器，後續增量同步時的日誌lsn很難找到
這裡的lsn是為了定位自上次備份以來的變更資料的事務起點
cdc完全適用，支援異構平台、大版本、雙向複製等
通過bookmark技術，記錄自上次備份以來的lsn號，下次cdc同步時僅需複製增量資料
綜上所述，我們只能選用cdc軟體技術實現。本文的重點就是**基於cdc技術如何實現db2資料庫大版本平穩公升級遷移。cdc的技術突破在於以下兩點：
當首次全量複製同步（源庫-->目標庫）時，可以通過將源庫的備份檔案傳至目標端進行restore. 而不是象傳統方式（傳統做法是每張表先定義然後通過遠端匯出/匯入）做法，這樣可以大大減少網路傳輸開銷，以及減輕源庫抽數帶來的效能的影響。
cdc斷點續傳功能，即bookmark功能可以標識當前的複製斷點，即使源庫在「bookmark」操作後有了新變更，cdc可以捕捉到增量的變更資料，下次複製只要從斷點開始複製資料即可，既節省了全量複製的時間，同時保證了事務的一致性和連續性。比其他複製方案更智慧型和先進。
>
>
>
>
cdc是什麼？
cdc，現在叫iidr（ibm infosphere data replication），是一種基於db2日誌的高效複製解決方案，功能強大，使用靈活，可以實現多種方式、多種用途的資料複製，被廣泛應用於企業報表、災難恢復和高可用性環境中。下圖為cdc的架構示意圖：
技術實現
當了解和熟悉了cdc複製技術的架構和原理之後，就可以開始制定db2大版本公升級遷移的流程和步驟。為了保障文章的簡潔性，流程步驟簡單概述如下：
在源端(假設db2版本為v9.1/v9.5/v9.7)和目標端(假設為v10.5)各自安裝cdc相應軟體。
將源端的最近一次online backup恢復到目標端相應的版本，或者通過ddl建立v10.5版本的空庫。
在cdc管理控制台中配置源和目標端的複製關係（具體操作參閱cdc管理手冊）。
匯出subscription定義，並且備份v10.5庫中cdc的metadata表(ts_開頭的三張表)
在源資料庫上執行dmmarkexternunloadstart，用來標記資料匯出的起始點。
需要重新恢復一次帶有cdc bookmark的全備至目標端，前一次恢復是僅僅為了定義複製關係，本次才是關鍵點。
在源資料庫上執行dmmarkexternunloadend，用來標記資料匯出的結束點。
匯入步驟4中備份的metadata表以及cdc的subscription定義。
將目標端的db2版本逐級公升級至v10.5(ese或purescale)（假設源庫的版本較低，如果為v9.7或以上則忽略此步驟）
定義反向複製關係（目標端至源端的方向），在cdc中定義兩個方向的同步關係，用於可回退到原版本執行。
啟動正向複製（源端至目標端的方向），開始進行增量資料的同步。
停止所有應用程式（停機的時間取決於應用程式的複雜程度）
驗證源和目標端資料一致性（停機的時間取決於資料驗證和校驗的粒度，必須前期做好資料校驗的計畫和流程，否則無法保障資料庫的完整性和一致性）
啟動反向複製（目標端db2高版本至源端db2低版本的方向），當源和目標端資料完全同步後，啟動雙向複製，保障「雙活」情況下資料能完全同步。
系統正式切割，啟動所有應用程式，但必須保障應用程式要麼連線老版本的資料庫，要麼連線是新版本的資料庫。
回退機制和流程的啟動，如果出現極端情況，應用程式完全可以退回原來版本，恢復如初。
三 方案小結
迄今為止這應該是最完美的公升級遷移方案了。
以上的流程和機制保障了db2大版本公升級遷移的平衡，在大版本公升級過程前對源庫無效能影響，公升級過程中僅需要同步複製增量的變更資料，使網路傳輸量最小化，在公升級失敗後也可以輕鬆回退。基於cdc複製技術實現了db2大版本的公升級遷移，讓客戶享受到了ibm db2原廠的售後服務，同時享受到了db2最新版本的新功能、新特性。那麼你還等什麼呢，現在開始制定db2大版本公升級計畫吧！
作者介紹：劉李明
DB2複製表結構及資料
在db2資料庫中，複製已經存在的表的結構及其資料。我們採用兩步走方式 第一步先複製表結構，第二部拷貝資料。第一步 複製表結構 方法一 create table test rate as select from t rate definition only test rate是新錶，t rate是老表...
python 連線db2 大迷糊的部落格
請教個事情，專案需要用python連db2，下了幾個pydb2 1.1.1 1.tar.gz ibm db 0.8.0 py2.5 linux i686.egg。先裝了ibm db 0.8.0 py2.5 linux i686.egg沒問題，然後裝pydb2 1.1.1 1.tar.gz提示 sh ...
DB2中實現等級查詢一
目錄表的資料結構，為了方便，採用了統一的資料型別 create table folder folderid varchar 20 本目錄的標識 parentid varchar 20 父目錄的標識 name varchar 20 目錄名 status varchar 20 目錄狀態 建乙個函式，通過...