【话题讨论】深入解析Oracle IMU模式下的REDO格式

ri6789

chendaodao2008 发表于 2014-1-10 17:59
1&5.IMU
        英文全称-In Memory Undo
        在共享内存中（Shared Pool）独立的内存区域用于存储Undo信息，

莉莉姐好

guoyJoe

chendaodao2008 发表于 2014-1-10 17:59
1&5.IMU
        英文全称-In Memory Undo
        在共享内存中（Shared Pool）独立的内存区域用于存储Undo信息，

美女DBA莉莉,分析的不错。

miniid1

wenzhou320 发表于 2014-1-9 11:16
alter system switch logfile;

update bbb set name='AAAAAAAAA' WHERE ID=1;

回复错了

miniid1

还不算晕 发表于 2014-1-9 12:42
再撕过年没衣服穿了。。

http://blog.csdn.net/haibusuanyun/article/details/18037635   关于SMO ...

这个实验设计值得商洽。
只能证明
1. 事务确实使用的private redo & IMU;
2. 在没提交或者刷新前，确实有进程会合并private redo & IMU写出去pulic log buffer.
但是不能证明是
1.smon所为
2.每3秒刷新， 未提交时，LGWR不是立即从log buffer写的，有延迟。

miniid1

我用gdb/oradebug 把smon进程挂起了，但是大概10分钟后在log file里还是看到了redo record,这证明除了smon外，还有进程在干这件事，当然也可能是这个server process自己干的。

miniid1

另外在做实验时，发现oracle在下面情况下会对当前transaction 放弃使用IMU & private redo：
1. 事务active时间过长(几分钟)
2. 对undo block dump,不管是用oradebug dump还是用alter session set events 'immediate trace name BUFFER level xxx'。其实对oradebug dump能终止IMU 还是挺惊讶的，看来只好用gdb去看了。

对数据块 dump没事，用undo record构造CR block也没事。

还不算晕

miniid1 发表于 2014-1-12 08:50
我用gdb/oradebug 把smon进程挂起了，但是大概10分钟后在log file里还是看到了redo record,这证明除了smon外 ...

我也觉得不严谨，不过暂时没想到其它方法来验证。。只能侧面证明确定有其它进程也会估这操作，可能是SMON, 把SMON,LGWR，DGWR都挂起试下呢？

miniid1

因为事务active时间过长(几分钟) 会终止IMU,所以smon挂起后，可能timeout后，server process 自己把IMU & private redo的东西刷新到log buffer了，但是我看了redo entries & redo size 没变，似乎这坏事又不是它干的。

guoyJoe

miniid1 发表于 2014-1-12 08:42
这个实验设计值得商洽。
只能证明
1. 事务确实使用的private redo & IMU;

从UNDO IMU的拷贝到UNDO块Buffer中，这一步不一定是在提交时由Server process进程完成，也有可能是由SMON进程完成。你用DTRACE跟踪过吗？

miniid1

guoyJoe 发表于 2014-1-12 09:18
从UNDO IMU的拷贝到UNDO块Buffer中，这一步不一定是在提交时由Server process进程完成，也有可能是由SMON ...

在11.2.0.4中，加cbc,不再用sskgslcas了，还没看到vage的更新,所以先等等