ITPub博客

首页 > Linux操作系统 > Linux操作系统 > low cache rba,on disk rba数据库恢复过程

low cache rba,on disk rba数据库恢复过程

原创 Linux操作系统 作者:atlantisholic 时间:2011-03-29 23:04:28 0 删除 编辑

low cache rba

  就是CKPT记录的DBWR写出的进度,也就是更新到控制文件和数据文件的进度记录,对于增量检查点,因为我们都知道,当checkpoint发生的时候,ckpt进程会通知dbwn进程去写出dirty buffer,但是需要特别注意的是ckpt进程通知dbwn进程后,并不需要等待dbwn写到当前触发检查点那个时候的scn后,再去更新当前控制文件和数据文件的scn(当然ckpt是有心跳的,通过心跳ckpt进程可以监视dbwn写的进度),而是将当前刚刚写完的dirty buffer(写多少算多少,写完那个算那个)对应的scn更新到数据文件和控制文件当中,我们都知道修改的data buffer会被移动到checkpoint queue中,当然这个dirty buffer是在checkpoint queue中按照low rba的先进先出的顺序写出的,无论后来对这个buffer做了多少次修改,他在queue中的写出顺序是不会被改变的。那么每3秒钟,ckpt还会去更新控制文件和数据文件的heartbeat值。那么实际上每隔3秒,也会触发检查点,但是,这样的操作并没有被oracle正式作为一种检查点的触发方式列入文档 ,因为这个3秒记录的是dbwr的写的进度而不是通知让dbwr去写出。

  on disk rba就是LGWR的写进度

  如果数据库carsh了,low cache rba是恢复的起点,on disk rba是恢复的终点。

  分析:

  dbwr成功写完后并不会把当前的此刻scn信息写到控制文件中,只有CKPT才更新控制文件和数据文件头,dbwr只要成功将dirty data写入数据文件就是成功, CKPT只要能将最新DBWR写完的SCN更新到控制文件和数据文件头就算成功。但是由于CKPT进程不是实时更新dbwr写完的scn到控制文件中,而是采用每3妙更新一次的策略,因此最后有ckpt进程写进控制文件的scn信息有可能不是当前dbwr刚刚写完的scn值。这点应该注意,也就是说dbwr写的进度与ckpt进程更新控制文件的进度是不同的。

 

异常关闭数据库

shutdown abort; startup mount;

转储控制文件

alter session set events 'immediate trace name controlf level 12'; alter database open;

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

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)

 07/31/2010 16:35:48

 DB Name "ENMO"

 Database flags = 0x00404000 0x00001000

 Controlfile Creation Timestamp  07/31/2010 16:35:49

 Incmplt recovery scn: 0x0000.00000000

 Resetlogs scn: 0x0000.00089c75 Resetlogs Timestamp  07/31/2010 16:35:52

 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  03/14/2008 18:46:22

 Redo Version: compatible=0xa200300

 #Data files = 4, #Online files = 4

 Database checkpoint: Thread=1 scn: 0x0000.00119459

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

此时记录数据库的检查点SCN119459,这是16进制,10进制是1152089

 

继续检查,在检查点进程记录部分,获得如下信息,这里就包含了Low Cache RBAOn Disk RBA的信息,也记录了Dirty Buffer的数量是48

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

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:48

low cache rba:(0x27.6c.0) on disk rba:(0x27.f9.0)

on disk scn: 0x0000.001195a5 09/10/2010 14:55:25

resetlogs scn: 0x0000.00089c75 07/31/2010 16:35:52

heartbeat: 729376761 mount id: 570757625

把这里的RBA信息简单分析一下:

 

RBA信息

Log Sequence

Blcok Number

Low Cache RBA

0x27.6c.0

0x27 = 39

6c=108

On Disk RBA

0x27.f9.0

0x27=39

F9=249

 

在启动数据库时,进行恢复产生了一个跟踪文件,记录了恢复的过程,恢复从39号日志文件的第108块恢复至249块,正是以上数据库关闭之前的RBA地址范围:

