關於資料遷移，在之前也討論過一些需要注意的地方，可能林林總總列了不少，都是在資料遷移遷移前和遷移時需要注意的。
http://blog.itpub.net/23718752/viewspace-1195364/
我在這個帖子的基礎上進行更多的總結和補充。

資料升級前的測試

-）充分的測試，評估時間，總結經驗,提升效能, 心中有數。
在生產中進行資料的大批次遷移時，充分的測試時必須的。一方面可以根據這些測試積累一些必要的資料作為生產中使用參考，另外一方面可以基於之前的測試，總結經驗，總結不足之處，加入改進，在生產中每一分鐘的改進都是很重要的。

補充：
需要做一些相關的效能測試，在條件允許的情況下在類似的環境中完全模擬，得到一些效能資料，然後不斷的改進，看能夠否有大的提升。
我們在做資料遷移的時候，就是在備份庫中克隆的一套環境，然後在上面做的效能測試，在生產上的步驟方式都一樣，結果在正式升級的時候就能夠做到心中有數。什麼時候需要注意什麼，什麼時候需要做哪些想關的檢查。

完整的備份策略
熱備甚至冷備
    在資料遷移之前進行完整的備份，一定要是全量的。甚至在允許的情況下做冷備都可以。資料的備份越充分，出現問題時就有了可靠的保證。
lob資料型別的備份，做表級的備份（create table nologging....)
    對於lob的資料型別，在使用imp,impdp的過程中，瓶頸都在lob資料型別上了，哪怕表裡的lob資料型別是空的，還是影響很大。
    自己在做測試的時候，使用Imp基本是一秒鐘一千條的資料速度，impdp速度有所提升，但是parallle沒有起作用，速度大概是1秒鐘1萬條的樣子。
    如果在資料的匯入過程中出了問題，如果有完整快速的備份，自己也有了一定的資料保證，要知道出問題之後再從備份庫中匯入匯出，基本上都是很耗費時間的。

補充：
關於lob資料的備份，大家可以根據自己的情況而定，如果使用資料泵來做資料遷移，強烈建議做表級備份，如果出現資料衝突的時候，能夠很方便的排查。
而在系統級的備份，也是很重要的，這個也是整個升級的關鍵，如果出現任何預料之外的情況，我們還可以退回一步。

資料升級前的系統級檢查
1）記憶體檢查
    可以使用top,free -m來做一個檢查，看記憶體的使用情況是否正常，是否有足夠的記憶體空間。
像下面的情況，在同一臺機器上有多個例項，如果能夠最大程度的釋放記憶體給需要的庫，可以考慮把剩下的庫failover到別的伺服器上。或者情況允許的情況下，直接停掉。

àDB instance in the same DB server(PRODB01)

As I remember XXXXX ,XXXX is on other DB server before, is it possible to switch to other DB servers?

> ps -ef|grep smon

oraccbs1 21056 1 0 Aug17 ? 00:00:17 ora_smon_PRODB01

oraaems2 22395 1 0 Aug17 ? 00:00:02 ora_smon_DBM02

oraarcs1 24868 1 0 Aug17 ? 00:00:02 ora_smon_DBC01

oramaes1 26396 1 0 Aug17 ? 00:00:01 ora_smon_DBE01

2）檢查cpu,io情況，檢視iowait是否穩定，保持在較低的一個幅度。
可以使用top,sar命令來檢視或者透過shell指令碼來得到一些系統的負載資訊，及時排除不必要的隱患。
可以檢視iowait的情況，如果超過30%,說明有比較嚴重的io等待了，一般都需要保持在一個很低的比例。

àIOwait

from system level has reduced much, as I remember, it is around 4% before. And vxfs_thread has gone.

top - 12:54:20 up 26 days, 11:51, 8 users, load average: 2.05, 2.22, 2.36

Tasks: 2150 total, 4 running, 2145 sleeping, 0 stopped, 1 zombie

Cpu(s): 5.8%us, 0.4%sy, 0.0%ni, 93.6%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st

Mem: 371307496k total, 187371412k used, 183936084k free, 2043876k buffers

Swap: 377487328k total, 9440k used, 377477888k free, 112921640k cached

3）檢查程式的情況
檢查是否有高cpu消耗的異常程式
檢查是否有殭屍程式
像下面的例子，程式中存在一個殭屍程式，可以檢視倒底是什麼程式，排查後可以殺掉。

top - 16:53:11 up 26 days, 15:50, 9 users, load average: 2.95, 2.61, 2.83

Tasks: 2096 total, 2 running, 2093 sleeping, 0 stopped, 1 zombie

Cpu(s): 5.8%us, 1.1%sy, 0.1%ni, 88.5%id, 4.2%wa, 0.0%hi, 0.2%si, 0.0%st

Mem: 371307496k total, 100558832k used, 270748664k free, 2047600k buffers

Swap: 377487328k total, 9440k used, 377477888k free, 26339800k cached

> ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'

Zs 8739 8745 [sh]

> ps -ef|grep 8739

root 8739 10743 0 00:01 ? 00:00:00 crond

root 8745 8739 0 00:01 ? 00:00:00 [sh]

oraccbs1 20785 6780 0 16:54 pts/5 00:00:00 grep 8739

> ps -ef|grep 8745

root 8745 8739 0 00:01 ? 00:00:00 [sh]

oraccbs1 22222 6780 0 16:54 pts/5 00:00:00 grep 8745

4）是否有crontab的設定
這個檢查太重要了，如果在升級的時候有什麼例行的job在執行，會有很大的影響，可以使用crontab -l來檢視crontab的情況

5）vxfs下的odm是否已經啟用
如果使用的veritas的檔案系統，需要檢查一下odm是否正常啟用。

àODM is enabled.

Oracle instance running with ODM: Veritas 6.0.100.000 ODM Library, Version 2.0

Sun Aug 17 23:24:39 2014

> ps -ef|grep odm

root 10615 1 0 Jul23 ? 00:00:17 [vxodm_ioreap]

root 10616 1 0 Jul23 ? 00:00:00 [vxodm_ioclean]

oraccbs1 24858 28913 0 12:58 pts/9 00:00:00 grep odm

6）IO 簡單測試
從系統角度來考慮，需要保證io的高效性。可以使用iostat,sar等來評估
還可以使用如下的指令碼簡單來測試一下。
time dd if=/dev/zero bs=1M count=204 of=direct_200M

->DD testing, result is expected.

> time dd if=/dev/zero bs=1M count=204 of=direct_200M

204+0 records in

204+0 records out

213909504 bytes (214 MB) copied, 0.401999 seconds, 532 MB/s

real 0m0.404s

user 0m0.001s

sys 0m0.035s

> time dd if=/dev/zero bs=1M count=204 of=direct_200M

204+0 records in

204+0 records out

213909504 bytes (214 MB) copied, 0.424942 seconds, 503 MB/s

real 0m0.433s

user 0m0.000s

sys     0m0.030s

  7）網路頻寬
    網路是很重要的一個因素，資料遷移的時候肯定會從別的伺服器中傳輸大量的檔案,dump等，如果網路太慢，無形中就是潛在的問題。
可以使用scp來進行一個簡單的測試，如果儲存還不錯的話，一般在50M左右/每秒的速度

資料遷移前的準備和系統檢查

相關文章