Oracle数据库紧急故障解决方案

开篇：润墨网以专业的文秘视角，为您筛选了一篇Oracle数据库紧急故障解决方案范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要:数据库是信息系统的核心,是其正常运行的重要保障,该文主要针对运行在归档模式下的oracle数据库可能遇到的各种类型的文件损坏故障提供了相应的恢复方案及具体操作过程的方法。

关键词:Oracle数据库;故障;损坏文件;恢复;归档模式

中图分类号:TP311文献标识码:A 文章编号:1009-3044(2009)27-7600-03

The Solution for Urgently Break Down of the Oracle Database

WANG Hong-yan, LI Tao

(The 477th Hospital of PLA, Xiangfan 441003, China)

Abstract: The database is the center part of information system, which is the important guarantee to normal working of system. This text mainly concentrate on the solution for latent breaking down of the Oracle databaseand the method of operation process when running in the archivelog mode.

Key words: oracle database;Break down; Damaged documents;recovery;archivelog mode

随着办公自动化和电子商务的飞速发展,企业对信息系统的依赖性越来越高,数据库作为信息系统的核心担当着重要的角色。尤其在一些对数据可靠性要求很高的行业如银行、证券、电信等,如果发生意外停机或数据丢失其损失会十分惨重。为此数据库管理员应针对具体的业务要求制定详细的数据库备份与灾难恢复策略,并通过模拟故障对每种可能的情况进行严格测试,只有这样才能保证数据的高可用性。数据库管理员在恢复时采取的步骤正确与否也直接影响最终的恢复结果,本文主要针对Oracle数据库可能遇到的各种故障提供了相应的恢复的方法。

1 故障分析

Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障。这些故障可能是由于硬件故障造成的,也可能是人为误操作而引起。所以我们首先要判断问题的起因,如果是硬件故障则首先要解决硬件问题。在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。

Oracle数据库错误主要分为5大类: SQL语句失败 ; 线程失败 ;实例失败;用户操作失败;存储设备失败。

2 解决方法

如果发生前三种失败,不需要我们人为干涉,Oracle系统会自动进行恢复。对于用户操作型的失败(如误删除数据),我们采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。从Oracle 8之后的新版本中引入了基于表空间的时间点恢复(TSPITR),可以单独将包含错误操作的表空间恢复到指定时间,而不必对整个数据库进行不完全恢复。

针对存储设备的失败的情况比较复杂也是本文讨论的重点,存储设备的失败必然会使放置在其上的文件变为不可用,我们先将Oracle数据库所涉及到的文件进行一个划分,主要可分为:Oracle的系统文件,指Oracle的运行文件,各种应用程序 ; 数据库控制文件 ; 数据库重做日志文件 ;数据文件; 归档日志文件 。

2.1 避免Oracle的系统文件失

败主要依赖系统管理员进行操作系统级的备份,当发生事故后只能依靠操作系统备份将其恢复。

2.2 控制文件损坏

控制文件记录了关于oracle的重要配置信息,如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏,会导致数据库异常关闭。一旦缺少控制文件,数据库也无法启动,这是一种比较严重的错误。

首先可以通过查询数据库的日志文件来定位损坏了的控制文件。日志文件位于$ORACLE_BASE/admin/bdump/alert_ORCL.ora.

2.2.1损坏单个控制文件

① 确保数据库已经关闭,如果没有用下面的命令来关闭数据库:svrmgrl>shutdown immediate;

② 查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。

③ 用操作系统命令将其它正确的控制文件覆盖错误的控制文件。

④ 用下面的命令重新启动数据库 svrmgrl>startup;

⑤ 用适当的方法进行数据库全备份。

2.2.2损坏所有的控制文件

① 确保数据库已经关闭,如果没有用下面的命令来关闭数据库:svrmgrl>shutdown immediate;

② 从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录;对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。

③ 用下面的命令来创建产生数据库控制文件的脚本:

svrmgrl>startup mount;

svrmgrl>alter database backup controlfile to trace noresetlogs;

④ 修改第三步产生的trace文件,将其中关于创建控制文件的一部分语句拷贝出来并做些修改,使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.

注意:

Trace文件的具体路径可以在执行完第3)步操作后查看$ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。

⑤ 用下面命令重新创建控制文件:

svrmgrl>shutdown abort;

svrmgrl>startup nomount;

svrmgrl>@createcontrol.sql;

⑥ 用适当的方法进行数据库全备份。

2.3 重做日志文件损坏

数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏,会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志,所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员,所以在下面的分析中只考虑重做日志组损坏的情况,而不考虑单个重做日志成员损坏的情况。

2.3.1确定损坏的重做日志的位置及其状态

① 如果数据库处于可用状态:

select * from v$logfile;

svrmgrl>select * from v$log;

② 如果数据库处于已经异常终止:

svrmlgr>startup mount;

svrmgrl>select * from v$logfile;

