Oracle介于Cache-Low RBA和On-Disk RBA之间的恢复过程

在最近（2010年9月6日）的一次培训中，有位朋友问起上节案例，该如何证明和验证Oracle介于Cache-Low RBA和On-Disk RBA之间的恢复过程？我们可以通过如下的过程来做一些观察和证明。

首先执行一个建表的CTAS操作，这个操作是为了多生成一些脏块（Dirty Buffer）,然后紧接着执行两次控制文件转储，两次转储是为了确认对比一下控制文件的检查点没有变化，然后紧接着执行强制关闭数据库（Abort方式），再启动数据库：







现在来分析一下跟踪文件，看看其中的相关信息，选取第二次转储的控制文件信息，在数据库Entry部分，可以找到检查点记录：

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

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

此时记录数据库的检查点SCN是119459，这是16进制，10进制是1152089。



继续检查，在检查点进程记录部分，获得如下信息，这里就包含了Low Cache RBA和On 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 RBA的SCN是1152421，转换为16进制也就是1195A5，也和控制文件中记录的On Disk SCN完全相符。

数据库的恢复SCN范围也就由此确定，即SCN范围：1152089~1152241。



启动数据库之后，查询一下日志信息，可以看到39号日志文件正是执行恢复的日志文件，其SCN范围处于1152088和1172422之间，一个日志就满足了之前恢复的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 RBA至On Disk RBA的过程。




Low cache RBA和On disk RBA的区别


　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进程更新控制文件的进度是不同的。