首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >dataguard备库的数据文件的迁移实战(r8笔记第24天)

dataguard备库的数据文件的迁移实战(r8笔记第24天)

作者头像
jeanron100
发布2018-03-19 11:39:11
5990
发布2018-03-19 11:39:11
举报

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

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

第二步中备库没有设置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; 看似一个略带复杂的迁移就这么轻松完成了,感觉做什么技术含量的事情,前期准备充足,在碰到问题的时候才会更加从容。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-02-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档