重建控制文件后,各文件(datafile、control file、redo log)中scn的关系

很久之前看了一个论坛上的帖子,谈论到到本文的主题,但是我觉得帖子上说的不足以让人信服。今天想起来了,就自己动手做做实验。

实验方法:

0:backup control file to trace

1:update一张表2000条记录,commit

2:shutdown abort

3:startup nomount

4:重建控制文件

5:dump 控制文件头,数据文件头,redo文件

6:recover database

7:dump 控制文件头,数据文件头,redo文件

8:open 数据库

下面列出部分实验过程中的数据:

第5步dump文件结果(片段):

controlfile :

                Controlfile Creation Timestamp  07/20/2016 02:06:03

                Database checkpoint: Thread=1 scn: 0x0000.00fbb8cc --与current的redo日志的低scn一致
Controlfile Checkpointed at scn:  0x0000.00000000

         控制文件记录的checkpoint process部分:
THREAD #1 - 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: 917640505 mount id: 898487178

        控制文件记录的数据文件部分:

Checkpoint cnt:615 scn: 0x0000.00fbb8cd 07/20/2016 02:01:49                

Stop scn: 0xffff.ffffffff 07/20/2016 02:06:03

datafile:
                 status:0x4 root dba:0x00000000 chkpt cnt: 615 ctl cnt:614
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.00fbb8cd 07/20/2016 02:01:49

redofile:

LOG FILE #3:
  name #1: /home/oracle/app/oracle/oradata/orcl2/redo03.log
  Thread 1 redo log links: forward: 0 backward: 2
  siz: 0x19000 seq: 0x00000138 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
  Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00fb6971
  Low scn: 0x0000.00fbb8cc 07/20/2016 02:01:49
  Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

第7步dump文件结果(片段):

控制文件没有变化

datafile:
    Checkpoint cnt:614 scn: 0x0000.00fc0810 07/20/2016 02:04:14
    Stop scn: 0x0000.00fc0810 07/20/2016 02:04:14

这里可以看到数据文件scn已经恢复到一致,这里贴一段alert日志,可以看到recover database使用了redo03文件。

Wed Jul 20 02:56:20 2016
ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 4 slaves
Wed Jul 20 02:56:20 2016
Recovery of Online Redo Log: Thread 1 Group 3 Seq 312 Reading mem 0
  Mem# 0: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Media Recovery Complete (orcl2)
Completed: ALTER DATABASE RECOVER  database 

 最后一步open后的dump信息:

database open
  controlfile :
  Database checkpoint: Thread=1 scn: 0x0000.00fc0813
  Controlfile Checkpointed at scn:  0x0000.00fc084c 07/20/2016 03:33:09

  datafile:

Checkpoint cnt:617 scn: 0x0000.00fc0813 07/20/2016 03:33:08
      Stop scn: 0xffff.ffffffff 07/20/2016 02:04:14

可以看到控制文件的数据库检查点与数据文件检查点一致。控制文件检查点略大,原因是因为增量检查点只更新控制文件检查点。

那么可以认为:重建控制文件后,控制文件的检查点来自于redo文件。因为recover过程中使用redo文件恢复数据文件使其一致。这是noresetlogs的情况。resetlogs的情况后续再实验。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值