表空间搬移后引起的Dataguard不同步

关键词 : 谨慎，周全的考虑.

     昨晚系统调整，将一套CRM数据库的几个用户迁移到另外一台性能较强的服务器数据库上去。

源库 ： oracle 9208
目标库 ： oracle 9206
字符集相同. 操作系统都是linux

     这样的环境太好了，几乎一下子就想到了传输表空间，不用忍受exp/imp大量数据带来的痛苦的煎熬与等待。由于之前使用传输表空间做了一些迁移案例，所以驾轻就熟，也没多想，简单列了checklist，然后待停机时间开始做这次迁移。

     迁移过程比较顺利，出现的问题都在想象中(dblink和job无法用imp进新环境，对于dblink，使用 dbms_metadata.get_ddl提取对应脚本/对于job,使用自己写的一个procedure从旧库提取生成).表空间传输从技术角度讲比 较简单，但实施中一定要细心，对存储过程/序列/授权/JOB/DBLINK等一系列object要有一个合理的迁移方法和后续检查。
     善后，配置/重启应用，发现应用能正常登陆，于是收工回家。
     早上醒来，数据库巡检告警短信不期而至，表空间搬移到新库的standby报警，提示主备不同步。这下才想到昨晚马虎了一下，忘记了这是个DG环境。因为 表空间搬移后，元信息被导入数据字典中，但数据文件是追加进来的，standby端通过apply归档日志只能得到表空间的相关信息，数据文件在备库端并 不存在，所以无法继续做日志恢复。
     查看备库alert.log，确有这样的报警:

——————————–
Thu Aug 19 02:59:02 2009
Errors in file /opt/oracle/admin/orc1/bdump/orc1_dbw0_25859.trc:
ORA-01157: cannot identify/lock data file 27 - see DBWR trace file
ORA-01110: data file 27: ‘/data/orc1/crm04.dbf’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
———————————

     利用空闲时间，在primary端将搬移过来的表空间做了一次RMAN热备并生成一个standby controlfile，将备份传输到standby端，在备库上restore这个standby cf，然后restore tablespace，做recover后，DG再次同步，运行正常。
     看来做事还是马虎不得，还好这次只是个dg问题，即使有问题也不至于对生产产生大的影响。O(∩_∩)O