Oracle的Archive Log模式下的恢复工作

oracle|恢复

    学习并测试了一下Oracle数据库在开启Archive Log模式下的恢复.
  
 系统是Win2K Server+Oracle 8.1.7.
  
 参考了Chinaunix.net和ITPub.com网站相关资料.在此感谢给我的帮助.
  
 注意,养成一个好的习惯非常重要.在开始恢复之前,以及恢复完成后,都要做一个系统全备份.
  
 首先,要开启Archive Log归档日志模式
  
 1. 关闭数据库
  
 2. 修改initSID.ora文件.这个文件通常在$ORACLE_HOME/admin/$ORACLE_SID目录下或是在$ORACLE_HOME/database目录下.
  
  log_archive_start = true
  log_archive_dest_1 = "location=F:oraclearchive"
  log_archive_format = "ORA_%S.arc"
  
 注意通常Windows版和Unix/Linux版的一些参数写法有差异,请参照各自版本的技术文档.
  
 3. 启动数据库到mount状态
  
  startup mount
  
 这样加载了数据库文件,但是不打开数据库.
  
 4. 检查当前的Archive Log归档日志模式
  
  archive log list
  
 显示的信息是:
  
  Database log mode       No Archive Mode
  Automatic archival       Disabled
  
 这时用下面的命令开启数据库的Archive Log模式
  
  alter database archivelog
  
 再次用"archive log list"显示信息,应该是:
  
  Database log mode       Archive Mode
  Automatic archival       Enabled
  
 再用命令alter database open来打开数据库.
  
 上面的工作完了以后,然后,我们可以来进行测试了.
  
 在测试之前,我们来熟悉一下这个归档日志Archive Log是什么样的.
  
 通过Sqlplus或Svrmgrl以sysdba身份连接到数据库,执行"alter system switch logfile;"在我们指定的F:oraclearchive目录下就可以看到归档日志了.
  
 文件名是我们指定的形同"ORA_0379.arc",其中0379是Oracle自动取的序号.在我们做
  
 最后,我们要来测试归档模式下的备份恢复有什么不一样.
  
 在非归档模式下,我们一般每天做一次数据库备份(冷备份和热备份的差别仅在于备份时数据库是关闭的还是开启的).这样,我们就拥有了每天一个的备份点,换句话说,我们可以在数据库崩溃的情况下,通过备份介质,将数据库恢复到某一个备份点上.
  
 但是显而易见,这样的备份和恢复是不完全的,我们对于两个备份点之间的数据是无法恢复的.
  
 而在开启了归档模式的情况下,情况不一样了.所有系统的REDO_log重做日志中提交的操作,均会在重做日志重复利用前被保存为归档日志保存下来,也就是说,所有用户对于数据库的每一个操作都被记录在案.这样.在维持我们原先的数据库备份计划的情况下,除了每天一个备份点之外,我们还拥有了没两个备份点之间的所有历史操作记录.
  
 这样,结合每天的数据库备份和归档日志以及在线重做日志,我们可以将数据库精确恢复到数据库崩溃前的那一时刻, 不会有数据丢失的情况发生.
  
 当然,这样的前提是,数据库备份和归档日志不能同时损坏或丢失.
  
 我们假设的环境是
  
  >> 假设有3个硬盘, C, D, E,系统在C盘, 数据文件在D盘,归档日志在E盘.控制文件,在线重做日志都有3组并复用,放在C盘,D盘和E盘.
  
  >> 现在的情况是我们保留有所有的归档日志,保留有5天前的备份磁带(很不巧,由于种种原因,近5天的备份都没有成功,不过幸运的是,在此期间系统及软件配置都没有更改).
  
  >> 硬盘D突然损坏了,数据库崩溃了,所有人都无法连接到数据库.
  
  >> 在本例中,我们只考虑了数据文件损坏, 假设所有的控制文件,重做日志都正常.
  
 我们现在要开始恢复工作了.
  
  >> 在联系了硬件供应商后,我们的新硬盘到了,安装上后,通过5天前的备份磁带,恢复D盘上所有的文件.
  
  >> 通过Svrmgrl或Sqlplus以system用户登录到Oracle,
  
  >> 打开数据库到mount状态,"startup mount",这时,Oracle会提示数据库文件损坏,需要修复
  
  >> 根据提示的文件,输入命令"recover datafile 'D:OracleData01.dbf';
  
  >> Oracle将自动寻找所需要的归档日志和当前的Redo_log来恢复数据文件,我们只需要在每一个提示信息后按回车键确定应用所显示的归档日志文件.恢复完成后,Oracle将有提示信息.
  
  >> 恢复完成后,可以尝试用命令"alter database open"来打开数据库,如果还是有数据文件损坏,Oracle将再次提示需要修复.只需要重复上面两步操作.
  
  >> 重复操作,直至所有的数据文件都恢复.用命令"alter database open"来打开数据库.
  
 这样,我们就基本完成了归档模式开启的情况下的数据库恢复工作,在这种模式下,数据库可以恢复到任一时刻(可以在应用归档日志文件恢复时取消以中断恢复过程).而且,即便因意外而导致我们的每日数据库备份没有成功执行时,仍然可以通过几天前的冷/热备份+连续的归档日志文件来完成我们的数据库恢复工作.
  
 另注, 可以直接通过命令"recover database" 来完成整个恢复过程,不过这样感觉缺乏成就感.除非对备份或是自己的水平很有信心,否则不建议使用.
  
 以上测试通过.

