Flashcopy与数据库恢复的完美结合(7/20)

1.3.4.7 主机B识别硬件,导入VG,修改LV的访问权限

#cfgmgr –v

#importvg –y testvg vpath0

#chown oracle:dba /dev/roar*

#chmod 755 /dev/roar*

本步骤不需要等到flashcopy后台复制完成，只需要等到flashcopy关系建立，开始后台复制工作后，就可以在主机B上识别存储设备，进行存储设备的读写操作了，这是flashcopy的一个很好的功能，节省了很多时间。

1.3.4.8 主机B上启动数据库B,检查特征表aidu.test02 的记录数

SQL>startup

SQL>select count(1) from aidu.test02;

1.3.5 案例总结

在备中心机房的存储上，执行flashcopy复制工作，不会对生产环境的运行效率产生影响，随时可以进行。

本案例可以实现在极短的时间内（5分钟内）创建出一个投运数据库的克隆数据库（不管这个数据库总容量为1T,还是10T或者更大），提供给查询与报表使用。

为了确保使用flashcopy的target盘可以启动数据库B,最好在mkflash前，将数据库设置为online backup模式，这是个善意的建议。但是，如果需要使用flashcopy和flashcopy时间点后面产生的数据库的归档日志(archielog)文件,进行数据库不完整恢复,则一定需要将数据库设置为online backup模式,否则恢复时将会遇到’WARNING! Recovering data file % from a fuzzy file’错误,最终导致无法恢复。

本案例使用pprc的目标盘作为flashcopy的源盘，为了达到flashcopy目标盘上数据的一致性，必须保证pprc 复制+flashcopy复制双层数据一致性，所以在执行mkflash之前，一定需要检查pprc的状态是否正常（FULL DUPLEX）,如果pprc的状态是非full duplex，则需要首先解决pprc的同步问题（通过resumepprc，failbackpprc或者mkpprc 等命令来重新建立好pprc的复制关系）。笔者曾经因为没有检查pprc状态，而当时的pprc关系的6个lun中有4个状态为suspend，2个为full duplex，导致多次flashcopy测试失败，启动数据库遇到很多问题，问题困扰笔者数日，甚至到了怀疑本案例的可行性的地步。