Data Guard备库未应用日志的问题一则

Posted 2021-12-11 bisal

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Data Guard备库未应用日志的问题一则相关的知识，希望对你有一定的参考价值。

这两天碰到一套库登录提示，

查看当前归档日志路径，空间的使用率已经到了100%，于是在rman中，删除30天之前的归档日志文件，

DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-30';

提示这个错误，原来这是套DG，草率了，他的意思是这些归档日志，备库还需要，所以不让删除，

RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=... thread=1 sequence=...

我们登录备库，发现归档空间，同样是100%的使用率，难道同步有问题？

一通乱敲，发现备库没启动，很可能是之前停机维护导致的。

于是启动到mount状态，同时启动监听器，执行日志应用，

alter database recover managed standby database using current logfile disconnect from session;

但是看到MRP进程等待sequence=61的日志，

SQL> select process,status,client_process,thread#,sequence#,block#,active_agents,known_agents from  gv$managed_standby where process in('LNS','RFS','LGWR','MRP0') and thread# <>0;
PROCESS   STATUS       CLIENT_P    THREAD#  SEQUENCE#     BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ---------- ------------- ------------
MRP0      WAIT_FOR_GAP N/A               1         61          0             9            9

通过检索v$archived_log，没同步的日志，还很多，

USERENV('INSTANCE')    THREAD#        LSQ        HSQ
------------------- ---------- ---------- ----------
                  1          1         61        316

rman中执行catalog start with(将最新的备份集以及归档日志文件列表导入到控制文中)，

catalog start with '/archive';

等了一会，现在MRP等的是sequence=317，

SQL> select process,status,client_process,thread#,sequence#,block#,active_agents,known_agents from  gv$managed_standby where process in('LNS','RFS','LGWR','MRP0') and thread# <>0;
PROCESS   STATUS       CLIENT_P    THREAD#  SEQUENCE#     BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ---------- ------------- ------------
MRP0      WAIT_FOR_GAP N/A               1        317          0             9            9

一直不动，手工注册日志，

alter database register logfile '/archive/1_317_xxxxxxxxxx.dbf';

反复做了几次catalog，备库的alert记录，还是提示空间满，

Errors in file /oracle/app/oracle/diag/rdbms/conflundg/conflundg/trace/xxxxx_arc1_xxxxx.trc:
ORA-19502: write error on file "/archive/1_433_xxxxxxxxxx.dbf", block number xxxxxx (block size=512)
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 28: No space left on device

找出当前能删除的归档日志，物理层执行删除，腾出归档空间，

select 'rm -rf '||name from  v$archived_log where name like '%.dbf' and applied='YES' and completion_time<=sysdate-30;

但是发现备库归档空间，有些断号的日志，还很多，一个个scp，很累，或者按照推荐，重建备库，推倒重来。再等一会，只能说Oracle真抗造，日志开始同步了，主备库的sequence，几乎一致了，

SQL> select process,status,client_process,thread#,sequence#,block#,active_agents,known_agents from  gv$managed_standby where process in('LNS','RFS','LGWR','MRP0') and thread# <>0;
PROCESS   STATUS       CLIENT_P    THREAD#  SEQUENCE#     BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ---------- ------------- ------------
MRP0      APPLYING_LOG N/A               1        537     181996             9            9
RFS       IDLE         Archival          1          0          0             0            0
RFS       IDLE         LGWR              1        537     181996             0            0

其实在主备库，都创建了crontab定时删除归档日志的任务，但通过调试发现，脚本中指定存储执行日志的文件夹被删除了，导致执行中断。

通过这个案例，一方面说明任务脚本的健壮性还可以提升，例如判断文件夹是否存在，至少不会因为一个非关键因素导致整个逻辑出错，另一方面也暴露出监控的覆盖面问题。

因此针对以上问题和场景，可以增加以下两个监控点功能，

1. 数据库可用性的探测监控，避免数据库异常关闭未打开的情况。

2. 归档日志删除任务的执行监控，避免执行失败，归档日志未删除的情况。

另外，在这个过程中，暴露出对于rman工具的操作和原理的理解上，还是相当地生疏，有待针对性提高。

近期更新的文章：

《Windows调试Oracle数据库问题的一些手段》