案例：ADG环境遇到redo日志member路径有误以及RMAN-6571错误
最近先后帮客户做了两套从虚拟化环境到物理机的数据库迁移，都是Linux系统，Oracle 11.2.0.4的RAC，最终选定ADG方案实现迁移，简单高效。
在之前的文章Oracle 11g ADG 部署(duplicate)快速参考中，已经详细介绍了搭建步骤。但本次环境准备时还是遇到些小问题，本文记录下解决过程。
问题1:备库Redo的一个member路径有误
按流程做完发现备库在open后，Redo的一个member路径有误，都是+FRA磁盘组：
SQL> select member from v$logfile;
MEMBER
-----------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.383.1050758359
+FRA
+DATA/jingyus/onlinelog/group_2.384.1050758359
+FRA
+DATA/jingyus/onlinelog/group_3.385.1050758359
+FRA
+DATA/jingyus/onlinelog/group_4.386.1050758359
+FRA
+DATA/jingyus/onlinelog/group_5.397.1050758359
+FRA
+DATA/jingyus/onlinelog/group_6.398.1050758361
MEMBER
-----------------------------------------------------------
+FRA
+DATA/jingyus/onlinelog/group_7.399.1050758361
+FRA
+DATA/jingyus/onlinelog/group_8.400.1050758361
+FRA
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
MEMBER
----------------------------------------------------------
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
26 rows selected.
这样的路径不全，也无法使用常规命令删除掉。
首先想到的是查convert参数是否配置有误：
--convert:
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string jingyu, jingyus
log_file_name_convert string +fra/jingyu, +arch/jingyus, jingyu,
jingyus
确认符合实际要求，没有问题。
检查db_recovery相关参数：
SQL> show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +FRA
db_recovery_file_dest_size big integer 90G
果然是这里有问题，新环境应该是+ARCH磁盘组，而且客户这里的新规范是不配置此参数，这里将参数去掉，重启实例生效：
SQL> alter system reset db_recovery_file_dest_size;
System altered.
SQL> alter system reset db_recovery_file_dest;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 7.4826E+10 bytes
Fixed Size 2261048 bytes
Variable Size 1.3959E+10 bytes
Database Buffers 6.0666E+10 bytes
Redo Buffers 199049216 bytes
Database mounted.
SQL> show parameter db_recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 0
SQL>
问题2:switch database to copy报错RMAN-6571
上面改完之后，已经有问题的member并不会自己修复，需要去主库生成适用于备库的控制文件，在备库进行恢复：
--standby controlfile
primary:
RMAN> backup current controlfile for standby format '/tmp/std_ctl.bak';
scp to standby.
standby:
shutdown immediate
startup nomount
RMAN> restore standby controlfile from '/tmp/std_ctl.bak';
alter database mount;
此时数据文件的名字因为OMF并不一样，convert转换的只有jingyu->jingyus，下面是示例：
selct name from v$datafile;
select member from v$Logfile;
NAME
--------------------------------------------------------------------------------
+DATA/jingyu/datafile/dmb_ts.381.1046616217
+DATA/jingyu/datafile/dmb_ts.383.1047808801
+DATA/jingyu/datafile/dmo_ts.384.1048122001
+DATA/jingyu/datafile/dmb_ts.385.1048755601
+DATA/jingyu/datafile/dmb_ts.386.1049724001
+DATA/jingyu/datafile/rpm.387.1049986803
116 rows selected.
--由于配置了db_file_name_convert 参数：
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string jingyu, jingyus
--会按上面设置的规则转换：
NAME
--------------------------------------------------------------------------------
+DATA/jingyus/datafile/dmb_ts.381.1046616217
+DATA/jingyus/datafile/dmb_ts.383.1047808801
+DATA/jingyus/datafile/dmo_ts.384.1048122001
+DATA/jingyus/datafile/dmb_ts.385.1048755601
+DATA/jingyus/datafile/dmb_ts.386.1049724001
+DATA/jingyus/datafile/rpm.387.1049986803
116 rows selected.
但实际上我们同步过来的数据文件是这样：
+DATA/jingyus/datafile/dmb_ts.342.1050704211
+DATA/jingyus/datafile/dmb_ts.363.1050706625
+DATA/jingyus/datafile/dmo_ts.364.1050706641
+DATA/jingyus/datafile/dmb_ts.365.1050706649
+DATA/jingyus/datafile/dmb_ts.366.1050706655
+DATA/jingyus/datafile/rpm.367.1050706663
116 rows selected.
最直接的方式是通过数据库的rename file 命令进行一一更正，但是比较麻烦，有一个通用的技巧就是将这些真实的文件catalog到rman中，将以copy的方式识别，然后直接switch到copy，就实现了更名的目的，且不容易出错：
catalog start with '+DATA/jingyus/datafile';
switch database to copy;
结果10号文件报错RMAN-6571，跳过10号文件，也是其他文件接连报错，看oerr的解释：
$ oerr rman 6571
6571, 1, "datafile %d does not have recoverable copy"
// *Cause: The SWITCH command with the option TO COPY was specified but
// the datafile has no valid copy to switch to.
// *Action: Verify whether the datafile has a valid datafile copy.
顺手还去查了MOS文档
- OERR: RMAN-6571 "datafile %d does not have recoverable copy" Reference Note (Doc ID 291493.1)
也没找到有效的解决方案。后来走了些弯路，又尝试做了一次备库控制文件的创建，效果依旧。
此时想到不如查下文件头，看看到底差异在哪，结果发现文件10-20都是别名的方式，根本不需要去switch：
SQL> select file#, name, checkpoint_change# from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE#
------------------------------ ------------------------------------------------------------------ ------------------------------
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 +DATA/jingyus/datafile/dmb_ts01.dbf 98520735063
11 +DATA/jingyus/datafile/dmb_ts02.dbf 98520735063
FILE# NAME CHECKPOINT_CHANGE#
------------------------------ ------------------------------------------------------------------ ------------------------------
12 +DATA/jingyus/datafile/dmb_ts03.dbf 98520735063
13 +DATA/jingyus/datafile/dmb_ts04.dbf 98520735063
14 +DATA/jingyus/datafile/dmo_ts01.dbf 98520735063
15 +DATA/jingyus/datafile/dmo_ts02.dbf 98520735063
16 +DATA/jingyus/datafile/dmo_ts03.dbf 98520735063
17 +DATA/jingyus/datafile/etl_ts01.dbf 98520735063
18 +DATA/jingyus/datafile/rpm01.dbf 98520735063
19 +DATA/jingyus/datafile/use01.dbf 98520735063
20 +DATA/jingyus/datafile/dms_ts01.dbf 98520735063
21 0
22 0
...省略后面无问题的显示。
再次验证下问题文件数，就是有这11个：
SQL> select checkpoint_change#, count(*) from v$datafile_Header group by checkpoint_change#;
CHECKPOINT_CHANGE# COUNT(*)
------------------------------ ------------------------------
0 105
98520757598 11
确认后，就只需要将需要switch的文件列出来：
switch datafile 1,2,3,4,5,6,7,8,9,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101 to copy;
再次查询：
SQL> set num 30
SQL> select checkpoint_change#, count(*) from v$datafile_Header group by checkpoint_change#;
CHECKPOINT_CHANGE# COUNT(*)
------------------------------ ------------------------------
98520757598 116
此时开库，名字也都是OK：
SQL> alter database open;
Database altered.
SQL> select member from v$logfile;
MEMBER
---------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.257.950284165
+ARCH/jingyus/onlinelog/group_1.257.950284167
+DATA/jingyus/onlinelog/group_2.258.950284167
+ARCH/jingyus/onlinelog/group_2.258.950284169
+DATA/jingyus/onlinelog/group_3.265.950286045
+ARCH/jingyus/onlinelog/group_3.259.950286047
+DATA/jingyus/onlinelog/group_4.266.950286047
+ARCH/jingyus/onlinelog/group_4.260.950286049
+DATA/jingyus/onlinelog/group_5.286.959014699
+ARCH/jingyus/onlinelog/group_5.266.959014703
+DATA/jingyus/onlinelog/group_6.287.959014717
MEMBER
---------------------------------------------------------
+ARCH/jingyus/onlinelog/group_6.273.959014719
+DATA/jingyus/onlinelog/group_7.288.959014729
+ARCH/jingyus/onlinelog/group_7.277.959014731
+DATA/jingyus/onlinelog/group_8.289.959014753
+ARCH/jingyus/onlinelog/group_8.269.959014755
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
26 rows selected.
然后启动备库的mrp时，会自动删除+ARCH 下的路径，这个应该就是因为我们前面去掉了db_recover的相关设置：
--recover ,+ARCH auto deleted..
SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------
+DATA/jingyus/onlinelog/group_1.397.1050759359
+DATA/jingyus/onlinelog/group_2.398.1050759359
+DATA/jingyus/onlinelog/group_3.399.1050759359
+DATA/jingyus/onlinelog/group_4.400.1050759361
+DATA/jingyus/onlinelog/group_5.401.1050759361
+DATA/jingyus/onlinelog/group_6.402.1050759361
+DATA/jingyus/onlinelog/group_7.403.1050759361
+DATA/jingyus/onlinelog/group_8.404.1050759363
+DATA/jingyus/standbylog/standby_group_101.log
+DATA/jingyus/standbylog/standby_group_102.log
+DATA/jingyus/standbylog/standby_group_103.log
+DATA/jingyus/standbylog/standby_group_104.log
+DATA/jingyus/standbylog/standby_group_105.log
+DATA/jingyus/standbylog/standby_group_201.log
+DATA/jingyus/standbylog/standby_group_202.log
+DATA/jingyus/standbylog/standby_group_203.log
+DATA/jingyus/standbylog/standby_group_204.log
+DATA/jingyus/standbylog/standby_group_205.log
18 rows selected.
至此，遇到的问题就都解决了。松一口气，等待晚上配合切换即可。
案例：ADG环境遇到redo日志member路径有误以及RMAN-6571错误的更多相关文章
- Spring boot+ logback环境下，日志存放路径未定义的问题
日志路径未定义 环境:Spring boot + logback 配置文件: <configuration> <springProfile name="dev"& ...
- mysql日志文件路径
SHOW VARIABLES LIKE 'general_log_file';日志文件路径SHOW VARIABLES LIKE 'log_error';错误日志文件路径SHOW VARIABLES ...
- Hadoop案例（五）过滤日志及自定义日志输出路径（自定义OutputFormat)
过滤日志及自定义日志输出路径(自定义OutputFormat) 1.需求分析 过滤输入的log日志中是否包含xyg (1)包含xyg的网站输出到e:/xyg.log (2)不包含xyg的网站输出到e: ...
- Oracle ADG环境搭建
部署 环境介绍 1,软件安装前基础部署 (两台做同样操作) 1.1,关闭selinux和防火墙 因为centos7里面没有/etc/sysconfig/iptables这个配置文件所以我们首先用yum ...
- 【恢复】Redo日志文件丢失的恢复
第一章 Redo文件丢失的恢复 1.1 online redolog file 丢失 联机Redo日志是Oracle数据库中比较核心的文件,当Redo日志文件异常之后,数据库就无法正常启动,而且有丢 ...
- Oracle11g ADG环境实施文档-1204
Oracle11g adg 环境搭建实施手册-1204 2017年8月30日 9:16 11g adg 环境搭建实施手册-0824 2017年8月24日 10:18 ################# ...
- 11g adg 环境搭建实施手册-0908
11g adg 环境搭建实施手册-0908 2017年8月30日 9:16 11g adg 环境搭建实施手册-0824 2017年8月24日 10:18 ####################### ...
- oracle redo日志维护
环境 OS:Red Hat Linux As 5 DB:10.2.0.1 1.添加日志组 alter database add logfile group 4 ('/u01/app/oracle/or ...
- 非IMU模式下DML语句产生的REDO日志内容格式解读
实验内容:非IMU模式下DML语句产生的REDO日志内容格式解读 最详细的解读是UPDATE的. 实验环境准备 11G中默认是开启IMU特性的,做此实验需要关闭此特性. alter system se ...
随机推荐
- JavaScript 循环数组的时候调用方法中包含Promise的时候如何做到串行
forEach是不能阻塞的, 默认[并行]方式 const list = [1, 2, 3] const square = num => { return new Promise((resolv ...
- Homekit_人体感应器
前置需求: 苹果手机一台 Homekit人体感应一台 USB供电线一根 这款产品内置人体红外感应器,使用圆环设计,增大了其接触面积,使感应变得更加灵敏,重量轻,方便将其粘贴到墙上,同时支持二次开发,如 ...
- 如何去除List集合中的重复元素?
一.问题由来 在实际开发的时候,我们经常会碰到这么一个问题:一个集合容器里面有很多重复的对象,里面的对象没有主键,或者说忽略主键,根据业务的需求,我们需要根据条件筛选出没有重复的对象. 二.去重操作 ...
- Oracle数据库安装教程
一.准备文件 Oracle安装程序(64位)下载地址: http://download.oracle.com/otn/nt/oracle11g/112010/win64_11gR2_database_ ...
- OptaPlanner的新约束表达方式 Constraint Streams
有好些时间没有写过关于OptaPlanner的东西了,其实近半年来,OptaPlanner还是推出了不少有用.好用的新特性.包括本文讲到的以Stream接口实现评分编程.关于OptraPlanner的 ...
- Jmeter系列（49）- 详解 HTTP Cookie 管理器
如果你想从头学习Jmeter,可以看看这个系列的文章哦 https://www.cnblogs.com/poloyy/category/1746599.html 简单介绍 功能一 首先,它像网络浏览器 ...
- 关于Spark RDD 的认识
一.基本认识 RDD 是Spark大数据计算引擎中,抽象的一种数据结构. RDD(Resilient Distributed Dataset),中文意思是弹性分布式数据集,它是Spark中的基本抽象. ...
- 微信DLL劫持反弹shell复现
(该文参考网络他人资料,仅为学习,不许用于非法用途) 一.操作环境 Windows7 : 微信 , Process Explorer(任务管理工具,本实验中用于查找微信程序调用的DLL文件) Ka ...
- 致敬学长！J20航模遥控器开源项目计划【开局篇】 | 先做一个开机界面 | MATLAB图像二值化 | Img2Lcd图片取模 | OLED显示图片
我们的开源宗旨:自由 协调 开放 合作 共享 拥抱开源,丰富国内开源生态,开展多人运动,欢迎加入我们哈~ 和一群志同道合的人,做自己所热爱的事! 项目开源地址:https://github.com/C ...
- springMVC入门（八）------拦截器
简介 springMVC拦截器针对处理器映射器进行拦截配置 如果在某个处理器映射器中配置拦截,经过该处理器映射器映射成功的Handler最终使用该拦截器 由于springMVC支持配置多个处理器映射器 ...