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

關於資料遷移，在之前也討論過一些需要注意的地方，可能林林總總列了不少，都是在資料遷移遷移前和遷移時需要注意的。
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左右/每秒 的速度