深入oracle log buffer发展史

wei-xh

wxhoracle 发表于 2013-7-19 17:24
楼主是怎么研究的啊？

你的名字也是以wxh打头的？

mike79

wei-xh 发表于 2013-7-19 16:12
看来你很关注私有REDO和IMU，毕竟主题比较大，很多细节没涉及，还有就是太细节的实现，也不可能知道
1） ...

3，比如说事务A插入纪录，导致HWM推高，新增了extent。如果是传统模式，在commit前redo record就会写入log buffer，并apply。那么其他事务就会识别到这个extent。但是用了private redo strand之后，通常只在commit时才写入log buffer。在事务A提交前，其他事务也要插入纪录该怎么办？

wei-xh

mike79 发表于 2013-7-19 19:20
3，比如说事务A插入纪录，导致HWM推高，新增了extent。如果是传统模式，在commit前redo record就会写入lo ...

HWM增高，其他会话立即就能看到的，这个动作是递归产生的，如果把他看成一个事务，这个事务是已经commit了的。跟本会话提交不提交没关系的

mike79

wei-xh 发表于 2013-7-19 19:32
HWM增高，其他会话立即就能看到的，这个动作是递归产生的，如果把他看成一个事务，这个事务是已经commit了 ...

对于ASSM segment，HWM增高或者insert时格式化unformatted block，也是通过递归事务完成的？

wei-xh

mike79 发表于 2013-7-19 20:02
对于ASSM segment，HWM增高或者insert时格式化unformatted block，也是通过递归事务完成的？

是的，增高HWM是不可逆的，即使你的会话回退，这个操作也不能回退了。

last_day_1983

把Redo allocation latch的申请机制用图说明出来，真的很形象。
多谢LZ分享，呵呵。

mike79

wei-xh 发表于 2013-7-19 20:05
是的，增高HWM是不可逆的，即使你的会话回退，这个操作也不能回退了。

IMU对修改block的影响

无论是传统上，还是采用了IMU，对block的修改都应该满足两个要求
1，先将record record拷贝到log buffer，然后再修改block
2，在修改block前后要获取和释放buffer pin

传统上对block的修改是one change = one record，因此redo record很快就apply到block上。也就是这个顺序：
加pin
拷贝redo record到log buffer
修改block
释放pin

采用了IMU后，所有change vector都打包成一个redo record，在事务提交时批量写入log buffer。那对block的修改会是怎样的？
想法1：
事务A提交，将redo record都写入log buffer，包括redo record
获取buffer1的pin，修改buffer1，释放pin
获取buffer2的pin，修改buffer2，释放pin
......
获取bufferN的pin，修改bufferN，释放pin

如果在修改buffer1的时候，某个会话读取bufferN，就读取到了事务A开始之前的纪录。这不符要求。

想法2
获取buffer1的pin，buffer2的pin......
事务A提交，将redo record都写入log buffer，包括redo record
修改buffer1,buffer2.....
释放pin1,pin2......
这个会导致对各个buffer pin的持有时间比传统更长，加剧buffer busy wait冲突

除了这两个想法外，还有什么其它想法么？

wei-xh

mike79 发表于 2013-7-19 21:28
IMU对修改block的影响

无论是传统上，还是采用了IMU，对block的修改都应该满足两个要求

"如果在修改buffer1的时候，某个会话读取bufferN，就读取到了事务A开始之前的纪录。这不符要求。"

你仔细想一下，读取的会话发现一个块上有私有redo，那就说明，这个事务还没提交，一个事物没提交，就不应该读取到他的内容，因此它甚至不需要去apply这些私有redo，直接以当前版本的数据块作为构造CR的起点，然后比对SCN，决定需要不需要继续构造CR。

因此你说的“读取到了事物A之前的记录，不符合要求“是不对的。  就是要读取到事物之前的样子，因为这个事物没提交，至少以当前版本的块为起点构造CR

mike79

wei-xh 发表于 2013-7-19 21:39
"如果在修改buffer1的时候，某个会话读取bufferN，就读取到了事务A开始之前的纪录。这不符要求。"

你 ...

假象这个流程：
block N上没有任何活动事务，有条纪录的值为1。

事务A开始了，采用IMU，它要更新若干block，包括将block N上的1改为2。
事务A提交了，将redo record写入log buffer，然后在buffer cache中逐个修改block。
在事务A提交后，修改block N之前，事务B开始了。它读取block N的话，会读到什么值？
1，因为事务B在事务A提交后才开始运行，因此它读取block N的话应该读到2
2，因为事务A还没有来得及修改block N，因此事务B直接读取block N的话只能读到1

如果是基于那个“标记每一个修改的块有private redo”（我很怀疑是否有这个东西），那么事务B应该会等待，相应等待事件是什么？

再说回这个所谓标记，我觉得它应该具备以下特性。这些特性很奇怪。
首先这个标记是工作在block层面，而不是row层面。结合上面这个案例来考虑，事务B只知道这个block上有private redo标记，但是不知道哪些row被事务A修改过。万一它要读取的纪录不是A修改过的呢？岂不是白等了？
其次这个标记应该是个计数器。缺省是0，说明没有private redo。有1个采用IMU的会话要修改这个block，计数器就递增。修改好了（或者事务提交了）就递减。因为每个block最多支持255个活动事务，那这个计数器应该也有1个字节。这个字节最可能的是在bh中。可你否认了这点。那么这个字节在哪里呢？

对于IMU，我觉得看似一个小改进，但实际上涉及很多Oracle基础的东西。
Core_ Essential里说Oracle的内核很紧凑，但是各个组件结合的也很紧密。修改一个地方，就会扩散到很多组件。牵一发而动全身。

guoyJoe

好文！