1.官方文档描述

关于Clearing a Redo Log File的官方文档描述:
> A redo log file might become corrupted while the database is open, and ultimately stop database activity because archiving cannot continue. In this situation the ALTER DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without shutting down the database.
>
> The following statement clears the log files in redo log group number 3:
>
> ALTER DATABASE CLEAR LOGFILE GROUP 3;
> This statement overcomes two situations where dropping redo logs is not possible:
>
> If there are only two log groups
>
> The corrupt redo log file belongs to the current group
>
> If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the statement.
>
> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;
> This statement clears the corrupted redo logs and avoids archiving them. The cleared redo logs are available for use even though they were not archived.
>
> If you clear a log file that is needed for recovery of a backup, then you can no longer recover from that backup. The database writes a message in the alert log describing the backups from which you cannot recover.

Note:

If you clear an unarchived redo log file, you should make another backup of the database.

To clear an unarchived redo log that is needed to bring an offline tablespace online, use the UNRECOVERABLE DATAFILE clause in the ALTER DATABASE CLEAR LOGFILE statement.

If you clear a redo log needed to bring an offline tablespace online, you will not be able to bring the tablespace online again. You will have to drop the tablespace or perform an incomplete recovery. Note that tablespaces taken offline normal do not require recovery.

2.故障报错信息

启动数据库在open阶段失败:

SQL> startup
ORACLE instance started. Total System Global Area 313860096 bytes
Fixed Size 1344652 bytes
Variable Size 205523828 bytes
Database Buffers 100663296 bytes
Redo Buffers 6328320 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 2039
Session ID: 102 Serial number: 5

进一步查看alert告警日志发现是redo日志文件损坏:

Mon May 20 01:00:52 2019
alter database open
Mon May 20 01:00:52 2019
LGWR: STARTING ARCH PROCESSES
Mon May 20 01:00:53 2019
ARC0 started with pid=18, OS id=2389
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Mon May 20 01:00:54 2019
ARC1 started with pid=19, OS id=2391
Mon May 20 01:00:54 2019
ARC2 started with pid=20, OS id=2393
Incomplete read from log member '/u03/oradata/PROD2/redo01.dbf'. Trying next member.
ARCH: All Archive destinations made inactive due to error 333
ARCH: Closing local archive destination LOG_ARCHIVE_DEST_1: '/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_1_1008712962.dbf' (error 333) (PROD2)
Committing creation of archivelog '/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_1_1008712962.dbf' (error 333)
Mon May 20 01:00:54 2019
ARC3 started with pid=21, OS id=2395
Errors in file /u01/app/oracle/diag/rdbms/prod2/PROD2/trace/PROD2_ora_2179.trc:
ORA-16038: log 1 sequence# 1 cannot be archived
ORA-00333: redo log read error block count
ORA-00312: online log 1 thread 1: '/u03/oradata/PROD2/redo01.dbf'
ARC1: Archival started
ARC2: Archival started
USER (ospid: 2179): terminating the instance due to error 16038
Mon May 20 01:00:55 2019
System state dump requested by (instance=1, osid=2179), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/oracle/diag/rdbms/prod2/PROD2/trace/PROD2_diag_2131.trc
Dumping diagnostic data in directory=[cdmp_20190520010055], requested by (instance=1, osid=2179), summary=[abnormal instance termination].
Instance terminated by USER, pid = 2179

3.分析解决问题

**3.1 再次尝试启动数据库故障可重现**

SQL> startup mount;
SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE#
------------------
2126114
2126114
2126114
2126114
2126114
SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE#
------------------
2126114
2126114
2126114
2126114
2126114
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 2179
Session ID: 102 Serial number: 5

3.2 启动到mount尝试clear重做日志文件

SQL> conn /as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started. Total System Global Area 313860096 bytes
Fixed Size 1344652 bytes
Variable Size 205523828 bytes
Database Buffers 100663296 bytes
Redo Buffers 6328320 bytes
Database mounted.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 1 52428800 512 1 NO INACTIVE 2080429 19-MAY-19 2105566 20-MAY-19
3 1 3 52428800 512 1 NO CURRENT 2106113 20-MAY-19 2.8147E+14
2 1 2 52428800 512 1 NO INACTIVE 2105566 20-MAY-19 2106113 20-MAY-19 SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-00350: log 1 of instance PROD2 (thread 1) needs to be archived
ORA-00312: online log 1 thread 1: '/u03/oradata/PROD2/redo01.dbf' SQL> alter database clear unarchived logfile group 1; Database altered. SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 0 52428800 512 1 YES UNUSED 2080429 19-MAY-19 2105566 20-MAY-19
3 1 3 52428800 512 1 NO CURRENT 2106113 20-MAY-19 2.8147E+14
2 1 2 52428800 512 1 NO INACTIVE 2105566 20-MAY-19 2106113 20-MAY-19

由于本次3个redo日志全部确认已损坏,需要依次clear:

SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-00350: log 2 of instance PROD2 (thread 1) needs to be archived
ORA-00312: online log 2 thread 1: '/u03/oradata/PROD2/redo02.dbf' SQL> alter database clear logfile group 3;
alter database clear logfile group 3
*
ERROR at line 1:
ORA-00350: log 3 of instance PROD2 (thread 1) needs to be archived
ORA-00312: online log 3 thread 1: '/u03/oradata/PROD2/redo03.dbf' SQL> alter database clear unarchived logfile group 2; Database altered. SQL> alter database clear unarchived logfile group 3; Database altered. SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 4 52428800 512 1 NO CURRENT 2106114 20-MAY-19 2.8147E+14
3 1 0 52428800 512 1 YES UNUSED 2106113 20-MAY-19 2106114 20-MAY-19
2 1 0 52428800 512 1 YES UNUSED 2105566 20-MAY-19 2106113 20-MAY-19 SQL> alter database open; Database altered. SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 4 52428800 512 1 NO CURRENT 2106114 20-MAY-19 2.8147E+14
2 1 0 52428800 512 1 YES UNUSED 2105566 20-MAY-19 2106113 20-MAY-19
3 1 0 52428800 512 1 YES UNUSED 2106113 20-MAY-19 2106114 20-MAY-19

