ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 单实例归档空间占满故障模拟实验

单实例归档空间占满故障模拟实验

原创 Linux操作系统 作者:realkid4 时间:2011-05-30 19:40:58 0 删除 编辑

 

归档日志(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文件系统查看该目录空间使用。注意,通常该空间中还会保留一部分控制文件controlfileonlinelog的备份。

 

//查看目录

[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

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

 

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。故障环境构造成功。

 

 

3Archive 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

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

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

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

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

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_109_6xw2q1rg_.arc RECID=1 STAMP=752170209

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_110_6xw2r574_.arc RECID=2 STAMP=752170245

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_111_6xw2r7t1_.arc RECID=3 STAMP=752170247

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_112_6xw2vggx_.arc RECID=4 STAMP=752170351

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_113_6xw2wpyb_.arc RECID=5 STAMP=752170392

validation succeeded for archived log

archived log file name=/u01/flash_recovery_area/WILSON/archivelog/2011_05_26/o1_mf_1_114_6xw2wwd6_.arc RECID=6 STAMP=752170397

Crosschecked 6 objects

 

 

删除日志。

 

//删除当前日期之前的所有日志;

RMAN> delete archivelog all completed before 'sysdate';

 

released channel: ORA_DISK_1

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=23 device type=DISK

List of Archived Log Copies for database with db_unique_name WILSON

=====================================================================

(篇幅原因,有省略

 

Do you really want to delete the above objects (enter YES or NO)? yes

Deleted 6 objects

(篇幅原因,有省略

 

RMAN>

 

此时,归档存储日志已经释放。已经下降到安全范围。

 

 

[oracle@oracle11g flash_recovery_area]$ du -h

151M    ./WILSON/onlinelog

9.4M    ./WILSON/controlfile

4.0K    ./WILSON/archivelog/2011_05_26

8.0K    ./WILSON/archivelog

160M    ./WILSON

160M    .

 

 

此时,普通用户可以登录,其他故障现象消除。

 

//scott用户登录;

SQL> conn scott/tiger@wilson;

已连接。

 

 

 

5、结论

 

本篇演示了最基本的归档空间满引起hange住的情况和解决。从这个例子出发,我们可以得到如下经验:

 

ü        不同的数据库结构、用途和系统要求,恢复archived log写满的方案是不同的。针对不同的结构,指定出不同的解决策略方法;

ü        关注归档空间策略和尽早制定解决之道。在系统切换或者计划切换到归档模式的那一刻起,就要开始针对归档日志、空间的管理策略制度。同时,要保证时刻进行空间监控,不要等出现hange住,特别是生产环境业务峰期hange住再解决问题;

ü        对归档环境下的大规模dml操作要慎重,防止短时间内redo log归档生成失控;(笔者有此教训)

ü        不要贸然rm掉归档,要关注整体的备份集合状态和系统要求;

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-696711/,如需转载,请注明出处,否则将追究法律责任。

下一篇: Decode函数语法
请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7754444