Redo丢失的4种情况及处理方法

Redo丢失的4种情况及处理方法

转载:http://blog.itpub.net/23135684/viewspace-626935/

一.说明：
1.以下所说的当前日志指日志状态为CURRENT,ACTIVE,非当前日志指日志状态为INACTIVE
2.不用考虑归档和非归档模式，2种模式下的Redo丢失情况一样。

二.丢失Redo的4种情况：
第一种情况：非当前日志，正常关闭。
第二种情况：非当前日志，非正常关闭。
第三种情况：当前日志，正常关闭。
第四种情况：当前日志，非正常关闭。

三.处理方法：
第一、二种情况的处理方法一样，直接把日志文件clear即可。
SQL> alter database clear logfile group 3;
SQL> alter database clear unarchived logfile group 3;//如果INACTIVE状态的在线Redo还未归档，增加关键字unarchived完成clear操作。（ACTIVE,INACTIVE都有可能未完成归档，归档是否完成可以查看v$log.archived字段）。

例子：

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size             167772596 bytes

Database Buffers           88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。

SQL> select group#,thread#,status,archived from v$log;

GROUP#    THREAD# STATUS                           ARCHIV

---------- ---------- -------------------------------- ------

1          1 CURRENT                          NO

3          1 ACTIVE                           NO

2          1 INACTIVE                         YES

SQL> alter database clear logfile group 3;

alter database clear logfile group 3

*

第 1 行出现错误:

ORA-01624: 日志 3 是紧急恢复实例 orcl (线程 1) 所必需的

ORA-00312: 联机日志 3 线程 1: ‘E:\APP\ORADATA\ORCL\REDO03.LOG‘

SQL> alter database clear logfile group 2;

数据库已更改。

第三种情况的处理办法：
SQL>startup mount;
SQL>recover database until cancel;
SQL>alter database open resetlogs;

例子1：

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size             167772596 bytes

Database Buffers           88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。

SQL> alter database open resetlogs;

alter database open resetlogs

*

第 1 行出现错误:

ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效

SQL> recover database until cancel;

完成介质恢复。

SQL> alter database open resetlogs;

数据库已更改。

例子2（第三种情况的第二个处理方法）：

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size             167772596 bytes

Database Buffers           88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。

SQL> select group#,thread#,status,archived from v$log;

GROUP#    THREAD# STATUS                           ARCHIV

---------- ---------- -------------------------------- ------

1          1 CURRENT                          NO

3          1 INACTIVE                         YES

2          1 INACTIVE                         YES

SQL> alter database clear logfile group 2;

数据库已更改。

SQL> alter database clear logfile group 3;

数据库已更改。

SQL> alter database clear unarchived logfile group 3;

数据库已更改。

这里CURRENT的Redo日志文件组能被clear unarchived。

SQL> alter database open;

数据库已更改。

如果Redo日志文件丢失，clear操作完成之后将在原有位置创建新的Redo日志文件。

第四种情况的处理方法：
1.通过备份来还原、恢复数据。
2.通过修改参数文件中的参数
_allow_resetlogs_corruption=TRUE
来强制启动数据库。//虽然能够启动数据库到open状态，但是启动后的数据库数据字典、数据有可能导致不一致的情况出现，故需要在open下把整个数据库export，然后删除库，重建，再将export的数据import到新的数据库中。

四.验证数据库是否正常关闭的方法

SQL> select open_mode from v$database;

OPEN_MODE

--------------------

READ WRITE

SQL> select status from v$instance;

STATUS

------------

OPEN

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

FILE# CHECKPOINT_CHANGE# FUZ

---------- ------------------ ---

1            1165820 YES

2            1165820 YES

3            1165820 YES

4            1165820 YES

FUZZY bit in datafile header means that there may have been writes into a datafile after the last checkpoint. E.g. there may be changes written to datafile with higher SCN than checkpoint_change# stored in datafile header (seen from v$datafile_header.checkpoint_change#).
        FUZYY表示模糊性，意思是，该数据文件处于模糊状态，在最近一次CHECKPOINT后，该文件上的数据可能被修改过了，但没来得及更新到该文件上（或者该文件不知道），需要读取日志信息来判断。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

---------- ------------------ ------------

1            1165820

2            1165820

3            1165820

4            1165820

由于数据库是打开的状态，所以终止SCN是空，SCN的内容可参考文章：http://space.itpub.net/23135684/viewspace-627343

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  313860096 bytes

Fixed Size                  1384352 bytes

Variable Size             155189344 bytes

Database Buffers          150994944 bytes

Redo Buffers                6291456 bytes

数据库装载完毕。

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

FILE# CHECKPOINT_CHANGE# FUZ

---------- ------------------ ---

1            1166324 NO

2            1166324 NO

3            1166324 NO

4            1166324 NO

在正常管理数据库的情况下，FUZZY字段都应该是NO，表示没有模糊不清的SCN存储在数据文件中。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

---------- ------------------ ------------

1            1166324      1166324

2            1166324      1166324

3            1166324      1166324

4            1166324      1166324

正常关闭数据库的终止SCN应该和启动SCN相同。FUZZY等于NO，且数据库的终止SCN等于启动SCN等于数据文件SCN，那么可以认为数据库是正常关闭，且在打开数据库之前不需要执行实例恢复或Crash恢复。

SQL> alter database open;

数据库已更改。

SQL> shutdown abort

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  313860096 bytes

Fixed Size                  1384352 bytes

Variable Size             155189344 bytes

