数据库中的undo日志、redo日志
MySQL中有六种日志文件，
分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。
其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。
undo是将用户上一步做的操作对程序造成的改动恢复到改动之前，而redo操作是指重新实现这种改动。
undo/redo操作的实现方式分为两类：记录数据和记录操作。
记录数据是指将信息编辑窗口打开时，保存原始数据，然后记录用户每次操作后的结果数据，这里的数据是指信息编辑窗口中所有可能发生变动的数据。做undo操作时程序将用户上一步操作前的数据传给信息编辑窗口相应控件。这种做法是以空间来换时间，程序不必考虑用户到底改变了哪些数据，反正每次都是替换的所有可能改变的数据。当每次保存的数据量比较小时，这种做法比较方便快捷，但是如果数据量大，比如包括图形、视频信息等，这种方法就比较耗费内存了。
记录操作是指信息编辑窗口打开后，记录用户每次的操作，包括具体的操作动作以及操作改变的数据，这里的数据是指既能还原操作的数据又能重复操作的数据。做undo操作时程序根据记录的用户操作进行反向处理，对信息编辑窗口进行改动，而做redo操作的时候程序根据记录的用户操作来重复用户的操作。这种做法是以时间换来空间，程序记录的信息变少了，每次只需要记录用户的操作类型以及相关的操作数据（比如用户编辑的哪个控件，编辑前后的控件内容分别是什么），与操作无关的其他数据则不需要记录。这种做法比起记录数据的方式肯定要复杂，但是胜于节俭内存。
Oracle中的redo和undo是关键技术的核心, 诸如实例恢复, 介质恢复, DataGuard, 闪回机制等都是给予redo和undo的, 所以很有必要详细梳理这块的知识, 总结记录.
-
数据变化日志
当我们改变一个数据块时, 都记录了哪些日志, 具体是怎么样的流程呢?
当在Oracle中改变一条数据时, 不仅仅要在数据文件里(可能在buffer里直接找到)找到并修改数据, 更重要的是需要做完善的日志记录, 具体如下:- 创建一个重做改变向量, 描述如何往undo块插入一条undo记录(即undo的redo日志)
- 创建一个重做改变向量, 描述数据块的变化(即data的redo日志)
- 合并这两个重做改变向量为一条日志记录, 并写到重做日志缓冲区
- 向undo块插入undo记录
- 改变数据块中的数据
图1: 更新操作经历的事件时序图
-
Redo
redo处理方式:
session -> redo日志 -> 写入redo log buffer -> 写到redo日志文件(循环利用) -> 归档到日志中
写redo log buffer会成为系统的瓶颈
session每次数据更改都会插入一条redo记录到buffer中, 一个session可能很短时间内做了很多更改, 同时可能有很多session并发操作, 却只有一个redo log buffer.
-
老机制, redo allocation latch: 保护redo log buffer, 控制对共享区内存的访问.
session -> 请求redo allocation latch -> 为写入到buffer的信息预留一些空间
避免了多个进程同时写入buffer相同部分的风险.
大并发系统会出现latch竞争, cpu空转 -
新机制, private redo和IMU(In-Memory undo)
在session的整个事务期间内, 生成所有改变向量, 写入private redo log buffer(PGA中), 当事务提交时, session会将private redo buffer中的记录copy到公共redo log buffer中.
一个session在一次事务里只需要获取一次公共的redo allocation latch.
e.g
脚步更新表记录, 观察期间latch统计信息.
-
9i的输出:
Latch Gets Im_Gets redo copy 0 51 redo allocation 53 0 Name Value redo entries 51 redo size 12,668 -
10g的输出:
Latch Gets Im_Gets redo copy 0 1 redo allocation 5 1 In memory undo latch 53 1 Name Value redo entries 1 redo size 12,048
10g里, redo copy latch只命中了一次; redo allocation latch也get很少; 只生成了一个redo entry;
测试中发现, 貌似竞争问题转移了?
-
- 待跟进:
- 分析v$latch_children, 搞清楚为什么latch活动的变化不是新的威胁(瓶颈);
- 分析重做日志, 搞清楚那个大的日志条目(redo entry)都记录了什么;
- 分析动态性能表(x$kcrfstrand和x$ktifp), 理解各种实例活动信息是如何串联到一起的;
- redo的2组内存结构:
- x$kcrfstrand, 私有redo区: 处理"前滚"改变向量(私有redo区里也包含传统的"公共"redo log buffer);
- x$ktifp, IMU区: 处理undo改变向量;
IMU区中有N多IMU池, N取决于数据库参数transactions/10, 每个池都有自己的latch.
x$ktifp中的每条记录(即IMU)在x$kcrfstrand中都有对应的一条private redo记录.
x$kcrfstrand中的每条private redo记录都由其自身的redo allocation latch保护, 每条"公共"的重做记录都由传统的redo copy latch保护.
-
In-Memory undo latch(IMU latch):
任何一个改变都会产生一次对IMU latch的访问, 用一个latch(IMU latch)代替两个(redo allocation latch与redo copy latch), 至少latch竞争是减半了.
IMU latch有许多子latch, 每个子latch负责一个IMU内存区域(池).
-
新机制的redo allocation latch:
2种latch:- 一类保护私有redo线程(private redo thread)
- 另一类保护公共redo线程(public redo thread)
每个线程都有自己的latch
-
- undo
-
读一致性
块的ITL entries里必须包含一个指向undo记录的指针(指针是有限的)
-
回滚
-
