關於修改分割槽表的問題總結

在之前的章節中討論了關於修改表分割槽的一些準備工作和操作細則，這個問題的來由有必要說一下。
透過分割槽鍵值發現效能問題   http://blog.itpub.net/23718752/viewspace-1263068/
當時是在做資料遷移的時候發現了一些表，匯入資料比較慢，儘管做了分割槽的並行切分，速度還是很慢，最後檢視資料的分佈時，發現90%左右的資料都分佈到了一個表分割槽上。
最後和開發部門協調，重新調整了分割槽鍵值，從DBA這邊來說，就需要重新來建立分割槽了。


儘管已經考慮了很多的準備工作和可能碰到的問題，還是遇到了一些問題，自己總結一下。
第一個判斷是否是關於備份，當時考慮使用exp來作為一個物理備份，結果在資料匯出的時候，儘管開了多個並行程式同時匯出，但是速度還是很慢。
結果exp還沒有執行到20%，外部表的匯出就完成了。從時間的角度考慮這個物理備份還是考慮有些欠缺，最後的解決方案就是匯出了一個dump,裡面只包含關於表結構，不包含資料，
如果出現問題，也能夠及時的參考和調整。


第二個沒有考慮到的因素就是表空間,當時想資料沒有增加，重新分割槽以後，應該也不會有多大的空間變化，就沒有申請額外的儲存空間，結果在刪除分割槽後，使用split來修改分割槽的時候
開始報一個勁的報錯。提示無法擴充套件空間。
ORA-01658: unable to create INITIAL extent for segment in tablespace xxxxx
碰到這種問題，只得重新來過,如果再根據日誌來逐個分析，也是得不償失，
最後重新估算了需要的表空間，折騰了幾輪才算把問題搞定。


第三個問題是在準備的時候也要考慮到各種可能遇到的情況，如果失敗，還能夠及時的調整。我是專門把分割槽的步驟分為了
以下的幾個步驟。
1)資料清理，--&gt在有完整備份的前提下
2）刪除分割槽
3）檢查刪除分割槽是否成功
4）先刪除分割槽表中分割槽鍵值是一個的。
5）刪除分割槽表中分割槽鍵值是兩個的。
6）檢查分割槽的修改情況是否滿足要求。
這樣的話，任何一個步驟失敗，都可以及時的調整，重新部署。我在碰到了一些問題之後，就及時調整或者重新來做，這樣不會浪費太多時間。


第4個問題就是資料的載入
對於大量的分割槽表資料的載入量還是很大的， 也需要合理的估算時間。這次做的分割槽表資料量都在億級，在資料匯入前也考慮了不少的細節，並行就是一個關鍵的因素。
合理的控制並行資源能夠極大的提高系統的響應速度。
我專門預留了兩個程式，等待其他的程式有提前完成的，然後作為補充，使得系統的處理速度一直處於高效狀態，不至於一開始壓力就太大，速度太慢，後期的時候空閒並行太多，導致系統的資源使用不是很合理。


以下是我在做資料匯入時的一些指標資訊。redo是1G大小，在不到一個小時的時間內切換300多次，載入的速度還是相當的快的。
    GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      11157          2       1024 YES INACTIVE
         2          1      11158          2       1024 NO  CURRENT
         3          1      11155          2       1024 YES INACTIVE
         4          1      11156          2       1024 YES INACTIVE
Redo Switch times per hour                                                   NFTCUS1                                                        2014-Oct-23 13:17:47
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
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
10  22    0    0    0    0    0    0    0    0    0    0    0    0    0    0    1    7    0    0    0    0    0    0    0    0
10  23    0    0    0    0    0    0    0    0    0    0  335  311  155    0    0    0    0    0    0    0    0    0    0    0


第5個問題是關於統計資訊的考慮，這個部分最後使用nohup在後臺收集，可以提前把環境先提供給開發，讓大家都有一個緩衝的時間，根據我的經驗，平均億級的資料收集大概在15-20分鐘左右。
需要提前準備好並行程式。


最後一個問題是關於效能調整的。
可能分割槽工作完成，大部分工作都完成了。但是最重要的工作還是分割槽之後的效能。


這個時候需要藉助awr來仔細的分析一下，到底是哪些地方存在較大的誤差。有些sql語句可能有毫秒級的差別，但是執行的頻率太高，可能導致的執行時間還是有很大的差別，這些可以和開發來做協調，看有些延遲是否能夠接受，當然了我們希望看到的是整體效能得到提高。畢竟付出這麼大的代價，效能下降的厲害，就有些得不償失了。