论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出来的文件,是带一串数字的独立的文件名,也就是说,是不会覆盖生产的文件的。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据