很多人不喜欢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命令创建:
1 2 3 4 5 6 7 8 9 10 11 |
duplicate target database for standby from active database spfile parameter_value_convert 'DATA','NEWDATA','FRA','NEWFRA' set db_file_name_convert='+DATA','+NEWDATA' set db_file_name_convert='+FRA','+NEWFRA' set db_unique_name='tmp1mydb' set db_create_file_dest='+NEWDATA' set db_create_online_log_dest_1='+NEWDATA' set db_create_online_log_dest_2='+NEWFRA' set db_recovery_file_dest='+NEWFRA' set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=11.22.33.44)(PORT=1538)))' nofilenamecheck; |
我们注意这里的第3,4行,第三行,写的正确;第四行,写的错误,应该是log_file_name_convert,写错成了db_file_name_convert。悲剧发生了。
由于2行重复,Oracle只认后一个。而后一个的路径下,没有对应的datafile,所以Oracle不进行路径转换,直接用了dataguard上的路径。
我们可以看到运行时审计日志中运行duplicate后有set newname操作。
1 2 3 4 5 6 7 8 9 10 11 |
……(snip)…… set newname for datafile 5 to "+DATA/1mydb/datafile/akb47data04.dbf"; set newname for datafile 6 to "+DATA/1mydb/datafile/akb47data03.dbf"; set newname for datafile 7 to "+DATA/1mydb/datafile/akb47data02.dbf"; set newname for datafile 8 to ……(snip)…… |
注意,由于不进行转换,直接用了dataguard的路径,所以它不是到+NEWDATA,而且去了+DATA路径。即restore去了+DATA路径。而dataguard上的diskgroup路径,由于和生产库一样,diskgroup的路径也是+DATA,所以restore的时候,由于是在集群1,就覆盖了生产库的文件。
客户DBA可能意识到了这个问题,赶紧cancel了duplicate操作。
而duplicate被cancel,是会自动去清理那些restore出来的文件,这是预期行为,所以,生产库上+DATA下的那些数据文件就被清理掉了。
所以,就是这样,数据文件神秘的消失了。
故障的处理还是比较容易的,当晚客户就通过从dataguard的文件restore到生产库,再recover了这个数据文件。但是找数据文件丢失的原因,还是花了一些时间去分析。这就和看侦探小说一样,如果你知道的结果,反过来看就很容易。呵呵。
好了,我们撇开误操作不说,如果数据库采用了omf管理,那么在这个场景下,由于omf restore出来的文件,是带一串数字的独立的文件名,也就是说,是不会覆盖生产的文件的。