普通表自動轉化為按月分割槽表的指令碼

最近我們專案組遇到非常多張表需要改造為按月分割槽的分割槽表，而且有的表非常大，這個時候該如何做最快呢？

方法1
CREATE出所有的表，把原表TAB_OLD的建表指令碼拿出來，改改後，建出新的分割槽表的表結構，如TAB_NEW
然後把TAB_OLD INSERT INTO 到TAB_NEW中（考慮並行和NOLOGGING),然後把TABLE_OLD RENAME TABLE_BK,把TAB_NEW RENAME 為TAB_OLD
優點：由於新表是根據指令碼來建的，COMMENTS，DEFAULT值，PK，CHECK,NULL，外來鍵等屬性都是全的。
缺點1：找出所有的指令碼，然後手工把結構建出來，寫成分割槽表的動作步驟好繁瑣！這個問題視乎難以避免，其實不然。
缺點2：執行非常慢，因為INSERT INTO是最慢的，可能是噩夢


方法2

直接用CREATE TABLE TAB_NEW （PARTITION ....) AS SELECT * FROM TAB_OLD的方式（考慮並行和NOLOGGING)
優點:CTAS是最快的,比方法1的INSERT INTO快了許多倍！
缺點：由於新表是不是指令碼來建後，在從原表導資料的方案，COMMENTS，DEFAULT值，PK，CHECK,NULL，外來鍵等屬性都是沒有，
這些都需要手工來完成，如果涉及到幾十張的大表改造，將非常繁瑣，而且極容易因為疏忽而導致漏了將上面的屬性加進新表中。

方法3
仍然選擇CTAS的方式改造分割槽，兼顧了方法2的優點，只是這些新表的屬性利用ORACLE的資料字典獲取非手動來做，不再麻煩了，我們可以通過寫一個程式讀取各個資料字典的資訊來暗地裡悄悄的獲取到，把方法1的第1個缺點也避免了。

由此分析可以得知，方法3是同時擁有方法1和方法2的優點，而避免了他們的共同的缺點，在大量分割槽表改造的方案中，這個是最快的，其實即便只有一張表需要改造，用指令碼也是安全的。

下面來看看我寫的方法3的指令碼
（由於分割槽表改造後，索引涉及到是選擇LOCAL還是全域性的問題，還有就是索引是否是必須的問題，所以新表的索引我就不考慮自動建了，另外外來鍵由於涉及到依賴表必須存在，否則會出錯，為了安全起見，我外來鍵也不自動建了，另外外來鍵自動建的指令碼也比較難寫些，呵呵，還沒構造好，必要性不是太大，所以還沒認真投入）
CTAS後，我保證了tab comments ,col comments ,check,DEFAULT ,PK,null,這6大屬性一定必須要有！程式也考慮了NOLOGGING和PARALLEL最終轉化成普通的LOGGING和NOPARALLEL

暫時不提供自動有索引和REFERENCE，索引沒上面的關鍵，屬於更加枝節，而且是否是全域性索引還是區域性索引有待考察，而REFERENCE雖然重要，但是可能由於在改造中引用表還沒建好而報錯，因此這2大屬性，可以讓開發人員手工選擇性的最後判斷在上述都完成後，來決定新表如何增加

另：輸入的表名小寫皆可，程式碼中統一轉換為UPPER

【通用指令碼分享】普通表自動轉化為按月分割槽表的指令碼
http://www.itpub.net/thread-1349399-1-1.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/642366/viewspace-1067040/，如需轉載，請註明出處，否則將追究法律責任。