暂无图片
暂无图片
5
暂无图片
暂无图片
暂无图片
首页 / 再谈 Oracle 19C 搭建 ADG 密码文件遇到的坑

再谈 Oracle 19C 搭建 ADG 密码文件遇到的坑

原创 JiekeXu All China Database Union 2025-05-30
762

大家好，我是 JiekeXu,江湖人称“强哥”，青学会 MOP 技术社区主席，荣获 Oracle ACE Pro 称号，墨天轮 MVP，墨天轮年度“墨力之星”，拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCA、KCP、KCSM 等众多国产数据库认证证书,今天和大家一起再谈 Oracle 19C 搭建 ADG 密码文件遇到的坑！欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！

前 言

近期我们有几套 Oracle 19c 测试环境因为虚拟机底层磁盘坏块或者资源到期等问题，需要迁移，采用 ADG 架构进行切换迁移，单机环境还好说，搭建 ADG 也没有任何问题，但当搭建 RAC 环境的 ADG 时，又被坑了一次，故记录一下。

ADG 环境搭建

环境搭建算是基础的操作了，以前也做过不少了，19c 环境中因密码文件保存在 ASM 中是有一定的坑的，这个也在第一次 搭建 19c MAA 架构的时候写过了。但是好几年不干这活了，今天又被坑了两次。

ora-rac-n1:/tmp(jiekedb1)$ rman target sys/'oracle'@JIEKEDB auxiliary sys/'oracle'@JIEKETDB

Recovery Manager: Release 19.0.0.0.0 - Production on Thu May 29 18:20:54 2025
Version 19.15.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

connected to target database: JIEKE2P (DBID=3857714555)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04006: error from auxiliary database: ORA-01017: invalid username/password; logon denied

密码错误问题

通过上面可以看到就是密码错误，那么可能是密码文件问题，源端能连接上，目标端不能连接，可能密码文件同步的有问题，那么就重新来同步一次呗。

源端将密码文件从 ASM 复制到文件系统。然后 scp 到备库文件系统

ASMCMD> cd +DATA/JXRT4DB/PASSWORD
ASMCMD> ls -l
Type      Redund  Striped  Time         Sys  Name
PASSWORD  UNPROT  COARSE   APR 29 2022  N    orapwjiekedb1 => +DATA/JIEKEDB/PASSWORD/pwdjiekedb.256.1103297913
PASSWORD  UNPROT  COARSE   APR 29 2022  Y    pwdjiekedb.256.1103297913
ASMCMD> pwcopy pwdjiekedb.256.1103297913 /tmp/orapwJIEKETDB
copying +data/JIEKEDB/PASSWORD/pwdjiekedb.256.1103297913 -> /tmp/orapwJIEKETDB
ASMCMD> exit 

scp -P 10022  /tmp/orapwJIEKETDB   192.168.221.180:/tmp/orapwJIEKETDB

目标端复制密码文件到 ASM 实例中，这个是有个知识点的。复制密码时需要添加 --dbuniquename 才行，不然在 ASM 中会出现 ‘DB_UNKNOWN’ 目录，这个在以前的文章也说过：关于 ASM 中出现 ‘DB_UNKNOWN’ 目录的说明 。即使用如下格式：

ASMCMD> pwcopy --dbuniquename JIEKETDB /tmp/orapwJIEKETDB  +DATA/JIEKETDB/PASSWORD/pwdJIEKETDB
PRCD-1120 : The resource for database JIEKETDB could not be found.
PRCR-1001 : Resource ora.jieketdb.db does not exist
copying /tmp/orapwJIEKETDB -> +DATA/JIEKETDB/PASSWORD/pwdJIEKETDB
ASMCMD-9453: failed to register password file as a CRS resource
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
PASSWORD  UNPROT  COARSE   MAY 29 15:00:00  N    pwdjieketdb => +DATA/JIEKETDB/PASSWORD/pwdjieketdb.256.1202399155
PASSWORD  UNPROT  COARSE   MAY 29 15:00:00  Y    pwdjieketdb.256.1202399155

上面报错是因为数据库和实例资源都没有加入到 CRS 集群资源里，不影响，可使用 srvctl 命令如下格式添加。

图片.png

密码问题小插曲

但是通过上面这样操作以后，还是一样的报错，直接让人抓狂，然后直接去原库修改了 SYS 用户密码，然后拷贝出来密码文件传到目标端，remove 移除数据库重新拷贝进 ASM，还是不行，衰~

srvctl add database -d JIEKETDB  -o /u01/app/oracle/product/19.0.0/dbhome_1 -p +DATA/JIEKETDB/PARAMETERFILE/spfile.257.1202399493 -pwfile +DATA/JIEKETDB/PASSWORD/orapwjieketdb -i jiekedb1 -y AUTOMATIC -r physical_standby 

