使用dump、BBED等多种工具结合恢复ORACLE实例的过程

---友情提示,内容较多,可以从博文左上的+目录选择小节方便阅读。

实验思路:  --实验相关TRACE文件:http://download.csdn.net/detail/q947817003/6646723

1.数据库OPEN,,做DML操作不提交,查看检查点。

2.SHUTDOWN ABORT并重启到MOUNT并查询检查点

3.DUMP控制文件查看CHECKPOINT_CHANGE#/RBA

4.DUMP数据文件查看CHECKPOINT_CHANGE#/RBA,与DUMP控制文件对比

5.DUMP REDO日志文件,查看、对比CHECKPOINT_CHANGE#/RBA

6.使用BBED查看数据文件头中的CHECKPOINT_CHANGE#/RBA

7.执行EVENT事件的语句,OPEN数据库,再DUMP控制文件

8.分析OPEN时,通过ALERT日志查看的恢复过程--前滚

9.分析OPEN时,EVENT事件生成的TRACE中查看恢复过程--前滚

10.OPEN数据库时,通过ALERT日志及EVENT事件生成的TRACE中信息解析实例恢复的回滚

11.分析OPEN后的控制文件信息

参考资料及感谢:

guoyJoe   http://blog.csdn.net/guoyJoe/article/details/9034425

dbsnake   http://www.dbsnake.com/oracle-instance-recovery-end-point.html

实验结论有:

1.控制文件提供恢复所需当前REDO日志的RBA信息,当前REDO日志提供具体的用于恢复的日志内容,最终是将日志内容应用于数据文件。--实例恢复三者不能缺。

2.数据库OPEN时开始实例恢复,先应用日志内容,应用完后从alert日志中来看是已经可以连接至数据库,此时如果UNDO未完成,就有用户发出操作,数据库进程会将回滚后的数据发送至用户--可能会有等待。

3.重要的一点,数据文件、当前REDO日志文件、控制文件正常时实例恢复无需DBA干预,自动完成哈哈。

4.如果当前REDO日志丢了,只能做不完全恢复了。

关于实例恢复起止点:--来自dbsnake

可能会出现On Disk RBA比Low Cache RBA小的情况,如果Oracle发现存在这种情况,则会强制写redo。

On Disk RBA只是表示Instance Recovery的时候至少要恢复到On Disk RBA,它只是真正的current redo log file的最尾端一个前镜像。

实例恢复的起点是:Low Cache RBA和Thread Checkpoint RBA中的较大值;实例恢复的终点就是current redo log file的最尾端。On-Disk RBA是要最低恢复到的位置--事实上是只要On-Disk RBA后还有日志块就要恢复完的。

Oracle在做实例恢复的时候是受隐含参数_two_pass的控制,其默认为true,这表示要Oracle做实例恢复的时候是采用Two Pass Recovery,即要扫描current redo log file两次。

Two Pass Recovery的核心是在做实例恢复时要去掉那些已经被写入数据文件的数据块所对应的redo record,Oracle称这些redo record为Block Written Record (BWR)。

###################################################################

1.数据库正常运行,多种途径查看数据库中检查点

在普通用户下执行DML操作不提交

BYS@ bys3>set time on

13:18:17 BYS@ bys3>select * from a;   --此表在USER表空间。

B

----------

55

8

0

3

13:18:21 BYS@ bys3>delete a;

4 rows deleted.

13:18:36 BYS@ bys3>select * from a;

no rows selected

再打开一个会话(同一会话切换用户会提交操作),多种途径查看数据库中检查点:详见:http://blog.csdn.net/q947817003/article/details/11590735

SYS@ bys3>set time on

13:18:44 SYS@ bys3>col name for a35

13:18:52 SYS@ bys3>select dbid,name,checkpoint_change# from v$database;

DBID NAME                                CHECKPOINT_CHANGE#

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

3358363031 BYS3                                           1991217

13:18:59 SYS@ bys3>select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile;

FILE# NAME                                CHECKPOINT_CHANGE# CPTIME

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

1 /u01/oradata/bys3/system01.dbf                 1991217 2013-12-02 13:17:26

