作者介紹：
曾令軍，云和恩墨技術專家，2009年開始接觸數據庫，8年數據庫運維經驗。思維敏捷，擅長于數據庫開發、解決棘手的數據庫故障和性能問題。服務于公司華南區多個客戶，曾參與過國內多家股份制銀行、城市商業銀行的核心業務系統、數據倉庫的部署建設和生產運維工作，在數據庫故障診斷、運維監控、性能優化方面積累了豐富的經驗。
什么是在線重定義
要了解什么是在線重定義技術，我想從表分區開始說起。在生產系統運維過程中，經常遇到的一個需求是如何把一個數據量非常大的普通表改造成分區表。分區最早在.0版本引入，支持將一個表或索引物理地分解為多個更小、更可管理的部分。
好處：
分區表在各行業的數據庫都得到廣泛應用，但是有些業務系統在設計階段對系統數據和性能容量增長估計不足，或沒有考慮到運維過程中的數據歸檔需求，往往沒有對表做分區設計。在生產運行經過長時間的數據積累之后，才發現表越來越大，某些查詢或插入數據的性能變得越來越慢，迫切需要做表分區改造。
那么問題來了，業務系統往往都是7*24在線作業，改造的過程又必然涉及表結構的變動，如果對表進行重建，會對系統運行產生非常大的影響，通常會設置計劃停機窗口來做這類維護操作。
當然，分區表的改造只是諸多數據重組織或重定義場景中的一種，在數據變動需求越來越多、越來越復雜，而系統停機的成本又顯著升高的背景下，從 8i開始就設計了有限的在線重新組織數據的功能，例如 , 。并在9i進一步擴展這方面的能力，引入了數據在線重定義。
在線重定義技術允許數據庫管理員在該表上有讀寫數據操作的情況下，非常靈活地修改表的物理屬性、表數據、表結構。
在線重定義的使用場景
有以下變更需求時，都可以考慮使用在線重定義技術，這些場景也是運維過程中經常遇到的：
在線重定義的實現原理
提供了一個包用于在線重定義操作，主要包含三個過程：
.
這個過程首先會創建一個快速刷新的物化視圖作為過渡表，然后將源表的數據加載到過渡表中，并在源表上創建物化視圖日志，以支持快速刷新同步數據
.
用來把源表中的數據同步到過渡表
.
這個過程的操作步驟比較多，也是做在線重定義時需要特別注意的，但其執行時間通常是非常短的：
1）先調用一次.，同步數據
2）鎖定源表，鎖定之后表數據不再允許發生變化
3）再調用一次.，同步數據
4）交換源表和過渡表的表名
5）刪除物化視圖和物化視圖日志
6）釋放表鎖資源
將普通表改造成分區表
下面我們通過實際案例來應用這項技術，本次實踐中我們要弄清楚幾個問題：
在線重定義的操作過程
將一個2000萬數據量的表進行重定義，需要多長時間
在線重定義期間，表相關的操作是否受影響，又是如何影響的
1檢查用戶權限
運行包需要以下權限：
可進入用戶后執行以下SQL進行檢查確認：
* from ;
2模擬創建一個源表，并插入測試數據
3模擬業務發生場景，一直持續到所有操作結束
按查詢更新插入比例為7:1:2模擬，TPS為10創建物化視圖權限不足，即每秒發生7筆查詢、1筆更新、2筆插入操作，這個負載并不算大,但是變更通常選在空閑時間段,而且對于單表來說已經算很高的負載了。
4按需求創建一個已分區的中間表
以上步驟完成準備工作，開始執行在線重定義過程。
5檢查源表是否具備在線重定義的條件
6開始在線重定義，這一步相當于初始化工作，耗時比較長
7在中間表上創建約束和索引并收集統計信息
這一步提前做，可以防止重定義完成后，新表沒有可用索引，而產生性能問題。
提供了.s過程，用于復制源表上的索引、約束、觸發器、權限等依賴關系到中間表，但是這個包存在的BUG也不少，可以選擇性使用。
這一步執行之后,可以再做一次手工同步刷新,耗時15秒
8手工同步數據，將上一步執行中將產生的數據先做同步刷新
9完成在線重定義過程，執行后，中間表和源表的表名互換
10刪除中間表，并將索引重命名回來
此時的中間表已經是原來未分區的普通表，而源表已經變成了分區表
至此創建物化視圖權限不足，使用在線重定義進行表分區改造的工作已經完成。
通過各個步驟的耗時情況可以看到，在我們模擬壓力的情況下，整個過程耗時12分鐘，而最關鍵的步驟，也就是會鎖表的步驟，只有2秒就完成了。監控數據庫的活動會話、等數據，沒有感覺到數據庫的明顯變化。
接下來把模擬壓力增加到TPS 100，即每秒發生7筆查詢、1筆更新、2筆插入操作，整個操作過程源表上DML的變化趨勢圖如下：
DML操作略有波動，但每一秒鐘都存在DML操作，也就是說在這種壓力之下，鎖表的時間仍然是毫秒級。這組數據也論證了使用在線重定義進行分區表改造的可行性和穩定性。
要注意的問題
使用在線重定義技術，以下情況是需要注意的：
加入"云和恩墨大講堂"，參與討論學習