資料遷移中的資料庫檢查和建議
關於資料遷移，在之前也討論過一些需要注意的地方，可能林林總總列了不少，都是在資料遷移遷移前和遷移時需要注意的。
http://blog.itpub.net/23718752/viewspace-1195364/
http://blog.itpub.net/23718752/viewspace-1254945/
我在這些帖子的基礎上進行更多的總結和補充。
資料庫級的檢查和建議
1)引數檢查
有些引數是需要在資料遷移前臨時做變更的，有些是效能相關的，需要考慮。
log_buffer在資料匯入的過程中會有極高的消耗，如果併發數夠多，對控制檔案的scn更新也有一定的影響，根據測試情況抓取addm報告，得到一個比較適合的lob_buffer值
àDB parameters
SQL> show parameter log_buffer
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_buffer integer 31252480
關於pga的調整可以根據系統的情況適當加大，在資料遷移完成之後改回原值也可以。
SQL> show parameter pga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 6G
關於buffer_cache的調整可以根據系統的情況適當加大，一般最好能在sga的範圍之內儘可能加大，在資料遷移完成之後改回原值也可以。
SQL> show parameter db_cache
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_cache_advice string ON
db_cache_size big integer 11872M
關於非同步io在11g是預設開啟的，不過filesystem_options一般都建議開啟
SQL> show parameter filesys
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
filesystemio_options string SETALL
SQL> show parameter asy
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
disk_asynch_io boolean TRUE
tape_asynch_io boolean TRUE
2)表空間評估
表空間的情況，根據資料分佈預估資料空間的情況，保留一定的額外空間。最好能富裕30%以上，畢竟資料遷移的過程中沒空間了還是很要命的。
3)歸檔頻率
歸檔的頻率也是衡量系統負載的一個很直觀的方法。
檢視歸檔的在一個小時內切換多少次，可以檢視最近兩週左右的情況，這樣在資料遷移的時候能夠有一個很清晰的評估。
比如下面的庫，切換頻率還是比較低的，日誌為1G大小，在半夜的時候因為備份，會有比較多的日誌切換。
DBNAME TIME_STAMP
--------- --------------------
CUST01 2014-Aug-19 23:46:03
GROUP# THREAD# SEQUENCE# MEMBERS SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
1 1 23289 2 1024 YES INACTIVE
2 1 23290 2 1024 YES INACTIVE
3 1 23291 2 1024 YES INACTIVE
4 1 23292 2 1024 NO CURRENT
Redo Switch times per hour xxxxxx 2014-Aug-19 23:46:03
MON DA 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08 05 3 25 1 1 6 8 1 1 3 1 1 3 5 2 1 3 2 3 2 3 1 1 7 0
08 06 0 0 0 0 0 0 0 0 0 1 0 1 1 3 6 3 4 2 2 2 2 1 12 0
08 07 0 2 2 2 12 19 2 1 3 3 4 2 2 2 2 3 5 20 14 3 11 2 4 0
08 08 5 1 11 25 4 2 2 2 3 3 2 4 12 3 6 13 2 2 2 3 1 1 3 1
08 09 0 5 0 1 0 3 3 1 21 3 3 2 1 2 2 2 1 2 2 1 1 1 1 1
08 10 2 0 0 17 0 4 0 1 1 2 1 1 2 1 2 2 1 2 2 1 1 4 1 1
08 11 2 1 16 3 0 0 0 1 1 1 1 2 2 1 2 2 2 2 2 2 1 1 2 2
08 12 5 2 17 1 0 1 0 1 1 1 2 2 2 2 1 2 2 2 2 1 1 2 1 2
08 13 2 0 1 20 0 1 0 1 1 3 2 2 3 2 1 3 2 8 5 2 1 1 1 6
08 14 2 1 0 17 0 2 1 1 2 6 1 7 1 2 1 4 1 2 2 3 1 1 4 2
08 15 1 2 0 7 0 1 0 1 1 2 3 4 2 3 1 2 3 6 2 2 1 1 4 1
08 16 2 2 5 6 22 1 0 1 1 5 1 2 1 2 2 6 10 4 1 5 2 1 1 1
08 17 3 6 1 1 0 1 0 1 1 2 2 1 2 3 1 25 10 4 2 2 1 2 0 1
08 18 0 0 2 55 0 1 0 1 3 2 2 2 2 2 2 2 2 2 1 3 1 1 1 1
08 19 2 18 0 1 0 1 0 1 3 2 1 3 1 3 1 13 5 2 3 2 1 0 0 0
看一下資料遷移的時候的情況,在資料遷移的工程中，幾乎跑到了極致，一個小時切換300多次。
GROUP# THREAD# SEQUENCE# MEMBERS SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
1 1 23813 2 1024 YES ACTIVE
2 1 23814 2 1024 NO CURRENT
3 1 23811 2 1024 YES INACTIVE
4 1 23812 2 1024 YES ACTIVE
Redo Switch times per hour CUST01 2014-Aug-20 02:08:17
MON DA 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08 05 0 0 1 1 6 8 1 1 3 1 1 3 5 2 1 3 2 3 2 3 1 1 7 0
08 06 0 0 0 0 0 0 0 0 0 1 0 1 1 3 6 3 4 2 2 2 2 1 12 0
08 07 0 2 2 2 12 19 2 1 3 3 4 2 2 2 2 3 5 20 14 3 11 2 4 0
08 08 5 1 11 25 4 2 2 2 3 3 2 4 12 3 6 13 2 2 2 3 1 1 3 1
08 09 0 5 0 1 0 3 3 1 21 3 3 2 1 2 2 2 1 2 2 1 1 1 1 1
08 10 2 0 0 17 0 4 0 1 1 2 1 1 2 1 2 2 1 2 2 1 1 4 1 1
08 11 2 1 16 3 0 0 0 1 1 1 1 2 2 1 2 2 2 2 2 2 1 1 2 2
08 12 5 2 17 1 0 1 0 1 1 1 2 2 2 2 1 2 2 2 2 1 1 2 1 2
08 13 2 0 1 20 0 1 0 1 1 3 2 2 3 2 1 3 2 8 5 2 1 1 1 6
08 14 2 1 0 17 0 2 1 1 2 6 1 7 1 2 1 4 1 2 2 3 1 1 4 2
08 15 1 2 0 7 0 1 0 1 1 2 3 4 2 3 1 2 3 6 2 2 1 1 4 1
08 16 2 2 5 6 22 1 0 1 1 5 1 2 1 2 2 6 10 4 1 5 2 1 1 1
08 17 3 6 1 1 0 1 0 1 1 2 2 1 2 3 1 25 10 4 2 2 1 2 0 1
08 18 0 0 2 55 0 1 0 1 3 2 2 2 2 2 2 2 2 2 1 3 1 1 1 1
08 19 2 18 0 1 0 1 0 1 3 2 1 3 1 3 1 13 5 2 3 2 1 1 0 0
08 20 303 212 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
4）重啟資料庫，釋放session，停掉listener
一般在資料遷移之前，最好能夠停掉相關的服務，比較直接的方式就是重啟資料庫，可以很快的清除系統中的一些Inactive session和客戶端連結的session
根據自己的情況來評估，如果庫的高可用性比較高，可以手工清理session。
5）parallel的選擇
這個部分我的感觸很深，比如資料庫伺服器裡有40個cpu，那麼一般預設一個cpu對應兩個並行，那麼就能支援大概80多個，還需要考慮系統的負載。
對於比較大的表適用一些並行度較高的操作，如果表本來很小，可以不用開啟，或者開啟很低的並行，要不得不償失，對於分割槽表，還是比較糾結的，因為自身使用並行有一些限制。而且如果做全表插入，會有和分割槽數相當的鎖，開啟的並行很可能不會適用。
6）undo的考慮
對於資料遷移來說，對於undo的空間使用來說是極大的挑戰，可能在Impdp的時候出了Undo的問題，那就是極為奔潰的問題了。
還要考慮undo_retention的設定，可以在資料遷移之前可以把retention調低一些，保證undo的使用率足夠用，然後在升級之後恢復設定。
6）歸檔空間
資料遷移的時候會有大量的日誌產生，一定需要保證歸檔空間足夠大，及時的轉移歸檔檔案。排除歸檔爆了以後資料的問題，使用sqlloader,impdp等資料遷移策略的時候，如果歸檔出了問題，是很頭疼的問題。如果可以的話，可以申請臨時加入一些檔案空間，在資料遷移之後把空間大小恢復。
7）表級nologging
如果條件允許，可以考慮對一些相關的表開啟nologging，在資料遷移之後再設定logging.
對速度有一些的提升，如果使用insert /*+append */的時候，那速度就很明顯了。
8）index級nologging
資料的insert操作，如果沒有index速度很有成倍的提高，但是在生產中可能並不能建議這麼做，如果重建索引的時候，也需要一定的時間，還需要一定保證索引和之前一定要沒有任何的差錯。所以一般來說，如果開啟Index的nologging也會有一定的提升。
9）lob級nologging
對於lob資料型別來說，在允許的條件下，可以設定為nologging，速度會有所提升。
10）foreign key
外來鍵的影響需要重視，如果外來鍵存在對於資料的插入順序無形中對會有一定的約束，所以在大批次的資料併發插入條件下，disable foreign key，可以更加高效，當然在enable foreign key的時候需要花費一些時間，做為資料檢查。
11）trigger的影響
tigger在資料的dml操作中都有這潛移默化的影響，所以對於trigger最好和開發部分做確認，是否需要禁用trigger
要不很可能在資料遷移之後發現一些莫名其貌的資料多出來了。
12）materialized view log的影響
有些外部系統可能為了資料同步，可能會在系統中建立一些物化檢視日誌，可以和他們做一個確認，刪除物化檢視日誌，減少資料插入的時候物化檢視日誌的影響，
還有一個問題就是物化檢視日誌會使rename table等操作無法進行。
13）godlengate的影響
goldengate的影響不容小視，需要和部分做一個確認在資料遷移之前停掉goldengate相關的程式。
14)資料統計資訊的收集
資料遷移之後會有大量的資料變化，這個時候需要考慮收集統計資訊，可以開啟多個session做並行的收集。
以下是在做資料遷移的時候，分10個session並行收集統計資訊的top資訊，cpu的使用率已經達到了極致，收集工作不會持續太久，一般在一個小時的樣子。不過可以同時做一些相關的檢查了。
top - 02:21:54 up 28 days, 1:19, 21 users, load average: 37.15, 22.01, 12.09
Tasks: 927 total, 27 running, 897 sleeping, 2 stopped, 1 zombie
Cpu(s): 62.6%us, 3.1%sy, 0.0%ni, 33.5%id, 0.0%wa, 0.2%hi, 0.6%si, 0.0%st
Mem: 371307496k total, 337238216k used, 34069280k free, 1259404k buffers
Swap: 377487328k total, 9440k used, 377477888k free, 266625964k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4602 oraccbs1 19 0 18.3g 132m 28m R 93.9 0.0 1:53.45 ora_p027_CUST01
4580 oraccbs1 19 0 18.3g 132m 28m R 91.6 0.0 2:05.36 ora_p026_CUST01
4612 oraccbs1 16 0 18.3g 132m 28m S 88.3 0.0 2:38.77 ora_p032_CUST01
4604 oraccbs1 16 0 18.3g 129m 25m R 87.6 0.0 1:59.36 ora_p028_CUST01
4616 oraccbs1 16 0 18.3g 132m 29m R 84.4 0.0 2:03.56 ora_p033_CUST01
23619 oraccbs1 18 0 18.2g 28m 21m R 82.7 0.0 1:35.33 ora_p042_CUST01
4606 oraccbs1 16 0 18.3g 132m 28m R 82.4 0.0 2:13.57 ora_p029_CUST01
25504 oraccbs1 18 0 18.2g 28m 23m R 81.4 0.0 1:00.60 ora_p046_CUST01
10342 oraccbs1 18 0 18.3g 129m 26m R 81.1 0.0 0:46.80 ora_p062_CUST01
23621 oraccbs1 18 0 18.2g 38m 32m R 80.4 0.0 1:38.34 ora_p043_CUST01
23600 oraccbs1 18 0 18.2g 31m 25m R 79.4 0.0 1:44.57 ora_p040_CUST01
31081 oraccbs1 17 0 18.2g 33m 20m D 78.7 0.0 2:43.19 ora_p003_CUST01
4620 oraccbs1 25 0 18.3g 129m 24m R 78.4 0.0 2:33.77 ora_p035_CUST01
4618 oraccbs1 17 0 18.3g 129m 24m D 78.1 0.0 2:31.58 ora_p034_CUST01
31079 oraccbs1 16 0 18.2g 36m 23m R 77.1 0.0 2:40.58 ora_p002_CUST01
6167 oraccbs1 18 0 18.3g 132m 28m S 74.5 0.0 0:36.50 ora_p056_CUST01
25506 oraccbs1 18 0 18.2g 26m 20m R 72.2 0.0 0:59.59 ora_p047_CUST01
23602 oraccbs1 18 0 18.2g 28m 21m R 71.2 0.0 1:47.88 ora_p041_CUST01
23623 oraccbs1 18 0 18.2g 28m 21m R 71.2 0.0 0:43.13 ora_p044_CUST01
6209 oraccbs1 18 0 18.3g 113m 19m D 69.5 0.0 0:38.34 ora_p057_CUST01
23625 oraccbs1 18 0 18.2g 32m 25m R 69.5 0.0 0:44.14 ora_p045_CUST01
10344 oraccbs1 18 0 18.3g 132m 28m S 67.9 0.0 0:46.73 ora_p063_CUST01
30746 oraccbs1 16 0 18.2g 23m 19m R 67.5 0.0 2:16.49 ora_p018_CUST01
25537 oraccbs1 16 0 18.2g 22m 18m R 64.6 0.0 0:49.59 ora_p048_CUST01
30748 oraccbs1 16 0 18.2g 24m 19m D 63.3 0.0 2:16.43 ora_p019_CUST01
25539 oraccbs1 16 0 18.2g 21m 18m D 62.9 0.0 0:49.08 ora_p049_CUST01
19872 oraccbs1 18 0 18.2g 26m 22m R 52.4 0.0 1:23.81 ora_p007_CUST01
19870 oraccbs1 18 0 18.2g 27m 23m R 52.1 0.0 1:43.02 ora_p006_CUST01
30760 oraccbs1 16 0 18.2g 24m 20m D 46.1 0.0 2:02.59 ora_p022_CUST01
25541 oraccbs1 16 0 18.2g 22m 17m R 44.5 0.0 0:53.93 ora_p050_CUST01
25543 oraccbs1 16 0 18.2g 21m 17m D 44.5 0.0 0:55.90 ora_p051_CUST01
30758 oraccbs1 16 0 18.2g 24m 19m R 41.8 0.0 2:07.19 ora_p021_CUST01
30756 oraccbs1 16 0 18.2g 24m 20m R 40.2 0.0 2:09.89 ora_p020_CUST01
30762 oraccbs1 16 0 18.2g 24m 20m R 39.9 0.0 1:52.12 ora_p023_CUST01
22568 oraccbs1 18 0 18.2g 20m 15m R 35.6 0.0 0:01.68 ora_p064_CUST01
1492 oraccbs1 15 0 18.2g 23m 19m S 28.0 0.0 0:15.01 ora_p053_CUST01
22570 oraccbs1 18 0 18.2g 22m 17m D 27.0 0.0 0:01.51 ora_p065_CUST01
同時及時檢視收集的進度，根據日誌或者程式情況。
> ps -ef|grep sqlplus
oraccbs1 853 18167 0 02:26 pts/7 00:00:00 grep sqlplus
oraccbs1 1486 18167 0 02:19 pts/7 00:00:00 sqlplus
oraccbs1 6099 18167 0 02:20 pts/7 00:00:00 sqlplus
oraccbs1 9260 25974 0 02:14 pts/5 00:00:00 sqlplus
oraccbs1 9932 18167 0 02:20 pts/7 00:00:00 sqlplus
oraccbs1 15320 18167 0 02:18 pts/7 00:00:00 sqlplus
oraccbs1 19862 18167 0 02:15 pts/7 00:00:00 sqlplus
oraccbs1 23615 18167 0 02:18 pts/7 00:00:00 sqlplus
oraccbs1 25533 18167 0 02:19 pts/7 00:00:00 sqlplus
oraccbs1 30209 18167 0 02:19 pts/7 00:00:00 sqlplus
oraccbs1 30498 18167 0 02:16 pts/7 00:00:00 sqlplus
14)申請較大的mount point
資料遷移的時候往往需要臨時的掛載點存放dump檔案，這個需要提前申請和準備。
像下面的情況，一定得提前檢查保證有足夠的許可權。
àShared mount point permission:
> touch testfile
touch: cannot touch `testfile': Permission denied
15)檢視資料的負載情況
提前檢視資料庫的執行情況，是否已經有過高的負載，及時進行排查。
以下是資料遷移的時候資料庫負載情況。在資料遷移之後就馬上恢復了正常。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BEGIN_TIME------------------------- END_TIME--------------------------- ELAPSED_TIME- BTIME----- WORKLOAD_PER--------
----------------------------------- ----------------------------------- ------------- ---------- --------------------
14134 ** 20-AUG-14 12.00.05.845 AM 14135 ** 20-AUG-14 01.00.10.524 AM 60.078 1170.81 1948%
14135 ** 20-AUG-14 01.00.10.524 AM 14136 ** 20-AUG-14 02.00.12.741 AM 60.037 612.2 1019%
14136 ** 20-AUG-14 02.00.12.741 AM 14137 ** 20-AUG-14 03.00.14.846 AM 60.035 745.48 1241%
14137 ** 20-AUG-14 03.00.14.846 AM 14138 ** 20-AUG-14 04.00.16.889 AM 60.034 72.05 120%
14138 ** 20-AUG-14 04.00.16.889 AM 14139 ** 20-AUG-14 05.00.19.070 AM 60.036 50.53 84%
提前準備好一些awr，ash之類的報告，作為一些備份和適當的參考材料
14139 ** 20-AUG-14 05.00.19.070 AM 14140 ** 20-AUG-14 06.00.21.069 AM 60.033 28.27 47%
15)完整的日誌和報告
在資料遷移，資料升級的時候，一定要保留完整的日誌記錄，這樣如果稍候有問題，也可以及時查驗，也可以避免很多不必要的紛爭。如果有爭議，可以找出日誌來，一目瞭然。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8494287/viewspace-1347052/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- ThinkPHP5.1 中的資料庫遷移和資料填充PHP資料庫
- 資料遷移前的準備和系統檢查
- 資料庫查詢和資料庫(MySQL)索引的最佳化建議資料庫MySql索引
- 資料庫遷移資料庫
- 資料庫-oracle-資料庫遷移資料庫Oracle
- 檢測資料庫遷移準確性資料庫
- [zt]prebuilt 物化檢視遷移資料庫UI資料庫
- 【遷移】使用rman遷移資料庫資料庫
- Oracle資料庫資料遷移流程Oracle資料庫
- 資料庫調優和資料遷移是如何影響資料庫的RY資料庫
- Oracle資料庫（DataGuard）遷移方案（中）Oracle資料庫
- EF 中多個資料庫遷移資料庫
- 資料庫遷移 ：理解資料庫
- laravel資料庫遷移Laravel資料庫
- Odoo遷移資料庫Odoo資料庫
- redis資料庫遷移Redis資料庫
- Cacti 遷移資料庫資料庫
- 資料庫遷移方案資料庫
- ORACLE資料庫遷移Oracle資料庫
- 遷移資料庫成功！資料庫
- 建立資料庫遷移資料庫
- 雲資料庫管理與資料遷移資料庫
- 遷移已存在的資料庫到ASM中資料庫ASM
- 海量資料遷移之誤操作和防範建議
- 資料庫檔案的遷移資料庫
- Laravel資料庫遷移和填充（支援中文）Laravel資料庫
- ORACLE資料庫切換和遷移方案Oracle資料庫
- 資料庫遷移神器——Flyway資料庫
- 遷移MySQL 5.7資料庫MySql資料庫
- 用rman遷移資料庫資料庫
- 資料庫遷移手記資料庫
- django資料庫遷移-15Django資料庫
- SQL Server資料庫遷移SQLServer資料庫
- mysql資料庫遷移 mysqldumpMySql資料庫
- 遷移資料庫到ASM資料庫ASM
- dm資料庫遷移命令資料庫
- 海量資料遷移之衝突資料篩查
- Oracle資料庫（資料泵）遷移方案（上）Oracle資料庫