Oracle 表空間整理實戰筆記：Undo 縮減後檔案殘留問題與徹底清除驗證

問題複現

• 執行 DROP TABLESPACE undotbs1 INCLUDING CONTENTS; 後，DBA_TABLESPACES 已無 UNDOTBS1。
• 但 ASM/檔案系統中 undotbs1.dbf 仍存在，佔用 27GB 空間。
• 查詢 V$DATAFILE 已不列出該檔案，證明資料字典已移除，但實體檔案殘留。

根因分析

INCLUDING CONTENTS 僅移除邏輯段 (Segments)，不包含 作業系統/ASM 層面的實體檔案。需加上 AND DATAFILES 子句才會同步刪除實體檔。

補救步驟與驗證

1. 確認資料庫層面已無該檔案

SELECT name FROM v$datafile;
-- 結果中無 undotbs1.dbf，確認字典已清除

2. 停止資料庫與監聽器 (冷備份窗口)

SQL> SHUTDOWN IMMEDIATE;
LSNRCTL> STOP

3. 移動/刪除實體檔案

檔案系統：

mv /u01/app/oracle/oradata/undotbs1.dbf /backup/undotbs1.dbf.bak

ASM 環境：

asmcmd rm +ORADG/danaly/datafile/undotbs1.265.600173875

4. 啟動資料庫與監聽器

LSNRCTL> START
SQL> STARTUP

5. 驗證服務正常

• 資料庫正常開啟 (OPEN MODE = READ WRITE)
• 應用連線測試通過
• Alert Log 無報錯

正確的一次到位指令

DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;

• INCLUDING CONTENTS：刪除表空間內所有段 (Tables, Indexes, LOBs 等)
• AND DATAFILES：同時刪除實體資料檔 (適用檔案系統與 ASM)

補充：9i/10g 非 OMF 環境手動刪除檔案風險

• 若使用 Raw Device 或非標準路徑，AND DATAFILES 可能無法刪除，需手動 rm。
• 手動刪除前 務必 確認 V$DATAFILE、V$CONTROLFILE、V$LOGFILE 均無該檔案引用。
• Controlfile 仍記錄檔案資訊時強行刪除檔案，會導致 ORA-01157、ORA-01110 錯誤，需 ALTER DATABASE DATAFILE ... OFFLINE DROP 後再處理。

經驗總結

1. 習慣加上 AND DATAFILES：除非有備份保留需求，否則 Drop Tablespace 態度應為「連檔案一起刪」。
2. 驗證磁碟空間實際釋放：執行後用 df -h (檔案系統) 或 asmcmd du (ASM) 確認 Used 空間下降。
3. Alert Log 留痕：DROP TABLESPACE 成功會寫入 Alert Log，包含刪除的檔案路徑，可作為稽核憑證。

結語

Undo 表空間縮減的關鍵在於「徹底」：不僅要切換邏輯表空間，更要確保實體檔案同步移除。DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 是最標準、最安全的單一指令完成方式。