数据库管理-第336期 江湖救急：Oracle归档卡住（20250612）

数据库管理-第336期 江湖救急：Oracle归档卡住（20240612）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

前天晚上开始发烧，昨天头疼欲裂，就没有去上班，调休一天在家休息，到了下午一个以前公司的领导打电话过来，说他们有套RAC好像是归档满了，数据库运行异常，要了个远程桌面看了一下，首先说明一下版本是11.2.0.4。

1 做了些啥

在grid用户使用下面命令查看：

crsctl status res -t

数据库确实处于Stuck Archiver状态。然后，对方已经先做了以下操作：

rman target /
RMAN> delete noprompt force archivelog all completed before 'sysdate-X';

由于这套RAC数据库还有一个DG备库，检查备库信息已经出现GAP了，查看日志发现主库归档已经丢失。

2 深入检查

通过以下命令检查FRA和归档位置：

SQL> show parameter db_recovery_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +DATA
db_recovery_file_dest_size           big integer 500G
SQL> show parameter log_archive_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
...
log_archive_dest_1                   string      location=+DATA
...

这里可以看到FRA有的位置，并有500G的上限，再通过以下命令查看FRA占用

select * from v$recovery_file_dest;

这里查询结果没有记录，但是SPACE_USED已经非常接近SPACE_LIMIT了，但是归档配置在+DATA未使用USE_DB_RECOVERY_FILE_DEST，同时已经删除了归档日志。接下来使用以下命令检查FRA占用：

select * from v$flash_recovery_area_usage;

最终发现FLASHBACK LOG的PERCENT_SPACE_USED已经达到98%以上，且NUMBER_OF_FILES达到253。但是检查对应参数：

SQL> show parameter db_flashback_retention_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target        integer     1440

参数是默认的1440分钟，即24小时，但是在asmcmd中查看闪回日志保留了很长时间的内容，这里应该是有闪回点的原因。

3 解决问题

为了快速恢复业务，和对方确认闪回功能没有起作用因此通过关闭闪回功能清理闪回日志：

shut immediate
startup mount
alter database flashback off;
alter database open;

执行完成后闪回日志被清理，对应的占用均被释放，但是事情还没有结束。由于DG已挂，还要执行下面一些命令来清除DG配置：

alter system set log_archive_config='';
alter system set log_archive_dest_2='';

事情还没完，当对方尝试执行本地备份脚本的时候出现了问题，大概情况是：

SQL> alter database archive log current;

ORA-16038 log one sequence xxx cannot be archived
ORA-00742 Log read detects lost write in thread % d sequence % d block % d
ORA-00312 online log <log#> thread <thread#>: '+<Diskgroup>/<DBName>/group_N.log'

由于时间紧张，且对这套数据库不熟悉，我估算这种情况下大概是因为因为前面频繁重启数据库/调整了归档参数/日志空间满了/强制删除了归档日志造成的，但是数据库一致性并没有受到影响，将当前所有未归档的日志clear即可：

alter database clear unarchived logfile group <group#>;

再执行对应命令即可正常执行。

总结

本期简述了昨天帮朋友江湖救急解决归档卡住的问题。
老规矩，知道写了些啥。