昨天拜读了刘润的“不要搞封建迷信活动”，深有感触． 前一段时间我在处理 Data Guard 的时候, 遇到过一件怪事. “怪现象一定有原因的”． 果然, 经过仔细分析之后, 果然发现并不是灵异现象. 凡事皆有因果.
情景描述:
在一个机器上建立两个同一数据库的 Data Guard. 其中一个 Data Guard 已经建立,数据文件放在 foo 目录下.现在准备建立第二个 Data Guard, 数据文件放在 fooback 下. 初始化参数已经设置:
*.db_file_name_convert='/opt/oracle/oradata/foo/','/opt/oracle/oradata/fooback/'
其他的设置略. 用第一个 Data Guard 备份的控制文件, 启动第二个实例, 进行恢复. 开始正常, 恢复了几个文件之后,遇到如下错误:
skipping datafile 56; already restored to file /opt/oracle/oradata/fooback/user_log_04.dbf
skipping datafile 57; already restored to file /opt/oracle/oradata/fooback/user_log_05.dbf
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00058 to /opt/oracle/oradata/foo/foo_note_06.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/24/2006 11:32:48
ORA-19504: failed to create file “/opt/oracle/oradata/foo/foo_note_06.dbf”
ORA-27086: skgfglk: unable to lock file – already in use
IBM AIX RISC System/6000 Error: 13: Permission denied
Additional information: 8
Additional information: 553070
已经作了数据文件名字映射, 在第 58 个文件映射失败(应该是 fooback 目录下的文件,又跑到 foo 上去恢复了!) 怪哉!
进入第一个实例, 查询文件名字,正常．进入第二个实例, 查询文件名字, 前面 57 个都是 fooback 目录下的, 第 58 个就变成了 foo . 难道是遇到了 Bug 么 ? 为什么是 58 ?
折腾了许久, 针对这个58 ,我去查以前的数据库变动, 发现这个文件,是第一个 Data Guard 建立之后我第一次添加的数据文件.
oops, 我用的这个控制文件有问题!! 如果只在一个机器上建立一个 standby ,那么用其他 standby
备份出来的控制文件, 并且不修改文件名字映射的话, 不会出现该问题的. 而第一个 Standby 的控制文件,只从 Primary DB 控制文件带来 57 个数据文件的信息.所以, 在 58 个失败. 而 Oracle 的 Data Guard 文档中建议的标准做法是从 Primary DB 取控制文件.
Bug ,这是一个 DBA 甚至是所有 IT 工程师最容易”迷信”的地方. 破除迷信, 从现在开始.