一、环境信息
操作系统：linux 7.6
数据库：oracle 11g rac 主库3节点 dg备库 3节点rac
数据库补丁：11.2.0.4.160719 (23054319)
$opatch lsinv|grep desc
patch description: “ocw patch set update : 11.2.0.4.160719 (23054319)”
patch description: “database patch set update : 11.2.0.4.170418 (24732075)”
二、问题现象
gv$dataguard视图apply lag值为 00 00:00:00表示dg同步正常，oracle 11g中正常情况apply lag在mrp进程所在节点有值，其他节点为空。节点1 apply lag值为 776 22:38:01。dg同步正常。
sql> select inst_id,name, value from gv$dataguard_stats where name in (‘transport lag’, ‘apply lag’) order by 1;
inst_id name value
1 transport lag 00 00:00:00
1 apply lag 776 22:38:01
2 apply lag
2 transport lag 00 00:00:00
3 apply lag 00 00:00:00
3 transport lag 00 00:00:00
6 rows selected.
三、分析过程
1、在备库每个节点检查v$dataguard_stats apply lag值
在备库3个节点分别执行 v$dataguard_stats apply lag值均为 00 00:00:00
sql> select name, value from v$dataguard_stats where name in (‘transport lag’, ‘apply lag’) order by 1;
name value
apply lag 00 00:00:00
transport lag 00 00:00:00
2、计算apply lag值为 776 22:38:01 时间
时间大约是2020年09月02日 17点24分
sql> select to_char(sysdate-776-22/24-38/24/60-01/24/60/60,‘yyyy-mm-dd hh24:mi:ss’) from dual;
2020-09-02 17:24:26
sql>
3、检查主库日志同步情况
主库：
sql> select max(sequence#), thread# from gv$archived_log
where resetlogs_change# = (select max(resetlogs_change#) from gv$archived_log)
group by thread#;
max(sequence#) thread#
843258 1
831828 2
829922 3
备库：
sql> select max(sequence#), thread# from gv$archived_log
where resetlogs_change# = (select max(resetlogs_change#) from gv$archived_log)
group by thread#;
max(sequence#) thread#
843258 1
831829 2
829922 3
4、检查实例启动时间
实例启动的时间看着和2020年09月02日 17点24分没有直接关系
sql> select inst_id,instance_name,host_name,startup_time,status,thread# from gv$instance;
inst_id instance_name host_name startup_time status thread#
3 proddb1 racnode1 2020-03-10 15:50:06 open 3
2 proddb2 racnode2 2019-09-10 22:32:19 mounted 2
1 proddb3 racnode3 2019-09-10 22:31:34 mounted 1
5、数据库日志分析
节点1 alert日志：
…
sat sep 04 00:47:25 2021
alter database recover managed standby database using current logfile disconnect from session
ora-1153 signalled during: alter database recover managed standby database using current logfile disconnect from session…
sat sep 04 00:47:28 2021
rfs[679]: assigned to rfs process 28312
rfs[679]: no standby redo logfiles available for thread 3
…
节点3 alert日志：
…
data guard broker initializing…
data guard broker initialization complete
this instance was first to open
picked lamport scheme to generate scns
wed sep 02 17:24:04 2020
smon: enabling cache recovery
dictionary check beginning
dictionary check complete
database characterset is al32utf8
no resource manager plan active
wed sep 02 17:24:10 2020
starting background process gtx0
wed sep 02 17:24:10 2020
gtx0 started with pid=72, os id=16156
replication_dependency_tracking turned off (no async multimaster replication found)
physical standby database opened for read only access.
completed: alter database open
alter database recover managed standby database using current logfile disconnect from session
attempt to start background managed standby recovery process
wed sep 02 17:24:16 2020
mrp0 started with pid=73, os id=16178
…
四、小结
数据库备库的mrp目前在节点3运行，gv$dataguard视图apply lag值为0表示dg同步正常，
正常情况apply lag在mrp进程所在节点有值，其他节点为空。节点1节点2021年09月04日启动过mrp进程并报错ora-1153，
节点3 2020年09月02日17点24分启动了mrp进程至今。节点1 apply lag值正好为节点mrp启动至今的时间约776天22小时38分。
五、m6米乐安卓版下载的解决方案
1）该信息不影响dg同步可以忽略。
2）将备库节点1的数据库open；或者重启一下备库节点1数据库。
-the end-