技術白皮書：Oracle GoldenGate 優勢

本文為技術白皮書Oracle GoldenGate 優勢的翻譯及閱讀筆記。以下注釋中GoldenGate為OGG。

副標題為：Oracle 數據庫的變更數據捕獲 (CDC) 技術比較。版本為July, 2021, Version 2.1。

Oracle GoldenGate 被客戶和分析師公認為功能最齊全、性能最高、最值得信賴的數據集成和數據庫復制解決方案。作為一種經過驗證的異構解決方案，它與數百種非 Oracle 數據庫、數據存儲和云的組合集成。對于 Oracle 數據庫，GoldenGate 是唯一可擴展、完整且完全支持的解決方案。用于從 Oracle 數據庫捕獲數據事件的其他框架和工具不完整、不可擴展和/或不受支持。例如，LogMiner 是一個功能有限的單線程診斷 API。依賴于 LogMiner API 的第三方數據集成技術無法與 Oracle GoldenGate 相媲美，無法與 Oracle 數據庫一起使用。

# 性能最高指低開銷，高實時性；經過驗證與唯一表示產品成熟度，和豐富的案例

異構支持的豐富性見下圖
在這里插入圖片描述

本文的重點和目的是解釋從 Oracle 數據庫捕獲數據事件的選項、GoldenGate 如何適應以及為什么它可能是您的最佳選擇。

Oracle GoldenGate

GoldenGate 是一家成立于 20 世紀 90 年代的舊金山初創公司，其最初的目的是為通過 Tandem NonStop 數據庫運行的聯網 ATM/自動取款機提供業務連續性和數據高可用性。

# 初衷并非用于數據集成

圖 1：Oracle GoldenGate 平臺功能

如今，Oracle GoldenGate 已擴展成為一個成熟的集成和分析功能平臺，可為 Oracle 和非 Oracle 數據源提供服務。保證交易交付的可靠性使 GoldenGate 成為提供 Oracle MAA“白金級”服務級別的核心技術。這種可靠性擴展到非 Oracle 數據庫，例如 NonStop、SQL Server、DB2 iSeries、大型機和其他支持的數據存儲。全球數以千計的銀行、零售商、電信、醫療保健公司等在 Oracle GoldenGate 的可靠基礎上運行其運營數據平臺。

# MAA白金級依賴OGG提供0切換時間，不過這種需求非常少，大部分還是黃金級，即用ADG。

GoldenGate 是一個實時數據復制平臺，可以檢測數據事件并以極低的延遲通過網絡進行路由。 GoldenGate 技術用于操作數據庫的地理分片、低停機時間數據遷移、多活動（在線）數據存儲、實時數據提取到云、數據湖和數據倉庫等。自 2015 年以來，GoldenGate 越來越關注多語言大數據和 noSQL 數據有效負載，并且已經完全重構為本機微服務“即服務”部署。

# 實時性對于業務非常重要。OGG從傳統關系型數據擴展到支持大數據。

在這里插入圖片描述
圖 2：Oracle GoldenGate 平臺。邏輯架構和關鍵組件

# 在CVC-GoldenGate-Overall中找到一個類似的圖，如下：
在這里插入圖片描述

2018 年，GoldenGate 平臺增加了數據管道和流分析功能，并配備了強大的復雜事件處理 (CEP) 核心引擎，該引擎可擴展到每秒數十億個事件，同時將有序數據處理保持在納秒級。該事件引擎可以使用非常強大的語義進行轉換或分析，并在開源 Apache Spark 上運行以進行大規模并行處理 (MPP)。

憑借這些新功能，GoldenGate 可以直接向數據消費者提供高價值數據產品。過去，GoldenGate 主要用于向數據管道或其他數據產品傳送低延遲原始數據。如今，GoldenGate 可以推送原始數據事件，并提供高價值的數據產品。

GoldenGate 的工作原理

從本質上講，GoldenGate CDC 功能用于檢測和傳輸數據事件。數據事件通常包括數據庫 DML（數據操作語言）和 DDL（數據定義語言）。在 Oracle 數據庫上，GoldenGate 還可以檢測和傳輸過程事件，這在保持數據庫同步時很有用。 GoldenGate 從一開始就被設計為值得信賴的數據事件提供商，并且可以用于 MAA（最大可用性架構）用例，以及任務關鍵型的 DW（數據倉庫）、數據湖和數據流（例如基于 Kafka）場景。

在這里插入圖片描述
圖 3：Oracle GoldenGate 中的變化檢測和傳播

# 過程事件指執行存儲過程或函數引發的DML和DDL

在這里插入圖片描述
圖源

對于Oracle數據庫，需要解釋一下Classic Capture和Integrated Capture的區別。簡單來說，Integrated Capture更推薦，比Classic Capture限制更少（盡管其也有限制），不直接訪問Redo Log，而是通過數據庫進程（源端為ora_ms_xxx，即mining server，目標端為ora_as_xxx，即applying server）。由于無需直接直接訪問redo log，因此OGG 抽取和復制進程可以部署在Oracle數據庫服務器之外。

兩種模式的比較參考官方文檔。

GoldenGate 交易剖析

當數據庫日志事件被捕獲時，它們會被轉換成名為 Trail 的 GoldenGate 規范分類賬。所有受支持的源/平臺的數百種組合的數據事件日志都被轉換為這種單一的規范 Trail 格式。它是通過 GG 分發微服務分發的 Trail。每個 Trail 可能有一個或多個“路徑”，并且 Trail 消費者可以發起自己對路徑的訪問，或者可以配置 GoldenGate 將 Trail 推送到下游接收器微服務中。

在這里插入圖片描述
圖 4：GoldenGate 事務剖析，在分布式架構中保留 ACID 屬性

GoldenGate 能夠感知所有源操作，因為它們會影響數據庫日志，并且每種不同類型的數據庫處理操作的方式都不同。一般來說，一旦數據事件在源系統上提交，GoldenGate 就會發出數據事件。在數據庫系統中，許多操作可以組合在一次提交中。事實上，在一些長期運行的事務中，數百萬個對象可能會作為單個事務的一部分被修改，而這個事務需要花費數小時才能完成，并且還會與數千個較小的未提交操作交織在一起。當這些事務在網絡中移動時，GoldenGate 會將它們分組、隔離并保持它們的一致性。

Oracle 數據庫中檢測事件的選項

多年來，Oracle 數據庫已經擁有許多可用于變更數據捕獲 (CDC) 的 API。如今，仍有少數技術仍然是 Oracle 生態系統的戰略組成部分：

數據庫觸發器是存儲的 PL/SQL 塊，它可能與表相關聯，并在發生 INSERT、UPDATE 或 DELETE 等 DML 語句時執行。使用觸發器來檢測事件需要對模式和應用程序有詳細的了解，這容易導致員工流失和文檔記錄不善。這種高度侵入性的策略既不完整，又會產生大量的運行時開銷。盡管如此，許多 ETL 供應商仍然支持使用帶有數據庫觸發器的 CDC。（文檔）
Oracle LogMiner 是 Oracle 數據庫的一個組件，它使用戶能夠通過 SQL 界面查詢在線和存檔的重做日志文件。 LogMiner 是許多 ETL 和復制供應商的熱門選擇，因為它是數據庫的 API，可以免費使用，無需任何額外的許可。激活 LogMinor 后，Oracle 數據庫的更新性能可能會明顯下降。（文檔）
Oracle XStream 由 Oracle 數據庫組件和應用程序編程接口 (API) 組成，使客戶端應用程序能夠從 Oracle 數據庫接收數據更改并將數據更改發送到 Oracle 數據庫。 XStream 需要 Oracle GoldenGate 許可，并被 ISV 應用程序合作伙伴和非 Oracle 復制工具用于支持來自 Oracle 數據庫的高速 CDC。（文檔）
Oracle GoldenGate 是檢測 Oracle 數據庫更改和復制事務的最佳性能和功能最豐富的方法。現代微服務架構使 GoldenGate 成為現代化運營 IT 系統、應用程序和分析數據平臺的理想解決方案。（文檔）

# 實際上OGG Integrated extract 也使用了xstream 和 logmining API

不受支持的磁盤日志讀取器是第三方專有工具，可直接從基于磁盤的存儲中挖掘 Oracle 數據庫日志。這些方法對 Oracle 數據庫數據文件和 API 進行逆向工程。這種方法不受 Oracle 支持，會帶來可衡量的安全風險，并且可能違反 Oracle 許可協議。在本文檔的后面，我們將解釋該技術所涉及的風險。

Oracle GoldenGate 是使用 Oracle 數據庫進行 CDC 和復制的推薦方法。它支持超過 300 種源和目標組合，包括所有補丁級別的所有版本的 Oracle 數據庫。 GoldenGate 使用其自身深度集成的日志捕獲 API 來檢測日志事件并從 Oracle DB 讀取日志記錄，從而實現侵入性最小、速度最快且可擴展性最強的解決方案。

使用數據庫觸發器更改數據

對于少量表以及沒有大量交易量的用例，使用觸發器是一種可接受的檢測 DML 事件的方法。但是，每個觸發器都會將新對象放置在數據庫中，并且本質上會為每個觸發的事件運行一個存儲過程 - 因此，在廣泛使用觸發器時，應用程序和數據庫可能會產生相當大的開銷。很少有高端工具會使用觸發器，但盡管如此，一些主流 ETL 工具仍然提供開發人員工具，將觸發器設置和配置為 ETL 流程的一部分，這是需要注意的，因為它可能會對數據庫的性能產生負面影響。

# 開銷可能是次要的，代碼的維護可能是個問題

此示例創建一個 DML 觸發器，該觸發器使用條件謂詞來確定四個可能的觸發語句中的哪一個觸發了它：

CREATE OR REPLACE TRIGGER tBEFORE INSERT OR UPDATE OF salary, department_id OR DELETEON employees
BEGINCASEWHEN INSERTING THENDBMS_OUTPUT.PUT_LINE('Inserting');WHEN UPDATING('salary') THENDBMS_OUTPUT.PUT_LINE('Updating salary');WHEN UPDATING('department_id') THENDBMS_OUTPUT.PUT_LINE('Updating department ID');WHEN DELETING THENDBMS_OUTPUT.PUT_LINE('Deleting');END CASE;
END;
/

圖 5：DML 觸發器示例

使用 Oracle Database LogMiner 更改的數據

從歷史上看，Oracle 創建了 LogMiner 并對其進行維護以支持和診斷用例。盡管許多第三方供應商使用此 API 來捕獲變更數據，但該用例并不是該 API 的初衷。

Oracle 重做日志捕獲對用戶數據或數據庫字典所做的所有更改，以便可以執行數據庫恢復操作并符合關系數據庫 ACID（原子性、一致性、完整性、持久性）屬性。

LogMiner 是 Oracle 數據庫中嵌入的實用程序，Oracle 支持使用它來查看重做日志文件的內容。它是一種審計和診斷工具，也是一種數據分析工具。作為 DBA，LogMiner 使用 PL/SQL 過程和函數來查找重做日志文件中更改的記錄。

LogMiner 的主要功能包括：

跟蹤數據庫邏輯損壞（例如應用程序級別的錯誤）何時開始。準確了解錯誤發生的時間非常重要，這樣您才知道何時啟動基于時間或基于變化的恢復。 (文檔)
使用一組反向 SQL 語句執行細粒度恢復，以便將表返回到其初始狀態
使用趨勢分析功能進行數據庫調整。確定哪個表接收了最多的更新和插入，以便從歷史角度了解磁盤訪問統計數據
檢查事務一致性，因為它不僅可以跟蹤 DDL 和 DML，還可以跟蹤執行的順序以及哪個用戶執行了語句

LogMiner 是 Oracle 數據庫的一個強大實用程序，但在嘗試擴展 LogMiner 的用例以超越其最初的設計目的時，也需要注意一些挑戰。

LogMiner 面臨的挑戰

以下部分列出了客戶在直接使用 LogMiner 或任何基于 LogMiner 的第三方 CDC 工具時應該注意的一些潛在痛點：

Log Miner 被設計為數據庫重做日志的診斷工具。當以持續的方式挖掘重做日志時，它的性能將達不到最佳水平。
Log Miner 是單線程的，并且設計時不考慮檢索重做記錄時的低開銷。
當日志挖掘器達到當前系統提交號（SCN）時，它將停止。新的請求將從日志的開頭開始，類似于全表掃描（FTS）操作。（文檔：https://docs.oracle.com/en/database/oracle/oracle-database/21/sutil/oracle-logminer-utility.html#GUID-319446A8-6FEC-42CE-A6A4-582CA65377CF）
使用 Log miner 進行 CDC 時處理回滾或部分回滾可能會很麻煩或容易出錯。當應用程序會話中止（例如，突然退出）時，應該因任何事務失敗而發生回滾。如果事務被取消或失敗，則數據庫必須清理該事務完成的未提交的工作，以便其他事務可以繼續進行。此清理工作涉及回滾未提交的工作。從 LogMiner 的角度來看，回滾語句本身被報告為 SQL_REDO 而不是 SQL_UNDO。對于回滾的 SQL，不會生成撤消 SQL，并且會設置回滾標志。
從 Oracle Database 12.2 開始，LogMiner 的 continuous_mine 選項已被棄用，并且在 Oracle Database 19.1 及更高版本中不再可用。任何依賴于持續挖掘的第三方工具將不再適用于數據庫 19c 及更高版本。如需了解更多詳細信息并查看已停用功能的完整列表，請查看文檔。（文檔）
自 DB 12.2 起的數據類型將生成不受支持的 sql_redo 和 sql_undo，包括：JSON、OSON、BFILE、嵌套表、帶有嵌套表的對象、帶有標識列的表、臨時表有效性列、PKREF 表、長標識列和屬性、嵌套 ID 列（在 Oracle Database 12.2+ 版本中，數據類型與 DBMS_ROLLING 兼容）

需要理解的一個關鍵事實是，每個實施基于 LogMiner 的客戶端的供應商可能都有自己獨特的限制和責任——使用 LogMiner 并不能保證任何特定級別的統一性或對服務級別 (SLA) 和 KPI 的共同期望。

# 不要重新發明輪子，除非你的輪子更好

例如，一家第三方供應商于 2021 年夏季推出了對 LogMiner 的 CDC 支持，但存在以下限制：

大于 100 GB 的表無法回填。
不支持 Oracle 多租戶架構 (CDB/PDB)。
不支持 Oracle 自治數據庫。
沒有主鍵的表中的事件將不包含在消費者端執行更新所需的信息。
事件的大小限制為 3 MB。
不支持索引組織表（IOT）。
對于 BFILE 類型的列，只會復制文件的路徑。該文件的內容將不會被復制。
不支持數據類型為 ANYDATA、BLOB、CLOB、LONG/LONG RAW、NCLOB、UDT、UROWID、XMLTYPE 的列，這些列將被替換為 NULL 值。
對于 Oracle 11g，不支持具有數據類型為 ANYDATA 或 UDT 的列的表，并且不會復制整個表。
Oracle Label Security (OLS) 未被復制。
如果模式發生變化，則可能會讀取新模式中的某些事件，但仍然應用舊模式。
并非所有對源模式的更改都能被自動檢測到，在這種情況下可能會發生數據損壞。以下架構更改可能會導致數據損壞或無法處理下游事件：
- 刪除列
- 在表格中間添加列
- 更改列的數據類型
- 重新排序列
- 刪除表（如果重新創建同一張表并添加新數據則相關）
- 截斷表
不支持復制視圖。
流運行時創建的物化視圖不會自動填充。

Log Miner 仍然專注于診斷用例，選擇依賴于 LogMiner 的第三方 CDC 工具的客戶應在框架的已知限制內謹慎行事。每秒超過數百個事務的在線工作負載的用例可能會導致延遲、內存和可擴展性問題。對于小型和低容量的數據庫，LogMiner 可能對于簡單的工作負載來說“足夠好”。然而，在許多情況下，LogMiner 會與其他第三方工具配對，這可能會給源數據庫帶來額外的生命周期挑戰或不必要的負載。

任何使用帶有 LogMiner 的第三方 CDC 工具的人都應該仔細衡量對源數據庫本身的影響和負載要求，并確保數據類型覆蓋范圍、功能限制和安全問題對于業務來說是可以接受的。

使用 XStreams API 更改數據

XStream 是 Oracle 數據庫的一個戰略組成部分，它提供了一個低級 API，使事務流能夠在數據庫“內”或“外”進行復制。其目的是為客戶端應用程序提供將邏輯更改記錄（LCR 包含從源發送到目標的 DML 和/或 DDL）插入和提取到隱式或顯式流中的能力。 XStream API 旨在幫助高級用戶、技術合作伙伴和第三方工具直接使用 Oracle 數據庫進行高性能 CD??C、流式傳輸和復制。

XStream 包含兩個主要功能：XStream Out 和 XStream In。 XStream Out 提供 Oracle 數據庫組件和 API，使您能夠與其他系統共享對 Oracle 數據庫所做的數據更改。 XStream Out 可以從重做日志中檢索數據操作語言 (DML) 和數據定義語言 (DDL) 更改，并將這些更改發送到使用 API 的客戶端應用程序。（文檔）

總的來說，XStream API 是一個非常強大、現代且最新的訪問層，用于在 Oracle 數據庫內外進行高速事務復制。然而，有一些重要的主題需要注意。

重要的 XStream 事實

許可，使用 XStream API 需要任何使用 XStream 的數據庫的 GoldenGate 許可證
無法保證使用 XStream 的工具的自動化和生命周期。由于 XStream 是一個低級 API，因此任何更高級別的工具（例如第三方 CDC 工具）都必須實現自己的軟件自動化和生命周期管理，以便處理用戶、連接、字典、事務以及任何補充日志記錄或檢查點語義。非 Oracle 供應商提供的各個工具的質量和功能各不相同。
與 XStream API 一起使用的任何數據庫的恢復語義。任何源或目標數據庫都可能由于多種原因而失敗，并且連接并使用 XStream 的第三方客戶端將需要實現自己的邏輯以正常處理重啟情況。如果檢查點和恢復操作不正確，第三方 CDC 工具可能會跳過某些記錄、寫入重復記錄或在復制的數據存儲中產生不一致的數據集。將事務從 Oracle 數據庫復制到非關系目標（如 Apache Kafka 或對象存儲）時，這種情況也很重要。
XStream 不保證第三方工具的一致性。當第三方工具僅僅是 XStream API 的客戶端時，沒有什么神奇的方法來保證高質量的 CDC。不同供應商的實現可能有所不同，并且開源框架在 XStream 之上可能有完全不同的實現。警惕任何供應商在使用 XStream 時的一致性問題，即使 Oracle 數據庫客戶實施了多種使用 XStream 的 CDC 工具，各個工具之間的各自功能、質量和結果也會有所不同。

# Oracle使用XStream發明了一個輪子OGG，其他的軟件廠商也可以使用XStream發明自己的論證，但是否好過OGG就看軟件開發水平了，另外，還需要支付OGG許可費用

使用 Oracle GoldenGate 更改數據

Oracle GoldenGate 利用其自身高度優化的本機 API 與 Oracle 數據庫緊密集成。 GoldenGate API 深度集成在數據庫核心中，以針對高速數據事件進行優化并利用數據庫的新功能。 GoldenGate 是唯一獲得 Oracle 最高可用性架構 (MAA) 白金級認證的復制框架。（文檔）

與上面提到的 MAA 技術論文一樣，GoldenGate 通常以“中心”配置運行。這對于單點項目和簡化 GoldenGate 組件的管理非常有利。

# 沒懂，后續看文檔

在這里插入圖片描述
圖 6：Oracle GoldenGate 可以部署為 Hub，也可以部署在基于微服務的數據網格中

Oracle GoldenGate 還可以作為大型企業、分布式環境或多云復制項目的網格（Mesh）運行。通過數據網格方法，客戶可以使用 GoldenGate 分發服務在微服務層/應用程序之間分發事件。

Oracle GoldenGate 的一般優勢

Oracle GoldenGate 與 Oracle 數據庫深度集成（日志記錄、重做、備份和恢復層、安全性、管理、數據保護、數據保管庫、自治數據庫等）

Oracle GoldenGate 是 Oracle 最穩定、性能最強、最可靠的 CDC/復制解決方案
高性能：Oracle GoldenGate 能夠實現亞秒級延遲的數據移動，具有低影響的事務數據捕獲、路由、轉換和交付
GoldenGate 是唯一一款與核心 Oracle 數據庫中新興創新（安全性、功能、數據類型等）保持同步的 CDC / 復制工具。
GoldenGate 支持廣泛的用例，從傳統的 OLTP 數據復制和高可用性（單向、雙向、點對點等）到數據湖提取或多云提取、SaaS 應用程序復制、消息傳遞復制。在過去的五年中，GoldenGate 一直在擴展到流處理模式，用于數據管道、數據轉換、時間序列分析、預測分析、地理空間、實時分析等用例。
從 Oracle 數據庫捕獲時，Oracle GoldenGate 更易于使用，尤其是在處理 Oracle Real Application Clusters (RAC) 和 Oracle Automated Storage Management (ASM) 等選項時。此外，GoldenGate 是唯一獲得 Exadata、Exadata Cloud Service 和 Exadata Cloud at Customer 認證的 CDC/復制技術。
由于 GoldenGate 是唯一獲得 Oracle 白金級最高可用性架構認證的 CDC / 復制工具，客戶可以放心，GoldenGate 已經過最嚴格的 RPO（恢復點目標）和 RTO（恢復時間目標）場景測試 - 我們的客戶數據信任和他們最寶貴的 GoldenGate

從操作角度來看，GoldenGate 具有命令行和圖形 Web 用戶界面，支持數據庫管理員、系統管理員和 DevOps 團隊。 GoldenGate 微服務優勢包括：

簡單易用的 Web 界面
快速簡便的安裝或配置
通過可以在任何地方運行的 AdminClient 進行命令行訪問
適用于 DevOps 的 RESTful API
提供內置監控，但也可以輕松適應您自己的監控

在這里插入圖片描述
圖7:Oracle GoldenGate的簡單易用用戶界面（本地或云原生）

銀行和金融客戶一直要求最嚴格的安全框架。GoldenGate的安全功能包括：

數據可以在磁盤上和通過在線協議進行加密
加密配置文件封裝了用于從Oracle密鑰庫檢索主密鑰的配置信息
原生支持DMZ環境和私有云環境。
通過所有版本的數據庫支持Oracle透明數據加密（TDE）和表空間加密（TSE）（擁有專有磁盤讀取器的第三方供應商無法支持此功能）
對跨分布式服務的證書的豐富支持，包括對mTLS 1.3的支持
API受到跨站點請求偽造（CSRF）身份驗證的保護。默認配置是強制執行基于CSRF令牌的保護。

關于第三方磁盤日志讀取器的簡要說明

多年來，一些供應商選擇創建專有軟件，直接對Oracle數據庫日志進行逆向工程，以發現數據更改。選擇此策略的供應商避免使用受支持的API和實用程序，如LogMiner和XStream。這使數據、數據安全和持續支持面臨風險。

這些專有日志解析器有以下缺點：

不受支持且未記錄 - Oracle 不記錄重做日志/歸檔日志的內容和結構，并且不支持使用第三方工具對這些日志進行逆向工程，這違反了 Oracle 主協議（第 8 部分）和 Oracle 軟件許可協議（第 9 部分）。
顯著的功能限制——由于這些讀取器正在對磁盤日志進行逆向工程，因此他們只能看到數據庫引擎所執行操作的一小部分語義（含義）。這導致與 Exadata、數據壓縮（EHCC）、表加密、安全密鑰訪問、數據類型不兼容等諸多不兼容問題。擁有二進制日志讀取器的供應商將強制客戶在數據庫中禁用此功能以處理數據。
最終用戶的治理和安全風險——需要直接主機訪問數據庫日志并有權使用用戶提供的加密密鑰的管理工具對許多政策（如 SOC2、巴塞爾、BCBS239 等）構成重大合規風險。
缺乏生命周期集成——對于關鍵任務系統，沒有支持或認證的 Oracle MAA 配置來提供使用第三方二進制日志解析器實現故障轉移和重啟的自動化。
5.意外停機風險——由于這是一個不受支持的集成，Oracle 可能會隨時更改日志格式、加密、密鑰庫等，從而導致在應用數據庫補丁時發生意外停機和復雜的回滾。
云數據庫問題——Oracle 托管云數據庫（例如 Oracle 數據庫云服務、Oracle 自治數據庫、Oracle Exadata 云服務和 Oracle Exadata Cloud at Customer）可能不受支持。特別是，不支持從 Oracle 管理的云主機安裝第三方二進制日志解析器。此外，Exadata 云系統需要加密表，而數據庫 19.1 及更高版本中的二進制日志解析器無法讀取這些表。
性能和規模平庸——與 GoldenGate 對 Oracle 數據庫引擎的本機訪問相比，任何基于磁盤的直接重做日志訪問都會導致不必要的 I/O 問題以及并行性和計算利用率的限制。當使用本機集成的 GoldenGate 提取時，實際工作負載的運行速度可能會提高 2 到 5 倍，處理的數據量可能會增加 3 到 10 倍。當遠程訪問 ASM 存儲時，這些問題會進一步加劇。
所有權和限制——Oracle 主協議明確禁止導致或允許他人對軟件的數據結構進行逆向工程，請參閱在線交易 Oracle 主協議第 3.4 節，網址。
數據庫軟件許可——Oracle 軟件許可協議還明確禁止導致或允許他人對軟件的數據結構進行逆向工程，請參閱 D 部分第 3 點。

關于 Apache Kafka 或對象存儲的 GoldenGate

GoldenGate 是一個用于將數據復制到 Apache Kafka 和對象存儲并從中復制數據的絕佳平臺。

Oracle GoldenGate 是第一個支持 Kafka 的 CDC / 復制工具，發明 Kafka 的 LinkedIn 團隊多年來一直廣泛使用 GoldenGate 來實現 Kafka。世界上幾個最大的 Kafka 實現每天都依賴 GoldenGate 將 PB 級的變化數據提取到其事件流中。 GoldenGate 客戶可以放心，該解決方案將擴展到地球上最苛刻、最關鍵的 Oracle 到 Kafka 用例。

在這里插入圖片描述

圖 8：使用 GoldenGate 進行 CDC、數據集成和流分析

高層目標是將數據庫事件從源數據庫流式傳輸到 Kafka。但在這樣做時，保留事務邊界（DML 和 DDL）對于事務完整性至關重要。這很重要，因為像 Kafka 這樣的消息傳遞系統不具備 ACID（原子性、一致性、完整性和持久性）屬性。當 GoldenGate 目標是具有 ACID 功能的存儲（例如關系數據庫、Apache Hive、MongoDB 等）時，用戶可以確定數據事件在寫入并合并到目標數據存儲時得到正確處理。這為支持 ACID 的數據存儲提供了可靠的“同步數據”的巨大優勢。

當 GoldenGate 將數據事件寫入非 ACID 存儲（例如 Apache Kafka、對象存儲、基于搜索的索引等）時，GoldenGate 通常需要采取額外步驟，用額外的元數據“裝飾”有效負載，以便數據事件的消費者能夠在需要執行回滾操作時正確地重建數據讀取器的位置。

例如，GoldenGate 用戶經常希望在其數據事件中看到的元數據類型包括：

交易前后映象
源操作類型（插入、更新、刪除、截斷、創建、更改、刪??除）
源提交序列號（SCN、LSN、RBA 等）
源提交時間戳
源元數據，例如表和列定義
GoldenGate 目標trail序列號
GoldenGate 目標trail RBA
元數據版本
源數據庫名稱和類型
源操作日志位置（如果有）
源交易用戶和名稱（如果有）

GoldenGate 可以將交易發送到數百個不同的數據存儲和平臺組合。具體來說，對于 Kafka，GoldenGate 輸出格式支持各種非關系有效負載，例如：CSV、固定長度、XML、JSON、Avro、Parquet、ORC。越來越多的高級文件類型正在嘗試注入高水平的模式演變和其他類似關系的屬性，例如 Kafka 注冊表中的 Avro 和元存儲目錄中的 Parquet。但是這些有效載荷格式都無法處理具有 ACID 功能的數據庫的豐富性和語義。

最終，開發人員需要將非 ACID 目標上的隔離性和一致性結合在一起，但 GoldenGate 元數據在很大程度上使這一過程變得更簡單。如果您選擇使用 GoldenGate 進行流分析，則默認情況下內置有支持 GoldenGate 元數據的模式（例如，部分/全部補充日志記錄）。這些整體流處理和流分析用例對于動態和實時的現代數據平臺變得越來越重要。