datapump跨平臺升級遷移的對比測試和優化
目前計劃對跨平臺的資料庫環境進行遷移,一來降低運維成本,二來更加可控。其實對於很多機器來說,如果機器跑了很多年,一直沒有重啟過,那麼時間長了,一個直觀的感受就是穩定,這也是小機口碑遠遠好於PC的一個重要原因吧,但是如果機器有一天出了問題,那麼可能就會讓大家坐立不安。其實這也能夠折射出很多的運維管理的一些誤區,很多問題沒有發生,不代表不會發生,這個時候墨菲定律就是大家公認的運維法則了。而且小機雖好,但是超過了服役期,那麼就有可能是定時炸彈,畢竟服役時間遠遠大於預期,於情於理都能說得通了。
當然也綜合評估了很多的原因,一來是datapump遷移步驟相對簡單,很多複雜的schema物件可以直接通過匯入來完成,如果是全庫匯入,那麼可操心的事情就更少了。使用者,角色,表空間等等全部都有。而且另外一個方面是考慮到datapump的遷移模式,這種邏輯遷移完全可以支援跨平臺跨資料庫版本,所以靈活性很高。最後就是效能了,在中小型的資料遷移中還是留有一席之地的。
那麼採用了datapump,我們做跨平臺的遷移,之前的測試不到200G的資料遷移大概需要1個小時左右的時間,我們需要在這個基礎上進行更多的優化,儘可能縮短視窗時間。
所以就有以下的幾個地方需要考慮。
redo的大小,
資料庫的歸檔模式
IO的優化
資料庫級別的優化
對於這幾個方面,自己也是做了一些工作,當然也做了詳細的對比測試,對比了機械硬碟和PCIE-SSD在同樣資料量的情況下的資料遷移效能資料。
為了能夠多次重現對比測試的效果,採用了初始化的資料庫環境做冷備,然後在其上部署新的資料結構(表空間等),然後使用datapump匯入資料。
大體的步驟羅列如下:
系統級核心引數設定和修改 --
重新建庫 --
資料庫引數設定和修改 redo設定為500M --
冷備,或者rman備份 --
部署變更後的資料結構資訊
機械硬碟使用datapump載入資料
冷備恢復
部署變更後的資料結構資訊,切換到SSD
SSD使用datapump載入資料
遷移完畢,重啟設定歸檔模式
完善檢查指令碼(dblink檢查 )
所以步驟已經很清晰了,我們就先打好基礎,然後開始對比測試。
1)系統級核心引數設定和修改
這個可以考慮關閉NUMA,設定hugepage,調整資源使用(/etc/security/limits.conf)
2)重新建庫
使用dbca silent模式建庫,當然需要重點考慮字符集,還有redo的設定。一個簡單的例子如下:
dbca -silent -createDatabase -templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname testdb -sid testdb -characterSet ZHS16GBK -redoLogFileSize 500 -nationalCharacterSet AL16UTF16
3)資料庫引數設定和修改
比如在一個64G的環境中,我考慮的資料庫引數變更如下,暫不考慮隱含引數的調整。
alter system set sga_max_size=40G scope=spfile;
alter system set sga_target=40G scope=spfile;
alter system set shared_pool_size=10G scope=spfile;
alter system set session_cached_cursors=200 scope=spfile;
alter system set deferred_segment_creation=false scope=spfile;
alter system set sec_case_sensitive_logon=false scope=spfile;
alter system set db_recovery_file_dest_size=200G scope=spfile;
alter system set open_cursors=1000 scope=spfile;
alter system set processes=3000 scope=spfile;
alter system set db_writer_processes=2 scope=spfile;
alter system set resource_limit=true scope=spfile;
4) 冷備,或者rman備份
然後做一個完整的冷備,尤其注意要備份控制檔案。
5)部署變更後的資料結構資訊
是否表空間,資料檔案存在一些路徑差異,需要初始化這些空間的設定。
6)機械硬碟使用datapump載入資料
使用datapump載入資料,得到基本的統計資訊
7)冷備恢復
測試完畢,開始恢復資料庫,把資料庫都切換到SSD上去
8)部署變更後的資料結構資訊,切換到SSD
重新部署資料結構的變化資訊
9)SSD使用datapump載入資料
使用datapump來做完全一致的資料匯入測試
10)遷移完畢,重啟設定歸檔模式
11)完善檢查指令碼(dblink檢查 )
當然這個過程中也著實準備了不少的指令碼,方便工作,而且對於測試的步驟做了一些簡單的總結。
當然測試的結果也是很有差距的,使用PCIE-SSD的速度可以比機械硬碟提高一倍,如果在非歸檔模式下,速度還能提高一倍。
當然也綜合評估了很多的原因,一來是datapump遷移步驟相對簡單,很多複雜的schema物件可以直接通過匯入來完成,如果是全庫匯入,那麼可操心的事情就更少了。使用者,角色,表空間等等全部都有。而且另外一個方面是考慮到datapump的遷移模式,這種邏輯遷移完全可以支援跨平臺跨資料庫版本,所以靈活性很高。最後就是效能了,在中小型的資料遷移中還是留有一席之地的。
那麼採用了datapump,我們做跨平臺的遷移,之前的測試不到200G的資料遷移大概需要1個小時左右的時間,我們需要在這個基礎上進行更多的優化,儘可能縮短視窗時間。
所以就有以下的幾個地方需要考慮。
redo的大小,
資料庫的歸檔模式
IO的優化
資料庫級別的優化
對於這幾個方面,自己也是做了一些工作,當然也做了詳細的對比測試,對比了機械硬碟和PCIE-SSD在同樣資料量的情況下的資料遷移效能資料。
為了能夠多次重現對比測試的效果,採用了初始化的資料庫環境做冷備,然後在其上部署新的資料結構(表空間等),然後使用datapump匯入資料。
大體的步驟羅列如下:
系統級核心引數設定和修改 --
重新建庫 --
資料庫引數設定和修改 redo設定為500M --
冷備,或者rman備份 --
部署變更後的資料結構資訊
機械硬碟使用datapump載入資料
冷備恢復
部署變更後的資料結構資訊,切換到SSD
SSD使用datapump載入資料
遷移完畢,重啟設定歸檔模式
完善檢查指令碼(dblink檢查 )
所以步驟已經很清晰了,我們就先打好基礎,然後開始對比測試。
1)系統級核心引數設定和修改
這個可以考慮關閉NUMA,設定hugepage,調整資源使用(/etc/security/limits.conf)
2)重新建庫
使用dbca silent模式建庫,當然需要重點考慮字符集,還有redo的設定。一個簡單的例子如下:
dbca -silent -createDatabase -templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname testdb -sid testdb -characterSet ZHS16GBK -redoLogFileSize 500 -nationalCharacterSet AL16UTF16
3)資料庫引數設定和修改
比如在一個64G的環境中,我考慮的資料庫引數變更如下,暫不考慮隱含引數的調整。
alter system set sga_max_size=40G scope=spfile;
alter system set sga_target=40G scope=spfile;
alter system set shared_pool_size=10G scope=spfile;
alter system set session_cached_cursors=200 scope=spfile;
alter system set deferred_segment_creation=false scope=spfile;
alter system set sec_case_sensitive_logon=false scope=spfile;
alter system set db_recovery_file_dest_size=200G scope=spfile;
alter system set open_cursors=1000 scope=spfile;
alter system set processes=3000 scope=spfile;
alter system set db_writer_processes=2 scope=spfile;
alter system set resource_limit=true scope=spfile;
4) 冷備,或者rman備份
然後做一個完整的冷備,尤其注意要備份控制檔案。
5)部署變更後的資料結構資訊
是否表空間,資料檔案存在一些路徑差異,需要初始化這些空間的設定。
6)機械硬碟使用datapump載入資料
使用datapump載入資料,得到基本的統計資訊
7)冷備恢復
測試完畢,開始恢復資料庫,把資料庫都切換到SSD上去
8)部署變更後的資料結構資訊,切換到SSD
重新部署資料結構的變化資訊
9)SSD使用datapump載入資料
使用datapump來做完全一致的資料匯入測試
10)遷移完畢,重啟設定歸檔模式
11)完善檢查指令碼(dblink檢查 )
當然這個過程中也著實準備了不少的指令碼,方便工作,而且對於測試的步驟做了一些簡單的總結。
當然測試的結果也是很有差距的,使用PCIE-SSD的速度可以比機械硬碟提高一倍,如果在非歸檔模式下,速度還能提高一倍。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2088965/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- datapump跨平臺升級遷移的對比測試和最佳化
- datapump跨平臺升級遷移的總結
- 同位元組序跨平臺資料庫遷移和升級的測試資料庫
- 遷移式升級的測試
- 一個跨平臺資料遷移的方案優化優化
- 遷移式升級的測試(二)
- 遷移式升級的測試(三)
- 測試環境的遷移式升級和資料整合
- Oracle 10g同位元組序跨平臺遷移的測試Oracle 10g
- 移動 App 雲測試平臺的對比與分析APP
- ORACLE11G從WINDOWS到LINUX跨平臺遷移並升級OracleWindowsLinux
- ORACLE 跨平臺遷移方法Oracle
- 跨 OS 平臺遷移 Oracle DBOracle
- 跨平臺遷移支援檢視
- 移動跨平臺方案對比:WEEX、React Native、Flutter和PWAReact NativeFlutter
- 測試平臺後端優化後端優化
- Oracle跨平臺遷移的簡單總結Oracle
- 使用RMAN完成跨平臺資料遷移
- 利用RMAN跨平臺遷移資料庫資料庫
- rman進行跨平臺資料遷移
- 跨平臺遷移oracle資料庫指南Oracle資料庫
- 傳真系統的跨平臺相容和更換升級
- zt 跨平臺 跨版本 大規模資料遷移
- expdp/impdp跨版本升級遷移問題總結
- Grafana的版本升級和資料遷移Grafana
- 【DATAPUMP】使用DataPump遷移Oracle資料庫Oracle資料庫
- Apifox(1)比postman更優秀的介面自動化測試平臺APIPostman
- 大型資料庫跨平臺遷移總結資料庫
- 對比測試工具平臺讓財務測試飛起來
- 【版本升級】PerfDog新增多維度測試報告對比功能、iOS電量測試功能升級測試報告iOS
- 12c跨平臺完成PDB的備份遷移
- 資料庫中跨平臺遷移方法介紹資料庫
- [zt]跨平臺表空間傳輸 (DB遷移)
- RMAN同位元組序跨平臺跨版本遷移資料庫資料庫
- 移動端 UI 自動化測試框架對比UI框架
- flutter跨平臺開發之App升級方案FlutterAPP
- PR效能測試工具升級到全鏈路效能測試與分析平臺
- API自動化測試平臺,高效實現對API的自動化測試API