归档日志（Archived Log File）是Oracle数据库进行备份还原的重要要素之一。开启归档模式（Archived Log Mode）、指定合理的备份计划是生产数据库环境的必要条件。

Oracle数据库在运行中，会不断的生成Redo Log（重做日志记录），当这些记录生成后，会依据一定规则写入到Online Redo Log File（在线重做日志文件中）。一般数据库Online Redo Log会以多个组的形式进行循环切换，写完一组Log切换switch到下一组Log。所谓的归档模式就是在切换结束之后，Oracle会将完成的Redo Log保存在一个位置上，用于进行完全恢复使用。

系统不断的运行，会生成大量的Redo Log记录，在归档模式下不断写入的归档日志量也会越来越多。通常设置的归档存放空间是有限制的，如果一旦写满就会发生数据库暂时hange住的现象。下面通过实验来模拟这个过程，并且解释如果解决。

1、实验环境构建

因为是模拟实验，所以选择Linux环境下的Oracle 11gR2进行。首先，要将系统调整为归档模式，并且检查各种归档相关参数指标。

//检查当前归档状态（非归档模式）

SQL> archive log list

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination USE_DB_RECOVERY_FILE_DEST //默认的归档存放位置；

Oldest online log sequence 107

Current log sequence 109

//归档核心参数

SQL> show parameter db_recovery_file

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest string /u01/flash_recovery_area

db_recovery_file_dest_size big integer 3852M

默认情况下，Oracle存放归档的位置是在参数db_recovery_file_dest指定的目录下，安装时候进行指定，通常是与$ORACLE_HOME相关路径。当然，此外还有如log_archive_dest_n类参数指定的其他位置。本篇就不加以涉及了。

参数db_recovery_file_dest_size指定的是该目录能够存放的大小。这个参数的作用就是从Oracle数据库层面对归档空间大小进行一定的限制。我们先从Linux文件系统查看该目录空间使用。注意，通常该空间中还会保留一部分控制文件controlfile和onlinelog的备份。

//查看目录

[oracle@oracle11g ~]$ cd /u01/flash_recovery_area/WILSON/

[oracle@oracle11g WILSON]$ ls

controlfile onlinelog

//查看空间

[oracle@oracle11g WILSON]$ du -h

151M ./onlinelog

9.4M ./controlfile

160M .

为了尽快看到实验效果，手工调整该目录参数。设置该目录容量最大为300M。

//该参数要求在重新启动之后才能生效；

SQL> alter system set db_recovery_file_dest_size=300M scope=spfile;

System altered.

其次，就是通过重新启动数据库，切换到归档模式。切换归档模式通常需要在mount状态实现。

--重新启动并且切换到归档模式

[oracle@oracle11g onlinelog]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Thu May 26 16:02:27 2011

SQL> conn / as sysdba

Connected.

//停止数据库

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

//启动到nomount状态

SQL> startup nomount

ORACLE instance started.

Total System Global Area 414298112 bytes

Fixed Size 1336904 bytes

Variable Size 314575288 bytes

Database Buffers 92274688 bytes

Redo Buffers 6111232 bytes

//进入mount状态

SQL> alter database mount;

Database altered.

SQL> alter database archivelog;

Database altered.

//open数据库

SQL> alter database open;

Database altered.

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 107

Next log sequence to archive 109

Current log sequence 109

SQL>

//查看参数已经被修改

SQL> show parameter db_recovery

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest string /u01/flash_recovery_area

db_recovery_file_dest_size big integer 300M

2、检查归档，构造故障环境

刚开始，归档日志记录v$archived_log中，是没有任何记录信息的。

SQL> select recid from v$archived_log;

RECID

----------

进行一些DML操作之后，就会生成redo log记录。同时，我们保持对db_recovery_file_dest目录的容量监控。直到出现下面情况：

//检查目录容量

[oracle@oracle11g WILSON]$ du -h

151M ./onlinelog

9.4M ./controlfile

126M ./archivelog/2011_05_26

126M ./archivelog

285M .

//此时v$archived_log记录为

SQL> select recid, stamp, name, sequence# from v$archived_log;

RECID STAMP NAME SEQUENCE#

---------- ---------- -------------------------------------------------------------------------------- - ----------

1 752170209 &&/2011_05_26/o1_mf_1_109_6xw2q1rg_.arc 109

2 752170245 &&/2011_05_26/o1_mf_1_110_6xw2r574_.arc 110

3 752170247 &&/2011_05_26/o1_mf_1_111_6xw2r7t1_.arc 111

4 752170351 &&/2011_05_26/o1_mf_1_112_6xw2vggx_.arc 112

5 752170392 &&/2011_05_26/o1_mf_1_113_6xw2wpyb_.arc 113

6 752170397 &&/2011_05_26/o1_mf_1_114_6xw2wwd6_.arc 114

6 rows selected

说明：

篇幅原因，结果有剪裁，其中&&表示路径：/u01/flash_recovery_area/WILSON/archivelog

此时，db_recovery_file_dest目录已经接近容量限额300M。故障环境构造成功。

3、Archive Redo Log写满故障现象

此时，我们观察到如下几个现象：

ü 进行所有DML等生成Redo Log操作，系统无响应

此时，任何会生成Redo Log记录的操作，都不能获取到响应。Online Redo Log要保证在被下次覆写之前，完成归档操作。由于归档空间不能实现写入，所以归档操作进程arch就被停止住，进而写redo log的动作也会被block住。

ü 除sys用户外的普通用户，连接失败

当我们尝试使用非sys用户登录系统时，Oracle提出拒绝。

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 5月 28 21:45:44 2011

SQL> conn scott/tiger@wilson ;

ERROR:

ORA-00257: archiver error. Connect internal only, until freed.

//只能sys用户登录；

SQL> conn sys/Sys@wilson as sysdba;

已连接。

ü Alert_log中写入错误信息

此时观察alert_log，可以看到错误提示。

--alert log信息

Thu May 26 16:18:52 2011

Errors in file /u01/diag/rdbms/wilson/wilson/trace/wilson_arc3_5893.trc:

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

Errors in file /u01/diag/rdbms/wilson/wilson/trace/wilson_arc3_5893.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 47672320 bytes disk space from 314572800 limit

ARC3: Error 19809 Creating archive log file to '/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_115_%u_.arc

4、解决问题

尝试解决此类型问题，要根据不同的数据库配置环境依据不同的方法来确定。如果是生产环境，可以考虑暂时扩大恢复区、或者直接删除归档日志之后全库备份的策略。

删除归档日志的方式上，有一些注意方面。因为归档记录是写入进控制文件Control File的，所以即使直接从文件系统中删除，Oracle数据库也不会认为该文件已经删除。解决的方式就是使用RMAN工具。

[oracle@oracle11g trace]$ rman nocatalog

Recovery Manager: Release 11.2.0.1.0 - Production on Thu May 26 16:20:32 2011

RMAN> connect target /

connected to target database: WILSON (DBID=3851616883)

using target database control file instead of recovery catalog

//显示归档日志

RMAN> crosscheck archivelog all;

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=23 device type=DISK