![640?wx_fmt=jpeg&wxfrom=5](https://i-blog.csdnimg.cn/blog_migrate/4bb53ec2a294a6b1fa585fdd39910c31.jpeg)
我在多年以前写下的DBA四大守则,其中的一条是“不以规矩,不成方圆”。任何一个企业的运维环境,都需要基本的规矩和准则,有所遵守、有所规范,才能保持长治久安,不出或少出低级错误和纰漏。运维的核心就应当是去保障生产能力,维护生产环境的稳定、安全和高效运行。
前一段在“恩墨微信大讲堂”中,有朋友遇到这样一个问题,一个数据文件处于RECOVER状态,然后尝试去删除这个文件,遇到了错误,表名数据文件中存在对象约束,不能被删除。
然而在检查时发现Unique和Primary的约束并不存在,这是为什么呢?
可是等等,不要被这个问题转移了视线,我们重新来审视一下,这个要被删除的表空间文件是什么?
一个奇怪的名字跃入眼帘:E:JYB.DBF 。而且这个文件被创建在dbs目录下(为什么在这个目录?留一个问题在这里)。
这显然是因为(也许不那么显然):用户用Windows的命令法,想在E:分区去建一个文件,然而出错,文件被扔到了dbs目录。
这个数据的规范性很明显是不足的,可能这个文件是某个开发人员远程创建出来的,甚至DBA根本不知道存在这个文件,还有可能就直接删除了。
一个企业的核心数据库:数据库文件的创建、备份、维护都应该具有明确的规则。
那么到底是为什么删除不了呢?
追查发现在该表空间存在很多临时段,于是用户猜测是有人将临时表建立到了这个表空间:
那么真的是这样么?
作为DBA的一个基本常识是:临时段不仅仅只在临时表或临时表空间中存在,很多中间操作以临时段作为过度。比如创建索引,在完成之前,数据段的状态是临时的,创建完成之后才更改为永久的。
我以前写过一个简短的记录,在一个IMP的数据导入过程中,导入完成之前大量数据以临时段存储(示例含有LOB对象),而且Oracle以 数据文件号+开始块号 来命名这些临时段(直接截图了):
即便是一个简单的案例,串联起来都会有很有意思的故事和知识。知其然之后才能够胸有成竹。
以上讨论的问题,将索引重建之后,该表空间就被顺利的删除。
本文出自数据和云公众号,原文链接