|
这两天碰到一套库登录提示，
c53b674f6da2f9a8e8e0adf6b899f137.png 查看当前归档日志路径，空间的使用率已经到了100%，于是在rman中，删除30天之前的归档日志文件， 代码语言：javascript 复制 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-30'; 提示这个错误，原来这是套DG，草率了，他的意思是这些归档日志，备库还需要，所以不让删除， 代码语言：javascript 复制 RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process archived log file name=... thread=1 sequence=... 我们登录备库，发现归档空间，同样是100%的使用率，难道同步有问题？ 一通乱敲，发现备库没启动，很可能是之前停机维护导致的。 于是启动到mount状态，同时启动监听器，执行日志应用， 代码语言：javascript 复制 alter database recover managed standby database using current logfile disconnect from session; 但是看到MRP进程等待sequence=61的日志， 代码语言：javascript 复制 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，没同步的日志，还很多， 代码语言：javascript 复制 USERENV('INSTANCE') THREAD# LSQ HSQ ------------------- ---------- ---------- ---------- 1 1 61 316 rman中执行catalog start with(将最新的备份集以及归档日志文件列表导入到控制文中)， 代码语言：javascript 复制 catalog start with '/archive'; 等了一会，现在MRP等的是sequence=317， 代码语言：javascript 复制 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 一直不动，手工注册日志， 代码语言：javascript 复制 alter database register logfile '/archive/1_317_xxxxxxxxxx.dbf'; 反复做了几次catalog，备库的alert记录，还是提示空间满， 代码语言：javascript 复制 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 找出当前能删除的归档日志，物理层执行删除，腾出归档空间， 代码语言：javascript 复制 select 'rm -rf '||name from v$archived_log where name like '%.dbf' and applied='YES' and completion_time<=sysdate-30; 但是发现备库归档空间，有些断号的日志，还很多，一个个scp，很累，或者按照推荐，重建备库，推倒重来。再等一会，只能说Oracle真抗造，日志开始同步了，主备库的sequence，几乎一致了， 代码语言：javascript 复制 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篇文章分类和索引》 (责任编辑：) |