Database Buffers          150994944 bytes

Redo Buffers                6291456 bytes

数据库装载完毕。

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

FILE# CHECKPOINT_CHANGE# FUZ

---------- ------------------ ---

1            1166327 YES

2            1166327 YES

3            1166327 YES

4            1166327 YES

非正常关闭数据库实例，FUZZY字段的值是YES。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

---------- ------------------ ------------

1            1166327

2            1166327

3            1166327

4            1166327

非正常关闭数据库实例，终止SCN依然为空。那么，在数据库被打开之前必须使用归档Redo日志完成实例恢复或Crash恢复。

五.结论：
非正常关闭的当前日志丢失，可能导致数据库启动后的混乱，并可能造成少量数据的丢失。其他情况不会导致数据的丢失。

时间： 2024-08-27 03:31:14

Redo丢失的4种情况及处理方法的相关文章

窗体间传递数据（跨控件跨类），三种情况与处理方法

环境:Qt5.5 MCVS2013 IDE:QtCreator 范例代码下载地址:http://download.csdn.net/detail/shihoongbo/9134859 发现很多Qt的初学者,经常会在“窗体间如何传递数据”的问题上卡住,而网上通常只是简单描述为使用信号与槽(signal& slot)机制来传递 虽然信号与槽的传递方式确实没错,但是却不一定能适用到全部的情况. 所以,总结了窗体间传递数据的三种情况和对应方法: 模型描述:  已知三个窗体,A为B C的父控件,B与C互为

Win10专业版桌面没有图标的三种情况及解决方法

正常情况,用户进入Win10系统桌面的时候会看到administrator文件夹.计算机.回收站.网络等图标,但有朋友进入桌面后什么图标都没有,这是怎么回事,Win10桌面没有图标可以分为三种情况,下面我们来看下这三种情况的具体解决方法. 一.系统图标消失 桌面右键进入个性化窗口,在主题选项找到桌面图标设置,在桌面图标设置中找到你想要显示的系统图标. 二.全部图标消失 这个时候很有可能是网上赌博桌面图标被隐藏起来了,鼠标右键进入查看选项后勾选,显示桌面图标. 三.桌面图标和任务栏一起消失 1.应

window7系统PID=4占用80端口的几种情况及解决方法

首先,我们要看怎么80端口是否被占用: 点击电脑左下角的 输入cmd , 回车,然后输入netstat -ano|findstr "80"  然后回车(注意,-ano后面是一个竖杠,也就是我们键盘上enter键上面那个键,按住shift再按那个键就会出现那个竖杠|,还有,双引号是英文字符的) TCP那一列后面的第一列中,有:80就是占用80端口的进程,最后那么他的PID就是最后一列的2632. 现在我们来看一下这个PID=2632的是哪个进程,在cmd中输入tasklist |find

“丢失更新” 两种情况分析！

第一类丢失更新 A事务撤销时,把已经提交的B事务的更新数据覆盖了.这种错误可能造成很严重的问题,通过下面的账户取款转账就可以看出来: 时间 取款事务A 转账事务B T1 开始事务 T2 开始事务 T3 查询账户余额为1000元 T4 查询账户余额为1000元 T5 汇入100元把余额改为1100元 T6 提交事务 T7 取出100元把余额改为900元 T8 撤销事务 T9 余额恢复为1000 元(丢失更新) A事务在撤销时,"不小心"将B事务已经转入账户的金额给抹去了. 第二类丢失更新

error C4430: 缺少类型说明符 - 假定为 int....的一种情况的解决方法

这段时间用VS2013写代码的时候,一不小心就出现了这个提示,这个问题困扰了我一段时间,不过总算解决了,这里记录一下! 我这里先描述本人碰到的问题: 正如上图所见,一段在我们眼里看起来没有任何错误的代码,居然爆出了4430的错误,先不急,我们先看一看DlgAddAccount.h文件中包含的头文件: 再看一看AddAccountInfoDlg.h中包含的头文件: 我们发现一件很有趣的事情,两个文件互相包含,这样的话,我们将AddAccountInfo.h中的#include "DlgAddAcc

中文乱码的几种情况以及解决方法

1.不要在链接中接中文参数,而是通过键值对的方式传递 Done!

Win7 64bit 系统安装DirectX提示失败的一种情况的解决方法记录

提示内容为"不能信任一个安装所需的压缩文件.请检查加密服务是否启用并且 Cabinet 文件证书是否有效." 右键点击"计算机"->"管理"->"服务"找到"Health Key and Certificate Management"点击启用,然后再次启动DirectX安装程序就能正常安装了.

DG备库，实时应用如何判断，MR进程，及MRP应用归档，三种情况的查询及验证

本篇文档学习,DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证 1.取消MRP进程 备库查询进程状态select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby;PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS--------- -------- ---------- ------------ ---------- -

关于VS2012 生成或调试时无响应的另一种情况

最近在做一个项目,差不多结尾了. 然后某天发现,生成和调试都会卡好一会(差不多要1分钟吧)才可以正常开始. 然后各种找问题,重装VS,重装系统,什么中文输入法,结果都一样. 最后只能怀疑是项目 问题了,后来想起来主窗口使用了一个自己写的用户控件,这个控件是容器来的,然后里面的控件全部变成空白了,当然之前是正常的,后来不知道为什么变成这样,然后我就自己手动将控件添加回去这个控件内 在Form1.Designer.cs文件内的 this.xxxx.Controls.Add(this.button3)