不以規矩 不成方圓

我在多年以前寫下的DBA四大守則，其中的一條是“不以規矩，不成方圓”。任何一個企業的運維環境，都需要基本的規矩和準則，有所遵守、有所規範，才能保持長治久安，不出或少出低級錯誤和紕漏。運維的核心就應當是去保障生產能力，維護生產環境的穩定、安全和高效運行。

前一段在“恩墨微信大講堂”中，有朋友遇到這樣一個問題，一個數據文件處於RECOVER狀態，然後嚐試去刪除這個文件，遇到了錯誤，表名數據文件中存在對象約束，不能被刪除。

然而在檢查時發現Unique和Primary的約束並不存在，這是為什麼呢？

可是等等，不要被這個問題轉移了視線，我們重新來審視一下，這個要被刪除的表空間文件是什麼？

一個奇怪的名字躍入眼簾：E:JYB.DBF 。而且這個文件被創建在dbs目錄下（為什麼在這個目錄？留一個問題在這裏）。

這顯然是因為（也許不那麼顯然）：用戶用Windows的命令法，想在E:分區去建一個文件，然而出錯，文件被扔到了dbs目錄。

這個數據的規範性很明顯是不足的，可能這個文件是某個開發人員遠程創建出來的，甚至DBA根本不知道存在這個文件，還有可能就直接刪除了。

一個企業的核心數據庫：數據庫文件的創建、備份、維護都應該具有明確的規則。

那麼到底是為什麼刪除不了呢？

追查發現在該表空間存在很多臨時段，於是用戶猜測是有人將臨時表建立到了這個表空間：

那麼真的是這樣麼？

作為DBA的一個基本常識是：臨時段不僅僅隻在臨時表或臨時表空間中存在，很多中間操作以臨時段作為過度。比如創建索引，在完成之前，數據段的狀態是臨時的，創建完成之後才更改為永久的。

我以前寫過一個簡短的記錄，在一個IMP的數據導入過程中，導入完成之前大量數據以臨時段存儲（示例含有LOB對象），而且Oracle以 數據文件號+開始塊號 來命名這些臨時段（直接截圖了）：

即便是一個簡單的案例，串聯起來都會有很有意思的故事和知識。知其然之後才能夠胸有成竹。

以上討論的問題，將索引重建之後，該表空間就被順利的刪除。

本文出自數據和雲公眾號，原文鏈接