[Oracle] Redo&Undo梳理

Oracle Redo&undo

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会成为系统的瓶颈



老机制, redo allocation latch: 保护redo log buffer, 控制对共享区内存的访问.

session -> 请求redo allocation latch -> 为写入到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改变向量;



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)



undo

读一致性

块的ITL entries里必须包含一个指向undo记录的指针(指针是有限的)

回滚