eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Linux many lost ticks 和 NIC Copper Link Down | Blog首页 | 祝大家虎年大吉 新年快乐 »

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

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

我们都知道在恢复过程中,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-


历史上的今天...
    >> 2011-02-12文章:
    >> 2009-02-12文章:
    >> 2007-02-12文章:
           Oracle10g 控制文件的改变
    >> 2005-02-12文章:

无觅

By eygle on 2010-02-12 16:27 | Comments (1) | Backup&Recovery | Internal | 2506 |

1 Comment

新年快乐!


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com