如果有一套環境，業務優先順序很高，伺服器的服役時間比我工作時間都長，現在需要遷移到x86平台，而且經過評估，如果能夠公升級資料庫的軟體版本，可以使用到更多的特性和功能。這套環境的資料量大概是800g,停機維護時間在2個小時的樣子，對於很多公司來說，盡可能縮短維護視窗時間，提前起服就意味著有更多的收入，所以2個小時如果能夠再縮短一些的話，就太好了，這樣乙個需求該怎麼辦?
這裡我刻意可以弱化了資料庫型別，其實這個需求具有一定的普適性，都可以參考借鑑。
而另一方面，我暫且按照oracle為例來說明，過於籠統，可操作性，實踐性不強，實際意義會打折扣。
這個需求是乙個硬骨頭，前前後後幾代dba也是前仆後繼，總算到了非遷不可的地步了。而且因為環境的限制，有一些硬傷，比如主庫承擔不了太大的壓力，網路條件不佳等。所以事兒真不好做，方案也不好來定。
這裡我建議大家先熟悉一下整個資料庫的情況，資料的分布情況之後再結合一些可行方案來得到乙個最合適的方案。
在梳理了初步的方案之後，在這個基礎上再細化了資料的分布情況，我想到了一種相對可控的方案。
這個庫磁碟空間占用有800g,但是不是800g的純資料，還有相當一部分是索引的消耗，經過分析，這個環境90%的資料在屬主使用者上，而索引佔據了近40%的空間，這樣一來實際的資料空間也就在50%左右，最後的10%的資料是一些資料字典資訊，補充輔助的一些資料資訊。
所以這樣一來我們可以把資料分為三類，然後給出相應的解決方案：
索引段資料，索引段的資料其實可以提前進行準備，能夠大大減少遷移過程中的資源消耗，整個過程中不需要同步，自適應即可。
資料字典和其它資訊，這部分資料都是資料字典，許可權資訊，少量的輔助資料等，經過評估這部分資料一次同步後，就不需要反覆同步了。
資料段，這部分資料占用空間400g左右,這個是遷移的關鍵所在。這個資料顯然是需要持續同步的。
這樣一來800g的遷移我們可以先簡化到400g的規格，聽起來難度降低了一半。
我們再來看看這400g資料的情況，大部分的資料都集中在了20個大表裡面，占用的空間遠超95%以上。而一些基礎的表資料大概只占用了5%的比例。
通過這些資訊，我們可以設想400g的資料遷移，大部分資料在20個表裡面，那這個事情可不可以這麼做：
20個大表的資料通過持續的同步來滿足，而其他表的資料則不需要持續同步，在遷移的時候直接匯出匯入即可。
而且更關鍵的是20個表裡面，70%的資料集中在了3個表上，剩下的30%的資訊集中在了17個表上。
我們可以做成彈性的方案，比如使用oracle的物化檢視prebuilt屬性，因為涉及的表很少，直接物化檢視增量重新整理即可。
而3個大表的資料量實在太大，這部分資訊就可以通過ogg來邏輯同步。
有的同學可能會問都用物化檢視增量重新整理得了，這樣一來3個大表的資料同步，資料庫層面沒有可以設定的閾值，控制措施，比如限定流量情況等。所以3個大表是不建議物化檢視增量重新整理來操作的。
而那17個表相對來說資料量較大，幾百mb其實還可以接受的，使用增量重新整理就可以。
或者有的同學說，乾脆都使用ogg同步得了，這個在目前的考慮方案中也是可行的。無非就是基礎的配置上需要提前準備除錯。
遮掩下來，整個的資料遷移其實絕大部分工作都可以提前安排好，到了遷移的時候，只是把5%的資料重新同步即可。
db2跨平台資料庫遷移
現在我們要把這個資料庫遷移到不同的作業系統 比如從aix到linux 我們應該怎麼辦呢？因為作業系統不同，所以使用backup restore命令顯然是不行了。那麼是不是可以使用db2move命令呢？也不行，首先db2move命令沒有辦法遷移索引 外來鍵約束 觸發器，更不能遷移含自增欄位資料的表。那...
SYBASE 資料庫的跨平台遷移
包括兩個方面 資料庫結構的遷移 如表結構 檢視 觸發器等 和資料的遷移 操作步驟如下 1 利用工具 sybase自帶工具或第三方工具 生成以下指令碼備用 createusetye createtable createview createprocedure dropindex createindex...
Qt跨平台的乙個例程
我的同事penk在近期北京的hackathon展示了乙個在多平台的例程。非常多開發人員對這個挺感興趣的。今天我就把這個資源介紹給大家。這是同乙個用qt寫的應用。能夠同一時候在ubuntu destkop。android,ios接ubuntu phone上能夠同一時候執行的乙個例程。在github裡有...