今天对一处于半上线状态的数据库做了drop tablespace操作，生产上offline倒是很多，drop反而是冷门操作了。由于数据库的性质，就偷了一次懒，没有去测试库上试试，结果惊出一身冷汗。
起因是这样的，开发人员提出想将某个schema下的所有object都清除掉，然后布新的。也是自己脑子发热，想着把tablespace给drop掉（其实完全没有必要，drop user user_name cascade就完事了）。操作的时候又懒得去查语法了，依稀记得官方文档上说and datafiles应该是默认参数，drop tablespace是会自动删除掉datafile。
执行了drop tablespace tablespace_name including contents;执行完了之后到oradata中去看了一下datafile，结果tablespace_name01.dbf文件赫然在目，原来没自动删掉。switch logfile了几次，依然存在，这下就郁闷了。寻思着这个datafile能不能就在os中去rm。
查询了一下dba_data_files视图，发现数据库里是没有了该datafile的记录，然后试着去os中rm tablespace_name01.dbf，删除掉了，去bdump的alert文件中看了看，没有报警才算放心。
然后去物理dg中rm了datafile，回到主库drop user，重建了同名的tablespace和user。
回想一下这个事情，虽然没有出什么事情，但是这样做事的思路是不对的。作为一个DBA，一定要拿最稳妥的方式来处理日常事务。事情做得蛮危险的。
误操作往往出现在这种偷懒，盲目相信记忆，没有做充分实验的时候。记下这些，以此杜绝一些坏习惯。
后来查了一下白皮书，对and datafiles的解释如下：
When you specify INCLUDING CONTENTS, the AND DATAFILES clause lets you instruct the database to delete the associated operating system files as well. Oracle Database writes a message to the alert log for each operating system file deleted. This clause is not needed for Oracle-managed files, because they are removed from the system even if you do not specify AND DATAFILES.
原来，只有在创建datafile时使用OMF，oracle才会在不用and datafiles子句的情况下也会自动删除datafiles
dg中的alert文件也验证了相关内容：
Recovery deleting file #7:'/u02/oradata/db/tablespace_name01.dbf' from controlfile.
Recovery dropped tablespace 'tablespace_name'
WARNING: File being created with same name as in Primary
其实如果要删除object，drop user user_name cascade;就完全够用了。
对tablespace应该只是offline，然后create新的就行了，这样能保证万一出事情了数据至少还没有丢失。
要drop tablespace连带datafile和包含的对象的语法是
drop tablespace tablespace_name including contents and datafile;
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/11258275/viewspace-666533/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
