论OMF管理文件的重要性

很多人不喜欢omf，包括我。但是我给大家讲个故事，在这个故事中，我们可以看到使用omf的重要性。因为在使用omf的情况下，也就不会发生下面的场景。

在一个夜黑风高的夜晚，客户的生产库某个数据文件在晚上突然之间消失了，数据库crash。

数据文件是在asm的+DATA diskgroup上，在数据库和asm的alertlog中看不到任何关于该数据文件被删除的信息。DBA和主机组的同事，都没有发起过删除该数据文件的命令。

并且由于该数据文件是正在被使用，正常情况下，即使运行asmcmd命令删除，也是无法执行成功的。

那么是谁删除了生产正在使用的数据文件呢？

幸好我们还有操作系统的旁路审计，从日志中可以看到当晚有个创建dataguard的操作。问题就发生在duplicate的过程中。

客户的环境是这样的，这个生产库在大集群中（我们姑且称大集群1），四节点。客户用的是single instance的HA，5，6个数据库跑在一个节点上，其他几个节点是空负载，在必要的时候可以切换过去。这些数据库的数据文件放在asm上，是在+DATA路径。

这个生产库后面跟着一个物理datguard，物理dataguard也是在一个大集群中（我们称作集群2），两节点，也是single instance HA，几十个数据库跑在一个节点上。剩余的节点空负载。这些数据库的数据文件也是放在asm上，是在+DATA路径。即primary和dataguard的路径一样。

晚上需要建立另外一个dataguard，由于没有多余的机器，便在集群1中找了一台空负载的机器，新划了一块diskgroup，叫+NEWDATA,来搭建dataguard。dataguard用了duplicate命令创建：

我们注意这里的第3，4行，第三行，写的正确；第四行，写的错误，应该是log_file_name_convert,写错成了db_file_name_convert。悲剧发生了。

由于2行重复，Oracle只认后一个。而后一个的路径下，没有对应的datafile，所以Oracle不进行路径转换，直接用了dataguard上的路径。

我们可以看到运行时审计日志中运行duplicate后有set newname操作。

注意，由于不进行转换，直接用了dataguard的路径，所以它不是到+NEWDATA，而且去了+DATA路径。即restore去了+DATA路径。而dataguard上的diskgroup路径，由于和生产库一样，diskgroup的路径也是+DATA，所以restore的时候，由于是在集群1，就覆盖了生产库的文件。

客户DBA可能意识到了这个问题，赶紧cancel了duplicate操作。

而duplicate被cancel，是会自动去清理那些restore出来的文件，这是预期行为，所以，生产库上+DATA下的那些数据文件就被清理掉了。

所以，就是这样，数据文件神秘的消失了。

故障的处理还是比较容易的，当晚客户就通过从dataguard的文件restore到生产库，再recover了这个数据文件。但是找数据文件丢失的原因，还是花了一些时间去分析。这就和看侦探小说一样，如果你知道的结果，反过来看就很容易。呵呵。

好了，我们撇开误操作不说，如果数据库采用了omf管理，那么在这个场景下，由于omf restore出来的文件，是带一串数字的独立的文件名，也就是说，是不会覆盖生产的文件的。