愚人节，被数据库“娱”了一下

4月1日，早上7点半正要出门的时候，被某省的同事电话叫住了，说归档目录快满了，由于带库正在备份另一个生产库，这个报表库暂时还不能用带库备份归档，想用手工删除归档日志，却无法删除，ls能列出所有文件，但是ls 某一个归档文件却报错无法找到该文件！单个文件ls不到，更别说rm了。

归档目录剩下6G左右的空间了，按照每5分钟256M的一个arch切出，时间不到半小时，打算赶紧做rm再做crosscheck了。由于之前备份作业都正常，觉得不太可能不能rm，登录上去测试了一下：

汗……真的ls不到，测试rm也是同样的问题！！

难道是文件系统有问题？试着switch logfile切出来几个最新的日志，也还是rm不掉！！赶紧联系了主机工程师上来检查了……最终找到了原因：原来我们看到的文件不是“headt_1_14136.arc”，而是“ headt_1_14136.arc”。注意：这里前面有一个空格！！

做rm的时候，rm headt_1_14136.arc 不行，要 rm ‘ headt_1_14136.arc’带上空格才可以。因此之前我们单个文件的ls或者rm报错找不到文件，但是一直以来用带库做备份，由于是backup archivelog all delete input，因此还是能正常备份了。

检查arch的名称设置，嘿嘿，果然有多一个空格：

趁着当时没有人用报表，赶紧改了参数，重启了库使之生效……

没想到愚人节一早就被数据库“娱”了一把！-_-!!各位朋友，今天你们是否也遇到了和我类似的倒霉事么？