回忆起来也是有些年没亲自动手搭建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备库的这个文件:
代码语言:javascript复制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,然后辅助实例是备库本机:
代码语言:javascript复制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
需要静态监听来解决,使用 “/” 本地方式连接不上的。静态监听的配置:
代码语言:javascript复制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方式也需要密码文件
代码语言:javascript复制rman target sys/oracle@jydb_p2 auxiliary sys/oracle@jydb_s1
DUPLICATE TARGET DATABASE FOR STANDBY from active database NOFILENAMECHECK;
会报错:
代码语言:javascript复制ERROR:
ORA-01017: invalid username/password; logon denied
因为备库还是nomount状态,所以需要密码文件登陆,但19c的密码文件默认不在$ORACLE_HOME/dbs下面了,而是在ASM磁盘组中。
所以需要pwcopy命令从ASM磁盘组中拷贝到文件系统上,再拷贝到备库$ORACLE_HOME/dbs下面。
代码语言:javascript复制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磁盘组上,需要调整
代码语言:javascript复制SQL> create pfile='/tmp/newpfile.ora' from spfile;
为了不再修改控制文件的名字,就选择依据它生成的spfile(但是在文件系统上)生成pfile,然后依据这个pfile创建spfile到ASM磁盘组组中;
期间需要重启几次实例。
但是可能因为我期间没有启动备库实例2,所以遇到一个问题ORA-304 ,就是参数文件中没有instance_number区分,而实际上,我最初修改的是有这个区分的。。
也就是说不管如何都得修改下喽。那还是趋向于之前的修改方案(只修正参数文件中指定的控制文件位置)
代码语言:javascript复制*.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总是有问题:
代码语言:javascript复制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.添加资源到集群
这个是后面也要做的,也先做了排除影响:
代码语言:javascript复制--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相关信息和进程状态
代码语言:javascript复制--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进程有问题的推论。
代码语言:javascript复制--2.
ALTER DATABASE SWITCHOVER TO jydb_s VERIFY;
提示ORA-16467: switchover target is not synchronized 。
代码语言:javascript复制--3.
set lines 1000
col value for a15
col name for a22
SELECT * FROM V$DATAGUARD_STATS;
延迟几十分钟,不断增长。
代码语言:javascript复制--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.配置一切正常,主库的相关进程TTxx等异常也可能影响到ADG正常传输同步。
好了,收工!