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

1.2.4 案例实施步骤

1.2.4.1 将数据库A设置为online backup模式

SQL>alter database begin backup;

如果只是使用这个flashcopy的target盘,直接启动数据库，可以不执行这个命令（即不需要将数据库设置到online backup模式）。这个结论已经测试过多次，没有问题。

如果需要使用flashcopy和flashcopy时间点后面产生的数据库的归档日志(archielog)文件,进行数据库不完整恢复,则一定需要执行这一步,否则将会遇到’WARNING! Recovering data file % from a fuzzy file’错误,最终导致无法恢复。

1.2.4.2 在DS8100_A上执行mkflash命令，创建flashcopy

Dscli>mkflash –freeze -cp 5000-5002:8000-8002 5100-5102:8100-8102

mkflash 命令分步完成两项任务:

1.使用1秒种左右时间,建立flashcopy的关系

2.开始后台复制工作

1.2.4.3 在DS8100_A执行unfreezeflash操作

Dscli>unfreezeflash 50 51 80 81

在mkflash拷贝完成第一步工作(建立了flashcopy关系)后,就可以执行unfreezeflash命令,解除freeze状态。

这个命令可以和mkflash一起执行(在文本编辑中,编辑好两行命令,复制,粘贴,一起执行),效果更好。

1.2.4.4 将数据库A退出online bacup模式

SQL>alter database end backup;

1.2.4.5 在DS8100_A上,命令查看flashcopy的复制进度

Dscli>lsflash –l 5000-9000

如果当该命令的输出为”CMUC00234I lsflash: No Flash Copy found“，则表示已经完成了flashcopy的复制工作。

本案例在mkflash拷贝时，没有使用-record –persist参数，所以flashcopy复制完成后，flashcopy关系被自动删除；如是使用了-record –persist 参数，则flashcopy复制完成后，flashcopy关系被保留，可以通过查看lsflash –l 命令的输出的各行的OutOfSyncTracks列的值来判断是否完成复制（值为0表示复制完成）。

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

#cfgmgr –v

#importvg –y testvg vpath0

#chown oracle:dba /dev/roar*

#chmod 755 /dev/roar*

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

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

SQL>startup

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

1.2.5 案例总结

在主中心机房的存储上，执行flashcopy复制工作，将一定程度上影响生产环境的运行效率，需要在系统不繁忙的时候进行。如果没有等待flashcopy复制工作完成，就用target盘启动克隆数据库，并投入运行，此时存储需要承受3方面的运行压力：主数据库运行压力、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的源盘，广义地讲应该与有没有做pprc，没有太大关系，所以可以将本案例广义地理解为，使用所有非target的LUN做flashcopy的源盘。