今天忽然有个疑问,如果我们执行alter system dump datafile # block #的话Oracle是否会先把block读入到buffer cache中呢?先打电话问了一下泡在广州温柔乡里面的eygle,他说应该不会,可以直接读取数据文件的。
为了确认,我还是自己测试了一下,结果证明eygle的记忆还是对的。
简略说一下测试步骤,超级简单。
1。重启一下数据库,这样buffer cache中几乎就没什么用户数据了,方便测试
2。随便找一张表看看是在哪个file哪个block里面
2 from dba_segments
3 where segment_name=’T1′;
HEADER_FILE HEADER_BLOCK
———– ————
4 19
3。T1表在数据文件4中,第一个block是19,检查v$bh,看看这个block有没有在buffer cache中
2 from v$bh
3 where file# = 4 and block# = 19;
COUNT(*)
———-
0
4。OK,目前buffer cache中没有这个block,作一次dump再看看有没有
System altered
SQL> select count(*)
2 from v$bh
3 where file# = 4 and block# = 19;
COUNT(*)
———-
0
5。至此验证了作block dump不会把数据块先读入buffer cache,好,继续作一次select看看,这次一定是读进buffer cache了
N
———-
SQL> select count(*)
2 from vbh
3 where file# = 4 and block# = 19;
COUNT(*)
———-
1
小知识
1. v$bh视图保存着buffer cache中每一个block的信息。
2. dba_segments视图中一个ASSM类型segment的header_block是从它的PAGETABLE SEGMENT HEADER算起的,并不包括前面用于控制free block的两个位图块(FIRST LEVEL BITMAP BLOCK和SECOND LEVEL BITMAP BLOCK)。
dump block会否让刚插入的块写入数据文件呢?
我们刚插入一条记录时, 这个块肯定不会马上写入数据文件的, 不过我们还是可以dump出准确的东西的. 那这时写入数据文件了吗?
对,所以我理解是,如果block不存在于内存中就直接从disk读,否则就直接从内存读,但是是不是同时会写disk我也有疑问。可惜我找不到一个好的方法来验证是否会写disk。
问题转化为怎样检查当前buffer cache中的block和disk中的block是一样的,并且还要确保这个写入是dump block引起的而不是其它原因。
在alter system dump后, 将文件热备出来, 再dump备份出来的文件的那个block就可以验证了, 或用os的方法看那个block也行, 🙂
用os的方法我不会。。。
热备的话,你如何确认如果buffer cache的block和数据文件中的一样是因为dump block引起的?我的意思是说比如3秒唤醒一次的DBWn检查到了dirty list的阀值,同样也会将脏数据写入数据文件。
已经验证完毕。
https://www.dbform.com/html/2006/108.html
不错,呵呵,很有启发 :)