導讀

進入年底，系統運維中的“安全問題”再次成為焦點。每年這個階段，隨着業務衝刺、系統擴容與變更頻繁，運維壓力陡增，操作風險也隨之攀升。稍有不慎，就可能引發嚴重事故——從核心表被誤刪，到關鍵配置被覆蓋，甚至造成長時間業務中斷。為此，我們邀請到雲和恩墨聯合創始人、資深數據庫技術專家楊廷琨在11月5日做了一場主題分享《數據庫日常運維中的不可回退操作》。以下文章為演講實錄整理而成，供大家進一步參考學習。

為什麼説 DDL 操作無法回滾？

在日常數據庫維護中，DBA 幾乎每天都要與各種結構調整打交道：建表、加列、刪字段、改索引、甚至調整參數。然而，很多人忽視了一個關鍵事實——並不是所有操作都能回滾。有些命令一旦下達，就意味着“沒有回頭路”。

Oracle 的設計理念裏，DDL 操作屬於數據定義語言，它修改的對象是數據字典（Data Dictionary），也就是數據庫的“元數據”。

為了確保數據字典的安全和一致性，Oracle 在執行 DDL 時會自動做兩件事：

1. 操作前自動執行一次 commit；
2. 操作完成後再次自動執行 commit。

這意味着 DDL 操作是原子且立即生效的，沒有回滾空間。哪怕你中途發現命令寫錯，按下 Ctrl+C、強制終止，之前的事務也已經被隱式提交。

簡單來説，Oracle 為了保證系統的完整性，犧牲了 DDL 的可逆性。這就是為什麼我們常説：“DDL 沒有後悔藥”。

那些不可撤銷的操作

以下幾類操作在日常中最容易引發嚴重後果。看似簡單，卻可能讓數據庫陷入長時間回滾、鎖等待，甚至“癱瘓”。

不可撤銷的操作

1、DROP 類操作 —— 對象徹底刪除

DROP用於刪除數據庫對象，執行後對象及其內容會永久丟失。

2、TRUNCATE 類操作 —— 快速清空數據

TRUNCATE用於清空表或簇（cluster）中的所有記錄，但保留結構定義。

3、ALTER 類操作 —— 修改結構定義

ALTER系列命令用於修改對象定義（如表、索引、用户等），但部分操作具有不可逆的後果。

4、OTHER 類操作 —— 特殊系統行為

除了常見的結構性 DDL，還有一些特殊命令同樣具備不可撤銷特性。

案例分享

為了更直觀地理解風險來源，我們不妨從幾個實際案例出發，看看當這些命令在生產環境中被誤用時，會帶來什麼樣的連鎖反應。

案例一：刪除字段引發的連鎖反應

在一次客户系統維護中，DBA 打算刪除大表中的一個廢棄字段。為了避免 undo 空間不足，他在語句中加上了 checkpoint參數，以為能“穩妥”一點。

問題模擬重現

結果卻事與願違，刪除操作持續了很久，期間大量業務 DML 被阻塞。當那位技術人員試圖中止操作時，系統立刻陷入更嚴重的鎖等待。幾分鐘後，幾乎所有業務查詢都卡死。

背後的原因很典型：

加上 checkpoint後，操作不再是一個原子事務，而是分段提交。此時再去終止，等於把結構修改停在半路上，數據字典與表數據之間出現不一致。

更安全的做法是：

• 使用 ALTER TABLE SET UNUSED 暫時棄用字段，而非直接刪除；
• 或採用 Oracle 提供的 在線重定義（DBMS_REDEFINITION），在不影響業務的情況下完成結構調整。

案例二：長事務的“回滾地獄”

如果説前一個案例體現了對結構性操作風險的誤判，那麼接下來這個案例，則揭示了在事務層面上“終止即災難”的隱患。

某金融行業客户在日常批處理任務中，因程序邏輯錯誤，在同一事務中誤插入了上千萬條重複數據。這個事務持續運行了一整天，直到 DBA 發現數據庫 I/O 異常、表空間迅速膨脹後，才意識到問題的嚴重性。

出於緊急止損的考慮，DBA 選擇了直接執行 KILL SESSION 來中止事務。然而，這一操作並沒有立刻釋放資源，反而引發了新的問題——

數據庫進入長時間回滾狀態；

涉及表被鎖定，其他業務會話全部阻塞；

整個系統近乎凍結，業務全面中斷。

根因在於：事務回滾的成本與執行時間幾乎等量級。換句話説，一個運行了 8 小時的事務，系統可能也需要 8 小時甚至更久來完成回滾。數據庫在撤銷過程中需逐條回退已執行的 DML 操作，佔用大量 undo 空間與資源。若此時強制中斷或重啓，將觸發後台的回滾，如果有併發的修改或DDL則進一步導致數據字典鎖死，導致併發訪問被鎖定，甚至引發數據庫級別的事故。

遇到類似問題時，盲目“Kill”往往只會加劇風險。正確做法是先評估事務規模與影響。例如：

事前防禦——大事務檢查

通過監控 vtransaction、vsession_longops 等視圖，定期發現運行時間長、undo 佔用高的事務，提前預警，避免問題擴大。

大事務檢查

事中診斷——死事務檢查

當出現死事務時，可以通過如下的方法來評估回滾所需的時間：

死事務檢查

事後加速——回滾優化

如果確實碰到回滾大事務時間過長，可以通過設置隱含參數：_cleanup_rollback_entries來加速回滾。

加速回滾

案例三：ONLINE REBUILD中止

某運營商系統在進行索引分區維護時，操作人員忘記加上 ONLINE 關鍵字。結果，DDL 操作直接鎖表，所有業務 DML 請求被阻塞。

面對突發業務中斷，管理員急於恢復，選擇了強制終止 session。然而，這一“止損”操作卻帶來了更大的損失——部分索引分區被標記為 UNUSABLE，導致查詢與寫入全面失敗，系統瞬間癱瘓。

這類問題在舊版本數據庫（尤其是 12c 以前）中尤為常見。雖然新版本在 DDL 併發與在線修改方面已有顯著改進，但仍需格外謹慎。

在執行任何在線結構操作前，應當：

• 確認操作關鍵字與參數（如 ONLINE、PARALLEL 等）；
• 評估對象依賴關係與鎖風險；
• 在中斷或異常後，及時驗證對象狀態，例如：SELECT index_name, status FROM dba_indexes WHERE table_name = 'XXX';

注意，任何被標記為 UNUSABLE 的索引，都必須儘快重建，以恢復數據訪問能力。

規避方法

經過以上幾個案例可以看到，數據庫的高危操作往往並非源於技術難度，而是源於“習慣性風險”——錯誤的經驗、自以為穩妥的操作方式、以及對機制的不充分理解。

以下幾點實踐經驗，值得每一位 DBA 和運維人員參考：

• 對不可回退操作保持敬畏
• 在操作前規劃好回退方案
• 執行前確認連接正確環境
• 長時間操作放置後台執行
• 高風險操作確保二次審核
• 出現非預期結果及時升級

數據庫的每一次 DDL，看似只是幾行命令，其實背後連接着整個系統的安全。DDL 的不可撤銷，是 Oracle 的設計選擇；而“有備無患”，是每一位 DBA 應該養成的職業習慣。