標籤：一段 注意 資料 bst strong 重要 失敗 logs acl
一、概述
前一段時間，有一個DBA朋友在完畢重建表(rename)工作後，第二天早上業務無法正常執行，出現資料無法插入的限制和錯誤，後來分析才發現，錯誤的原因是使用rename方式重建表以後，其他引用這個表的外鍵約束指向沒有又一次定義到這個重建的新表中，從而導致這些表在插入新資料時，違反資料完整性約束，導致資料無法正常插入。
影響了業務大概有1個多小時，真是一次血淋淋的教訓啊。
使用rename方式重建表是我們日常DBA維護工作中常常使用的一種方法，由於CTAS+rename這樣的配合方式。非常有用和高效。
非常多DBA朋友應該也都是用過rename方式重建表。並且重建完畢以後也都一切正常，沒有引起過問題。可是，我想說的是，使用rename重建表後。詳細須要完畢哪些掃尾工作你真的清楚嗎？？
這篇文章主要就是歸納當我們使用rename方式重建表後。須要進行哪些掃尾工作，假設你還不是非常清楚。一定要細緻閱讀這篇文章。同一時候在以後的重建表工作中矯正過來。否則。問題遲早有一天會降臨到你的身邊！
二、重建表的方式這裡先不談其他，只說一下重建表的方法。
例如以下
1、為了確保全部表欄位、欄位類型、長度全然一樣，我一般不建議使用CTAS方式來重建表。2、一般我都是使用以下兩種方法中的一個，來抽取表的定義
- select dbms_metadata.get_ddl(‘TABLE‘,upper(‘&i_table_name‘),upper(‘&i_owner‘)) from dual;
- 使用PL/SQL developer類似這種工具，來查看錶定義語句
3、又一次建一張_old類型的表（依據上面的抽取的表定義），然後使用insert /*+ append */ xx select xxx 方式完畢資料的轉換4、最後使用rename方式倒換這兩張表的名字
三、重建表注意事項
索引重建：這裡最關鍵的是，重建後索引的名字是否必須和曾經的一樣，假設須要一樣。則必須將當前使用的索引名字先rename，否則建立的時候會出現索引名字已經存在的錯誤,例如以下：select ‘alter index ‘ || owner || ‘.‘ || index_name || ‘ rename to ‘ || substr(index_name, 1, 26) || ‘_old;‘ from dba_indexes a where a.table_owner = ‘DBMON‘ AND A.table_name = ‘DH_T‘;
依賴對象重建：一般能夠使用例如以下方式完畢select ‘alter ‘||decode(type,‘PACKAGE BODY‘,‘PACKAGE‘,type)||‘ ‘||owner||‘.‘||name||‘ compile;‘ from dba_dependencies a where a.referenced_name = ‘DH_T‘ and a.referenced_owner = ‘DBMON‘;
注意：1、這裡重建的僅僅是直接依賴對象，必須考慮那些間接依賴的對象（比如 view1依賴A表，view2依賴view1），尋找方法和上面幾乎相同2、假設這些依賴對象中存在一些私人對象（比如dblink等）。我們用DBA使用者又一次編譯是會出現編譯錯誤，對於這樣的對象。必須以相應對象的所屬者才幹編譯成功。(也可用用10g以後新出現的代理許可權來完畢這類任務！）針對PL/SQL代碼（包、函數、過程等），是否存在私人對象的尋找方法，例如以下：select * from dba_source a where (a.owner, a.name) in (select owner, name from dba_dependencies b where b.referenced_name = ‘DH_T‘ and b.referenced_owner = ‘DBMON‘) and a.TEXT like ‘%@%‘;
針對視圖中是否存在私人對象的尋找方法，例如以下(因為是long類型。必須得一個一個查看）：select * from dba_views a where (a.owner, a.view_name) in (select owner, name from dba_dependencies b where b.referenced_name = ‘DH_T‘ and b.referenced_owner = ‘DBMON‘ and b.type = ‘VIEW‘)
許可權重建：能夠使用例如以下語句select ‘grant ‘ || PRIVILEGE || ‘ on ‘ || owner || ‘.‘ || table_name || ‘ to ‘ || grantee || ‘;‘ from dba_tab_privs where table_name = upper(‘&i_table_name‘) and owner = upper(‘&i_owner‘);
外鍵重建：對於外鍵，如今的業務資料邏輯非常多都是在應用程式層來實現。因此表上的外鍵可能都非常少，因此。導致非常多DBA都忘記須要檢查和重建這一部分了，從而導致業務出現故障，本章最開始說的故障案例就是由於沒有重建外鍵而引起，因此我們一定要提高警惕。
能夠使用例如以下語句查看，哪些表引用了重建表
select a.table_name, a.owner, a.constraint_name, a.constraint_type, a.r_owner, a.r_constraint_name,--被外鍵引用的約束名 b.table_name --被外鍵引用的表名 from dba_constraints a, dba_constraints b where a.constraint_type = ‘R‘ and a.r_constraint_name = b.constraint_name and a.r_owner = b.owner and b.table_name = ‘FSPARECEIVEBILLTIME‘ and b.owner=‘‘;
物化視圖：另外一個很重要的依賴對象就是物化視圖，一般來說，rename表以後，物化視圖是不會有問題的，再次重新整理時會自己主動編譯，可是這可能會影響最佳化其選擇運行計劃。因此，建議手工直接編譯這些失效的物化視圖，例如以下alter MATERIALIZED VIEW DH_T_MV compile; 備忘。事實上這步已經包括在依賴對象重建部分了。單獨拿出來是由於這個依賴對象很重要，不容有不論什麼意外
物化視圖日誌：物化視圖日誌是為了高速重新整理準備的。並且從dba_dependencies 這張依賴表中無法尋找出來的。可是，對於這個對象。我們一定要保持謹慎和敬畏，由於假設表上存在物化視圖日誌對象的話，那麼這張表無法完畢rename（在一個變更的晚上，其他什麼都OK了，突然遇到一個這種問題。還得找開發確認。是非常被動的，整個變更非常有可能由於這個無法確認而取消）。會直接報錯。尋找表上的物化視圖日誌對象方法例如以下：
select master,log_table from user_mview_logs awhere master in (‘DH_T‘);
備忘：
- 我們可能還須要關注表欄位類型，那些LOB、long欄位都是我們重建表是須要考慮的
- 還有就是重建表是我們可能都會使用parallel+nologging模式來加高速度，一定要記得在重建完畢後將這些屬性改動回來。（曾經遇到過一個案例，未將parallel屬性改回來，導致運行計劃選用並行，終於導致資源非常快耗盡，CPU100%）
- 另一些同步機制。假設同步依賴rowid，因為重建表rowid會該表。可能造成即時同步失敗，這些都是我們須要考慮的
- 最後。在工作完畢後，檢查一下全部對象的有效性是一個不錯的方案。
（建議在重建前儲存快照。重建後與前面的快照比較）
- 上面講述的都是一些我們最經常使用的對象，其他一些非常少使用的對象這裡就不概述了
Oracle 重建表(rename)注意事項總結