数据库开启后建议尽快重新执行一次全备。

记录一则clear重做日志文件的案例的更多相关文章

  1. Oracle重做日志文件

    一.联机重做日志的规划管理 1.联机重做日志 记录了数据的所有变化(DML,DDL或管理员对数据所作的结构性更改等) 提供恢复机制(对于意外删除或宕机利用日志文件实现数据恢复) 可以被分组管理  11 ...

  2. Oracle 联机重做日志文件(ONLINE LOG FILE)

    --========================================= -- Oracle 联机重做日志文件(ONLINE LOG FILE) --================== ...

  3. 初识oracle重做日志文件

    转自 http://blog.csdn.net/indexman/article/details/7746948 以下易容翻译自oracle dba官方文档,不足之处还望指出. 管理重做日志文件 学习 ...

  4. oracle redo 重做日志文件

    以下易容翻译自oracle dba官方文档,不足之处还望指出. 管理重做日志文件 学习目标:1.解释重做日志文件的目的2.描述重做日志文件的结构3.学会控制日志切换与检查点4.多元化管理重做日志文件5 ...

  5. ORACLE 移动数据文件 控制文件 重做日志文件

    ORACLE数据库有时候需要对存储进行调整,增加分区.IO调优等等,此时需要移动数据文件.重做日志文件.控制文件等等,下文结合例子总结一下这方面的知识点. 进行数据文件.重做日志文件.控制文件的迁移前 ...

  6. MySQL 重做日志文件

    一.innodb log的基础知识 · innodb log顾名思义:即innodb存储引擎产生的日志,也可以称为重做日志文件,默认在innodb_data_home_dir下面有两个文件ib_log ...

  7. InnoDB存储引擎的表空间文件,重做日志文件

    存储引擎文件:因为MySQL表存储引擎的关系,每个存储引擎都会有自己的文件来保存各种数据.这些存储引擎真正存储了数据和索引等数据. 表空间文件 InnoDB存储引擎在存储设计上模仿了Oracle,将存 ...

  8. (Les16 执行数据库恢复)-重做日志文件恢复

    丢失重做日志文件         丢失了重做日志文件组中的某个成员,并且组中至少还有一个成员:             -不会影响实例的正常操作.             -预警日志中会收到一条信息, ...

  9. ORACLE - 管理重做日志文件

    ORACLE重做日志文件用于在数据库崩溃等情况下用于恢复数据,默认情况下为三个文件redo01.log/redo02.log/redo03.log,文件组循环使用,在录入与更新操作比较多的应用中,日志 ...

随机推荐

  1. python 2.7 - 3.5 升级之路 (一) : 准备阶段开发环境 -- pip3, vitualEnv, pycharm

    背景 由于之前项目采用的版本是Python2.7, 考虑到Python 2.7 到明年(2020年后将会停止更新),以及为了更好的适应中文和拥抱新的特性.我们决定将其从python 2 升级到最新的 ...

  2. Excel催化剂开源第39波-json字符串解释的超能类库

    对一般VBA开发群体来说,处理json.xml结构的数据源,在VB6的世界里,是一件非常不容易的事情,隐约记得当年自己从哪里找到了一个使用字典实现的json解释的函数,实在非常稀有. 在.Net的世界 ...

  3. C#3.0新增功能09 LINQ 基础01 语言集成查询

    连载目录    [已更新最新开发文章,点击查看详细] 语言集成查询 (LINQ) 是一系列直接将查询功能集成到 C# 语言的技术统称. 数据查询历来都表示为简单的字符串,没有编译时类型检查或 Inte ...

  4. ES6 symbol 以及symbol的简单应用

    前置 1.ES6 引入了一种新的原始数据类型Symbol,表示独一无二的值. 2.Symbol 值通过Symbol函数生成. 3.Symbol 函数可以接受一个字符串作为参数,表示对 Symbol 实 ...

  5. js数字格式化(截断格式化或四舍五入格式化)

    /*** * 数字格式化(适合金融产品截断小数位后展示) * @param num * @param pattern (标准格式:#,###.## 或#.## 或#,###00.00) * @para ...

  6. Xshell为什么连不上虚拟机

  7. git push 出现non-fast-forward的错误

    1.git push origin liu_0909:daily_liu_0909 出现non-fast-forward的错误,证明您的本地库跟远程库的提交记录不一致,即 你的本地库版本需要更新2.g ...

  8. VIM常用命令速查(转)

  9. spring 注解验证@NotNull等使用方法

    @Null 被注释的元素必须为null@NotNull 被注释的元素不能为null@AssertTrue 被注释的元素必须为true@AssertFalse 被注释的元素必须为false@Min(va ...

  10. 在Linux - Centos上安装Python3(上)

    必看内容 在Linux上安装Python常用的2种方法 1.Python源码编译安装,有点复杂,适合老司机 2.从EPEL/IUS仓库安装,新手建议使用些方法,比较简单,目前2019-07-31提供最 ...