前言

不管現階段美國和中國對峙到何種程度，不管桀傲不馴拉里.埃裡森如何不看好中國，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 日誌中記錄的內容

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 記錄到物理檔案中對應關係如下：

從 Oracle 日誌解析學習資料庫核心原理

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 的後映象，有興趣的同學可以參考詳細列表。

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，並沒有太大區別

從 Oracle 日誌解析學習資料庫核心原理

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 中的。

文末一張圖，簡要總結一下他們的關係：

從 Oracle 日誌解析學習資料庫核心原理

｜附錄

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.......5ΥA�.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

從 Oracle 日誌解析學習資料庫核心原理

前言

前置知識瞭解

資料庫日誌

怎麼檢視 Oracle 日誌中記錄的內容

supplemental log

日誌組織形式

redo 和 undo

日誌記錄內容

redo 邏輯結構

redo record

change vector

undo 和 redo

表和行

小結

redo 物理結構

redo file & block header

redo record & redo block

log redo header

總結

｜附錄

redo 邏輯格式 = redo 的 trace 檔案

redo 物理格式 = hexdump -C redo 檔案

相關文章