數(shù)據(jù)遷移中需要考慮的問題

1、數(shù)據(jù)遷移中需要考慮的問題分類：Oracle在生產(chǎn)環(huán)境中，做數(shù)據(jù)遷移需要考慮很多的可能性和場景，盡量排除可能發(fā)生的問題。我自己總結(jié)了下， 大體有如下需要注意的地方。1）充分的測試，評估時(shí)間，總結(jié)經(jīng)驗(yàn)，提升性能在生產(chǎn)中進(jìn)行數(shù)據(jù)的大批量遷移時(shí)，充分的測試是必須的。一方面可以根據(jù)這些測試積累一些必要的數(shù)據(jù) 作為生產(chǎn)中使用參考，另外一方面可以基于之前的測試，總結(jié)經(jīng)驗(yàn)，總結(jié)不足之處，加入改進(jìn)，在生產(chǎn)中 每一分鐘的改進(jìn)都是很重要的。2）完整的備份策略熱備甚至冷備在數(shù)據(jù)遷移之前進(jìn)行完整的備份，一定要是全量的。甚至在允許的情況下做冷備都可以。數(shù)據(jù)的備份 越充分，出現(xiàn)問題時(shí)就有了可靠的保證。lob數(shù)據(jù)類型的備份，

2、做表級的備份（create table nologging.）對于lob的數(shù)據(jù)類型，在使用imp,impdp的過程中，瓶頸都在lob數(shù)據(jù)類型上了，哪怕表里的lob數(shù) 據(jù)類型是空的，還是影響很大。自己在做測試的時(shí)候，使用Imp基本是一秒鐘一千條的數(shù)據(jù)速度，impdp速度有所提升，但是parallle 沒有起作用，速度大概是1秒鐘1萬條的樣子。如果在數(shù)據(jù)的導(dǎo)入過程中出了問題，如果有完整快速的備份，自己也有了一定的數(shù)據(jù)保證，要知道出 問題之后再從備份庫中導(dǎo)入導(dǎo)出，基本上都是很耗費(fèi)時(shí)間的。3）網(wǎng)絡(luò)網(wǎng)絡(luò)帶寬網(wǎng)絡(luò)是很重要的一個(gè)因素，數(shù)據(jù)遷移的時(shí)候肯定會(huì)從別的服務(wù)器中傳輸大量的文件,dump等，如果網(wǎng) 絡(luò)太

3、慢，無形中就是潛在的問題?？梢允褂胹cp來進(jìn)行一個(gè)簡單的測試，如果存儲還不錯(cuò)的話，一般在50M左右/每秒 的速度網(wǎng)絡(luò)臨時(shí)中斷網(wǎng)絡(luò)的問題需要格外重視，可能在運(yùn)行一些關(guān)鍵的腳本時(shí)，網(wǎng)絡(luò)突然中斷，那對于升級就是災(zāi)難，所以在 準(zhǔn)備腳本的時(shí)候，需要考慮到這些場景，保留完整的日志記錄?？梢允褂胣ohup來做外后臺運(yùn)行某些關(guān)鍵的腳本。這樣網(wǎng)絡(luò)斷了以后，還有一線希望。4）完整的日志在數(shù)據(jù)遷移，數(shù)據(jù)升級的時(shí)候，一定要保留完整的日志記錄，這樣如果稍候有問題，也可以及時(shí)查驗(yàn)，也 可以避免很多不必要的紛爭。如果有爭議，可以找出日志來，一目了然。5）存儲存儲也是很重要的一個(gè)方面。從系統(tǒng)角度來考慮，需要保證io的高效性。

4、可以使用iostat,sar等來評估 還可以使用如下的腳本簡單來測試一下。time dd if=/dev/zero bs=1M count=204 of=direct_200M歸檔空間數(shù)據(jù)遷移的時(shí)候會(huì)有大量的日志產(chǎn)生，一定需要保證歸檔空間足夠大，及時(shí)的轉(zhuǎn)移歸檔文件。排除歸檔爆 了以后數(shù)據(jù)的問題，使用sqlloader,impdp等數(shù)據(jù)遷移策略的時(shí)候，如果歸檔出了問題，是很頭疼的問題。表級 nologging如果條件允許，可以考慮對一些相關(guān)的表開啟nologging，在數(shù)據(jù)遷移之后再設(shè)置logging.對速度有一些的提升，如果使用insert /*+append */的時(shí)候，那速度就很明顯了。i

5、ndex 級 nologging數(shù)據(jù)的insert操作，如果沒有index速度很有成倍的提高，但是在生產(chǎn)中可能并不能建議這么做，如果重 建索引的時(shí)候，也需要一定的時(shí)間，還需要一定保證索引和之前一定要沒有任何的差錯(cuò)。所以一般來說， 如果開啟Index的nologging也會(huì)有一定的提升。lob 級 nologging對于lob數(shù)據(jù)類型來說，在允許的條件下，可以設(shè)置為nologging，速度會(huì)有所提升。foreign key外鍵的影響需要重視，如果外鍵存在對于數(shù)據(jù)的插入順序無形中對會(huì)有一定的約束，所以在大批量的數(shù)據(jù) 并發(fā)插入條件下，disable foreign key，可以更加高效，當(dāng)然在ena

6、ble foreign key的時(shí)候需要花費(fèi)一 些時(shí)間，做為數(shù)據(jù)檢查。trigger 的影響tigger在數(shù)據(jù)的dml操作中都有這潛移默化的影響，所以對于trigger最好和開發(fā)部分做確認(rèn)，是否需要 禁用 trigger。materialized view log 的影響有些外部系統(tǒng)可能為了數(shù)據(jù)同步，可能會(huì)在系統(tǒng)中創(chuàng)建一些物化視圖日志，可以和他們做一個(gè)確認(rèn)，刪除 物化視圖日志，減少數(shù)據(jù)插入的時(shí)候物化視圖日志的影響。還有一個(gè)問題就是物化視圖日志會(huì)使rename table等操作無法進(jìn)行。godlengate 的影響goldengate的影響不容小視，需要和部分做一個(gè)確認(rèn)在數(shù)據(jù)遷移之前停掉gold

7、engate相關(guān)的進(jìn)程。主鍵沖突數(shù)據(jù)排除主鍵沖突數(shù)據(jù)的排查是一個(gè)很重要的環(huán)節(jié)，如果之前的準(zhǔn)備工作不到位，到了生產(chǎn)之后，那就是數(shù)據(jù)災(zāi)難。 大半夜修復(fù)數(shù)據(jù)的痛苦真是不言而喻啊。如果數(shù)據(jù)前一部分不給力，你就得給力，想想辦法來排查吧。constraint 級的數(shù)據(jù)不一致這種問題存在而且很隱蔽，比如如下的錯(cuò)誤。就是not null constraint在源schema中不存在，在導(dǎo)入目 標(biāo)庫的時(shí)候出問題了。cannot insert NULL into (xxxx.test_data.TOT_OBLIGATION_PCT)對于這類問題需要和數(shù)據(jù)遷移組協(xié)調(diào)，盡可能保證constraint的一致性。undo的考慮對于數(shù)據(jù)遷移來說，對于undo的