时间: 2024-10-29 23:13:36

Oracle的Archive Log模式下的恢复工作的相关文章

oralce非归档模式下的恢复(一)历史日志没有被覆盖(可完全恢复)

案例1: 历史日志没有被覆盖(可以完全恢复) 1)切换到非归档模式 SQL> archive log list Database log mode              Archive Mode Automatic archival             Enabled Archive destination            /disk1/arch/anny Oldest online log sequence     7 Next log sequence to archive  

oralce非归档模式下的恢复(二)日志发生切换且历史日志已经被覆盖

案例2:日志发生切换,历史日志已经被覆盖(只能做不完全恢复) 1)模拟环境 SQL> insert into scott.tb01 values(777); 1 row created. SQL> insert into scott.tb01 values(888); 1 row created. SQL> commit; Commit complete. SQL> col status for a10 SQL> select * from v$log; GROUP#    

SA 沙盘模式下不用恢复xp_cmdshell和xplog70.dll也执行命令_安全相关

首先开启沙盘模式: exec master..xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0\Engines','SandBoxMode','REG_DWORD',1 然后利用jet.oledb执行系统命令 select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\windows\system32\ias\ias.mdb','select shell(

oracle归档模式下的Rman备份集在异机恢复简介

环境: OS:Red Hat Linux As 5 DB:10.2.0.4 有些时候因为测试环境需要,我们需要使用生产库的备份集在另外一台新的机器上做恢复(前提是新机器事先安装Oracle软件,版本跟原库一致),下面是恢复过程. 1.在原库上做全备(在原库上操作) run{ allocate channel c1 device type disk; allocate channel c2 device type disk; backup format '/u02/rman_backup/full

Oracle IMU模式下REDO格式详解

1. 什么是IMU?IMU的主要作用是什么,也就是说为了解决什么问题? IMU--->In Memory Undo,10g新特性,数据库会在shared pool开辟独立的内存区域用于存储Undo信息, 每个新事务都会分配一个IMU buffer(私有的),一个buffer里有很多node,一个node相当于一个block(回滚块). IMU特性: IMU顾名思义就是在内存中的undo,现在每次更改data block,Oracle 不用去更改这个undo block(也不会生成相应的redo了

Mongorestore的archive(归档)模式恢复原理解析

在上篇Mongodump的archive(归档)模式原理解析中介绍过,Mongodump的archive(归档)模式产生的文件是将多个集合的数据通过一个Multiplexer多路复用混合在一起,因此对应在恢复的时候就需要有一个Demultiplexer来将数据进行解析,是一个多路复用的逆过程.对应于mongodump,MongoDB官方提供了mongorestore这个恢复工具. 归档文件的格式 复习一下归档文件的格式,其最前面有4个字节的magic number,然后是元数据部分(prelud

oracle非归档遭遇ora-00600 [kcratr_nab_less_than_odr]的恢复

主要遇到了如下几个问题: 1. mount 发现控制文件异常,通过替换,用pfile mount成功,这个不说了. 2. open报了一个如下的错误: Fri Jul 04 20:03:23 2014 alter database open Beginning crash recovery of 1 threads  parallel recovery started with 15 processes Started redo scan Completed redo scan  read 22

【BBED】丢失归档文件情况下的恢复

[BBED]丢失归档文件情况下的数据文件的恢复   1.1  BLOG文档结构图     1.2  前言部分   1.2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 若丢失归档情况下数据文件的恢复,bbed和隐含参数(重点) ② 数据库启动过程中的介质恢复,scn号的关系 ③ BBED如何修改文件头 ④ 归档和非归档模式下数据库的全备     Tips:        ① 若文章代码格式有错乱,推荐使用QQ

【DATAGUARD】物理dg在主库丢失归档文件的情况下的恢复(七)

[DATAGUARD]物理dg在主库丢失归档文件的情况下的恢复(七) 一.1  BLOG文档结构图     一.2  前言部分   一.2.1  导读 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 物理dg的在主库丢失归档文件的情况下的恢复 ② 物理dg管理和维护的一些sql   注意:本篇BLOG中代码部分需要特别关注的地方我都用黄色背景和红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33,thread 2