知識星球精彩預告：第八屆資料技術嘉年華大會將於2018年11月16日~17日在北京市朝陽區東三環中路61號富力萬麗酒店盛大開啟。本次大會邀請網際網路領先企業的資料庫專家，國產資料庫的領軍人物，雲技術等領域的知名人士，圍繞資料、智慧、連結組織前沿議題，倡導以智慧智慧演演算法應用，發掘資料價值，以技術將企業連結到未來的戰略制高點！
社群專屬福利（99.9%的人不知道）：一分錢全場通票等你搶
本文來源於讀者投稿，作者在此分享線上重定義生產環境大表分割槽的慘烈踩雷記錄，感謝投稿，歡迎大家投稿分享自己日常中“難忘”的解決過程。
01
任務與方案
公司有一批大表需要分割槽，由於業務是24X7，所以停服是不可能的，只能考慮線上重定義。線上重定義推出已經很久了（不算新功能），但在生產上，還是沒用過，在測試環境進行模擬測試，很順利，速度也很快，幾千萬的表，十幾分鐘就完成了，於是方案就這樣敲定了；
02
開局
先從一張小表（1億記錄），按以下步驟：
第一步、空間準備、建立中間表（先分好區）、檢測是否可線上重定義；這個是準備工作；
第二步、啟動重定義（start_redef),這個會建立一些物化檢視等物件，然後插入當前記錄到中間表，這一步比較耗時間，如果開8個並行，一般150G的表15分鐘左右；
第三步、複製索引、約束、觸發器、統計資訊等物件(copy_dep)；這個也比較耗時，取決於表的大小與索引的多少，以150G的表，8個並行為例，索引約5分鐘一個，按10個索引算，這一步要50分鐘；
第四步、資料同步(sync_inter)，原理是新的插入與更新都記錄在物化檢視中，然後同步到中間表去，如果不做這一步，切換時也會做這一個動作的；
第五步、把原表與中間表做一個調換(Finish_redef)，這一步肯定會鎖表的，所以可以預見是有阻塞會話風險的，而且也未必一定能成功；
如果不成功或者中止了的話，就還有第六步:回退（Abort_redef),這一步目的是回滾到最初的狀態，這樣才會刪除物化檢視等中間物件，才可以重新進行重定義；
這些算是標準的步驟，但實際根據生產環境的情況（比如存在ogg複製），還需要做以下調整：
開始之前，最好是排除了中間表與物化表的複製，因為量太大，容易造成複製延時很長，寧可在標的環境也做一次重定義，如果能接受，也可以不排除；
在完成切換之後，要馬上重新加一下add trandata table_name,因為中間表切成了業務表，相當於是一個新表，不加的話，就會造成只有插入的記錄能複製，而更新的記錄的不能，時間隔得越久，需要修複的資料可能越多；
在資料同步之前，最好給中間表進行一次表分析，可以避免同步時走錯執行計劃；
按照以上步驟，前面幾個1億左右的小表都順利地完成了分割槽切換，開局還算不錯；
03
第一個雷：資料同步導致的鎖
完成了小表，便接著處理中等大小的表（1億-10億,50G-200G),開始時間都放在晚上22：00，但操作的時間明顯增長了，資料同步用時也很久，久就多等下唄，我也沒太在意，突然，手機簡訊報警，活動會話已達到50了，馬上登入資料庫查，活動會話已是300多了，都是行鎖，而且阻塞源有多個，沒有發現明顯的根阻塞會話，為了儘快解除會話堆積問題，採取了kill全部阻塞源的方案，阻塞解決了，但也誤殺了一些業務會話；事後分析發現，真正的阻塞源還是資料同步引發的，資料同步是把物化檢視的資料merge到中間表，事實上的確是不阻塞業務表的，但一旦同步完成，sys使用者會立即啟動一個非同步purgelog的任務，delete物化檢視日誌的已同步資料，如果資料量一大，這個SQL就很慢（執行計劃不佳），它就會阻塞物化檢視日誌的update,而物化檢視的update又會阻塞表的插入與update,造成了多層阻塞，如果層層追溯的話，還是可以找到根會話的，kill根會話即可；即便是吃過一次虧，後來我們也還是再上了一次當，出現了阻塞的情況但是仍然找不到阻塞源，原來這個purgelog的任務自動跑到另一個實體去運行了（RAC），而我們的檢測指令碼卻是單實體的；
這一個雷的總結就是，資料同步也有阻塞的風險！原先一直以為，只有切換才會有鎖。
避開的辦法是，要麼找到業務最低谷時段進行操作，小表晚上22點就OK，但更大的表則不行，要到凌晨2：00才是最低谷；然後，不要想先提前把前面3步做完，等到低谷時來做同步與切換，因為間隔時間越長，物化日誌量就越大，purgelog就越久； 總之，就是在低谷期做，而且是一氣呵成，要同步的量小，可能是最順利的；
這裡，個人感覺oracle在這個地方完全可以加強一下，非同步purgelog是否真的必要？能否允許設定不啟動？或者能否先不delete，搞完後一次性truncate?如果資料同步沒有阻塞問題，那就方便好多，把這些步驟分散進行，比如提前把多個表的初始化與索引弄好，並不斷同步，只在低谷期一一進行切換，效率就高得多；
04
第二個雷：進退停，都不行
在給某個表做切換時，到了資料同步這一步，發現資料同步沒法完成，眼看著造成越來越多的會話阻塞，只有停止它，
既然不能前進，那麼我們就回退，結果發現，回退也是久久不能完成，阻塞達到一定程度之後，只有中止回退，暫時停在這裡，但停下來並不代表就沒有問題，物化檢視與日誌在不斷增長，一天增長幾千萬，而且每次插入或更新都還要掃清物化檢視，高併發下造成了一次活動會話造過100的險情，感覺就像踩著了地雷，進也不能，退也不能，停在這裡又有被敵人掃射的風險。
這下可扎心了，怎麼辦？請教同事朋友，以及相關的群，都沒這方面的經驗；開SR，從中文到英文，從二級到一級，也得不到有幫助的回答，oracle雖然檔案很多，但有些問題，也不容易找到答案。只有去分析它的行為，最終發現是一個遞迴SQL走錯了執行計劃（這個SQL也只是我的一篇文章《 記一次增加分割槽要兩個小時的最佳化案例 》裡描述的那個SQL，，把這個SQL的執行計劃固化後，操作就正常了，完成了回退後，重新進行了一次重定義，分割槽完成；
對於這個坑，真的是很坑！而且還有可能不盡相同的入坑方式，一旦入了坑，可能面對的壓力會很大，因為可能好幾次變更都不能完成，進退兩難，最關鍵的是缺少可供參照的解決方案，只能具體問題，具體分析了；
05
第三個雷：執行計劃突變引發了宕機
中等大小的表做完後，還有一個62億記錄600GB的大表，這個表我最擔心的第一次同步資料時IO太大或時間太久，其實一些老資料是可以歸檔了，如果線上重定義能自定義初始化資料的範圍，比如只初始化最近三個月的資料，那就太好了，可惜不能，只能全量插入，但插入之後，我可以用truncate分割槽的方法把老資料清掉，這樣，後面建索引就快了，相當於同時實現了分割槽與歸檔的功能（老資料在原表以及ogg複製庫仍存在）。
這是特定場景的特殊用法，建立在兩個基礎以上：
-
線上重定義是透過物化檢視日誌同步的，它透過merge的機制可以實現兩邊資料的一致性，但它並不強制要求兩邊一模一樣；只要物化檢視中insert與update能全部實施到中間表上，那麼最新的資料能保證是一致的，哪怕老資料已經沒有了；
-
我們的業務恰好是跟時間緊密相關的，3個月之前的資料已經很冷了，可以確認不會再有更新了。
最擔心的IO消耗竟然還比較好，開8個並行，共用了50分鐘，儲存的IO使用率沒有超過25%，之後清掉了老資料，建好索引，分析表，同步很快，切換很快，都順利地完成了，以後大石落定，開始處理OGG的事，這個時候，發現活動會話又上來了，仔細一看，竟然是一個相關的SQL走錯了執行計劃，由索引變成了分割槽全掃描！最悲催的是，這個時候，操作已不正常，無法像平時一樣，生成kill會話的SQL，記憶體在也沒有原來正確的執行計劃，想構造一個，任何操作一提交就變成了視窗“無響應”，接著，實體都連不上了，宕機了！馬上轉到另一個節點，有一些會話已經飄過來了，好在這個節點還可以正常操作，馬上構造正確的執行計劃，固化，然後KILL現有的全表掃描會話，情況得到了控制，再重啟掛了的節點，然後，只能是暗自阿彌佗佛，如果沒有控制住的話，那估計要跑路了；
其實執行計劃的變化，一開始就考慮過，所以每個表都要做一次統計，之前的表，就從來沒有出現過執行計劃的變化，但這個執行計劃的變化，跟表的分割槽有關，跟SQL的寫法不當也有關，總之就是沒有充分評估到這方面的風險，這方面是有欠缺的；
06
第四個雷：OGG的所有抽取都掛空擋了
進行各方面檢查後，看似一切正常了，但ogg的抽取任務卻有些怪，狀態是running的，但lag卻是不斷地增長，檢查標的端，資料沒有進來！納悶啊納悶，不只是這個表相關的extract,而是所有的extract都是這樣，可是又不報錯，反覆STOP加START，還是一樣的情況，從來沒有遇到過這種現象，網上也找不到類似的案例，Strace也看起來是正常工作的，嘗試跳過大事務，沒有進展，嘗試跳過一點時間，也沒有解決，百思不得其解，陷入深深地困惑中……
時間一分一秒地過去，延時一分一秒地增長，也是一個耽誤不起的坑，於是決定拿一個表做測試，跳過較長的一段時間，發現報錯了，redo日誌不可用（不在本地節點的問題），複製過來後，發現正常了！只能這麼乾，都往前跳一段時間，這個抽取正常了，開始追日誌了，但代價是跳過的這一段時間，就需要去比對與手工同步了；
猜想這個跟600G的大表初始化生成了很多的日誌檔案有關，但具體怎麼相關，暫不清楚，惹不起，只能躲了。
07
寫在最後
終於走出了地雷陣，感覺是鬆了一口氣，儘管付出了慘痛的代價，但真的有很多值得吸取的經驗與教訓，如果我所付出的代價，能夠給到其他人一些參考，從而少踩一些坑，那也算值得了^_^
原創：ycc。
投稿：有投稿意向技術人請在公眾號對話方塊留言。
轉載：意向文章下方留言。
更多精彩請關註 “資料和雲” 公眾號 。
