oracle非归档模式恢复,Oracle数据库非归档模式重做日志恢复方法

本文主要是介绍oracle非归档模式恢复,Oracle数据库非归档模式重做日志恢复方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

王超，祝永志

(曲阜师范大学信息科学与工程学院，山东日照 276800)

摘要：Linux系统是在企业中广泛使用的操作系统，企业亦多基于该操作系统安装数据库。当数据库运行在非归档模式中，且数据库处于无日志备份的情况时，一旦重做日志文件丢失将会导致数据库不可用。针对Oracle数据库重做日志文件丢失问题，提出一种非归档模式下的重做日志恢复方法。实验证明，该方法能有效实现重做日志的无备份恢复。

关键词：Oracle数据库；非归档模式；日志恢复；Linux

0引言

Oracle数据库是广泛应用的大型关系型数据库，数据库的高可用性是一个重要的研究课题，快速准确地恢复数据库日志文件对提高数据库可用性有重要意义。本文以Linux操作系统为基础，针对非归档模式下重做日志文件丢失问题提出一种恢复方法。实验表明，该方法能有效实现非归档模式下的重做日志文件恢复，实现数据库的可用性。

1重做日志概述

重做日志文件(Redo Log File)用于保存表、索引或其他Oracle对象中添加、删除或者改变数据的记录。由于Oracle用循环的方式重复使用重做日志文件，因此每个Oracle数据库有且至少有两个重做日志文件。当一个重做日志文件充满重做日志条目时，如果系统需要实例恢复，则当前的日志文件标记为ACTIVE；如果不需要实例恢复，则标记为INACTIVE；系统从文件开始按序列使用下一个日志文件，并将其标记为CURRENT［1］。在Oracle数据库体系结构中，数据文件、控制文件、重做日志文件和归档日志文件等组成数据库的文件系统，如图1所示。

在现实使用中，为了保证数据库稳定运行，通常需要对数据库日志文件备份，日志文件与其镜像文件记录相同的日志信息，共同组成日志文件组。为了确保日志文件的安全，在同一个组中的日志文件通常会被放在不同的磁盘中［2］。日志文件丢失可能是由数据库管理员(Database Administrator，DBA)操作引起不当，如误删日志文件,或由于磁盘存储问题导致数据库日志文件丢失。在重做日志文件丢失期间，可能会引起数据库系统无法使用，此时一旦数据库数据文件丢失，将无法及时恢复，有可能会造成极大的损失。因此，确保重做日志文件的安全性、冗余性对确保数据库系统稳定是极为重要的。

2日志恢复存在的问题

2.1归档模式

Oracle数据库可以运行在归档(Archivelog)模式和非归档(Noarchivelog)模式。数据库非归档模式只能用于保护数据库实例失败，而不能用于保护存储介质失败。为了防止数据库物理文件损坏所导致的数据丢失，数据库通常运行在归档模式下［3］。在实际的使用中，可能由于DBA的错误操作使数据库系统运行在非归档模式下，此时一旦重做日志文件丢失，则无法通过归档日志恢复重做日志。在此前研究中，数据库日志的备份与恢复策略大多是基于归档模式［4］，在非归档模式下的数据库恢复也大多是使用RMAN通过备份文件恢复［56］。

2.2一致性检查

在Oracle数据库启动过程中，当启系统动到装载数据库MOUNT状态时会进行数据一致性检查［7］，如图2所示。在重做日志丢失的情况下，无法完成数据一致性检查，为了使数据库恢复可用，需要通过修改系统隐藏参数，使数据库在启动时跳过一致性检查。

2.3身份验证

在Oracle数据库日志文件丢失期间，数据库无法正常启动并进行基本的身份验证。此时，对数据库的操作需要通过SYS用户进行，需通过操作系统认证(Operating System Authentication，OSA)的方式获得SYS用户权限。

3重做日志恢复

3.1恢复方法概述

