记录一则clear重做日志文件的案例

  • 1.官方文档描述
  • 2.故障报错信息
  • 3.分析解决问题

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

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

原文地址:https://www.cnblogs.com/jyzhao/p/10891892.html

时间: 2024-10-28 22:01:50

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

数据库恢复之丢失联机重做日志文件的恢复

联机重做日志文件用来循环记录ORACLE数据库的所有操作,几乎时刻都在读写,因此单纯备份某个时间点的联机重做日志文件没有意义,恢复时根本用来上.RMAN的备份里根本就没有备份联机重做日志的功能,而且不止RMAN,所有的备份软件都没有备份联机重做日志文件的说法.因此,丢失联机重做日志后的数据库恢复也用不到RMAN. 如果ORACLE数据库在启动时发现丢失某一某一联机重做日志文件,则直接报错.ORACLE通过文件冗余的方式来确保联机重做日志文件的安全.即每组联机重做日志创建 多个文件,至少两个,每个

Oracle重做日志文件

http://blog.csdn.net/leshami/article/details/5749556 一.Oracle中的几类日志文件 Redo log files      -->联机重做日志 Archive log files   -->归档日志 Alert log files     -->告警日志 Trace files         -->跟踪日志 user_dump_dest          -->用户跟踪日志 backupground_dump_dest

oracle redo 重做日志文件

以下易容翻译自oracle dba官方文档,不足之处还望指出. 管理重做日志文件 学习目标:1.解释重做日志文件的目的2.描述重做日志文件的结构3.学会控制日志切换与检查点4.多元化管理重做日志文件5.使用OMF管理重做日志文件 1.概念介绍:重做日志文件通过记录数据的所有改变情况对系统或介质故障提供恢复机制.1)重做日志文件以组的形式存在2)一个oracle数据库至少需要两组,每组至少有一文件3)在一组里的每一重做日志文件叫做成员The redo log files are used only

联机重做日志文件 (转)

文章转自:http://www.cnblogs.com/kerrycode/archive/2012/08/09/2631035.html 联机日志文件又叫重做日志文件,记录了对数据库修改的信息,包括用户对数据修改和数据库管理员对数据库结构的修改.它主要用于在发生故障的时候和数据库备份文件配合恢复数据库,一般发生故障有2个情况:一个是介质损坏另外一个是用户误操作.每个数据库至少有两个日志文件组,每组至少包含1个或者多个日志成员,这里要多个日志成员的原因是防止日志文件组内某个日志文件损坏后及时提供

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

--========================================= -- Oracle 联机重做日志文件(ONLINE LOG FILE) --========================================= 一.Oracle中的几类日志文件 Redo log files      -->联机重做日志 Archive log files   -->归档日志 Alert log files     -->告警日志 Trace files        

重做日志文件组和重做日志文件组成员的管理

一.重做日志文件组: 1.添加重做日志组的指令: alter database [数据库名称] add logfile[group 正整数] 文件名称 [,[group 正整数]文件名称]] 不是有group选项时oracle系统会自动在当前最大的组号上加1来产生新的组号 ex:alter database add logfile ('D:\REDO04.LOG','D:\REDO05.LOG') size 15m; 增加新的重做日志组并且添加两个重做日志成员,大小设置为15M 2.删除重做日志

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

存储引擎文件:因为MySQL表存储引擎的关系,每个存储引擎都会有自己的文件来保存各种数据.这些存储引擎真正存储了数据和索引等数据. 表空间文件 InnoDB存储引擎在存储设计上模仿了Oracle,将存储的数据按表空间进行存放.默认配置下,会有一个初始化大小为10MB.名为ibdata1的文件.该文件就是默认的表空间文件(tablespace file).你可以通过参数innodb_data_file_path对其进行设置.格式如下: innodb_data_file_path=datafile_

oracle_重做日志文件--笔记

重做日志文件(redo log file) 目录       重做日志文件相关.       重做日志文件简介.       查询重做日志文件的信息.       日志切换.       管理日志文件组       增删日志文件组.       增删日志文件成员.       归档与非归档模式. 一.重做日志文件相关.        Oracle引入重做日志的目的:数据库的恢复.    Oracle相关进程:重做日志写进程(LGWR).    重做日志性质:联机日志文件,oracle服务器运行时

13_Oracle_Admin_联机重做日志文件和检查点

在数据库中所有的文件都可以丢失,唯有OnlineRedo Log Files和Archive RedoLog Files不可以丢失,否则数据库将无法恢复. 一.什么是联机重做日志文件 联机重做日志文件的主要用于数据库的备份和恢复,它记录了数据的所有变化情况,提供了数据的恢复机制(Oracle在对数据进行操作时,会先写入联机重做日志),它被组织成组,至少有两组日志. Oracle先写第一组,当第一组写满了,再写第二组,依此类推,如果第三组也写满了,就重新从第一组写起,每一组要保证有两个联机重做日志