崩溃恢复的起点和终点(五)
cast_to_number('c121') from dual;
UTL_RAW.CAST_TO_NUMBER('C121')
------------------------------
32
注意到这里差异就产生了。我们刚才用BBED查看了表T在磁盘上的最后一条记录，其id值是28。但这里对current redo log file的dump清晰的告诉我们，上述表T的最后一条被成功插入的记录的id值是32也就是说，id为29、30和31，32的那四条记录还在buffer cache里，还没有被写回到数据文件。
另外我们刚才已经从对控制文件的dump内容看到On Disk RBA的值是0x25.48.0，而上述插入id值为32的这条redo record的RBA是0x000025.00000049.0010，即现在的On Disk RBA小于id值为32的这条redo record所在的RBA。如果
Oracle在做Instance Recovery的时候只恢复到On Disk RBA，那么就意味着id为32的这条记录就真的丢掉了，这显然是很扯淡的事情，不可能这样的。
上面的内容我们可以看到，现在current redo log file尾端的最后一条redo record对应的RBA是0x000025.00000049.0010，翻译过来就是current redo log file尾端的最后一条redo record对应的logfile sequence是37，logfile block number是73：
SESSION A>select to_number('25','XXXXXXXX') from dual;
TO_NUMBER('25','XXXXXXXX')
--------------------------
37
SESSION A>
SESSION A>select to_number('49','XXXXXXXX') from dual;
TO_NUMBER('49','XXXXXXXX')
--------------------------
73
好了，我们现在回到上述command窗口来把上述
数据库open。在open完毕后我们马上紧跟着执行对当前控制文件的dump操作：
SESSION A > alter database open;
SESSION A>alter session set events 'immediate trace name controlf level 3';
会话已更改。
Using 45 overflow buffers per recovery slave
Thread 1 checkpoint: logseq 37, block 66, scn 1678310
cache-low rba: logseq 37, block 66
on-disk rba: logseq 37, block 73, scn 1678316
start recovery at logseq 37, block 66, scn 1678310
SESSION A>select * from t;
ID
----------
1
2
3
4
5
6
7
8
9
10
11
ID
----------
12
13
14
15
16
17
18
19
20
21
22
ID
----------
23
24
25
26
27
28
29
30
31
32
已选择32行。
OK验证完毕