前几天公司一套重要程度挺高的系统，早上4点的时候发出了磁盘空间超过预设阈值85%的告警，由于睡得太沉，没有听到手机告警，导致在6点多的时候，数据库发出error告警，我这才一下惊醒，立刻远程连接查看系统状况。

1、现象

    存放归档日志的磁盘空间使用率到100%，导致归档日志写不进去，数据库出现异常。

2、处理步骤

(1)查看alert日志

Sun Apr 09 06:54:27 2017
ARC3: Encountered disk I/O error 19502
ARC3: Closing local archive destination LOG_ARCHIVE_DEST_1: '/oralog/AMAS/1_113303_894381839.dbf' (error 19502) (AMAS)
ARC3: I/O error 19502 archiving log 2 to '/oralog/AMAS/1_113303_894381839.dbf'
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance AMAS - Archival Error
ORA-16038: log 2 sequence# 113303 cannot be archived
ORA-19502: write error on file "", block number  (block size=)
ORA-00312: online log 2 thread 1: '/orasys/AMAS/redo02a.log'
ORA-00312: online log 2 thread 1: '/orasys/AMAS/redo02b.log'
Sun Apr 09 06:54:28 2017
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance AMAS - Archival Error
ORA-16014: log 2 sequence# 113303 not archived, no available destinations
ORA-00312: online log 2 thread 1: '/orasys/AMAS/redo02a.log'
ORA-00312: online log 2 thread 1: '/orasys/AMAS/redo02b.log'
Sun Apr 09 06:55:21 2017
Thread 1 cannot allocate new log, sequence 113305
Checkpoint not complete
  Current log# 3 seq# 113304 mem# 0: /orasys/AMAS/redo03a.log
  Current log# 3 seq# 113304 mem# 1: /orasys/AMAS/redo03b.log
Thread 1 cannot allocate new log, sequence 113305
Private strand flush not complete
  Current log# 3 seq# 113304 mem# 0: /orasys/AMAS/redo03a.log
  Current log# 3 seq# 113304 mem# 1: /orasys/AMAS/redo03b.log
Thread 1 advanced to log sequence 113305 (LGWR switch)
  Current log# 1 seq# 113305 mem# 0: /orasys/AMAS/redo01a.log
  Current log# 1 seq# 113305 mem# 1: /orasys/AMAS/redo01b.log

(2)由于归档日志产生的频率很高，而且设定的archivelog备份,NBU也已经执行成功，为减少数据库异常时间，我先将部分归档日志mv到别的目录，随之，数据库正常。

(3)查看系统层面是否还有为该数据库预留的空间，然后为/oralog扩了20G。

(4)将之前移到别的目录的归档日志重新移回来，通知备份管理员启动daily backup.

  BACKUP
  filesperset 20
  FORMAT 'al_%s_%p_%t'
  ARCHIVELOG ALL DELETE INPUT;

(5)跟AP管理员确认系统影响，请他们补资料。

3、调查归档日志异常增长的原因

    跟AP管理员沟通后，他们说最近有新上一个功能，该功能运行失败后会一直重新尝试运行，导致redo量暴涨，进而导致归档日志量增加。

4、后续工作

    经过这套数据库异常后，我们主要做了以下平行展开的工作：

    (1)将所有server存放归档日志的目录监控频率调整为5分钟一次。

    (2)规划的是/oralog目录可以存放3天的归档日志的量，但随着产能持续上升，导致/oralog的大小只能够存放一天的归档日志的量，一旦daily backup失败，则/oralog空间就会不足，引发数据库故障。所以我们有review所有数据库目前每天及三天归档日志的量，对归档日志量比较大的库，提高daily backup的备份频率，调整为每4小时备份一次。对归档日志量较小的库，密切关注量的增长，一旦归档日志的量达到一定数值，则调整其备份的频率。

    (3)修改到手机的告警内容，明确显示告警信息，可以使DBA第一时间辨别问题严重程度。

5、总结

    这次数据库异常，上面老板也挺关注的，我们主管也做了相应的异常汇报，现在我将经验教训总结如下：

    (1)作为DBA，要时刻保持高度的警惕，认真对待每条告警，第一时间处理。杜绝人为异常。

    (2)在故障发生的时候，迅速辨别严重程度，如果等级很高，第一时间报告主管及资深DBA，请求协助处理。

    (3)对于AP team，要加强同他们的沟通，如果他们有新上功能，我们要对系统及数据库做相应的调整。