在Linux环境中，对非归档模式下故障的Oracle数据库系统使用数据库控制文件实现数据库恢复，并通过修改Linux系统中Oracle数据库的隐藏参数“_allow_resetlogs_corruption”值实现跳过启动一致性检查，实现数据库启动，在此基础上使用resetlogs方法完成重做日志文件的恢复。基于以上方法，进行以下实验。

3.2实验过程

实验基于Linux环境中Oracle 11g R2数据库系统，由于Linux文件系统与Windows文件系统的差别，其恢复过程与在Windows环境中的恢复过程存在一定差异。为了模拟实际使用中重做日志恢复效果，这里手动删除redo01.log、redo02.log、redo03.log 3个日志文件。在实际操作中建议提前对数据文件备份，防止恢复失败导致数据丢失。在实验过程中也对一些常见的系统异常提示进行相应的处理，具体实验操作如下。

(1)进入系统命令终端，通过OSA方式获得SYS用户权限，按照常规流程使用startup命令启动Oracle数据库进程：

SQL>startup

此时系统返回如下信息：

Oracle instance started.

……

Database mounted

ORA-00313:open failed for members of log group 1 of thread 1

ORA27037:unable to obtain file status

Linux ERROR:2:No such file or directory

Additional information:3

(2)由于该数据库文件系统缺少重做日志文件，系统提示无法找到文件，数据库启动过程中系统报错。此时，可以使用下面的命令查询当前数据库的实例名、数据库归档模式和打开模式，确定当前状态所处开启模式：

SQL>select name,log_mode from vMYMdatabase;

返回查询结果如下：

(3)这里的LOG_MODE为NOARCHIVELOG模式，说明数据库处于非归档模式，且当前数据库开启到MOUNTED状态。此时，使用resetlogs方法打开数据库，输入以下命令：

SQL>alter database open resetlogs;

系统返回信息如下：

……

ERROR at line 1:

ORA01139:RESETLOGS option only valid after an complete database recovery

(4)根据系统提示，数据库如果要使用resetlogs方法，则需要在一个系统恢复之后，因此，需先对数据库实施数据恢复。在该实验的情况中，由于实验环境中仅重做日志文件丢失，而控制文件未丢失，此处可通过使用控制文件对数据库进行恢复，使用如下命令：

SQL>recovery database using backup controlfile;

系统返回异常：

……

ORA00308:cannot open archived log

ORA27037:unable to obtain file status

Linuxx86_64 Error:2:No such file or directory

(5)该问题的产生是由于系统处于非归档模式下，系统提示错误，归档日志无法使用，但实际中数据库恢复过程已经通过控制文件完成，此时再次使用resetlogs方法进行数据库日志恢复，系统返回异常：

ORA01113:file 1 needs media recovery

ORA01110:data file 1:’/usr/app/oracle/oradata/orcl/

system01.dbf’

(6)该异常提示表明：如果要使用resetlogs方法恢复则需要通过恢复媒介，这里由于重做日志文件丢失，无法通过媒介来恢复。因此需要修改隐藏参数，让Oracle数据库忽略数据一致性检查。使用以下命令：

SQL>alter system set”_allow_resetlogs_corruption”

=true scope=spfile;

System altered.

(7)在修改完此参数后，使用强制数据库重启命令启动数据库：

SQL>startup force mount

系统返回如下信息：

……

Database mounted.

(8)数据库装载成功后，再次使用resetlogs方法执行数据库恢复。在一段时间之后，系统返回信息“Database altered”。该信息表明数据库重做日志恢复完成，打开文件所在目录，实例文件夹中显示redo01.log、redo02.log、redo03.log 3个日志文件，重启数据库即完成恢复。

(9)修改_allow _resetlogs_corruption参数为系统默认的false，则在启动时进行数据一致性检查：

SQL>alter system reset”_allow_resetlogs_corruption” scope=spfile;

(10)使用startup force命令重启数据库后，查询修改的隐藏参数值：

SQL>selcet KSPPINM,KSPPSTVL from xMYMksppi a,

xMYMksppcv b where a.indx=b.indx and ksppinm like ‘%resetlogs’;

返回查询结果如下：