前语
不论现阶段美国和我国对峙到何种程度,不论桀傲不驯拉里.埃里森怎样不看好我国,Oracle 仍是数据库中的鹤立鸡群。然而,他山之石能够攻玉,多个国产数据库在要害技术攻关方面的全体水平也已达到国际先进。
国内越来越多的 Oracle 数据库开端下线,迁移到开源或者国产数据上,o2k 支撑实时增量的将 Oracle 数据库增量改变抽取出来,助力国产化数据库无缝接收 Oracle。
笔者作为数据库内核的负责人参与完成了 o2k 来解析 Oracle 日志,并于 2022 年 2 月 15 号把它敞开出来给社区免费运用,期间阅历了各种迷茫,获得了众多大佬的辅导,最终总算是交出了一份还算不错的试卷。
作为一个 DBA 兼开发人员,在整个 o2k 的完成过程中,关于 Oracle 数据库的数据库理论和工程才能学习了许多,也进一步对数据库原理有了进一步了解。
凭借 Oracle 的规划理念和完成,咱们也看看是否能对新一代的数据库从业者有必定的帮助和借鉴作用。
国内软件因为美国的打压,数据库作为基础软件赢来了一个难得的繁荣发展期。
曾几何时,数据库从业人员仅仅公司 IT 团队->运维团队里的一个小小部分,而今一个能辅导开发正确运用数据库,选择数据库来适配业务来适应业务的数据架构师求过于供。
假如能掌握着数据库原理,乃至能自动改造数据库适配相关使用场景的人才年薪至少百万。
作为计算机皇冠上的其间一粒明珠,数据库上承业务在线离线之责,下接硬件内核之妙,看到越来越多的人才参加数据库及数据库内核部队,不胜欣慰!
本系列文章中咱们将由浅入深以 Oracle 日志解析遇到的重重阻塞为例,来介绍在数据库中常见,而又要害的概念,了解数据库规划思路及工程完成中需求留意的事项。
本文以浅为主,咱们先简略介绍一下数据库的背景和 Oracle 日志解析的基础常识
前置常识了解
数据库日志
-
类似于银行账户系统相同,张三存入 100 块钱会’先’被记载为’张三添加 100’的流水账,然后再把张三的账户从 1000 块修正为 1100 块。
-
数据库为了确保原子性和耐久化,也会’先’在 redo 日志中记载一笔或者多笔 redo record,然后再修正数据库实际的行记载
-
留意,这儿的“修正账户/修正行记载”都是在“写流水账/写日志”之后完成的。也便是说 redo 先于“数据写入”,这也便是闻名的数据库 write-ahead logging (WAL) 。
-
Oracle 写数据库日志选用的是物理日志方法,记载的是内部数据块的改变;MySQL 在 Server 层的 binlog 是逻辑日志,记载的是逻辑行数据的改变。所以对 Oracle 的日志解析不仅需求了解日志自身 filespace、redo record,change vector 的改变,还需求了解 Oracle 内部数据存储的格局。
怎样检查 Oracle 日志中记载的内容
Oracle 中有专门的命令,支撑将指定的二进制 redo 日志解析为逻辑的文本文件,类似于 MySQL 供给的 mysqlbinlog 东西,便利用户检查和确诊数据库问题。
ALTER SYSTEM DUMP LOGFILE ‘/opt/oracle/oradata/master1/redo01.log’;
当然,这个解析出来的文本文件也并不是那么简单了解,下文中咱们会对要害信息进行解读。 别的,这个逻辑的文本文件也并不是把一切的二进制 redo 日志中的信息都解析并输出出来,例如 supplement log 这种,就没有输出
supplemental log
Oracle 默许只记载改变的信息,类似于 MySQL 中 binlog_row_image=minimal 的情况。
也便是说,你履行了 update t1 set c2=3 where id=2,它只会记载 c2=3 的后镜像数据和 c2=2 修正之前的前镜像数据。
关于主备物理块同步,这些信息现已足够了,可是关于数据仓库或者大数据平台,不知道究竟更新的是哪一行(id=2)的数据,是无法坚持跟 Oracle 的数据共同的。
通过 alter database add supplemental log data (primary key) columns;能够让 Oracle 在记载日志的时分顺便把 primary key 主键也记载下来,便利同步东西将改变对应到具体哪一行,这些额定添加的日志称为 supplemental log。
OGG,O2K 等同步东西都会要求源端 Oracle 敞开 supplemental log。
日志组织方式
-
WAL 日志是逻辑的日志表现方式,一个 update 的业务更新了 5 行数据,会产生多个 redo record(begin,5 行记载的前镜像和后镜像,commit),而这些日志记载到日志文件中是以一个 block 一个 block(默许为 512 字节)写到文件中的
-
逻辑上,数据库日志是由一个一个的 redo record 组成的;
-
物理上,数据库日志文件中每个 block 都有 Header 和 Tail,逻辑的 redo record 记载到物理文件中对应联系如下:
redo 和 undo
日志记载内容
说了这么多理论的、务虚的东西,咱们来点干货。
首要,咱们看看咱们做一个 update 一行数据究竟会生成哪些日志信息,为了扫除其他的搅扰,咱们在做 update 之前和之后都 switch logfile,确保咱们查询的 redo log 中只要 update 一个改变
在 Oracle 上履行的语句如下
## 这儿新建一个表用于测试
create table test1 (id number primary key, name varchar2(15) not null, hiredate date default(sysdate) );
insert into test1 (id, name) values (1, 'o2k1');
insert into test1 (id, name, hiredate) values (2, 'o2k2', sysdate);
commit
## 为了扫除其他的搅扰,咱们在做update之前和之后都switch logfile,确保咱们查询的redo log中只要update一个改变
ALTER SYSTEM SWITCH LOGFILE;
update test1 set name='o2k3' where id=2;
commit;
ALTER SYSTEM SWITCH LOGFILE;
## 查询究竟应该从那个归档日志中获取update的改变
select * from v$archived_log;
## 将二进制日志反解析出来
ALTER SYSTEM DUMP LOGFILE '+SSDDG1/chenmm/archivelog/2022_05_12/thread_2_seq_114.1017.1104513037';
## 检查日志被导入到哪个trace文件了
select value from v$diag_info where name='Default Trace File'; # 返回ora_6130.trc
这儿咱们得到两个文件:
- 二进制的 redo 日志文件”thread_2_seq_114.1017.1104513037″
- 依据这个二进制日志解析出来的文本文件 ora_6130.trc
相关的内容我都放到了文末的附录中了,咱们能够自行检查。
redo 逻辑结构
咱们先从文本文件 ora_6130.trc 下手检查一下 redo 文件的逻辑方式。参阅redo 逻辑格局(见附录),能够看到
- FILE HEADER:日志文件有日志文件的头,记载了 Db Id,Db Name 的数据库信息,也记载了文件巨细、文件类型以及 Blksiz=512(也便是说,redo 物理块巨细为 512 字节),比照redo 物理格局(见附录)FILE HEADER 是放到榜首个 512 字节的 BLOCK 中。这儿的文件号对应的便是日志序号 Seq#
FILE HEADER:
File Number=3, Blksiz=512, File Type=2 LOG
- REDO HEADER:别的这儿还记载了这是 RAC 的哪个节点,是那个序号的 redo 日志,scn 的规模,”Thread 0002, Seq# 0000000114, SCN 0x0000004f1aa1-0x0000004f1aa8″。比照redo 物理格局REDO HEADER 是放到第二个 512 字节的 BLOCK 中
descrip:"Thread 0002, Seq# 0000000114, SCN 0x0000004f1aa1-0x0000004f1aa8"
thread: 2 nab: 0x4 seq: 0x00000072 hws: 0x2 eot: 0 dis: 0
- REDO Record:redo record 是 redo 逻辑日志的最重要的组成部分,数据库的更新都会记载到一个一个的 Redo Record 中,咱们履行的 update 和 commit 就被记载成了两个 Redo Record。一个长度为 0x0244,一个长度 0x00a4
REDO RECORD - Thread:2 RBA: 0x000072.00000002.0010 LEN: 0x0244 VLD: 0x05
...
REDO RECORD - Thread:2 RBA: 0x000072.00000003.0064 LEN: 0x00a4 VLD: 0x01
redo record
进一步分化 redo record,能够看到 redo record 又是由一个 redo header 和多个 change vector(‘CHANGE #?’)组成
- Redo Header:记载了 Redo 的长度 LEN: 0x0244,redo record 的地址 RBA: 0x000072.00000002.0010,SCN:0x0000.004f1aa1 等信息
REDO RECORD - Thread:2 RBA: 0x000072.00000002.0010 LEN: 0x0244 VLD: 0x05
SCN: 0x0000.004f1aa1 SUBSCN: 1 05/12/2022 17:10:35
(LWN RBA: 0x000072.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.004f1aa1)
- Change Vector:它是数据改变的原子结构,调查榜首个 Redo Record,咱们能够看到 CHANGE #1 记载了业务开端;CHANGE #2 记载了 update 的 undo 前镜像;CHANGE #3 记载了 update 的 redo 后镜像;CHANGE #4 记载了 session 信息;而第二个 Redo Record 的 CHANGE #1 记载了业务提交的信息
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0000.004f1121 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0013 sqn: 0x00000648 flg: 0x0012 siz: 200 fbi: 0
uba: 0x00c00e4c.0209.23 pxid: 0x0000.000.00000000
change vector
在进一步分化 change vector,它也是有 Change Vector 的 header 和可变数据组成,在 Lewis《oracle core》中被称为“仅有最重要的特性”。header 和可变数据的具体信息咱们在以后的文章中再具体介绍。
这儿仅介绍几个最要害的信息:
- opcode:OP:5.2 记载的是业务开端,OP:5.4 记载的是业务完毕,OP:5.1 记载的是前镜像,OP:11.5 记载的是 update 的后镜像,有爱好的同学能够参阅lewis记载的opcode具体列表。
- xid:业务号,Oracle 业务管理开端于 undo 段,并依此为中心。这也是你看到为什么业务开端 5.2、业务完毕 5.4 和 undo 记载 5.1 都是对 Layer 5 : Transaction Undo 的操作的原因。xid 记载的信息从某种程度上来说记载的便是在 undo 上占有了哪个 slot。阿里巴巴的 GalaxyEngine 运用的 lizard 业务优化跟 Oracle 的业务殊途同归
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0000.004f1121 SEQ:1 OP:5.2 ENC:0 RBL:0
CHANGE #2 TYP:0 CLS:18 AFN:3 DBA:0x00c00e4c OBJ:4294967295 SCN:0x0000.004f1120 SEQ:1 OP:5.1 ENC:0 RBL:0
xid: 0x0001.013.00000648
CHANGE #3 TYP:2 CLS:1 AFN:4 DBA:0x010000ad OBJ:98733 SCN:0x0000.004f1a8c SEQ:1 OP:11.5 ENC:0 RBL:0
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0000.004f1aa1 SEQ:1 OP:5.4 ENC:0 RBL:0
undo 和 redo
这儿要专门说一下 undo 和 redo,因为 MVCC 多版别的规划:
- 对一切数据的修正,都需求记载这个数据修正前的值,即在 undo 里面记载前镜像。关于咱们的 update 便是要记载 name=’o2k2′
- 同时,对一切数据的修正又有必要先以 Redo 的方法记载到 WAL 日志中,也出现了在 redo 中记载 undo 信息的情况,即榜首个 Redo Record 的 CHANGE #2 记载了 update 的 undo 前镜像。
- 假如在数据库做康复前滚的时分,undo 跟表数据相同也需求康复
也便是说,张三存了 100 块钱,流水账里面记载的不是”张三 +100″,而是“ 前镜像:张三 1000;后镜像:张三 1100”,修正一行数据,或许仅仅几个字节的改变,可是数据库为了确保数据康复、读共同性多写了这么多日志,多做了这么多工作。而假如你深化做数据库内核,你会发现这个是一个天才的规划。因为文章篇幅问题,这儿不细讲。
表和行
进一步细看的话,你能够看到前镜像和后镜像里面具体改的数据,例如,前镜像数据如下:
ncol: 3 nnew: 1 size: 0
col 1: [ 4] 6f 32 6b 32
这儿表明这个表有 3 列,修正了一个列,巨细改变为 0,修正的是 col1,对应的四个字节为 6f 32 6b 32,也便是 o2k2 6f 32 6b 32 是 Oracle 的数据存储格局,跟 redo 的存储结构联系不大。
小结
从上面的逻辑日志能够看出来,Oracle 想要对表更新:
- 首要要在程序中构建一个 Redo Record
- 然后构建几个 Change Vector,包含业务开端、修正数据的前镜像、修正业务的后镜像等等
- 将 Redo Record 和 Change Vector 序列化到 Redo Buffer (Oracle 有专门的 LGWR 来改写 Redo Buffer 到日志文件中)
- 最后才是将 Change Vector 使用到数据块上去,这儿来说,使用的是表还是 undo,并没有太大差异
redo 物理结构
上面主要介绍的是 redo 的逻辑结构,是 Oracle 帮咱们解析出来的,一般的疑难问题排查到这一步应该够了,可是假如你要做日志解析或者想要进一步深化排查,你或许会关注究竟他在二进制层面是怎样落地的。
这个章节仅面向 1%的读者,假如你对这块不感爱好,能够直接跳过这个章节:)
参阅附录redo 物理格局,这儿是将 redo 文件拷贝出来以后用 Hexdump 以十六进制格局输出的 Oracle redo 日志
redo file & block header
首要看榜首个 block,是 file header 的 block 榜首行,是 block header,每个 block 的开头 16 个字节记载的都是这个 block 的 header。
比照下面的一般 block,能够看到 0x0022 是 logfile header, 0x0122 是 logfile block 第二行开端是 redo 文件头 file header,这儿记载了几个比较要害的信息:“00 02 00 00”表明 0x00 00 02 00 = 512 即这个 redo log 一个 block 究竟有多大(在 oracle 11.2 以后 BLOCKSIZE 能够设置为 512,1024 或者 4096), “03 00 00 00”表明 0x00 00 00 03 = 3 表明一共有 3 个 block。
00000000 00 22 00 00 00 00 c0 ff 00 00 00 00 00 00 00 00 |."....��........|
00000010 65 58 00 00 00 02 00 00 03 00 00 00 7d 7c 7b 7a |eX..........}|{z|
留意:因为咱们的 Oracle 是安装在 little endian 小端 x86 的 linux 服务器上的,所以“00 02 00 00”表明 0x00 00 02 00 = 512 需求倒过来一下,假如你的 Oracle 跑在 Big Endian 大端的 IBM AIX 上的时分,“00 02 00 00”表明 0x00 02 00 00 = 131072 就不必倒过来了
redo record & redo block
已然知道了一个 block 的巨细为 0x00000200,那榜首个真实的 redo block 的开端方位开端的 block 便是 00000000+00000200=00000200,第二个便是 00000400,第三个便是 00000600
00000200 01 22 00 00 01 00 00 00 72 00 00 00 00 80 25 cd |."......r.....%�|
00000400 01 22 00 00 02 00 00 00 72 00 00 00 10 80 66 66 |."......r.....ff|
00000600 01 22 00 00 03 00 00 00 72 00 00 00 64 80 1b 9a |."......r...d...|
这儿“01 00 00 00”, “02 00 00 00” 和“03 00 00 00”便是 block 序号,表明这是第几个块;”72 00 00 00″=0x00000072=114 是日志序号,对应的便是 redo 日志空间中的 Seq#号;而”00 80″, “10 80”, “64 80″对应的是该 block 中榜首个 redo record 相对 block 开端地址的偏移量。
00000400 开端的 redo block 的 redo record 是从“10 80”=0x8010-0x8000=0x10=16 即从 00000410″44 02 00 00…”开端便是 redo record 的字节信息了。
00000400 01 22 00 00 02 00 00 00 72 00 00 00 10 80 66 66 |."......r.....ff|
00000410 44 02 00 00 05 6e 00 00 a1 1a 4f 00 01 00 00 23 |D....n..�.O....#|
00000600 开端的 redo block 的 redo record 是从“64 80”=0x8064-0x8000=0x64=100 即从 00000664″a4 00 00 00…”开端便是 redo record 的字节信息了。
00000600 01 22 00 00 03 00 00 00 72 00 00 00 64 80 1b 9a |."......r...d...|
00000610 01 00 03 01 00 00 00 00 00 1a 4f 00 01 00 70 72 |..........O...pr|
00000620 6f 32 6b 33 05 14 00 00 00 00 00 00 00 00 00 00 |o2k3............|
00000630 00 00 00 00 00 00 00 00 00 06 00 00 12 00 04 00 |................|
00000640 00 00 02 00 04 00 04 00 00 00 00 00 03 00 4f f0 |..............O�|
00000650 2a 00 37 00 00 00 00 00 00 04 20 0b ff ff ff ff |*.7....... .����|
00000660 53 59 53 00 a4 00 00 00 01 06 00 00 a2 1a 4f 00 |SYS.�.......�.O.|
咱们能够明显看到一个 redo record 是能够跨两个 block 的。也便是前面咱们介绍的逻辑的 redo record 是或许包含在一个物理 redo block 中的,也有或许跨多个物理 redo block。
log redo header
榜首个 redo block 比较特别,”00 80″的开端 redo record 为 0。开端这个 redo block 中并没有 redo record。而是包含了这个 redo file 的所属实例信息,起止 SCN 等信息,乃至部分信息是以纯文原本记载的“Thread 0002, Seq# 0000000114, SCN 0x0000004f1aa1-0x0000004f1aa8”
总结
综上所述,本文简略的介绍了 Oracle redo 的物理和逻辑格局。
一条 update 语句实际履行时,在 Oracle 上阅历的写 undo、记载 WAL,修正数据块的过程;介绍了 Oracle 在二进制 redo 日志中把逻辑的 redo record 对应记载到 redo block 中的。
文末一张图,扼要总结一下他们的联系:
|附录
redo 逻辑格局 = redo 的 trace 文件
DUMP OF REDO FROM FILE '+SSDDG1/chenmm/archivelog/2022_05_12/thread_2_seq_114.1017.1104513037'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=2935349816=0xaef5e238, Db Name='CHENMM'
Activation ID=2935307061=0xaef53b35
Control Seq=18659=0x48e3, File size=102400=0x19000
File Number=3, Blksiz=512, File Type=2 LOG
descrip:"Thread 0002, Seq# 0000000114, SCN 0x0000004f1aa1-0x0000004f1aa8"
thread: 2 nab: 0x4 seq: 0x00000072 hws: 0x2 eot: 0 dis: 0
resetlogs count: 0x41a5ccfa scn: 0x0000.000e2006 (925702)
prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1)
Low scn: 0x0000.004f1aa1 (5184161) 05/12/2022 17:10:35
Next scn: 0x0000.004f1aa8 (5184168) 05/12/2022 17:10:36
Enabled scn: 0x0000.001f0753 (2033491) 04/07/2022 12:21:09
Thread closed scn: 0x0000.004f1aa1 (5184161) 05/12/2022 17:10:35
Disk cksum: 0xcd25 Calc cksum: 0xcd25
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 2 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x800011
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 8
Format ID is 2
redo log key is 5732c0d413f33575933d9e64c4ff5c6
redo log key flag is 5
Enabled redo threads: 1 2
REDO RECORD - Thread:2 RBA: 0x000072.00000002.0010 LEN: 0x0244 VLD: 0x05
SCN: 0x0000.004f1aa1 SUBSCN: 1 05/12/2022 17:10:35
(LWN RBA: 0x000072.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.004f1aa1)
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0000.004f1121 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0013 sqn: 0x00000648 flg: 0x0012 siz: 200 fbi: 0
uba: 0x00c00e4c.0209.23 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:18 AFN:3 DBA:0x00c00e4c OBJ:4294967295 SCN:0x0000.004f1120 SEQ:1 OP:5.1 ENC:0 RBL:0
ktudb redo: siz: 200 spc: 2574 flg: 0x0012 seq: 0x0209 rec: 0x23
xid: 0x0001.013.00000648
ktubl redo: slt: 19 rci: 0 opc: 11.1 [objn: 98733 objd: 98733 tsn: 4]
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c00e4c.0209.20
prev ctl max cmt scn: 0x0000.004ebaab prev tx cmt scn: 0x0000.004ebaea
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12586531 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L itl: xid: 0x000a.013.00006307 uba: 0x00c0025b.072e.0b
flg: C--- lkc: 0 scn: 0x0000.004f1a39
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x010000ad hdba: 0x010000aa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 0 ckix: 0
ncol: 3 nnew: 1 size: 0
col 1: [ 4] 6f 32 6b 32
CHANGE #3 TYP:2 CLS:1 AFN:4 DBA:0x010000ad OBJ:98733 SCN:0x0000.004f1a8c SEQ:1 OP:11.5 ENC:0 RBL:0
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0001.013.00000648 uba: 0x00c00e4c.0209.23
Block cleanout record, scn: 0x0000.004f1aa1 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.004f1a8c
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x010000ad hdba: 0x010000aa
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 2 ckix: 0
ncol: 3 nnew: 1 size: 0
col 1: [ 4] 6f 32 6b 33
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:5.20 ENC:0
session number = 42
serial number = 55
transaction name =
version 186647552
audit sessionid 4294967295
Client Id =
login username = SYS
REDO RECORD - Thread:2 RBA: 0x000072.00000003.0064 LEN: 0x00a4 VLD: 0x01
SCN: 0x0000.004f1aa2 SUBSCN: 1 05/12/2022 17:10:35
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0000.004f1aa1 SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0013 sqn: 0x00000648 srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00c00e4c.0209.23 ext: 2 spc: 2372 fbi: 0
CHANGE #2 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:24.4 ENC:0
END OF REDO DUMP
redo 物理格局 = hexdump -C redo 文件
(base) pickupli@pickupli1 ~ % hexdump -C ~/Downloads/114.redo
00000000 00 22 00 00 00 00 c0 ff 00 00 00 00 00 00 00 00 |."....��........|
00000010 65 58 00 00 00 02 00 00 03 00 00 00 7d 7c 7b 7a |eX..........}|{z|
00000020 a0 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |�...............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 01 22 00 00 01 00 00 00 72 00 00 00 00 80 25 cd |."......r.....%�|
00000210 00 00 00 00 00 04 20 0b 38 e2 f5 ae 43 48 45 4e |...... .8��CHEN|
00000220 4d 4d 00 00 e3 48 00 00 00 90 01 00 00 02 00 00 |MM..�H..........|
00000230 03 00 02 00 35 3b f5 ae 00 00 00 00 00 00 00 00 |....5;�........|
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 54 68 72 65 |............Thre|
00000260 61 64 20 30 30 30 32 2c 20 53 65 71 23 20 30 30 |ad 0002, Seq# 00|
00000270 30 30 30 30 30 31 31 34 2c 20 53 43 4e 20 30 78 |00000114, SCN 0x|
00000280 30 30 30 30 30 30 34 66 31 61 61 31 2d 30 78 30 |0000004f1aa1-0x0|
00000290 30 30 30 30 30 34 66 31 61 61 38 00 04 00 00 00 |000004f1aa8.....|
000002a0 fa cc a5 41 06 20 0e 00 00 00 00 00 02 00 00 00 |�A. ..........|
000002b0 02 00 00 00 a1 1a 4f 00 00 00 00 00 0b 88 d5 41 |....�.O.......�A|
000002c0 a8 1a 4f 00 00 00 00 00 0c 88 d5 41 00 00 08 02 |�.O.......�A....|
000002d0 53 07 1f 00 00 00 00 00 35 ce a5 41 a1 1a 4f 00 |S.......5A�.O.|
000002e0 00 00 00 00 0b 88 d5 41 00 00 00 00 11 00 80 00 |......�A........|
000002f0 00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 |................|
00000300 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 |................|
00000310 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|
00000320 00 00 00 00 7a c9 21 31 00 00 00 00 00 00 00 00 |....z�!1........|
00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000003c0 57 32 c0 0d 41 3f 33 57 59 33 d9 e6 4c 4f f5 c6 |W2�.A?3WY3��LO��|
000003d0 27 f7 6c 1f 74 8a 40 20 48 9c 47 0b 46 31 76 e0 |'�l.t.@ H.G.F1v�|
000003e0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000400 01 22 00 00 02 00 00 00 72 00 00 00 10 80 66 66 |."......r.....ff|
00000410 44 02 00 00 05 6e 00 00 a1 1a 4f 00 01 00 00 23 |D....n..�.O....#|
00000420 06 c5 1e 24 23 63 11 03 00 00 01 00 02 00 00 00 |.�.$#c..........|
00000430 02 00 00 00 0a 65 6c 5f a1 1a 4f 00 00 00 72 76 |.....el_�.O...rv|
00000440 65 72 73 00 00 00 80 f4 a3 1a 4f 00 00 00 00 00 |ers....�.O.....|
00000450 0b 88 d5 41 05 02 11 00 03 00 ff ff 80 00 c0 00 |..�A......��..�.|
00000460 21 11 4f 00 00 00 7c 99 01 00 ff ff 04 00 20 00 |!.O...|...��.. .|
00000470 13 00 00 00 48 06 00 00 4c 0e c0 00 09 02 23 00 |....H...L.�...#.|
00000480 12 00 c8 00 00 63 82 41 00 00 00 00 00 00 00 00 |..�..c.A........|
00000490 05 01 12 00 03 00 ff ff 4c 0e c0 00 20 11 4f 00 |......��L.�. .O.|
000004a0 00 00 00 00 01 00 ff ff 16 00 14 00 4c 00 20 00 |......��....L. .|
000004b0 1d 00 02 00 04 00 14 00 02 00 02 00 02 00 00 00 |................|
000004c0 c8 00 0e 0a 12 00 00 00 01 00 13 00 48 06 00 00 |�...........H...|
000004d0 09 02 23 00 ad 81 01 00 ad 81 01 00 04 00 00 00 |..#.�...�.......|
000004e0 00 00 00 00 0b 01 13 00 08 0c 01 00 00 00 00 00 |................|
000004f0 4c 0e c0 00 09 02 20 00 ab ba 4e 00 00 00 00 00 |L.�... .��N.....|
00000500 ea ba 4e 00 00 00 41 bc 40 08 00 00 ff ff ff ff |�N...A�@...����|
00000510 ff ff 00 00 23 0e c0 00 00 00 00 00 00 00 00 00 |��..#.�.........|
00000520 04 0d 00 00 00 00 00 00 0a 00 13 00 07 63 00 00 |.............c..|
00000530 5b 02 c0 00 2e 07 0b 00 00 80 00 00 39 1a 4f 00 |[.�.........9.O.|
00000540 ad 00 00 01 aa 00 00 01 fa 12 25 01 02 00 00 00 |�...�...�.%.....|
00000550 2c 00 00 00 01 00 03 01 00 00 00 00 00 00 00 00 |,...............|
00000560 01 00 00 00 6f 32 6b 32 01 1c 01 00 01 00 02 00 |....o2k2........|
00000570 02 00 00 00 00 10 00 00 00 00 00 00 01 00 00 00 |................|
00000580 02 00 00 00 c1 03 00 00 0b 05 01 00 04 00 01 00 |....�...........|
00000590 ad 00 00 01 8c 1a 4f 00 00 00 00 00 01 02 ad 81 |�.....O.......�.|
000005a0 0a 00 40 00 1d 00 02 00 04 00 00 00 11 0d 00 00 |..@.............|
000005b0 00 00 00 00 01 00 13 00 48 06 00 00 4c 0e c0 00 |........H...L.�.|
000005c0 09 02 23 00 00 00 00 00 00 00 00 00 00 00 00 00 |..#.............|
000005d0 00 00 00 00 ad 81 01 00 02 01 01 00 a1 1a 4f 00 |....�.......�.O.|
000005e0 00 00 00 00 01 02 00 00 8c 1a 4f 00 ad 00 00 01 |..........O.�...|
000005f0 aa 00 00 01 fa 12 05 01 02 00 00 00 2c 02 00 00 |�...�.......,...|
00000600 01 22 00 00 03 00 00 00 72 00 00 00 64 80 1b 9a |."......r...d...|
00000610 01 00 03 01 00 00 00 00 00 1a 4f 00 01 00 70 72 |..........O...pr|
00000620 6f 32 6b 33 05 14 00 00 00 00 00 00 00 00 00 00 |o2k3............|
00000630 00 00 00 00 00 00 00 00 00 06 00 00 12 00 04 00 |................|
00000640 00 00 02 00 04 00 04 00 00 00 00 00 03 00 4f f0 |..............O�|
00000650 2a 00 37 00 00 00 00 00 00 04 20 0b ff ff ff ff |*.7....... .����|
00000660 53 59 53 00 a4 00 00 00 01 06 00 00 a2 1a 4f 00 |SYS.�.......�.O.|
00000670 01 00 00 00 00 00 00 00 00 00 00 00 05 04 11 00 |................|
00000680 03 00 ff ff 80 00 c0 00 a1 1a 4f 00 00 00 00 00 |..��..�.�.O.....|
00000690 01 00 ff ff 08 00 14 00 10 00 04 00 13 00 00 00 |..��............|
000006a0 48 06 00 00 00 00 00 00 09 00 00 00 02 00 00 00 |H...............|
000006b0 4c 0e c0 00 09 02 23 00 02 00 44 09 00 7f 00 00 |L.�...#...D.....|
000006c0 0b cf 7c 62 18 04 00 00 00 00 00 00 00 00 00 00 |.�|b............|
000006d0 00 00 00 00 00 00 00 00 00 06 00 00 0a 00 10 00 |................|
000006e0 04 00 02 00 08 00 00 00 28 23 00 00 01 00 13 00 |........(#......|
000006f0 48 06 00 00 ff 00 0e 00 01 0a 09 00 00 00 00 00 |H...�...........|
00000700 a1 1a 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 |�.O.............|
00000710 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
参阅文章和 blog
-
juliandyke 大神 blog 介绍 redo 日志的文章:www.juliandyke.com/Internals/R…
-
Lewis 大神写的《Oracle Core: Essential Internals for DBAs and Developers (Expert’s Voice in Databases) 》数据库内核人员都奉为经典的书:www.amazon.com/Oracle-Core…\
-
lewis blog 中记载的 Oracle 的 opcode:jonathanlewis.wordpress.com/2017/07/25/…\
-
阿里开源的 GalaxyEngine 也运用了 lizard 业务:github.com/ApsaraDB/ga…\
-
WAL 日志先行机制:en.wikipedia.org/wiki/Write-…