srvctl add instance -d JIEKETDB -i jiekedb1 -n ora-rac-n1
srvctl add instance -d JIEKETDB -i jiekedb2 -n ora-rac-n2

--srvctl remove database -d jieketdb -f

过了好久发现原来源端数据库密码文件竟然存在于各个节点的本地文件系统 dbs 目录下，瞬间明白了，不知何人什么时候把密码文件又给放到本地了，还又改过密码，怪不得 ASM 上的密码文件日期是 2022 年，总算真像大白了，那就把源端文件系统中的密码文件复制到目标端再来一次就行。

--节点1
ll $ORACLE_HOME/dbs/orapw*
-rw-r----- 1 oracle oinstall 4608 May 29 18:22 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwjiekedb1
--节点2
ll $ORACLE_HOME/dbs/orapw*
-rw-r----- 1 oracle oinstall 4608 May 29 18:24 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwjiekedb2

ASMCMD> cd PASSWORD
ASMCMD> ls -l
Type      Redund  Striped  Time         Sys  Name
PASSWORD  UNPROT  COARSE   APR 29 2022  N    orapwjiekedb1 => +DATA/JIEKEDB/PASSWORD/pwdjiekedb.256.1103297913
PASSWORD  UNPROT  COARSE   APR 29 2022  Y    pwdjiekedb.256.1103297913
ASMCMD> pwd
+DATA/JIEKEDB/PASSWORD
ASMCMD>

已经到六点半左右了，数据同步还没有进行，这里有遇到了一个小问题,不知道是时间久了失去了耐心，还是着急下班还是咋滴，复制过程中使用如下的命令来了一遍，结果就是 rman duplicate 连接还是密码错误。。。

ASMCMD> ls -l
ASMCMD> pwcopy --dbuniquename jieketdb /tmp/orapwjiekedb2  +DATA/JIEKETDB/PASSWORD/
PRCD-1120 : The resource for database jieketdb could not be found.
PRCR-1001 : Resource ora.jieketdb.db does not exist
copying /tmp/orapwjiekedb2 -> +DATA/JIEKETDB/PASSWORD/orapwjiekedb2
ASMCMD-9453: failed to register password file as a CRS resource
ASMCMD> ls -l
ASMCMD> pwcopy --dbuniquename jieketdb /tmp/orapwjiekedb2  +DATA/JIEKETDB/PASSWORD/
PRCD-1120 : The resource for database jieketdb could not be found.
PRCR-1001 : Resource ora.jieketdb.db does not exist
copying /tmp/orapwjiekedb2 -> +DATA/JIEKETDB/PASSWORD/orapwjiekedb2
ASMCMD-9453: failed to register password file as a CRS resource

因为这里复制密码文件时,没有指定文件名，所以还是从文件系统复制过来的名字 orapwjiekedb2 ，这也导致了 srvctl 重新添加实例，rman 连接报错。

最终解决问题

删除 ASM 中复制的密码文件 orapwjiekedb2，重新指定 dbuniquename 和全路径及密码文件名进行复制。注意密码文件名为 orapw+ 或者 orapw+SID。参考文档：‘DB_UNKNOWN’ directory was created when using asmcmd pwcopy (Doc ID 2329386.1)

ASMCMD> pwcopy --dbuniquename <database> /tmp/pw<database> +DATAP/<database>/PASSWORD/pwd<database>

ASMCMD> rm orapwjiekedb2
ASMCMD>
ASMCMD> pwcopy --dbuniquename jieketdb /tmp/orapwjiekedb2  +DATA/JIEKEDB/PASSWORD/orapwJIEKETDB
PRCD-1120 : The resource for database jieketdb could not be found.
PRCR-1001 : Resource ora.jieketdb.db does not exist
copying /tmp/orapwjiekedb2 -> +DATA/JIEKETDB/PASSWORD/orapwJIEKETDB
ASMCMD-9453: failed to register password file as a CRS resource
ASMCMD>
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
PASSWORD  UNPROT  COARSE   MAY 29 18:00:00  N    orapwjieketdb => +DATA/JIEKETDB/PASSWORD/pwdjieketdb.256.1202409413
PASSWORD  UNPROT  COARSE   MAY 29 18:00:00  Y    pwdjieketdb.256.1202409413

图片.png

注册完密码之后，rman 就可以连接了。

ora-rac-n1:/u01/app/oracle/product/19.0.0/dbhome_1/dbs(jiekedb1)$ rman target sys/'oracle'@JIEKEDB auxiliary sys/'oracle'@JIEKETDB

