Data Guard备库未应用日志的问题一则
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 316rman中执行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数据库问题的一些手段》
《O’Reilly动物书系列》
《最近碰到的一些问题》
《MySQL的几种常用存储引擎》
《创建PDB的两种操作》
《Oracle中执行truncate操作出现hang》
文章分类和索引：
《公众号800篇文章分类和索引》