什么时候会产生实例恢复呢?当你数据库服务器异常断电,重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的,无须DBA的干涉。当然这里有个前提条件:数据文件、

在线日志文件、控制文件不得有损坏。

我们用实验来分析一下实例恢复的整个过程吧!

1、在关闭数据库前,我们先看一下几个检查点的SCN

--System checkpoint SCN  (存在于控制文件)

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

     856021

--控制文件中保存的数据库检查点SCN号实际上在所有数据文件头部中最小的检查点SCN

SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

  1        856021

  2        856021

  3        856021

  4        856021

  5        856021

--控制文件中保存的数据文件检查点SCN:当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件中

SQL>  select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

  1        856021

  2        856021

  3        856021

  4        856021

  5        856021

--每个数据文件的文件头中的检查点SCN

select name,last_change# from v$datafile

STOP SCN(存在于控制文件)

最后一类SCN,End SCN他也是记录在控制文件当中,每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用

来去验证数据库启动过程中是否需要做instance recovery。我们可以通过

那么其实在数据库正常运行的情况下,对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).

2、此命令可以模拟异常断电

SQL> shutdown abort;

ORACLE instance shut down.

这三个检查点的SCN一致,接下来模拟异常断电,重启机器

3、监控告警日志

Tue Oct 31 17:51:47 2000

Shutting down instance (abort)

License high water mark = 2

Instance terminated by USER, pid = 2350

4、数据库启动到MOUNT状

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

     856021

SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

  1        856021

  2        856021

  3        856021

  4        856021

  5        856021

SQL>  select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

  1        856021

  2        856021

  3        856021

  4        856021

  5        856021

SQL> col name format a30

SQL> select name,last_change# from v$datafile;

NAME      LAST_CHANGE#

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

/oradata/june/june/system01.dbf

/oradata/june/june/sysaux01.dbf

/oradata/june/june/undotbs01.dbf

/oradata/june/june/users01.dbf

/oradata/june/june/example01.dbf

发现与异常断电前的检查点的SCN一致,这里一致无须介质恢复。

先不着急open数据库,我们做一些dump

alter session set events 'immediate trace name CONTROLF level 12';

***************************************************************************

***************************************************************************

DATABASE ENTRY

***************************************************************************

 (size = 316, compat size = 316, section max = 1, section in-use = 1,

  last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 1, numrecs = 1)

 11/07/2000 12:05:40

 DB Name "JUNE"

 Database flags = 0x00404000 0x00001000

 Controlfile Creation Timestamp  11/07/2000 12:05:41

 Incmplt recovery scn: 0x0000.00000000

 Resetlogs scn: 0x0000.000b8338 Resetlogs Timestamp  11/07/2000 12:05:44

 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  08/13/2009 23:00:48

 Redo Version: compatible=0xb200000

 #Data files = 5, #Online files = 5

 Database checkpoint: Thread=1 scn: 0x0000.000d0fd5   ----转换为10进制是856021

 Threads: #Enabled=1, #Open=1, Head=1, Tail=1

 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000

 Max log members = 3, Max data members = 1

 Arch list: Head=0, Tail=0, Force scn: 0x0000.000cc0ccscn: 0x0000.000b8338

 Activation ID: 307689684

 Controlfile Checkpointed at scn:  0x0000.000d34a8 11/07/2000 20:29:02

 thread:0 rba:(0x0.0.0)

 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

  00000000 00000000 00000000 00000000 00000000 00000000

 

 234 DATA FILE RECORDS

235 ***************************************************************************

236  (size = 520, compat size = 520, section max = 100, section in-use = 5,

237   last-recid= 64, old-recno = 0, last-recno = 0)

238  (extent = 1, blkno = 11, numrecs = 100)

239 DATA FILE #1:

240   name #7: /oradata/june/june/system01.dbf

241 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1

242  tablespace 0, index=1 krfil=1 prev_file=0

243  unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

244  Checkpoint cnt:91 scn: 0x0000.000d0fd5 11/07/2000 15:19:36

245  Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39

Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39

--结束的SCN填无穷大,说明是异常关机的,重启数据库必须做实例恢复

从dump 控制文件查看

***************************************************************************

***************************************************************************

CHECKPOINT PROGRESS RECORDS

***************************************************************************

 (size = 8180, compat size = 8180, section max = 11, section in-use = 0,

  last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 2, numrecs = 11)

THREAD #1 - status:0x2 flags:0x0 dirty:37

low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)

on disk scn: 0x0000.000d3522 11/07/2000 20:31:01

resetlogs scn: 0x0000.000b8338 11/07/2000 12:05:44

heartbeat: 413022655 mount id: 307684709

THREAD #2 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #3 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #4 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #5 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #6 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #7 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

THREAD #8 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 0 mount id: 0

low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)

on disk scn: 0x0000.000d3522 11/07/2000 20:31:01

-- low cache rba:(0xa.12a30.0)实例恢复的起点:10号日志,第76336个块,第0个字节

--on disk rba:(0xa.12ab4.0):实例恢复的终点:10号日志,第76468个块,第0个字节

-- Database checkpoint: Thread=1 scn: 0x0000.000d0fd5   ----转换为10进制是856021 scn恢复起点

--on disk scn: 0x0000.000d3522 11/07/2000 20:31:01   ---865570 scn恢复终点

low cache rba:就是CKPT记录的DBWR写出的进度

on disk rba:就是LGWR的写进度

Beginning crash recovery of 1 threads

Started redo scan

Completed redo scan

 read 66 KB redo, 37 data blocks need recovery