Recovery Manager: Release 19.0.0.0.0 - Production on Thu May 29 18:37:59 2025
Version 19.15.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

connected to target database: JIEKE2P (DBID=3857714555)
connected to auxiliary database: JIEKE2P (not mounted)

RMAN>

RMAN> exit

图片.png

然后便可以 duplicate 复制数据了，放后台执行，下班~第二天来看结果就行。

--脚本后台执行（脚本放在/home/oracle/下）：
vi rman_duplicate.cmd

duplicate target database for standby from active database dorecover nofilenamecheck;

vi rman_dup.sh
rman target sys/'oracle'@JIEKEDB auxiliary sys/'oracle'@JIEKETDB  cmdfile=/home/oracle/rman_duplicate.cmd log=/home/oracle/rman_dup.log append

--后台执行：
chmod o+x rman_dup.sh
nohup sh /home/oracle/rman_dup.sh &

启动复制后，因为带宽原因这里仅使用单线程单通道复制，可根据网速大家自行加通道或者限速。allocate channel p1 type disk rate 50m;

--查看日志
tail -90f rman_dup.log

Recovery Manager: Release 19.0.0.0.0 - Production on Thu May 29 18:44:16 2025
Version 19.15.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

connected to target database: JIEKE2P (DBID=3857714555)
connected to auxiliary database: JIEKE2P (not mounted)

RMAN> duplicate target database for standby from active database  dorecover nofilenamecheck;
2>
Starting Duplicate Db at 2025-05-29 18:44:18
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=3121 instance=jiekedb1 device type=DISK
current log archived

contents of Memory Script:
{
   backup as copy reuse
   passwordfile auxiliary format  '+DATA/JIEKETDB/PASSWORD/orapwjieketdb'   ;
}
executing Memory Script

Starting backup at 2025-05-29 18:44:26
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1225 instance=jxrt4db1 device type=DISK
Finished backup at 2025-05-29 18:44:31

contents of Memory Script:

……省略中间内容……

Finished restore at 2025-05-29 18:44:39

contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script

sql statement: alter database mount standby database
RMAN-05529: warning: DB_FILE_NAME_CONVERT resulted in invalid ASM names; names changed to disk group only.


executing command: SET NEWNAME

Starting restore at 2025-05-29 18:44:45
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service JIEKEDB
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to +DATA
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service JIEKEDB
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00002 to +DATA

…省略中间内容……

archived log file name=+ARCH/JIEKETDB/ARCHIVELOG/2025_05_29/thread_2_seq_78742.275.1202417665 thread=2 sequence=78742
media recovery complete, elapsed time: 00:00:11
Finished recover at 2025-05-29 20:54:44

contents of Memory Script:
{
   delete clone force archivelog all;
}
executing Memory Script

released channel: ORA_DISK_1
released channel: ORA_AUX_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1225 instance=jiekedb1 device type=DISK
archived log file name=+ARCH/JIEKETDB/ARCHIVELOG/2025_05_29/thread_2_seq_78741.274.1202417663 RECID=16 STAMP=1202417664
deleted archived log
archived log file name=+ARCH/JIEKETDB/ARCHIVELOG/2025_05_29/thread_2_seq_78742.275.1202417665 RECID=17 STAMP=1202417664
Deleted 17 objects

Finished Duplicate Db at 2025-05-29 20:55:05

Recovery Manager complete.

当然也可以通过 ASM 查看数据文件的生产情况判断是否同步有问题。

ASMCMD> cd ..
ASMCMD> ls
CONTROLFILE/
DATAFILE/
PARAMETERFILE/
PASSWORD/
ASMCMD> cd datafile
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    SYSTEM.261.1202409889
ASMCMD>
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    SYSTEM.261.1202409889
ASMCMD>
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    SYSAUX.262.1202409935
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    SYSTEM.261.1202409889
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    UNDOTBS1.263.1202410171
DATAFILE  UNPROT  COARSE   MAY 29 18:00:00  Y    USERS.264.1202410225
ASMCMD>

图片.png

最终 ADG 数据库搭建成功，可以正常同步数据~

图片.png

703.png

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

❤️ 欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————

facebook_pro_light_1920 × 1080 副本.png

墨力计划oracle rac adgadgrac to rac adg密码文件
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

文章被以下合辑收录

JiekeXu DBA之路（共243篇）
JiekeXu：来自西北，90 后，获得 11g OCP、11g OCM 认证，墨天轮 MVP，墨天轮 2021 十大突出贡献人物之一，此专栏记录一个菜鸟 DBA 学习成长之路，欢迎关注公众号 JiekeXu DBA之路，一起学习进步。

评论