Menu Close

ORA-19809: limit exceeded for recovery files

lcc0556

1. 故障现象：

　　我们通常会非常密切地观察日志归档目的地的空间使用情况，因为如果空间已满，数据库将被暂停。 特别是，如果日志归档目的地是 USE_DB_RECOVERY_FILE_DEST，那么您必须监视快速恢复区 (FRA) 的使用情况，以防止 ORA-19809。 　　当您遇到以下错误时，您就达到了 FRA 的空间限制。 
ARCH: Error 19809 Creating archive log file to '/dbData/OracleArch/LZUCDB/archivelog/2021_07_20/o1_mf_1_4251_%u_.arc'
2021-07-20T13:29:28.918876+08:00
Errors in file /u01/app/oracle/diag/rdbms/lzucdb/lzucdb/trace/lzucdb_ora_10532.trc:
ORA-16038: log 3 sequence# 4251 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 3 thread 1: '/dbData/OracleData/lzucdb/redo03.log'
USER (ospid: 10532): terminating the instance due to error 16038
如果您已经关闭了数据库，该错误会阻止您启动，这可能很严重。 我们来看看这个错误的内容： 
~]$ oerr ora 19809
19809, 00000, "limit exceeded for recovery files"
//*Cause: The limit for recovery files specified by the
//        DB_RECOVERY_FILE_DEST_SIZE was exceeded.
// *Action: There are five possible solutions:
//          1) Take frequent backup of recovery area using RMAN.
//          2) Consider changing RMAN retention policy.
//          3) Consider changing RMAN archived log deletion policy.
//          4) Add disk space and increase DB_RECOVERY_FILE_DEST_SIZE.
//          5) Delete files from recovery area using RMAN.
然后检查当前的初始化参数： 
SQL> show parameter db_recovery

NAME                     TYPE    VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest            string  /dbData/OracleArch
db_recovery_file_dest_size       big integer 400G
查询闪回区已经使用的大小： 
SELECT file_type,
        percent_space_used as used,
        percent_space_reclaimable as reclaimable,
        number_of_files as "number"
   FROM v$flash_recovery_area_usage;

2. 解决方案：

下面列出了几种可以解决 ORA-19809 的方法：

2.1. Resize FRA

假设你的数据库无法正常打开，此时磁盘仍有更多空间可用于 FRA，则将 FRA 大小调整为更大的值。 
SQL>
STARTUP MOUNT;

ALTER SYSTEM SET db_recovery_file_dest_size=600g SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;
其实，启动数据库到 MOUNT 或 NOMOUNT 没有区别。 只需确保该值不超过 FRA 的整体磁盘空间。 如果您的数据库仍然在线，则使用 SCOPE=BOTH 
SQL>
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=600G SCOPE=BOTH;

2.2. Delete Expired Archived Logs

如果归档日志没有更多空间，请删除过期的归档日志。前提是有大量过期的归档日志可供删除。 
RMAN>
CROSSCHECK ARCHIVELOG ALL;
DELETE EXPIRED ARCHIVELOG ALL;
在 DELETE 后添加 NOPROMPT 使 RMAN 无需用户确认即可直接删除所有存档日志。

2.3. Delete All Archived Logs

无论如何，删除所有存档日志。 
RMAN>
DELETE ARCHIVELOG ALL;
或者使用：
DELETE NOPROMPT ARCHIVELOG ALL;
最后使归档日志列表一致
CROSSCHECK ARCHIVELOG ALL;

2.4. Switch FRA to Another Location

将快速恢复区更改为另一个位置 
SQL>
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/home/oracle/fra_dest' SCOPE=SPFILE;

2.5. Change Destination of Archived Logs

将日志存档目标更改为另一个位置 
SQL>
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='/home/oracle/fra_dest' SCOPE=SPFILE;
同样，您必须重新启动数据库才能使其工作。

3. 预防措施

以下是您可以考虑采取的预防措施，以防止 ORA-19809。

3.1. Larger FRA or Destination

3.2. Smaller Recovery Window

如果当前恢复窗口非常大，则对保留期施加较小的恢复窗口。例如，我们将恢复窗口从 60 天更改为 7 天。 
RMAN>
SHOW ALL;
...
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
然后我们立即根据新策略删除一些过时的备份，如以下命令，或将其放入您的备份脚本中。 
RMAN>
DELETE OBSOLETE;

3.3. Fewer Backup of Archived Logs

更改归档日志删除策略。假设当前设置是备份2次，我们设置为1次或NONE。 
RMAN>
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO SBT;
DELETE OBSOLETE;
参考：https://logic.edchen.org/
Post Views: 633
Tagged