2 /u01/oradata/bys3/sysaux01.dbf                 1991217 2013-12-02 13:17:26

3 /u01/oradata/bys3/undotbs01.dbf                1991217 2013-12-02 13:17:26

4 /u01/oradata/bys3/user01.dbf                   1991217 2013-12-02 13:17:26

13:19:25 SYS@ bys3>select name,checkpoint_change# from v$datafile_header;

NAME                                CHECKPOINT_CHANGE#

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

/u01/oradata/bys3/system01.dbf                 1991217

/u01/oradata/bys3/sysaux01.dbf                 1991217

/u01/oradata/bys3/undotbs01.dbf                1991217

/u01/oradata/bys3/user01.dbf                   1991217

当前当前REDO日志使用情况:

13:19:57 SYS@ bys3>col member for a30

13:20:01 SYS@ bys3>select a.member,a.type,b.thread#,b.sequence#,b.bytes/1024/1024 MB,b.status,b.archived from v$logfile a,v$log b where a.group#=b.group#;

MEMBER                         TYPE       THREAD#  SEQUENCE#         MB STATUS           ARC

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

/u01/oradata/bys3/redo01.log   ONLINE           1        106         50 INACTIVE         YES

/u01/oradata/bys3/redo02.log   ONLINE           1        107         50 CURRENT          NO

/u01/oradata/bys3/redo03.log   ONLINE           1        105         50 INACTIVE         YES

###################################################################

 

2.模拟断电--shutdown abort,并重启到MOUNT 查询检查点

13:20:02 SYS@ bys3>shutdown abort;    ----13:22:11执行完此命令

ORACLE instance shut down.

13:22:11 SYS@ bys3>

alert日志:  --推荐个小方法:把alert日志做一个软链接到ORACLE用户家目录,查看方便。

[oracle@bys3 ~]$ cat alert_bys3.log

Mon Dec 02 13:22:09 2013

Shutting down instance (abort)

License high water mark = 4

USER (ospid: 846): terminating the instance

Instance terminated by USER, pid = 846

Mon Dec 02 13:22:11 2013

Instance shutdown complete

######################################

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索数据库
, 日志
, 文件
, 实例
检查点
oracle存储过程实例、mysql dump实例、oracle dump、oracle dump 导入、oracle dump 导出,以便于您获取更多的相关知识。

时间: 2024-12-31 05:19:26

使用dump、BBED等多种工具结合恢复ORACLE实例的过程的相关文章

Oracle实例恢复和介质恢复

Oracle恢复基础概述  一.恢复解决方案 错误类型及解决方案 错误分类 恢复解决方案 介质失败 如果是少量的块损坏,使用块介质恢复:如果是大量的块.数据文件.表空间的损坏,可能需要对损坏的数据文件或者表空间执行完全恢复:如果是归档Redo日志文件或者联机Redo日志文件的丢失,那么只需要不完全恢复方式. 逻辑损坏 如果是程序员错误导致出现的问题,可通过补丁应用修复问题.对于无法修复的问题,也可采用介质恢复手段来恢复数据. 用户错误 根据不同用户错误,选择不同的Flashback技术恢复,使用

《Effective Debugging:软件和系统调试的66个有效方法》——第7条:试着用多种工具构建软件,并将其放在不同的环境下执行

第7条:试着用多种工具构建软件,并将其放在不同的环境下执行 有时我们可以通过改变环境来锁定一些难以捕获的bug.例如,我们可以用另外一款编译器来构建这个软件,也可以切换到其他的运行时解释器.虚拟机.中间件.操作系统或CPU架构上.由于那些环境可能会更加严格地检查输入数据,或能通过其结构来凸现程序中的错误(参见第17条),因此可以帮助我们发现原来很难找到的一些bug.如果程序不够稳定.总是发生无法重现的崩溃问题,或移植起来不太顺利,那就应该试着把它放在另外一种环境下进行测试,这使得我们能够使用更为

《Effective Debugging:软件和系统调试的66个有效方法》一第7条:试着用多种工具构建软件,并将其放在不同的环境下执行

