Oracle实例恢复：范围介于Cache-LowRBA和On-Disk RBA之间

DBA手记:Cache-Low RBA与On-Disk RBA的恢复

作者： eygle | English 【转载时请标明 出处和作者信息】|【 恩墨学院 OCM培训传DBA成功之道】

链接： http://www.eygle.com/archives/2011/02/cache_low_rba.html

站内相关文章|Related Articles

Oracle数据恢复-慎用OEM误操作数据文件删除案例
Oracle数据恢复:ORA-00600 6002错误的解决
kcbz_check_objd_typ_3与参数 _db_block_check_objtyp
Oracle数据恢复:kcbz_check_objd_typ_3 错误处理
Oracle数据恢复:异常中断的操作都很危险

在最近（2010年9月6日）的一次培训中，有位朋友问起上节案例，该如何证明和验证Oracle介于Cache-LowRBA和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 = 0x004040000x00001000

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

 Incmplt recovery scn:0x0000.00000000

 Resetlogs scn: 0x0000.00089c75Resetlogs 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 diskrba:(0x27.f9.0)

on disk scn: 0x0000.001195a5 09/10/201014: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, block108, 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)

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

数据库恢复的检查点起点是SCN1152089，也就是控制文件中记录的数据库最后完成的检查点，On-Disk RBA的SCN是1152421，转换为16进制也就是1195A5，也和控制文件中记录的OnDisk 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的过程。

=============================================================

Cache-low rba 与 on-disk rba - 恢复笔记

1

这几天，帮某银行客户恢复了一个重要的数据库，过程自不必说，稍微记录一下一些技术细节。

我们都知道在恢复过程中，Cache-Low RBA和On-Disk RBA主导了恢复过程，Oracle的恢复从上一次成功的写出开始，也就是以Cache-Low RBA为起点，恢复至日志的最后成功记录，也就是以On-Disk RBA为终点。

这些信息在以下（告警）日志中可以看到明晰的记录：

*** 2010-02-09 10:39:23.422
Start recovery for domain 0, valid = 0, flags = 0x0
Successfully allocated 16 recovery slaves
Using 19 overflow buffers per recovery slave
Instance recovery not required for thread 1
Thread 2 checkpoint: logseq 3694, block 6834, scn 1472458427
  cache-low rba: logseq 3694, block 7612
    on-disk rba: logseq 3694, block 51065, scn 1472496904
  start recovery at logseq 3694, block 7612, scn 0

当前数据库的实例2需要恢复，恢复从日志序号3694开始，块号为7612
接下来（告警）日志中还会记录Redo读取的统计信息，估算IO速度等：

----- Redo read statistics for thread 2 -----
Read rate (ASYNC): 22047Kb in 0.21s => 102.53 Mb/sec
Total physical reads: 22528Kb
Longest record: 12Kb, moves: 0/66327 (0%)
Change moves: 0/15 (0%), moved: 0Mb
Longest LWN: 513Kb, moves: 20/3658 (0%), moved: 2Mb
Last redo scn: 0x0000.57c4854e (1472496974)
----------------------------------------------

这些信息对于我们了解恢复历程具有很大的帮助， 在很多时候，能够运用我们的知识解释某个技术细节的来龙去脉，对于恢复故障具有决定性的意义，就仿佛福尔摩斯破案时的现场回放一下，最近看了这部精彩的电影，祝大家新年快乐，回家喽。

-The End-