Online Redo Log丢失常见场景恢复方法

Online Redo Log丢失损坏场景恢复实验

场景介绍:

场景一.inactive状态的redo恢复,

场景二.active状态的redo恢复 ,

场景三.current状态的redo恢复。

场景一:inactive状态的redo损坏及恢复

会话1:我们可以看到,当前数据库为非归档模式(No Archive Mode),并且当前存在3个日志组,GROUP 3为Current状态,2和3均为INACTIVE状态,我们即将要破坏GROUP# 2或GROUP#3的日志文件,模拟故障现象

redo-1

会话2:dd group#2 日志文件,该文件状态为INACTIVE:

redo-2

会话1:重启数据库报错,通过alert日志中可以看到,无法打开GROUP 2 redolog文件,数据库一致性无法保证,数据库启动失败

redo-3

 修复工作:

因丢失的日志文件为INACTIVE的,数据一致性可以保证,也就是不丢数据,可以利用重建日志组的方式或直接alter database clear logfile group 2; 进行修复,本例采用重建日志组的方式

redo-4

场景二.active状态的redo恢复:

ACTIVE状态下Redo Log中的内容需要参与Instance Reveroy,丢失数据与否取决于数据库关闭方式(一致性关闭或非正常关闭Database);

会话1进行状态查询,GROUP 3位ACTIVE状态的redo log file

redo-5

 

会话2:破坏该ACTIVE Redo log

redo-6

 

一致性关闭数据库,同理,数据库启动时失败:

redo-7

 修复工作:

一致性关闭数据库时,当前完全检查点操作,可以保证不丢数据:

redo-8

非正常关闭数据库(shutdown abort)

会话1:

redo-9

会话2:破坏ACTIVE redolog file

redo-10

会话1:启动数据库失败,因丢失的数据为ACTIVE状态,又因关库方式为shutdown abort方式,所以需要日志中内容进行实例恢复:

redo-11

修复方式:需要借助隐含参数”_allow_resetlogs_corruption”进行非正常启动数据库,存在数据字典不一致的状态的风险;

redo-12

成功OPEN数据库,但是之前提交的事务数据已经丢失:

reod-13

场景三.current状态的redo恢复,破坏Current logfile

redo-14

修复工作,仍然需要借助”_allow_error_simulation”隐含参数,丢失事务已提交数据

redo-15

成功起动数据库,代价为丢失数据,出现ORA-600 【2662】报错,该报错原因为需要推进SCN信息,可以尝试重复启动数据库达到SCN一致状态,或者需要利用oradbug poke推进SCN信息,本实验案例通过重启数据库方式推进了SCN

redo-16