回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。
正好看下19c的ADG和11g的ADG在部署方面有啥不同？
主备库都是RAC架构，数据库是CDB架构，包含有4个PDB，整个搭建过程还是遇到很多小问题，但基本也都知道原因并能快速解决，也有个别折腾了很久的，蛮有意思，所以记录下本次遇到的问题供日后参考，客户信息已脱敏。
注意：这不是一篇安装手册指引，如果想要安装手册的指引还是参考之前的文章：
新的版本有细微差异（密码文件位置等）影响到部署的部分也会在本文提到。
- 1.主备库ASM磁盘组名称问题
- 2.主备库的环境变量不一致
- 3.使用scp拷贝文件时发现权限问题
- 4.评估duplicate方式快速创建备库
- 5.duplicate方式只需要创建参数文件
- 6.duplicate方式是需要静态监听的
- 7.duplicate方式也需要密码文件
- 8.只有参数文件没在ASM磁盘组上,需要调整
- 9.开启ADG实时同步时，主库节点1传输一直有问题
1.主备库ASM磁盘组名称问题
主备库的ASM磁盘组名称有差异，实际上这也不影响搭建，反正配DG时有convert参数可以指定转换规则。 但为了规矩，不给后人挖坑，还是修正成一样的了，反正备库还没东西，直接使用asmca删除重建一样名字的磁盘组。 这样convert参数只需指定db_unique_name即可。2.主备库的环境变量不一致
同样不影响，但还是为了规范还是修正为一样了。 主要指ORACLE_BASE、ORACLE_HOME这些，而ORACLE_SID为了区分可以规划成不一样。3.使用scp拷贝文件时发现权限问题
主库因为已纳入堡垒机，有安全设置，无法输入密码登陆，所以scp拷贝也不成； 而备库尚未纳入可以密码登陆，所以可以都通过备库来进行scp拷贝； 比如：主库需要备库的tnsnames.ora文件，无法在备库scp到主库，那么就反向来操作，去主库scp备库的这个文件：scp 10.xx.16.1:/dba/oracle/product/19.16.0.0/db_1/network/admin/tnsnames.ora ./
4.评估duplicate方式快速创建备库
首先评估这套环境是CDB架构，下面有4个PDB，查询cdb_data_files显示总大小有875GB，而实际cdb_segments只有50GB的样子，说明实际库还比较小，所以即便不开并行，15分钟也搞定了整个duplicate过程。 该备库平均每秒1GB写入速率的样子。5.duplicate方式只需要创建参数文件
如果选用duplicate方式，其实无需手工创建备库的控制文件，因为会在duplicate过程中自动创建； 而参数文件的修改，还是选择vi批量修改的方式，注意增加db_unique_name的设置；6.duplicate方式是需要静态监听的
使用duplicate复制，可以写好脚本，在备库执行，连接到比较清闲的生产节点2，然后辅助实例是备库本机：rman target sys/oracle@jydb_p2 auxiliary /
DUPLICATE TARGET DATABASE FOR STANDBY from active database NOFILENAMECHECK;
发现会报错
RMAN-06217: not connected to auxiliary database with a net service name
需要静态监听来解决，使用 “/” 本地方式连接不上的。静态监听的配置：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = jydb_s)
(ORACLE_HOME = /dba/oracle/product/19.16.0.0/db_1)
(SID_NAME = jydbs1)
)
)
7.duplicate方式也需要密码文件
rman target sys/oracle@jydb_p2 auxiliary sys/oracle@jydb_s1
DUPLICATE TARGET DATABASE FOR STANDBY from active database NOFILENAMECHECK;
会报错：
ERROR:
ORA-01017: invalid username/password; logon denied
因为备库还是nomount状态，所以需要密码文件登陆，但19c的密码文件默认不在$ORACLE_HOME/dbs下面了，而是在ASM磁盘组中。
所以需要pwcopy命令从ASM磁盘组中拷贝到文件系统上，再拷贝到备库$ORACLE_HOME/dbs下面。
ASMCMD> pwcopy +DATA_DG/jydb_P/PASSWORD/pwdjydb_p.xxx.xxxxxxxxxx /tmp/orapwjydb_s
scp /tmp/orapwjydb_s standby_server:$ORACLE_HOME/dbs/orapwjydbs1
备库实例2也可参考。或者干脆放到ASM磁盘组共享。
另外注意文件系统上的密码文件的命名是orapw
8.只有参数文件没在ASM磁盘组上,需要调整
SQL> create pfile='/tmp/newpfile.ora' from spfile;
为了不再修改控制文件的名字，就选择依据它生成的spfile（但是在文件系统上）生成pfile，然后依据这个pfile创建spfile到ASM磁盘组组中；
期间需要重启几次实例。
但是可能因为我期间没有启动备库实例2，所以遇到一个问题ORA-304 ，就是参数文件中没有instance_number区分，而实际上，我最初修改的是有这个区分的。。
也就是说不管如何都得修改下喽。那还是趋向于之前的修改方案（只修正参数文件中指定的控制文件位置）
*.control_files='+DATA_DG/jydb_S/CONTROLFILE/current.257.1121430431','+FRA_DG/jydb_S/CONTROLFILE/current.257.1121430431'#Restore Controlfile
create spfile='+DATA_DG' from pfile='/tmp/pfile_jydb_s.ora';
然后两个地方设置指定这个新生成的spfile位置。确保下次启动能读取这个位置的spfile。
9.开启ADG实时同步时，主库节点1传输一直有问题
SRL的thread# 1总是有问题：ORA-12154: TNS:Could not resolve the connect identifier specified
这个问题折腾了好久。。最终解决方案不重要，重要的是尝试过程：
a.尝试修改了备库的 local_listener，为正确的vip串；
开始发现local_listener未设置，监听也未注册，所以手工设置。但问题依旧。。
b.尝试修改tnsnames.ora文件，统一主库/备库。共4个节点。
因为ORA-12154最可能的还是这个配置，重新统一确认配置完成一致（copy方式确保），然后主备各节点互相验证远程连接，均OK；但问题依旧。。
c.尝试多次切换日志和归档current日志，均无果：
alter system switch logfile;
alter system archive log current;
但问题依旧。。
d.尝试defer后再enable链路log_archive_dest_state_2
因为有时这样反复激活下可以解决一些问题，但问题依旧。。
e.步骤8中的控制文件，后来折腾后又要重新设置listener相关参数
local_listener
remote_listener
但问题依旧。。
f.去掉静态监听设置；
检查监听状态时发现UNKONW的状态，其实不影响，但为了看起来规范，去掉已经不再需要的静态监听。
但问题依旧。。
g.尝试重建SRLs。 thread 1 2
有些怀疑是不是SRLs有异常，为了排除这个干扰项，SRLs全部删除重建。
但问题依旧。。
h.添加资源到集群
这个是后面也要做的，也先做了排除影响：
--oracle user:
srvctl add database -db jydb_s -dbname jydb_p -oraclehome /dba/oracle/product/19.16.0.0/db_1 -dbtype RAC -spfile +DATA_DG/....spfile.xxx.xxxxx -role physical_standby -diskgroup DATA_DG,FRA_DG
srvctl add instance -db jydb_s -instance jydbs1 -node jystdrac1
srvctl add instance -db jydb_s -instance jydbs1 -node jystdrac2
srvctl start database -d jydb_s
但问题依旧。。
b2.再次尝试修改tnsnames.ora文件，统一主库/备库。共4个节点。
主备库tnsnames.ora中都修改为scanip。
但问题依旧。。
i.查询DG相关信息和进程状态
--1.
SELECT * FROM (SELECT INST_ID, SEVERITY, ERROR_CODE,TO_CHAR(TIMESTAMP,'MON-DD HH24:MI') time_stamp, MESSAGE
FROM GV$DATAGUARD_STATUS
ORDER BY MESSAGE_NUM DESC)
WHERE ROWNUM < 11;
severity列中的Error都是12154，这个Error和之前诊断（直接查看gv$archive_dest的error信息）一致。另外severity列中的Warning类型对应的message列都是网络重连有问题。看起来就是网络问题？
是防火墙的锅？但是有一点很奇怪，就是主库节点2到备库目前看是OK的，那防火墙的可能性比较小，因为不太可能同一套环境的两个节点网络策略还不一样。
而且毕竟tnsping和sqlplus互联测试都OK。此时其实也更加坚定了节点1进程有问题的推论。
--2.
ALTER DATABASE SWITCHOVER TO jydb_s VERIFY;
提示ORA-16467: switchover target is not synchronized 。
--3.
set lines 1000
col value for a15
col name for a22
SELECT * FROM V$DATAGUARD_STATS;
延迟几十分钟，不断增长。
--4.
SELECT INST_ID, PROCESS, STATUS, CLIENT_PROCESS, THREAD#, SEQUENCE#, BLOCK# FROM GV$MANAGED_STANDBY WHERE CLIENT_PROCESS='LGWR' OR PROCESS='MRP0';
这个是比较关键的结果，MRP0进程的状态是“WAIT_FOR_LOG”，RFS进程的状态是“IDLE”，但是THREAD#只有2的一行；
也跟最初观察到的现象一致，就是主库节点1的日志无法连接到备库。
j.怀疑主库进程存在异常
因为能检查的都查了很多遍，确实是没问题，最终找窗口重启下主库。。也顺便让之前在主库设置的convert参数生效，两个节点都需要重启。
重启主库后，自动恢复正常。。
再次查询验证上一步的查询：
- severity列全是Control的类型，message列也都是正常开始归档和完成归档的信息。
- 返回“Database altered.”
- 传输和应用延迟全部显示为0；
- 多了一行RFS进程，对应THREAD#=1的情况；也就是之前两行（一个MRP0，一个RFS），现在三行（一个MRP0，两个RFS，每个RFS对应一个thread#）
问题解决。
最后检查下基础配置，尤其是检查有没有删除归档日志的策略（确定有定时任务定期删除）。
最后小结一下：
1.duplicate方式备库需要静态监听，搭建完成后可以删除掉；
2.新版本的主库密码文件已经存放在ASM磁盘组中，需要pwcopy命令进行拷贝；
3.配置一切正常，主库的相关进程异常也可能影响到ADG正常传输同步。
好了，收工！
标签：主库,ASM,备库,部署,DG,ADG,duplicate,jydb,19c From： https://www.cnblogs.com/jyzhao/p/16920548.html