闪回恢复区空间不足导致DataGuard远程归档失败

　　前段时间搭建了DataGuard环境（Oracle11gR2），采用Physical Standby，工作于最大性能模式，最近在对主库的操作系统日志例行检查时发现有大量的错误信息：

Archive process error: ORACLE Instance orcl - Archival Error. Archiver continuing.

　　经过检查，上述信息最早出现在12个小时之前，不过相关业务系统一直未见异常，看来问题并不严重。由于错误和归档进程有关，先检查了下主库的归档日志，发现从错误信息第一次出现的时间开始，归档日志文件的大小由原来的40M左右变为5M以下，难道是业务系统做了升级导致归档过于频繁？于是电话联系开发负责人，得到的回复是未做任何操作。看来只能检查诊断日志了，发现有如下提示：

Mon Mar 30 04:32:03 2015

Thread 1 advanced to log sequence 24337 (LGWR switch)

  Current log# 1 seq# 24337 mem# 0: D:\ORA\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_1_970693O2_.LOG

  Current log# 1 seq# 24337 mem# 1: D:\ORA\LOG_ONLINE_DEST_02\REDO_G01_M02.RDO

  Current log# 1 seq# 24337 mem# 2: D:\ORA\LOG_ONLINE_DEST_03\REDO_G01_M03.RDO

Mon Mar 30 04:32:04 2015

LNS: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (270)

LNS: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned

Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_nsa3_2116.trc:

ORA-00270: error creating archive log 

Error 270 for archive log file 1 to 'Oracle-02'

Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_nsa3_2116.trc:

ORA-00270: error creating archive log 

Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_nsa3_2116.trc:

ORA-00270: error creating archive log 

Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_nsa3_2116.trc:

ORA-00270: error creating archive log 

　　通过上述信息可以推断，是主库向备库发送重做日志失败，具体是什么原因导致的，需要再查看备库诊断日志，有如下信息：

Errors in file d:\app\administrator\diag\rdbms\orcl_2\orcl\trace\orcl_arc3_2052.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 27616256 bytes disk space from 214748364800 limit

ARC3: Error 19809 Creating archive log file to 'E:\RECOVERY\ORCL_2\ARCHIVELOG\2015_03_30\O1_MF_1_24336_%U_.ARC'

Mon Mar 30 04:45:49 2015

Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST

Errors in file d:\app\administrator\diag\rdbms\orcl_2\orcl\trace\orcl_arc0_1768.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 214748364800 bytes is 100.00% used, and has 0 remaining bytes available.

　　同时查看备库的归档日志，发现从主库操作系统日志出现归档错误提示开始，备库没有任何重做日志被归档，问题很清楚了，备库的闪回恢复区空间耗尽导致无法接收主库传输的重做日志，推断归档日志变小是因为DataGuard的保护机制自动提高了日志切换频率，此时备库的数据是滞后的，解决问题的办法很简单，删除备库部分归档日志释放闪回恢复区空间即可。

经验教训：

　　自搭建DataGuard以来，对备库的管理一直比较随意，幸亏是最大性能模式，如果是最大保护模式，主库肯定被SHUTDOWN了，想想凌晨4点出这种状况就后怕，看来failover一定是要做了，备库也一定要加强管理。