svrmgrl>select * from v$log;

其中,logfile的状态为INVALID表示这组日志文件出现已经损坏;log状态为Inactive:表示重做日志文件处于非激活状态;Active: 表示重做日志文件处于激活状态;Current:表示是重做日志为当前正在使用的日志文件。

2.3.2损坏的日志文件处于非激活状态

① 删除相应的日志组:

svrmgrl>alter database drop logfile group group_number;

② 重新创建相应的日志组:

svrmgrl>alter database add log file group group_number (’log_file_descritpion’,…) size log_file_size;

2.3.3 损坏的日志文件处于激活状态且为非当前日志

① 清除相应的日志组:

svrmgrl>alter database clear unarchived logfile group group_number;

2.3.4 损坏的日志文件为当前活动日志文件

① 用命令清除相应的日志组:

svrmgrl>alter database clear unarchived logfile group group_number;

② 如果清除失败,则只能做基于时间点的不完全恢复。

③ 打开数据库并且用适当的方法进行数据库全备份:

svrmgrl>alter database open;

2.4部分数据文件损坏

若损坏的数据文件属于非system表空间,则数据库仍然可以处于打开状态可以进行操作,只是损坏的数据文件不能访问。这时在数据库打开状态下可以单独对损坏的数据文件进行恢复。若是system表空间的数据文件损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开,然后再对数据文件进行恢复。可以通过查看数据库日志文件来判断当前损坏的数据文件到底是否属于system表空间。

2.4.1非system表空间的数据文件损坏

① 确定损坏的文件名字:

svrmgrl>select name from v$datafile where status=’INVALID’;

② 将损坏的数据文件处于offline状态:

svrmgrl>alter database datafile ‘datafile_name’ offline;

③ 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复;对于用带库备份的点用相应的rman脚本来恢复。

④ 恢复数据文件:

svrmgrl>alter database recover datafile ‘file_name’;

⑤ 使数据库文件online:

svrmgrl>alter database datafile ‘datafile_name’ online;

⑥ 用适当的方法进行数据库全备份。

2.4.2 system表空间的数据文件损坏

① 以mount方式启动数据库

svrmgrl>startup mount;

② 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复;对于用带库备份的点用相应的rman脚本来恢复。

③ 恢复system表空间:

svrmgrl>alter database recover datafile ‘datafile_name’;

④ 打开数据库:

svrmgrl>alter database open;

⑤ 用适当的方法进行数据库全备份。

2.5 归档文件损坏

归档文件或归档文件所处的物理位置不可用,首先shutdown数据库,立即作一个冷备份。然后修改ini文件中的归档日志文件目的路径,重新启动数据库。以后再发生灾难只需从最新的备份中将相关文件恢复,数据库作recover时就不需要备份之前丢失的归档文件了。在Oracle 8之后的新版本中提供了log_archive_duplex_dest和log_archive_dest_1...5等参数允许保留多份归档文件到不同位置,甚至到远端服务器从而保证归档文件的可靠性。

3 几点数据库恢复时的注意事项

1)该文讨论所有情况的默认前提是数据库运行在归档(ARCHIVELOG)模式下,并只涉及到一般常见的情况和最基本的恢复方法。使用Oracle提供的恢复管理器RMAN也能完成上述任务,如果运行环境比较复杂建议使用RMAN来做备份和恢复。

2)一旦数据库发生灾难,最好在进行恢复之前做一次完全的冷备份,以便在进行恢复时产生差错还可以进行补救。很大一部分数据丢失是由于不正确的恢复操作所引起的。

3)当数据库完成恢复之后,尤其是使用resetlogs选项打开数据库之后,要马上关闭数据库进行一次完全的冷备份。因为,为防止放弃的重做日志被下次恢复时再次运用,resetlogs选项会重新创建redo log文件并将其的计数清零,这将使之前做的所有备份将变为不可用(一般情况下)。

4)要特别注意当进行数据库完全恢复,从发生故障的时间点前的备份中恢复损坏文件时,一定不要使备份中的redo log文件覆盖了当前的redo log文件,否则就只能进行不完全恢复并且要丢失一部分数据了。

4 结束语

要充分意识到数据备份的重要性,恢复都是基于备份基础之上的。 当数据库出现故障时要依据备份的策略作出及时、有效的恢复策略,以便确保数据的完全恢复。

参考文献:

[1] 李佩铎.Oracle数据库备份和恢复优化[J].医疗设备信息, 2007(3):47,85.

[2] 于鸿飞,黄昊,柯新华,等.医院信息系统备份与恢复方案的实现方法[J].医疗设备信息,2003(4):20-21.

[3] 孟刚,兰世龙,汪新建.HIS系统数据库恢复方法分析[J].西南军医,2009(3):536-537.

[4] 薛f炜.基于BACKUP EXEC 11D的SQL Server 2005备份与恢复[J].电脑知识与技术,2008(30):545-548.