Online Redo Log损坏处理的示例分析

本篇文章给大家分享的是有关Online Redo Log损坏处理的示例分析，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

我们一起来看一下非一致性关闭条件下当前日志组删除的处理。 

6、非一致性关闭当前日志组处理

我们回到10g Windows版本进行实验。

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

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#  SEQUENCE#

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

         1 NO       CURRENT                 605509          8

         2 YES      ACTIVE                  604411          7

         3 YES      INACTIVE                604371          6

SQL> shutdown abort;

ORACLE 例程已经关闭。

SQL>

E:\oracle\product\10.2.0\oradata\orcl>rename REDO01B.LOG REDO01B.LOG_bak

E:\oracle\product\10.2.0\oradata\orcl>rename REDO01A.LOG REDO01A.LOG_bak

SQL> startup

ORACLE 例程已经启动。

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员

ORA-00312: 联机日志 1 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_1_85TNYSWS_.L

OG'

ORA-27041: 无法打开文件

OSD-04002: ？???？？?

O/S-Error: (OS 2) ？？？????？???？？???

ORA-00312: 联机日志 1 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ONLINELOG\O1_MF_1_85TNYS8S_.LOG'

ORA-27041: 无法打开文件

OSD-04002: ？???？？?

O/S-Error: (OS 2) ？？？????？???？？???

之后，使用常规方法很难打开数据库。

SQL> recover database until cancel;

ORA-00279: 更改 605036 (在 09/23/2012 09:01:03 生成) 对于线程 1 是必需的

ORA-00289: 建议:

E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1_

7_%U_.ARC

ORA-00280: 更改 605036 (用于线程 1) 在序列 #7 中

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: 更改 605509 (在 09/23/2012 09:02:53 生成) 对于线程 1 是必需的

ORA-00289: 建议:

E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1_

8_%U_.ARC

ORA-00280: 更改 605509 (用于线程 1) 在序列 #8 中

ORA-00278: 此恢复不再需要日志文件

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1

_7_85WQXX8S_.ARC'

ORA-00308: 无法打开归档日志

'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_09_23\O1_MF_1

_8_%U_.ARC'

ORA-27041: 无法打开文件

OSD-04002: ？???？？?

O/S-Error: (OS 2) ？？？????？???？？???

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误

ORA-01194: 文件 1 需要更多的恢复来保持一致性

ORA-01110: 数据文件 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_SYSTEM_85TSQFJM_.DBF'

SQL> alter database open resetlogs;

alter database open resetlogs

*

第 1 行出现错误:

ORA-01194: 文件 1 需要更多的恢复来保持一致性

ORA-01110: 数据文件 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_SYSTEM_85TSQFJM_.DBF'

在处理这个问题上，处理上节介绍的备份还原的手段，我们没有太多很好的选择。但是，如果没有备份的时候，我们就需要进行冒险操作。

之所以我们无法从mount进入open状态，主要是源于无法通过文件头完整性检验步骤。在Oracle中，我们可以利用一些后门来让Oracle不进行检查，通过open阶段。下面我们就需要在参数中添加这些配置。

SQL> shutdown abort;

ORACLE 例程已经关闭。

SQL> startup nomount;

ORACLE 例程已经启动。

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

SQL>

--生成PFILE

SQL> create pfile='d:\pfile.ora' from spfile;

文件已创建。

隐含参数_allow_resetlogs_corruption可以让我们避开一致性检查。在pfile中加入参数行。

（参数文件内容）

_allow_resetlogs_corruption=TRUE

orcl.__db_cache_size=377487360

orcl.__java_pool_size=4194304

orcl.__large_pool_size=4194304

orcl.__shared_pool_size=209715200

orcl.__streams_pool_size=0

之后，尝试打开数据库。

SQL> shutdown abort

ORACLE 例程已经关闭。

SQL> startup pfile='d:\pfile.ora';

ORACLE 例程已经启动。

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             218106804 bytes

Database Buffers          377487360 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项

SQL> alter database open resetlogs;

数据库已更改。

SQL> conn sys/oracle@orcl as sysdba

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as SYS

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

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#  SEQUENCE#

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

         1 NO       CURRENT                 605510          1

         2 YES      UNUSED                       0          0

         3 YES      UNUSED                       0          0

注意：这种方法是有很多的问题的。加入参数可以让我们绕开一致性验证，但是很多场景下，特别是文件损坏的场景下，启动可能还会遇到其他错误信息。一旦我们打开数据库，要明白这个库是处在危险之中，我们能做的就是将重要数据尽快的备份出来。

无论发生何种类型的错误，可用、完整的备份都是我们的救命草。要制定完备的备份策略，经常性的检查备份有效性，防患于未燃。

以上就是Online Redo Log损坏处理的示例分析，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。