记一次奇葩的ADG搭建过程

起因

一次主库问题导致需要做failover切换,切换后需要重新搭建备库,但是当初设计的时候,备库的环境本不是做此用途的,因此环境差异较大,导致了这次奇葩问题的出现。

问题描述

 主备库都是ASM环境,不过切换后的主库规划的是单个较大的磁盘组,而备库是多个较小的磁盘组,如下图所示:

    主库

图片

    备库

图片

可以看到,即使备库的磁盘组使用的是external模式,单个磁盘组的最大容量也只在9T左右,而主库数据文件的总大小接近9T,于是第一次duplicate之后,发现报错了,容量不够存放所有的文件了……

解决方法尝试

碰到这种情况,我心想只能恢复数据文件的时候指定路径了,幸好duplicate脚本是可以指定数据文件的路径的,通过SETNEWNAME参数,将源端的数据文件指定一部分到DATA2,另一部分指定到DATA3,再次执行脚本。然后…依然报错:
图片

set newname手动指定数据文件路径
图片

此处提示DATA2空间满
图片

可以看到,setnewname命令是生效了的,但是通过ASMCMD去查看具体文件,发现还是恢复到了DATA2,奇怪。

最终解决办法

无奈只能去翻阅一下Oracle的相关文档了,最终找到了问题所在,参考:OnStandby Datafiles are Going Into Wrong Diskgroup (Db_file_name_convert, Db_create_file_dest ) (Doc ID1408666.1)、DataguardDB/LOG FILE NAME CONVERT has been set but files are created in adifferent directory (Doc ID 1348512.1)

If OMF parameters are set on the standby, then new files on that standby are always created as OMF, regardless of how they were created on the primary. Therefore, if both the DB_FILE_NAME_CONVERT and DB_CREATE_FILE_DEST parameters are set on the standby, the DB_CREATE_FILE_DEST parameter takes precedence.

其实就是ASM环境下启用OMF时,DB_CREATE_FILE_DEST参数的优先级更高,查看辅助实例的pfile文件,确实设置了DB_CREATE_FILE_DEST,将此参数删除,再次执行,问题解决:
图片

总结

正常情况下,DG备库作为容灾,环境是与主库保持一致的。本次遇到的问题应该是极少出现的情况,万一有遇到相同情况,仅以此文作为参考。。。

来源:IT那活儿,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/111848

发表评论

电子邮件地址不会被公开。 必填项已用*标注

技术服务
技术服务
关注抖音
关注抖音
进群学习 侵权联系
返回顶部