OracleBlog.cn -天堂向左 DBA向右

今天接到个电话，说某省的一个非归档数据库中，为某个表空间添加数据文件时误操作，加成了文件系统（数据库是使用裸设备做数据文件的），当时处理的方式是直接在os级rm掉了这个数据文件。结果在oem里面点击表空间的时候就报数据文件找不到了。然后，另一个同事将该数据文件执行offline drop后，在oem里面点击表空间不报错了。

但是这是否就正常了呢？

我们说，表空间就像一个容器，像一个空的水杯，一旦我们把水倒进水杯里面，我们就分辨不出那些水是第一次倒入的，哪些是第二次倒入的。我们也无法把已经倒进去的水区别开来，把最后一次倒入的水在倒出来。

我们检查了那个数据文件说涉及到的表空间，将这个表空间下的所有的表都count(*)一遍，如果没有报错，那么我们比较幸运，那个被rm掉的文件里面没有数据，如果有数据，那就比较惨了……count(*)的结果表明：我们就是属于那种不幸的情况。

我们首先考虑恢复数据，由于是非规定模式，redolog就显得比较重要了。如果redolog没有使用一圈的话，我们还能用redolog来进行恢复：

上述的这个情况是属于比较幸运的情况，我们的redolog还没有被重复利用，但是实际中遇到的情况往往是，等到发现数据文件误删报错，已经是好几天之外了，生产系统中redolog的切换，已经切换n次了。因此，在这里，我们只能尽量的挽回数据了：

首先查看被删除的数据文件涉及到哪几个表空间，将这些表空间里面的所有表都count一次，以确定有哪些表受到影响，如果是分区表，还比较好办些，分别count每一个分区的数据确认没有问题，将没有问题的数据进行exp备份，或者ctas到别的表。然后将表drop掉之后进行重建，注意重建的时候也要重新表的索引约束等等。如果对于非分区表，无法一个分区一个分区的进行测试，因此只能exp表，在exp的时候，会报错，但是无须理会，exp出来成一个文件后，可以imp到另一用户，重新本用户的表，在insert into table select * from user_b.table，注意索引和约束也要重建。

当然，重建表只是最低影响的处理，正确的处理方式应该是重建表空间，对表空间中的所有表都进行重建，但是这个工程量就比较大了……

DBA切记：数据文件一旦加入表空间，切勿随意删除！！（特别是9i的数据库，10g还能drop empty datafile。）