翻车了，总是自以为是，出生产事故了吧！

DBA属于运维范畴，涉猎甚广–DB(Oracle、MySQL、PG)、Linux、硬件、网络、脚本(Python、Shell)、监控(Zabbix、nagois)无所不会，随着工作年限的增长，DBA的经验在增加，就像医生一样，其价值会越来越高。

但是往往就是因为自以为是，所以这不最近翻车了，发生了一次生产事故，盘点便于后期再犯

1.故障现象

这不就是非常经典的归档满嘛，再常见不过了，明明有备份，备份完成删除归档，而且备份的任务也是好的，那为什么归档所在的磁盘还爆满呢？

2.根因分析

排查发现在共享磁盘AMS中
归档日志目录+ARC中的文件
与GV$ARCHIVED_LOG视图中的不一致，

在GV$ARCHIVED_LOG视图中只有将15天的日志记录，
但+ARC里面有所有的归档日志。

查询GV$ARCHIVED_LOG视图中
只有从2024年7月16日至今的日志数据

ASM磁盘归档日志文件
与GV$ARCHIVED_LOG视图中不一致导致了本次故障

这也就是备份任务里一直没有删除15天归档的原因，
因为GV$ARCHIVED_LOG压根没有记录

DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-15';

V$ARCHIVED_LOG保留记录的规则如下

这取决与两个参数CONTROL_FILE_RECORD_KEEP_TIME和MAXLOGHISOTRY，

CONTROL_FILE_RECORD_KEEP_TIME
指controlfile中可重複使用部分最小保留天數，
MAXLOGHISOTRY是控制文件中记录的归档日志最大数量，

v$log_history 视图里所有归档日志文件总数
必须小于等于MAXLOGHISOTRY的设定值 。

一旦归档日志超过这个最大数目，
且参数 control_file_record_keep_time
设定的值在备份的保留策略之外，
即可以被重用，
v$log_history里的相应记录会被清除。

3.故障处理

新增rm删除归档的定时脚本

$crontab -l
30 23 * * * sh /home/oracle/del_arch.sh 1>>/home/oracle/log/del_arch.log
$cat /home/oracle/del_arch.sh
#!/bin/bash
export ORACLE_HOME=/u01/product/grid/11.2.0
export ORACLE_SID=+ASM1
dirname=`date -d "20 days ago" +%Y_%m_%d`
/u01/product/grid/11.2.0/bin/asmcmd
cd +ARC/
cd ARCHIVELOG/
ls -l
rm -rf $dirname
ls -l
exit
EOF

在历史的某个时间，数据库产生大量的归档（没有超过七天），控制文件会分配大量的block用于记录archived log的记录。即使之后，每天生成的归档量很少，数据库依然会以历史最大分配的archived log的行数来循环保存archived log。而不是依照control_file_record_keep_time参数设置的7天。