不以规矩 不成方圆

我在多年以前写下的DBA四大守则，其中的一条是“不以规矩，不成方圆”。任何一个企业的运维环境，都需要基本的规矩和准则，有所遵守、有所规范，才能保持长治久安，不出或少出低级错误和纰漏。运维的核心就应当是去保障生产能力，维护生产环境的稳定、安全和高效运行。

前一段在“恩墨微信大讲堂”中，有朋友遇到这样一个问题，一个数据文件处于RECOVER状态，然后尝试去删除这个文件，遇到了错误，表名数据文件中存在对象约束，不能被删除。

然而在检查时发现Unique和Primary的约束并不存在，这是为什么呢？

可是等等，不要被这个问题转移了视线，我们重新来审视一下，这个要被删除的表空间文件是什么？

一个奇怪的名字跃入眼帘：E:JYB.DBF 。而且这个文件被创建在dbs目录下（为什么在这个目录？留一个问题在这里）。

这显然是因为（也许不那么显然）：用户用Windows的命令法，想在E:分区去建一个文件，然而出错，文件被扔到了dbs目录。

这个数据的规范性很明显是不足的，可能这个文件是某个开发人员远程创建出来的，甚至DBA根本不知道存在这个文件，还有可能就直接删除了。

一个企业的核心数据库：数据库文件的创建、备份、维护都应该具有明确的规则。

那么到底是为什么删除不了呢？

追查发现在该表空间存在很多临时段，于是用户猜测是有人将临时表建立到了这个表空间：

那么真的是这样么？

作为DBA的一个基本常识是：临时段不仅仅只在临时表或临时表空间中存在，很多中间操作以临时段作为过度。比如创建索引，在完成之前，数据段的状态是临时的，创建完成之后才更改为永久的。

我以前写过一个简短的记录，在一个IMP的数据导入过程中，导入完成之前大量数据以临时段存储（示例含有LOB对象），而且Oracle以 数据文件号+开始块号 来命名这些临时段（直接截图了）：

即便是一个简单的案例，串联起来都会有很有意思的故事和知识。知其然之后才能够胸有成竹。

以上讨论的问题，将索引重建之后，该表空间就被顺利的删除。

本文出自数据和云公众号，原文链接