部署19c ADG过程中的问题处理

回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。
正好看下19c的ADG和11g的ADG在部署方面有啥不同？
主备库都是RAC架构，数据库是CDB架构，包含有4个PDB，整个搭建过程还是遇到很多小问题，但基本也都知道原因并能快速解决，也有个别折腾了很久的，蛮有意思，所以记录下本次遇到的问题供日后参考，客户信息已脱敏。

注意：这不是一篇安装手册指引，如果想要安装手册的指引还是参考之前的文章：

• 模拟生产搭建Standby RAC实验环境(11.2.0.4 DG)

新的版本有细微差异（密码文件位置等）影响到部署的部分也会在本文提到。

• 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,这个SID指的是实例的名字，且区分大小写，比如这里就需要orapwjydbs1这样才可以（Linux平台区分大小写），之前大写和实际实例名字不一致，就登录不上。

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参数生效，两个节点都需要重启。
重启主库后，自动恢复正常。。
再次查询验证上一步的查询：

1. severity列全是Control的类型，message列也都是正常开始归档和完成归档的信息。
2. 返回“Database altered.”
3. 传输和应用延迟全部显示为0；
4. 多了一行RFS进程，对应THREAD#=1的情况；也就是之前两行（一个MRP0，一个RFS），现在三行（一个MRP0，两个RFS，每个RFS对应一个thread#）

问题解决。
最后检查下基础配置，尤其是检查有没有删除归档日志的策略（确定有定时任务定期删除）。

最后小结一下：
1.duplicate方式备库需要静态监听，搭建完成后可以删除掉；
2.新版本的主库密码文件已经存放在ASM磁盘组中，需要pwcopy命令进行拷贝；
3.配置一切正常，主库的相关进程TTxx等异常也可能影响到ADG正常传输同步。

好了，收工！