的确没有那么多”迷信” [DBA工作备忘]

昨天拜读了刘润的“不要搞封建迷信活动”,深有感触. 前一段时间我在处理 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 工程师最容易”迷信”的地方. 破除迷信, 从现在开始. 


参考以前的”备忘录”系列:
[Oracle] DBA工作备忘录之一: 用events 跟踪解决不能创建物化试图一例
[Oracle] DBA工作备忘录之二: Exp出错的一个案例
[Oracle] DBA工作备忘录之三: rman备份,未使用catalog,控制文件丢失的解决办法
[Oracle] DBA工作备忘录之四: Apache上部署Pro*c常见错误两例


5 thoughts on “的确没有那么多”迷信” [DBA工作备忘]

  1. sudan

    看到了“(应该是 fooback 目录下的文件,又跑到 foo 上去恢复了!) ”
    看了一遍不知道这个“应该”解决了吗??
    求教!

    Reply
  2. zhu1 (木匠)

    看来我比你幸运,从来没有考虑过copy standby db control file.
    我们的配置是, 4 nodes RAC 10.1.0.4, 1 real time standby, 1 read-only standby, for reporting, refresh every night.
    跑了一年多了 啥问题也没有 可惜Logcial stdby 不支持宽表(100+ columns)
    等升级到10.2.0.3,会加一个Logical Standby.
    根据我的经验,Oracle 整体稳定,但总有一些莫名其妙的Bug,
    我们的宗旨是: “绕过去, 别较劲”
    ps. Oracle db 11g Partition(Time dimension and Based on master tables partition columns)和数据压缩, 令人神往. 嘻嘻.

    Reply
  3. Fenng

    你的 real time standby 是 Logical Standby ?
    如果不是必需的功能,没必要升级到 10g
    10g 出来三四年了,我认为还是不够稳定

    Reply
  4. zhu1 (木匠)

    忘了说了, 全是 Physical Standby, Oracle 10.1 Logcial stdby 不支持宽表.
    唉, 我就爱尝鲜, 对每个新特性如获至宝, 记得2001年秋天, 就给世界第二大长话公司上了Oracle 9i on HP-UX.
    我的老板(Borland J Builder 的首席构架师),啥时候换MySQL呀,要不MS-SQL 2005 也行 (整天宣传SQL-Server2005的优越性), 前两天又来了个 Enterprise DB (基于Postgres)
    像我这样只懂Oracle的 咋办呀?!!
    (我就建议老板 试试DB2还行 我有认证)
    还好-最近的统计显示Oracle市场占有率超过50%.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *