0 引言

“十三五”期間國家電網公司制定了“一系統、一平臺、多應用、微服務”的信息化規劃,公司數據統一訪問共享、流通是公司信息化工作的重點^[1-2]。當前公司各類數據在抽取交互過程中,使用了較多的Goldengate產品^[3-4],由于數據庫抽取產品直接讀取生產系統數據,產品無法自主可控,存在嚴重的信息安全隱患^[5-7],如何解決數據抽取過程中變化數據的定位,是當前面臨的一個難點。當前工具應用最廣泛的是基于邏輯級的數據庫抽取技術^[8-10],由于數據庫抽取技術一直是國外數據庫廠商的核心技術,國內廠商尚未完全掌握技術實現細節,在此類技術上國外技術封鎖重重,鮮有技術細節披露^[11-12]。針對上述問題,更加說明數據庫抽取技術值得深入研究探討。

 1 Oracle數據庫前映像Undo數據解析原理

1.1 Undo日志文件解析流程

Oracle數據庫Undo日志中詳細記錄了數據庫操作的所有變化前的備份信息^[13-14],Undo日志記錄所有的前印象,用于回滾操作,Undo日志有嚴格的格式與內部規律,但由于Oracle數據庫廠商的技術壁壘,無法直接獲取相關資料^[15],在Undo日志分析方法上,采用硬解析方式。即先模擬一次數據庫操作,找到對應操作的trace文件,再用數據庫塊瀏覽編輯器（Block Browser and Editor,BBED）等塊讀取工具讀取對應的數據塊^[16],通過trace文件注釋與二進制數據塊結合進行解析,找出其中的格式與規律流程。Undo日志解析方法如圖1所示。

1.2 追蹤文件解析

追蹤文件（Trace file）是以trc為后綴的文本文件,記錄了各種SQL操作及所消耗的時間等。根據追蹤文件可以查詢到詳細的數據庫操作過程,包括SEQ、SCN、KDO、OPCode等詳細的事務過程信息。具體追蹤文件內容如圖2所示。

圖1 Undo日志解析方法Fig.1 Undo log parsing method

圖2 Trace文件結構Fig.2 Trace file structure

通過追蹤文件中的內容,可以依次推理出數據庫每一種操作碼對應的標記位以及對應的執行過程內容,為下一步抽取有效操作內容奠定基礎。

1.3 Undo 數據塊文件解析

利用Oracle內部工具數據庫塊瀏覽編輯器（BBED）可以直接查看和修改日志數據塊文件。通過BBED工具DUMP日志文件塊查看Oracle內部Undo日志塊內容,如圖3所示。

圖3 Undo數據塊文件結構Fig.3 Undo data block file structure

1.4 Undo 日志文件結構

通過分析追蹤文件,將追蹤文件內容與Undo數據塊與十六進制數據塊相匹配,分析解讀Undo日志格式,經過多次比對,推斷出Redo日志文件結構。

Redo日志由操作系統頭（OS Head Block）、Undo頭標記段（Undo Head Block）與Undo數據塊（Undo Data Block）3種類型數據塊組成。其中操作系統頭位于第一個塊,Undo頭標記段位于第二個塊,從第三塊開始為Undo數據塊。Undo日志文件結構如圖4所示。

圖4 Undo 日志文件結構Fig.4 Undo log file structure

日志文件通常使用操作系統的塊大小,一般為512 B,Redo Logs循環寫。日志格式依賴于操作系統與數據庫版本,一般是由日志文件頭（Redo Logs Header）以及后面的日志記錄（Redo Record）組成,日志記錄同樣由記錄頭（Record Header）以及多個日志操作（Redo Change）組成;數據庫的許多變化都放在記錄（Record）中,記錄可以大于一個塊,也可以小于一個塊,記錄的大小和數據庫的塊大小有關,默認情況下最大的記錄是3個數據塊。記錄是Redo日志中表示數據庫操作的一個原子單位,每個Redo記錄包含每個Change所需的Undo信息。

 2 前映像數據抽取模型

Oracle數據庫Undo日志抽取技術主要包括物理數據塊Block處理、數據抽取引擎設計兩大部分。本文將對數據抽取技術進行詳細闡述。

2.1 Undo KDO結構

前映像日志的 KDO結構記錄數據變化關鍵信息,利用Oracle內部工具BBED可以直接查看和修改KDO數據。通過BBED工具DUMP日志文件塊查看Oracle內部Undo日志塊內部KDO結構（見
表1）。

表1 Undo KDO結構Tab.1 Undo KDO structure

2.2 數據抽取引擎流程設計

在確定KDO結構后,對前映像日志數據塊內容進行具體解析。針對前映像數據塊內部結構特點,本文設計了日志數據抽取引擎,通過獲取數據庫版本信息、解析前映像的change第4塊中的KDO數據,提取其中的操作碼;根據不同的操作碼采用不同的解析方式,獲取附加日志數據塊編號;根據附加日志結構,獲取附加日志內部的主鍵列數據;將獲取的主鍵列數據依次添加到改變列數據中。前映像數據抽取引擎如圖5所示。

圖5 前映像數據抽取引擎Fig.5 Pre-image data extraction engine

主要流程描述如下：

1）初始化UndoReader、數據庫連接,獲取當前日志文件路徑;

2）根據具體情況,打開存放在文件系統、裸設備、ASM上的日志文件;

3）根據KDO公共結構解析change第4塊中的KDO數據;

4）根據opKDO確定是哪一類DML操作,如果是INSERT操作,則進入步驟5）,如果是UPDATE操作,則執行步驟8）,如果是DELETE操作,則執行步驟13）;

6）根據INSERT特定的KDO結構解析change第4塊中余下KDO數據;

7）從第5塊開始根據改變列數量(KDO.cc)讀取各列的值;

8）計算附加日志開始change數據塊編號index,然后執行步驟15）;

9）根據UPDATE特定的KDO結構解析change第4塊中余下KDO數據;

10）從第5塊數據中獲取改變的列編號,每兩位一個;

11）從第5塊數據中獲取改變的列編號,每兩位一個,返回改變列號list;

12）從change第6塊數據開始,根據KDO.nchanged,逐個解析,獲得列數據,column id與改變列號list對應;

13）獲取附加日志開始change數據塊編號index,然后執行步驟15）;

14）opcode 為delete,無剩余KDO數據;

15）獲取附加日志開始change數據塊編號index = 5;

16）根據index在change的第index塊中解析附加日志結構;

17）設置附加日志標志信息、開始列信息;

18）從change的index+1塊中讀取主鍵的列id（此id從1而非0開始）,得到列號index;

19）從change第index+3塊數據開始,根據opSupplemental.totalCols,逐個解析,獲得主鍵列數據,column id與列號list對應;

20）添加到之前的改變列數據list中,然后重新繼續新的數據抽取。

 3 測試結果與分析

為驗證前映像數據抽取模型的可行性,搭建如圖6所示的測試環境。本文設計的抽取模型軟件系統架構由2部分組成,包括數據復制層與管理層。其中數據復制層由數據庫抽取工具組成,抽取工具分別部署在源端數據庫服務器（1臺16核64 GB內存、Oracle11g數據庫）、目標端數據庫服務器（1臺16核64 GB內存、oracle11g數據庫）;管理層由數據庫抽取管理工具組成,抽取管理工具部署在管理庫服務器（16核64 GB內存、Oracle11g數據庫）與應用服務器（16核64 GB內存）。測試環境中網絡帶寬100 Mb/s,其余測試參數不再詳述。

圖6 測試環境拓撲Fig.6 Test environment topology

測試源端數據庫執行DML操作時,數據抽取記錄如圖7所示。

圖7 數據抽取記錄Fig.7 Data extraction record

從圖7可以看出執行的DML操作數據已被抽取轉換成數據對象格式,數據對象記錄了詳細的操作過程數據,后續在數據投遞到目標端后,可以根據目標端數據庫類型,組裝成相應的SQL語句。

統計結果表明本文設計的前映像數據復制模型可以從Undo日志中抽取出變化附加日志信息,將抽取后的數據與源數據庫信息進行比對,驗證了抽取數據的完整性,進一步說明復制模型具有一定的工程應用價值。

 4 結語

數據庫前映像數據抽取是數據復制領域中的關鍵技術,當前業界主要是以goldenGate為代表的邏輯級數據庫日志抽取產品。本文設計了一種高效的數據抽取模型,測試結果證明該模型具有較好的實用價值。下一步將針對復雜混合云環境下分布式數據庫前映像數據抽取技術進行研究,完善數據抽取模型,更好的支撐智能電網建設。