转载

dataguard备库的数据文件的迁移实战

在前几天也花了一点时间测试了一下关于备库数据文件的迁移，这部分的工作看起来还是比较常规的，当然方法也很多。但是在实际工作中就更不能掉以轻心，所有的操作都要有理有据。都要经过一些严格的测试，如果测试不当，很可能在后期就会出现一些看似奇怪的问题，造成一些不必要的麻烦和影响。
dataguard备库的数据文件的迁移实战

所以在开始之前，做了下面的准备工作。
1.在zabbix中设定了维护窗口，这样在维护操作中就不会报警。
2.检查目前的备库参数设置，是否开启了闪回区，目前的文件路径设置情况和归档情况
3.检查目标文件路径的情况，涉及权限，文件夹属主，大小等
4.准备完整的脚本，估算时间。
第一步中，设定维护窗口的方式如下，加入对应的机器就万事大吉了。
dataguard备库的数据文件的迁移实战

第二步中备库没有设置db_file_name_convert和log_file_name_convert,所以说是默认按照主库的路径来生成的。
检查闪回区竟然没有开启，还是不太规范，都是指定使用了归档路径。
SQL> show parameter recovery
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
db_recovery_file_dest                string
db_recovery_file_dest_size           big integer 0
SQL> show parameter log_archive_dest
NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------
log_archive_dest                     string
log_archive_dest_1                   string      location="/U01/app/oracle/admin/testdb/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)
对此的产出脚本如下：
alter system set db_recovery_file_dest='/U01/app/oracle/admin/testdb/arch' scope=spfile;
alter system set db_recovery_file_dest_size=100G;
alter system log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST' scope=spfile;
对于数据文件和日志文件的路径切换
alter system set db_file_name_convert='/U01/app/oracle/oradata/testdb','/DATA/testdb' scope=spfile;
alter system set log_file_name_convert='/U01/app/oracle/oradata/testdb,/Redo/testdb' scope=spfile;
第三步中
磁盘空间情况如下，权限属主都没有问题。
$ df -h
Filesystem      Size Used Avail Use% Mounted on
。。。
/dev/sda6       510G 393G   92G 82% /U01
/dev/sdc1       733G 197M 696G   1% /DATA
/dev/sdb2       534G 198M 506G   1% /Redo
。。。
第四步中，如果采用rman的方式迁移数据文件就需要提前准备脚本。可以使用如下的方式生成动态脚本。
select 'COPY DATAFILE '||file#||' to '||chr(39)||name||chr(39)||';'||chr(10)
||' switch datafile '||file#||' to copy;'||chr(10)
||' sql '||chr(39)||'alter database datafile '||file#||' online;' from v$datafile;
生成内容如下：
COPY DATAFILE 5 to '/DATA/testdb/acc_data01.dbf';
switch datafile 5 to copy;
sql 'alter database datafile 5 online;
。。。
准备好脚本就开始实践了。
因为这个操作有些参数需要重启生效，而且这套环境是一主两备，所以重启暂时没有什么风险。因为考虑到修改convert参数会导致dg broker检查失败，需要修改dg broker的参数，如此一来还不如直接做remove操作，迁移完成直接再add database即可，也就免去了更多的属性修改设定。
所以部署脚本如下：
remove database stestdb2;   --在dg broker中操作
alter system set db_recovery_file_dest='/U01/app/oracle/admin/testdb/arch' scope=spfile;
alter system set db_recovery_file_dest_size=100G;
alter system set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST' scope=spfile;
alter system set db_file_name_convert='/U01/app/oracle/oradata/testdb','/DATA/testdb' scope=spfile;
alter system set log_file_name_convert='/U01/app/oracle/oradata/testdb','/Redo/testdb' scope=spfile;
重启数据库实例至mount阶段
然后就准备开始rman迁移文件了。
但是刚开始就碰到一些意料之外的事情。迁移的时候竟然提示找不到文件。
RMAN> COPY DATAFILE 1 to '/DATA/testdb/system01.dbf';
Starting backup at 2016-02-29 10:47:21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=6596 devtype=DISK
could not read file header for datafile 1 error reason 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 02/29/2016 10:47:21
RMAN-06056: could not access datafile 1
经过一番排查发现原来在v$datafile里，文件路径已经根据db_file_name_convert变成了最新的路径了。
即原来的路径
FILE_NAME
------------------------------------------------------------
/U01/app/oracle/oradata/testdb/users01.dbf
/U01/app/oracle/oradata/testdb/sysaux01.dbf
/U01/app/oracle/oradata/testdb/undotbs01.dbf
在重启之后v$datafile里面已经变成了下面的样子。
FILE_NAME
------------------------------------------------------------
/DATA/testdb/users01.dbf
/DATA/testdb/sysaux01.dbf
/DATA/testdb/undotbs01.dbf
当然这部分信息在官方文档中也是有出处的。可以参考http://www.di.unipi.it/~ghelli/didattica/bdldoc/B19306_01/backup.102/b14191/rcmdupdb002.htm
对于这部分内容，还是会有一个优先级设定。按理说这部分信息是写在控制文件中的。没想到通过convert的数据看参数应优先生成了。
那么我们需要做的事情就更简单了。只需要操作系统级拷贝数据文件即可。
拷贝完成之后，在dg broker中添加这个实例即可。
add database stestdb2 as
connect identifier is stestdb2
maintained as physical;
enable database stestdb2;
看似一个略带复杂的迁移就这么轻松完成了，感觉做什么技术含量的事情，前期准备充足，在碰到问题的时候才会更加从容。

正文到此结束