Started redo application at

 Thread 1: logseq 10, block 76336

Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0

  Mem# 0: /oradata/june/june/redo01.log

Completed redo application of 0.06MB

Completed crash recovery at

 Thread 1: logseq 10, block 76468, scn 885570

 37 data blocks read, 37 data blocks written, 66 redo k-bytes read

实例恢复的起点和终点;

checkpoint position 到 end of redo log

10、最后总结一下实例恢复

(1)数据文件、在线日志文件、控制文件不得有损坏

(2)数据库自动恢复,无需DBA干涉

(3)恢复只需在线日志文件,无需归档日志

(4)数据库在open的时候开始实例恢复

实际上我做的这个实例恢实验的还没有写完整, 还有最后一步回滚!这个就留给你们思考!

实例恢复三步:前滚--->打开库---->后滚(也叫回滚)

dump 验证实例恢复的起点和终点的更多相关文章

  1. ORACLE实例恢复过程详细分析--使用dump、BBED等多种工具结合分析

    ---友情提示,内容较多,可以从博文左上的+目录选择小节方便阅读.  实验思路:  --实验相关TRACE文件:http://download.csdn.net/detail/q947817003/6 ...

  2. SQL Server的实例恢复解析

    同Oracle一样,SQL Server在非一致性关闭的时候也会进行实例恢复(Instance Recovery),本文根据stack overflow的文章介绍一些SQL Server实例恢复的知识 ...

  3. Oracle 实例恢复

    -======================= -- Oracle 实例恢复 --======================= 一.Oracle实例失败 Oracle实例失败多为实例非一致性关闭所 ...

  4. 【百度地图API】让用户选择起点和终点的驾车导航

    原文:[百度地图API]让用户选择起点和终点的驾车导航 摘要: 如果用户搜索“从机场到火车站”,使用驾车导航DrivingRoute会默认显示一条结果.但同一个城市可能有多个机场和火车站,那么,如何用 ...

  5. oracle--介质恢复和实例恢复的基本概念

    1.概念 REDO LOG是Oracle为确保已经提交的事务不会丢失而建立的一个机制.实际上REDO LOG的存在是为两种场景准备的,一种我们称之为实例恢复(INSTANCE RECOVERY),一种 ...

  6. (实用篇)php通过会话控制实现身份验证实例

    会话控制的思想就是指能够在网站中根据一个会话跟踪用户.这里整理了详细的代码,有需要的小伙伴可以参考下. 概述 http 协议是无状态的,对于每个请求,服务端无法区分用户.PHP 会话控制就是给了用户一 ...

  7. jQuery 验证实例(shopnc二次开发)

    shopnc 商家用户实现添加用户与前台用户分离, jQuery 验证实例 equalTo:等于 <div id="saleRefund" show_id="1&q ...

  8. 未找到或无法访问服务器 请验证实例名称是否正确并且SQL Server 已配置为允许远程连接

    无法连接到sql server 2008服务器 报下错误 其他信息    在与SQL Server建立连接时出现与网络相关的或特定于实例的错误 未找到或无法访问服务器请验证实例名称是否正确并且SQL ...

  9. 请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接。 (provider: Named Pipes Provider, error: 40 - 无法打开到 SQL Server 的连接)

    程序异常,错误信息:在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误.未找到或无法访问服务器.请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接. (pro ...

随机推荐

  1. MVC知识总结(前序)

    距离2015年的来临还有1天的时间,是时候总结一下今年的经过脑子的知识了,由于今年里工作中接触MVC的时间特别多,所以打算针对MVC这个东西的知识进行一个总结,好歹对得起在几个项目中用了MVC来进行开 ...

  2. Asp.Net Core简单整理

    1.Asp.NetCore 中文入门文档 http://www.cnblogs.com/dotNETCoreSG/p/aspnetcore-index.html

  3. nyoj349 poj1094 Sorting It All Out(拓扑排序)

    nyoj349   http://acm.nyist.net/JudgeOnline/problem.php?pid=349poj1094   http://poj.org/problem?id=10 ...

  4. SqlServer Change Data Capture(CDC)数据变更捕获

    最近在使用SqlServer2008r2数据库做系统的时候,在某些重要的.经常涉及到修改的表上,想加上一些恢复机制,一开始想找找看看有没有类似Oracle数据库闪回那样的功能,后来发现CDC的功能可以 ...

  5. 注册dll

    unit Unit1; interface uses  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, Syste ...

  6. 周末充电之WPF(三 ) .后台动态生成控件

    布局 -连连看: 代码: private void Window_Loaded_1(object sender, RoutedEventArgs e) { //动态创建行 ; i < ; i++ ...

  7. mkisofs出错解决办法

    使用mkisofs遇到错误: genisoimage: Uh oh, I cant find the boot catalog directory 'beini/boot/isolinux'! 使用的 ...

  8. bzoj1478:Sgu282 Isomorphism

    思路:由于题目中是通过改变点的编号来判断两种染色方案是否相同,而染色的确是边,于是考虑如何将点置换转化为边置换. 对于一个有n个点的完全图,其点置换有n!个(即全排列个数),又由于每一个边置换都对应了 ...

  9. c++primer复习(六)—面向对象编程

    1 C++中,通过基类的引用(或指针)调用虚函数时,发生动态绑定,两个条件(基类引用或指针.虚函数)缺一不可 虚函数的默认实参将发生静态绑定 2 继承层次的根类一般都需要定义虚析构函数 3 任意非st ...

  10. C# DES

    using System; //这个是使用DES的基础 using System.Security.Cryptography; //这个是处理文字编码的前提 using System.Text; // ...