第7条:试着用多种工具构建软件,并将其放在不同的环境下执行 有时我们可以通过改变环境来锁定一些难以捕获的bug.例如,我们可以用另外一款编译器来构建这个软件,也可以切换到其他的运行时解释器.虚拟机.中间件.操作系统或CPU架构上.由于那些环境可能会更加严格地检查输入数据,或能通过其结构来凸现程序中的错误(参见第17条),因此可以帮助我们发现原来很难找到的一些bug.如果程序不够稳定.总是发生无法重现的崩溃问题,或移植起来不太顺利,那就应该试着把它放在另外一种环境下进行测试,这使得我们能够使用更为

PS综合多种工具完美抠出背景杂乱的婚纱

  PS综合多种工具完美抠出背景杂乱的婚纱            原图 最终效果 1.把原图素材大图保持到本机,打开PS,再打开保持的原图素材,进入通道面板,把蓝色通道复制一层,得到蓝副本通道,如下图. 2.选择蓝副本通道,按Ctrl + L 调整色阶,把暗部及中间调都压暗一点,参数及效果如下图. 3.按Ctrl + A 把蓝副本通道全选,按Ctrl + C 复制,点RGB通道返回图层面板,新建一个图层,按Ctrl + V 粘贴,效果如下图.后面的操作比较复杂新手最好到240ps.com视频栏目

在Linux系统下使用PhotoRec & TestDisk工具来恢复文件

当你在系统中有意或无意地使用 shift + delete 组合键.删除选项,或是清空回收站的方式来删除一个文件时,该文件的内容并没有从硬盘(或是其它存储设备)上直接销毁. 它仅仅是从系统的目录结构中被移除,然后你在删除文件的目录下就看不到该文件了,但是这个文件仍然存在你磁盘中的某个位置上. 如果你有一个合适的工具和相关的专业知识,你就可以从电脑中恢复已丢失的文件.然而,随着你存储的文件越来越多,删除的文件将会被覆盖,你可能只能恢复最近删除的文件了. 在这篇文章中,我们将阐明如何在 Linux

分享一个安卓的内置多种工具类的Activity_java

一个安卓的Activity,内置了多种工具类.要用的话,让自己的Activity继承这个Activity,各种方便,便于理解我在每个方法上都写了详细的注释,添加了网络部分,添加了表单文件一键上传 演示图 代码 void Call(java.lang.String number) 拨打=电话的方法 void download(java.lang.String url, NetResult result) 用于下载文件的函数 java.lang.String formatMemorySize(lon

Oracle实例恢复

Oracle实例恢复原理 首先从事物说起,当执行update开启一个事物的时候,首先需要在buffer cache中找到可用的块(block)更新数据,然后构造cr块,将update之前的数据放入到undo中,同时会在log buffer内写日志,log buffer内数据每隔3秒通过lgwr进程将往redo log写日志,在这个过程更改的数据还在内存中,产生脏数据,直到dbwr进程将脏数据写入到磁盘,如果脏数据还未写入磁盘,脏数据中包括提交或未提交的,这个时候由于掉掉或其他原因导致数据库意外宕

PL/SQL远程备份和恢复Oracle数据库_oracle

在客户端远程备份的文件保存在数据库所在主机上,不会直接拷贝到客户端.------------------------------------------  首先无论你的Oracle服务器是Linux还是windows操作系统,Oracle的备份和恢复操作都是使用DBMS_DUMP来实现导入(备份)和导出(恢复).首先你要安装好PL/SQL,用PL/SQL来执行我下面提供的JOB就可以实现了.  一.Oracle的导出(备份) 1.用PLSQL连接Oracle数据库服务器,使用你需要导出的用户连接

oracle介质恢复和实例恢复的概念

1.概念 REDO LOG是Oracle为确保已经提交的事务不会丢失而建立的一个机制.实际上REDO LOG的存在是为两种场景准备的,一种我们称之为实例恢复(INSTANCE RECOVERY),一种我们称之为介质恢复(MEDIA RECOVERY). 实例恢复的目的是在数据库发生故障时,确保BUFFER CACHE中的数据不会丢失,不会造成数据库的不一致. 介质恢复的目的是当数据文件发生故障时,能够恢复数据. 虽然这两种恢复使用的机制类似的,但是这两种恢复也有着十分本质的不同,这一点也是很多D