*** SESSION ID:(158.4) 2010-09-10 14:56:11.738

Successfully allocated 2 recovery slaves

Using 545 overflow buffers per recovery slave

Thread 1 checkpoint: logseq 39, block 2, scn 1152089

  cache-low rba: logseq 39, block 108

    on-disk rba: logseq 39, block 249, scn 1152421

  start recovery at logseq 39, block 108, scn 0

----- Redo read statistics for thread 1 -----

Read rate (ASYNC): 70Kb in 0.20s => 0.34 Mb/sec

Total physical reads: 4096Kb

Longest record: 8Kb, moves: 0/243 (0%)

Change moves: 2/29 (6%), moved: 0Mb

Longest LWN: 53Kb, moves: 0/6 (0%), moved: 0Mb

Last redo scn: 0x0000.001195a4 (1152420)

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

数据库恢复的检查点起点是SCN 1152089,也就是控制文件中记录的数据库最后完成的检查点,On-Disk RBASCN1152421,转换为16进制也就是1195A5,也和控制文件中记录的On Disk SCN完全相符。

数据库的恢复SCN范围也就由此确定,即SCN范围:1152089~1152241

 

启动数据库之后,查询一下日志信息,可以看到39号日志文件正是执行恢复的日志文件,其SCN范围处于11520881172422之间,一个日志就满足了之前恢复的SCN范围,恢复完成之后日志切换,当前使用了40号日志:

SQL> select * from v$log;

 

GROUP# THREAD#  SEQUENCE#    BYTES MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME

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

     1       1         40 52428800       1 NO  CURRENT        1172422 10-SEP-10

     2       1         38 52428800       1 NO  INACTIVE       1131823 10-SEP-10

     3       1         39 52428800       1 NO  INACTIVE       1152088 10-SEP-10

 

至此我们清晰地看到了数据库恢复从Low Cache RBAOn Disk RBA的过程。

         注意到Oracle在恢复过程中,首先读取日志,从最后完成的检查点开始,应用所有的重做记录,这个过程叫前滚(rolling forward),也就是crash recovery过程,完成前滚之后,数据库可以被打开并提供访问和使用。

         此后进入实例恢复的第二个阶段,Oracle回滚未提交事务。Oracle使用两个特点来增加这个恢复阶段的效率,这两个特点是fast-start on-demand rollback和fast-start parallel rollback(这些特点是fast-start fault recovery的组成部分,仅在oracle8i之后的企业版中可用)。

        使用fast-start on-demand rollback特点,Oracle自动允许在数据库打开之后开始新的事务,这通常只需要很短的crash recovery时间。如果一个用户视图访问被异常终止进程锁定的记录,Oracle回滚哪些新事务请求的记录,也就是说,因需求而回滚。因而,新事务不需要等待漫长的事务回滚时间。在fast-start on-demand rollback中,后台进程SMON充当一个调度员,使用多个服务器进程并行回敬一个事务集。

         fast-start parallel rollback主要对于长时间运行的未提交事务有效,尤其是并行insert,update和delete等操作。SMON自动决定何时开始并行回滚并且自动在多个进程之间分散工作。

         fast-start parallel rollback的一个特殊形式是内部事务恢复(intra-transaction recovery)。在内部事务恢复中,一个大的事务可以被拆分,分配给几个服务器进程并行回滚。可以通过初始化参数fast_satrt_parallel_rollback来控制并行回滚,改参数有3个参数值。

        false:禁用fast-start parallel rollback.

       low:限制恢复进程不能超过2倍的cpu_count.

        high:限制恢复进程不能超过4倍的cpu_count.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23071790/viewspace-691263/,如需转载,请注明出处,否则将追究法律责任。

上一篇: shared_pool图解
请登录后发表评论 登录
全部评论

注册时间:2010-08-30

  • 博文量
    130
  • 访问量
    629248