2025年3月13日 星期四

IBM Data Replication (CDC) 系統架構、功能與支援資料庫

在上一篇文章《IBM Data Replication (CDC) 即時資料同步抄寫解決方案》中，我們從企業資料整合基礎架構（Data Integration Infrastructure）的角度，深入探討基於 CDC 技術的 IBM Data Replication 的運作原理，並分析它能為企業帶來的價值與效益。此外，文章也分享了四種常見的 CDC 商業應用場景，包括主機系統報表查詢外移、數據中台資料共享架構、混合雲資料庫即時同步，以及集中式主資料管理系統等。在本篇文章中，我們將進一步介紹 IBM Data Replication 的系統架構與功能特性，以及它所支援的各類來源與目標資料庫系統。



【文章目錄】



1.IBM Data Replication (CDC) 系統架構

IBM Data Replication（以下簡稱為 IDR）是一款即時資料同步抄寫解決方案，利用內建的 CDC 技術，它能夠即時擷取來源資料庫系統中發生的資料變更，並且根據預先設置的對應規則，將這些變更傳送到目標資料庫或其他應用系統中。由於 IDR 強調資料同步的即時性，它的核心元件：資料抄寫引擎（Replication Engine），通常會直接安裝於資料庫所在的作業系統中，專責處理來源與目標資料庫之間的資料同步。

針對同步抄寫工作的配置與監控，則由存取伺服器（Access Server）和管理主控台（Management Console）負責提供服務。為了降低對資料庫系統資源的影響，存取伺服器與管理主控台一般會部署在獨立的電腦上，系統管理員可以透過網路連線的方式管理來源端與目標資料庫上的資料抄寫引擎。

IDR 的系統架構及其三大核心軟體元件之間的關係，可以參考以下的系統架構圖（資料來源：IDR 官方技術文件）。

接下來，我們將進一步說明資料抄寫引擎（Replication Engine）、存取伺服器（Access Server）以及管理主控台（Management Console）這三個 IDR 核心軟體元件在即時資料同步作業中所扮演的功能與角色。

  • 資料抄寫引擎（Replication Engine）

    • 資料抄寫引擎是 IDR 非常重要的的核心元件，基於雙向資料同步的特性，這個引擎可以根據工作任務的需求分別擔任來源系統資料異動擷取引擎與目標系統資料異動寫入引擎的角色。

    • 資料儲存庫（Datastore）與抄寫引擎實例（Instance）：資料儲存庫代表欲連結的資料庫系統。在安裝軟體的過程中，首要步驟就是選擇資料儲存庫的類型，例如：IBM Db2、Microsoft SQL Server 或 Oracle Database 等資料庫管理系統。軟體安裝完成後，可以根據需求建立一個或多個執行實例，分別連結至不同的資料庫。每個執行實例將作為獨立的執行程序運行，負責處理來源與目標資料庫之間的資料同步抄寫，或是同時扮演來源與目標系統的角色，處理雙向資料同步的抄寫作業。

    • 組態資料表（Metadata）：每個抄寫引擎實例都會擁有一組用於記錄資料庫連線、資料表對應（Mappings）、抄寫訂閱工作（Subscriptions）以及事件通知（Notifications）等相關設定的組態資料表。這些資料表預設會建立在來源與目標資料儲存庫中，共計三個以〝TS〞開頭的資料表，分別是：TS_AUTH、TS_BOOKMARK 和 TS_CONFAUD。

    • 來源擷取與目標抄寫引擎（Source Capture Engine & Target Engine）：每個抄寫引擎實例會根據其扮演的角色，配置 Source Capture Engine 和 Target Engine。前者負責擷取來源系統的資料異動，後者則將這些異動套用於目標系統。抄寫引擎中的 Refresh Reader 負責讀取資料表的歷史資料，以便讓 Apply Agent 執行從來源資料表到目標資料表的初始化資料同步。Log Reader 則負責讀取資料庫日誌（Transaction Logs），以便於讓 Apply Agent 可以執行資料異動交易的同步，將變更從來源資料表傳送到目標資料表。

    • 資料轉換引擎（Transformation Engine）：在來源與目標系統進行資料同步抄寫的過程中，資料轉換引擎負責處理資料表欄位與內容過濾、格式與編碼轉換，以及衝突偵測等相關工作。


  • 存取伺服器（Access Server）

    • 存取伺服器在 IDR 的三大主要軟體元件中，扮演著溝通橋樑的角色。所有對資料抄寫引擎的設定、控制與監控，都必須透過存取伺服器來進行連接，IDR 提供的二種管理工具，包括管理主控台（Management Console）與命令列指令控制介面（Command Line Interface，CLI）都會透過存取伺服器與資料抄寫引擎進行互動。存取伺服器通常運行於與資料抄寫引擎不同的電腦設備上，並支援 Linux、UNIX 和 Windows 平台。它不僅作為管理主控台使用者登入的驗證點，還支援多個管理主控台的分散式管理架構。

  • 管理主控台（Management Console）

    • 管理主控台是一個運行在 Microsoft Windows 平台的 GUI 管理工具，用於配置和監控資料抄寫引擎，並協助管理來源與目標系統之間的資料同步抄寫作業。透過這個直覺且簡單的圖形使用者介面，系統管理人員可以定義來源系統的資料如何同步、何時同步，以及同步抄寫到那些目標系統。

    當同步抄寫作業啟動後，即使關閉管理主控台應用程式，來源與目標系統之間的資料同步作業也不會受到影響。此外，管理主控台內建事件日誌（Event Logs）與效能監控功能，事件日誌能夠顯示資料同步過程中的各種事件訊息，監控工具則以圖表方式協助系統管理人員持續監控抄寫狀態、延遲時間以及相關的統計資訊。




2.IBM Data Replication (CDC) 訂閱與抄寫方法

訂閱（Subscriptions）是指在 IDR 中定義的一個抄寫工作任務，每個訂閱包含對來源與目標資料儲存庫的配置，以及多個一對一資料表對映的配置與抄寫方法（稱為表格對映）。每個表格對映將一個來源資料表對應到一個目標資料表，並可詳細指定欄位對映（Column Mappings）、過濾（Filtering）、轉換（Translation）、編碼（Encoding）以及衝突偵測與處理（Conflicts）等相關細節。此外，在每個訂閱中，一個來源資料表只能對映到一個目標資料表；若需要將同一個來源資料表對映到兩個目標資料表，則需要分別建立二個訂閱來實現。


在建立訂閱時，應該合理地將相關資料表組織在一起，以維護關聯式資料表的參照完整性（Referential Integrity），從而確保同步抄寫資料的一致性。例如，若資料表 S1 中的主鍵（Primary Key）被資料表 S2 中的外鍵（Foreign Key）引用，則資料表 S1 與資料表 S2 之間形成了一對多的關係。基於參照完整性的要求，若需同步抄寫資料表 S2，則應將資料表 S1 與 S2 放置於同一個訂閱中，讓 IDR 可以同步抄寫這兩個資料表，保持資料的完整性和一致性。

為了方便管理，我們可以將相關的訂閱納入管理主控台中的專案（Project）。專案並不是 IDR 的軟體元件，而是管理主控台用來對訂閱進行分組的一種方法。在多人協同工作的環境中，管理主控台的專案可以透過「匯入／匯出」功能，實現在不同管理主控台應用程式之間的資料移轉。再者，為避免多位使用者在同時修改訂閱配置時發生衝突，我們可以透過鎖定訂閱的方式進行編輯，以防止這類情況的發生。


在一個訂閱任務中，我們可以選擇來源與目標資料表同步抄寫的方法。IDR 支援兩種抄寫方法：「鏡映」以及「重新整理」，詳細說明如下。

  • 鏡映（Mirror）

    • 基於異動資料擷取（Change Data Capture, CDC）技術，IDR 能夠將來源資料表的資料異動即時同步到目標資料表，確保來源與目標資料表之間的資料保持同步。在鏡映模式下，IDR 透過來源擷取引擎中的 Log Reader 持續監控並讀取資料庫日誌（Transaction Logs）中的變更。當資料表發生 INSERT、UPDATE、DELETE 等 SQL 操作時（即資料表內容發生變化），IDR 會根據 SQL 操作的順序，將已提交（COMMIT）的交易透過 TCP/IP 網路傳輸給目標抄寫引擎中的 Apply Agent，進而在目標資料庫執行相同的 SQL 操作，實現兩個資料表之間的即時資料同步。

    當啟動訂閱並開始執行資料表鏡映抄寫時，管理主控台會提示我們選擇鏡映方法，選項包括「連續（Continuous）」與「預定結束（Scheduled End）」。前者會以不中斷的方式持續同步來源與目標資料表，直到停止該訂閱。後者則會立即開始同步來源與目標資料表，並於指定的結束條件（如日期與時間或資料庫日誌位置）滿足時，自動停止同步抄寫訂閱。

  • 重新整理（Refresh）

    • 重新整理，也稱為快照（Snapshot），主要是將來源資料表的完整副本抄寫到目標資料表（Table copy）。有別於資料表鏡映抄寫，重新整理是透過來源擷取引擎中的 Refresh Reader 讀取資料表的歷史資料，然後通知目標抄寫引擎中的 Apply Agent 將這些資料插入（Insert）至目標資料表中。開始執行重新整理抄寫時，目標資料表的內容和已建立的索引會被刪除（Truncation）；當重新整理作業結束後，來源資料表與目標資料表的資料將完全一致。

    通常，首次啟動資料表鏡映抄寫（Mirror）時，IDR 會先執行重新整理（Refresh）操作，確保來源資料表與目標資料表的資料一致，接著就會開始即時監控來源資料庫的交易日誌，並針對資料表的異動進行鏡映抄寫。此外，重新整理抄寫模式也可以設置為在指定時間啟動，作為批量資料整合工作結束後，對資料表的同步快照（例如，將快照備份的資料表用於事後稽核或資料驗證）。




3.IBM Data Replication (CDC) 支援的來源與目標系統

部署 IDR 解決方案的第一步是確認資料抄寫引擎（Replication Engine）是否支援企業現有的來源與目標系統。由於 CDC 技術係透過擷取資料庫日誌的方式實現異動資料的即時同步，因此 IDR 支援的來源系統大多以資料庫與資料倉儲系統為主。至於目標系統，IDR 的支援範圍較為廣泛，除了資料庫與資料倉儲系統外，還包括大數據平台（如 Apache Hadoop）、ETL 工具（IBM DataStage）、以及事件串流平台（Apache Kafka）等系統。

以下我們以表格的形式整理了 IBM Data Replication V11.4 版本（本文撰寫時的最新版本）支援的來源與目標系統。資料來源為 IDR 官方技術文件，詳細內容請參見：System requirements for IBM Data Replication Version 11.4。

  • IDR 支援的來源系統（Source Databases）

    • 品牌/家族 軟體名稱 版本 作業系統
    IBM Db2 for Linux, UNIX and Windows (LUW) DB2 Enterprise Server Edition 11.1.0、11.5.0.0、11.5.8.0、11.5.9.0、12.1
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    DB2 Workgroup Server Edition 11.1.0
    Db2 Advanced Workgroup Server Edition 11.1.0、11.5.0.0
    Db2 Developer-C 11.5.0.0
    DB2 Direct Advanced Edition 11.1.0
    DB2 Direct Standard Edition 11.1.0
    Db2 Advanced Enterprise Server Edition 11.1.0、11.5.0.0、11.5.8.0、11.5.9.0、12.1
    IBM Db2 Warehouse Db2 Warehouse on Cloud Continuous Delivery N/A
    Db2 Warehouse 11.5.4.0、11.5.6.0、11.5.7.0、11.5.8.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    IBM Integrated Analytics System 1.0
    IBM dashDB Local 1.0
    IBM Db2 for i IBM Db2 for i5/OS 7.2、7.4 IBM Power Systems
    IBM Db2 for z/OS IBM Db2 for z/OS 12.1、13.1.0 IBM Mainframe
    IMS & VSAM IBM z/OS N/A IBM Mainframe
    Informix Informix Dynamic Server Enterprise Edition 12.10、14.10、14.10.xC2、14.10.xC3
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    Microsoft SQL Server Microsoft SQL Server Enterprise Edition 2016、2017、2019、2022
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Microsoft SQL Server Standard Edition 2016、2017、2019、2022
    Microsoft Azure SQL Database N/A N/A
    MariaDB MariaDB Enterprise 10.4
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    MySQL MySQL 5.6、5.7、8.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Oracle Oracle Database 23ai
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Oracle Enterprise Linux 8
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Oracle Database 12c Release 2 Enterprise Edition 12.2
    Oracle Database 12c Release 2 Standard Edition 12.2
    Oracle Database 18c Enterprise Edition 18.3
    Oracle Database 19c All Versions
    PostgreSQL PostgreSQL 12.0、13、14.0、15、16.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Amazon RDS for PostgreSQL N/A N/A
    Amazon Aurora PostgreSQL N/A N/A
    Azure Database for PostgreSQL N/A N/A
    Sybase Sybase Adaptive Server Enterprise 15.5、15.7、16.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025


  • IDR 支援的目標系統（Target Databases and Applications）

    • 請注意：除非規格表中另有註明，IDR 支援的來源資料庫系統皆可作為目標系統使用。下表僅列出 IDR 額外支援的目標資料庫系統與應用程式。

    品牌/家族 軟體名稱 版本 作業系統
    Apache Hadoop Apache Hadoop 2.2.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Cloudera CDH 5.0、6.0
    Hortonworks HDP 2.4
    Apache Kafka Apache Kafka 0.10.0.0、1.0.0、2.0.0
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    IDR for Kafka 使用 Apache Kafka 3.5.1 Client 進行連線，並相容於以下商業發行版：
    • Amazon Managed Streaming for Apache Kafka (Amazon MSK)
    • Confluent Platform 3.0+
    • Cloudera Distribution of Apache Kafka v2.1.0
    • Hortonworks Data Platform (HDP) v2.5
    • IBM BigInsights v4.3
    • IBM Event Streams for IBM Cloud (formerly Message Hub)
    • IBM Event Stream for IBM Cloud (version 2018.3.1+)
    Amazon Redshift Amazon Redshift N/A N/A
    Event Server Sun Java Message Service Specification 1.1
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    CockroachDB CockroachDB 23
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    PostgreSQL EnterpriseDB Postgres Advanced Server 12.0、13、14.0、15、16.0
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    Google BigQuery Google BigQuery N/A N/A
    IBM Cloudant IBM Cloudant N/A N/A
    IBM InfoSphere DataStage IBM InfoSphere DataStage (IBM InfoSphere Information Server) 9.1、11.3、11.5、11.7
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 11 / 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    IBM Netezza IBM Netezza Cartridge for IBM Cloud Pak for Data 11.0
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    SingleStore DB SingleStore DB 7.8、8.0
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    Snowflake Snowflake N/A N/A
    Teradata Teradata 16、16.10、16.20、17、17.10
    • AIX 7.2 / 7.3
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15
    • Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025
    YugabyteDB YugabyteDB v2.14、v2.16、v2.17
    • CentOS 7(7.1~7.9) / 8(8.1~8.3-2011)
    • Red Hat Enterprise Linux 7(7.1, 7.5) / 8(8.1)
    • SUSE Linux Enterprise Server 12 / 15





4.IBM Data Replication (CDC) 五大主要功能及特性

在現代化企業資料整合架構中，實現即時資料同步與高效資料整合是一項關鍵的需求。到目前為止，我們已經從系統架構、軟體元件、訂閱與抄寫方法、以及支援的來源與目標系統等角度為您說明 IDR 實現資料同步抄寫的運作機制以及它所支援的運行環境。接下來，我們將聚焦於 IDR 五大主要功能及特性，這些功能將有助於企業更清楚理解如何透過 IDR 解決方案滿足其特定的業務需求。

  1. 資料轉換功能（Transformational capabilities）

    2. IDR 可以讓企業在異質的來源與目標系統之間進行即時資料共享，由於異質資料庫系統通常會出現資料結構與定義不同的情況，因此我們可能還需要在同步抄寫過程中完成以下的工作：
    • 不同欄位名稱的對應。
    • 不同資料型別的轉換。
    • 修改欄位的資料長度。
    • 指定欄位抄寫的預設值。
    • 關聯資料表進行合併。
    • 使用包含 IF / THEN / ELSE 邏輯判斷的資料轉換操作。
    • 透過衍生表達式（Derived Expressions）建立新欄位。
    • 執行客製化資料轉換程式碼（User Exits 功能）。

    IDR 提供強大且多樣化的資料轉換功能，能夠輕鬆滿足使用者在欄位命名、型別轉換、資料長度調整以及指定預設值等基本需求。除此之外，藉由衍生表達式（Derived Expressions）的強大功能，使用者還能執行資料表關聯、邏輯判斷以及建立新欄位等更為複雜的操作。透過管理主控台（Management Console），使用者只需進行簡單的點擊和拖拉，即可輕鬆創建各種衍生表達式，並將其儲存，方便未來重複使用。為了有效管控系統資源的使用，IDR 內建的資料轉換操作支持在來源系統（衍生欄位）或目標系統（衍生表達式）中執行。這樣一來，系統管理員可以根據實際需求選擇最適合的處理方式，從而提供更高的靈活性與可配置性。

    以下是 IDR 常用的資料轉換功能介紹：
    • 欄位轉換函數（Column Functions）
      • IDR 提供多種欄位轉換函數，使用者可以在對映目標欄位時，將這些函數套用於衍生表達式中，從而在資料同步抄寫過程中執行各種簡單而有效的資料轉換操作。

      • 字串函數（String functions）：用於處理文字型字串，例如字串串接（Concatenation）、子字串提取（Substring）、去除字串開頭與結尾的空白（Trimming）等操作。

      • 日期時間函數（Date and time functions）：專門處理日期與時間格式的資料，像是取得當前日期、將日期與時間欄位合併為一個 Timestamp 欄位等功能。

      • 轉換函數（Conversion functions）：用於不同資料型別之間的轉換，例如將 Character、Numeric、Date 等型別的資料進行相互轉換。

      • 條件與變數函數（Conditional and variable functions）：提供靈活的邏輯運算能力。例如，使用 %IF 函數進行表達式判斷並根據條件返回不同結果；使用 %VAR 函數來宣告新變數並為其指定值，或檢索已存在變數的值。

      • 資料函數（Data functions）：在同步抄寫過程中對資料值進行特別處理，例如使用 %BEFORE 函數可強制將資料恢復至異動前的值。


    • 日誌控制欄位（Journal Control Fields）
      • 日誌控制欄位提供了有關來源資料庫系統交易日誌條目（Transaction log entry）的相關資訊。當來源資料庫系統發生資料異動時，該異動會被記錄於交易日誌中，並包含異動行為、異動類型、異動人員及異動時間等資訊。在 IDR 的管理主控台中，日誌控制欄位會在欄位名稱前加上「&」符號以示區別。

      在資料同步抄寫過程中，使用者不僅可以將日誌控制欄位同步至目標系統，還可以利用這些欄位進行資料過濾或邏輯判斷。具體操作方式舉例如下：

      • 直接對應到目標系統的欄位，例如：&TIMESTAMP 代表異動時間、&USER 代表異動人員、&CCID 代表 Commit Cycle ID。

      • 進行資料行層級（Row level）資料過濾，用來識別需要包含或排除的日誌條目，例如：&JOB = 'PURGE001'。

      • 結合衍生表達式（Derived Expressions）進行 IF / THEN / ELSE 邏輯判斷的資料轉換操作，例如：%IF(%SYSTEM = 'USHDQR', 'Atlanta', 'Toronto')。


    • 關聯資料表（Table Joining）
      • IDR 提供一個名為 %GETCOL 的 Column Function，透過這個函數，使用者可以查詢並擷取特定資料表中的欄位值，即使該欄位並不存在於交易日誌中。透過 %GETCOL 函數，使用者可以在衍生表達式（Derived Expressions）中執行以下操作：

      • 當 IDR 同步抄寫交易資料表時（僅包含產品代碼欄位），透過 %GETCOL 函數從產品資料表中取得對應的產品名稱，並將產品代碼及產品名稱一併傳送至目標資料庫。

      • 若透過指定鍵值從產品資料表中找出超過一筆以上的產品名稱，則 %GETCOL 函數會傳回第一筆找到的產品名稱；如果未能找到任何產品名稱，則會傳回指定的預設值。

      • 在使用 %GETCOL 函數關聯產品資料表時，使用者可以同時取得多個欄位值，例如：產品名稱、產品規格、產品包裝等。


    • User Exit 功能
      • 當 IDR 內建函數無法滿足特定業務需求時，使用者可以透過 User Exit 功能，引用外部 Java Class 或資料庫 Stored Procedure，執行特定的資料轉換處理邏輯並取得回傳結果。User Exit 包含以下兩種類型：

      • Table-level User Exits：在指定資料表發生資料庫異動事件之前或之後，執行一組自定義操作。

      • Subscription-level User Exits：在指定訂閱（Subscription）發生資料庫 Commit 事件之前或之後，執行一組自定義操作。


  2. 資料抄寫方法（Replication modes）

    3. 在前文中，我們已介紹過 IDR 支援「重新整理（Refresh）」與「鏡像（Mirror）」等兩種資料表同步抄寫方法。接下來，我們將進一步說明這兩種資料抄寫方法所支援的操作類型。透過靈活運用這些操作，使用者可以更輕鬆地滿足實際業務需求。
    • 重新整理（Refresh）
      • 由於 Refresh 操作會直接讀取來源資料表並將資料同步抄寫至目標資料表，因此其執行時間會受到資料量及抄寫過程中轉換處理複雜度的影響。一般而言，影響 Refresh 操作時間的因素包括：資料表的大小（欄位數量與資料筆數）、是否包含 Large Object (LOB) 型別資料、資料轉換邏輯的複雜度、網路速度與頻寬，以及目標資料表上的索引數量等。

      為了同時滿足資料即時性、同步效率與效能的需求，我們可以根據實際情況選擇 IDR 提供的兩種重新整理類型及列子集重新整理操作來設計同步抄寫訂閱（Subscription）。這樣可以充分發揮 IDR 強大的功能，實現最佳的資料同步效果。

      • 標準重新整理（Standard Refresh）
        將來源資料表中的完整資料副本傳送到目標資料表，通常用於資料同步的初始化階段。

      • 差異重新整理（Differential Refresh）
        基於來源與目標資料表之間的差異來更新目標資料表。與 Standard Refresh 不同，Differential Refresh 不會清除目標資料表中既有的資料，而是逐一比對來源與目標資料表中的每筆資料，找出缺漏、變更或新增的資料並進行同步。差異重新整理可以選擇以下三種模式：

        • 僅重新整理（Refresh Only）：針對目標資料表與來源資料表之間的差異部分進行同步更新。

        • 重新整理並記錄差異（Refresh and Log Differences）：除了進行差異重新整理外，IDR 還會在目標抄寫引擎的 Metadata 中建立一個 Log table，用於記錄同步過程中的操作。

        • 僅記錄差異（Only Log Differences）：這個模式僅建立 Log table，並不會實際執行資料同步更新。它主要用於識別來源資料表和目標資料表之間的所有差異。使用這個模式可以先評估資料表之間的差異，並在隨後決定是否進行資料同步更新。

      • 列子集重新整理（Subset Refresh）
        此模式主要透過 SQL 語句中的 WHERE 子句，根據指定的過濾條件，對資料進行細緻化的標準或差異重新整理操作。要執行 Subset Refresh，需要在資料同步抄寫時配置資料表擷取點（Table Capture Point），或在訂閱（Subscription）中設置擷取點（Scraping Point）。這樣便可以精確地篩選需要同步的資料子集，提升同步效率與精確度。


    • 鏡映（Mirror）
      • 如前文所述，在鏡映模式下，IDR 會持續監控並讀取來源資料庫日誌中的變更，並將這些變更即時同步至目標系統。此外，鏡映模式提供「連續（Continuous）」與「預定結束（Scheduled End）」兩種選項，用於決定即時同步作業停止的時機。

      • 連續鏡映（Continuous Mirroring）

        連續鏡映啟動後，IDR 會以不中斷的方式進行來源與目標系統之間的資料異動即時同步。欲停止連續鏡映同步抄寫，可以在管理主控台中針對選定的訂閱（Subscription）執行「結束抄寫」功能。啟動結束抄寫功能，可以選擇以下四種結束抄寫方法：

        啟動結束抄寫功能，可選擇以下四種結束抄寫的方法：

        • 正常結束（Normal）：待目前正在進行的同步抄寫工作完成後停止連續鏡映抄寫。因此，這個選項需要一些時間來確認同步抄寫工作已達到穩定並可結束的狀態。

        • 立即結束（Immediate）：立即停止所有正在進行的同步抄寫工作，然後結束連續鏡映抄寫工作。

        • 中止抄寫（Abort）：立即停止所有正在進行的同步抄寫工作，然後快速結束連續鏡映抄寫工作。此選項是結束抄寫工作最快的方法。

        • 預定結束（Scheduled End）：IDR 會處理資料庫交易日誌中所有已 Commit 的變更，然後以正常方式結束同步抄寫工作。此選項可以指定「立即」、「特定日期和時間」以及「特定日誌位置」作為結束同步抄寫工作的時機。

      • 預定結束（Scheduled End）

        「預定結束」與「連續鏡映」的唯一區別在於，使用者可以在啟動同步抄寫工作之前決定結束抄寫的時機點。例如，當系統管理人員不希望應用系統在尖峰使用期間因同步抄寫工作影響效能時，可以透過設定「特定日期和時間」選項，讓 IDR 在預定的時間自動停止同步抄寫工作。

  3. 資料過濾功能（Row & Column level filtering）

    4. IDR 提供的資料過濾功能包括對資料行的過濾（Row-level filtering）以及對資料表欄位的過濾（Column-level filtering）。前者類似於 SQL SELECT 語句中的 WHERE 子句條件；後者則用於選擇或排除特定的欄位。

    • 資料行過濾（Row level filtering）
      • 資料行過濾支援 IDR 衍生表達式（Derived Expressions）以及 SQL SELECT WHERE 語句。在衍生表達式中，使用者可以靈活地結合欄位轉換函數（Column Functions）、算術和布林運算子、欄位名稱及日誌控制欄位（Journal Control Fields），來組成一個可以傳回布林結果的過濾條件。

      以下是一些合法的資料行過濾表達式範例：

      • 1 = 1：此表達式始終傳回 True 值。

      • (SALES < 10000) OR (SALES > 90000)：需使用括號將同一欄位變數的布林表達式進行分組。請注意，表達式不支援 SALES < 10000 OR > 90000 這樣的寫法。

      • NOT((AIRPORT = ‘ATL’) OR (AIRPORT = ‘CLT‘))：判斷式的分組順序需要明確以括號進行區隔。請注意，表達式不支援 NOT(AIRPORT = 'ATL' OR 'CLT‘) 這樣的寫法。

      • %RTRIM(DEPT) = ‘IT‘：欄位轉換函數（Column Functions）可應用於表達式中的任何運算子。

      • PRINCIPAL *(1 + INTRATE) > 20000：表達式中可使用四則運算。

      • %IF(COUNTRY = ‘US’, PRICE, PRICE * 1.2) > 50：由於 %IF 函數無法傳回布林結果，因此必須將 %IF 函數的回傳值與表達式中的另一個值進行比較。

      • STATE IN (‘CA’, ‘AZ’, ‘AL’, ‘GA’, ‘CT‘)：IN 運算子是一個 SQL SELECT WHERE 子句中有效的語法。

      • &JOB = ‘QTRPURGE‘：日誌控制欄位（Journal Control Fields）可用於識別特定交易日誌的資訊。在此範例中，&JOB 用於識別特定的工作，接著可以決定要包含或省略與該工作相關的資料記錄。


    • 資料表欄位過濾（Column level filtering）
      • 預設情況下，IDR 會將所有已對應和未對應的來源資料表欄位同步抄寫到目標系統。如果需要在同步過程中排除不必要的來源資料表欄位，可以在管理主控台（Management Console）中的「過濾（Filter）」頁籤中進行設定。
      以下是使用資料表欄位過濾的兩個範例：

      • 目標資料表只需要來源資料表 150 個欄位中的 20 個欄位。因此，若僅選擇所需的 20 個欄位，可以大幅減少同步到目標資料表的資料量，從而節省網路頻寬和處理資源。

      • 來源資料表包含使用者 ID 和個人薪資等機密資訊。如果目標資料表不需要這些資料，則可以將這些欄位排除在資料同步抄寫的範圍之外。


  4. 對映套用類型（Apply methods）

    5. 在介紹 IDR 系統架構與主要組件功能時，我們大致說明了目標抄寫引擎（Target Replication Engine）中的 Apply Agent，該組件負責執行資料異動交易的同步，並將變更從來源資料表傳送到目標資料表。在配置資料表對映時，除了選擇對映模式外，還需要指定對映類型，也就是選擇如何將來源資料表對映到目標資料表的方法。

    IDR 提供了六種對映套用類型，具體說明如下：
    • 標準模式（Standard）
      • 在 Standard 模式下，IDR 會將來源資料表中的異動操作完整複製到目標資料表。例如，當來源資料表中新增一筆資料時，目標資料表也會新增對應的該筆資料，依此類推。以下是 Standard 模式常見的使用場景：

      • 在應用系統移轉或升級的平行測試期間，為了確保舊系統與新系統能夠使用相同的資料，可以透過 Standard 模式在兩個資料庫之間即時同步資料。

      • 為實現應用程式讀寫分離架構，降低資料查詢或產製報表對應用程式資源的耗用，可以透過 Standard 模式將所需資料即時同步到另一個資料庫。


    • 稽核模式（LiveAudit）
      • LiveAudit 模式除了可以同步來源與目標資料表的資料外，還會將來源資料表中執行的異動操作類型（如 INSERT、UPDATE、DELETE 和 TRUNCATE）、操作時間戳記以及使用者資訊記錄在目標資料表中。以下是 LiveAudit 模式常見的使用場景：

      • 基於法規或監管要求，需要保留所有與資料相關的操作稽核軌跡記錄。

      • 對資料庫中敏感資料異動的稽核軌跡進行追蹤和記錄。

      • 向下游應用程式提供來源資料處理的操作資訊。例如，ETL 應用程式可以利用時間戳記值來確定應處理哪些異動操作，從而確保目標系統的資料與特定時間點保持一致。


    • 調適性套用模式（Adaptive Apply）
      • Adaptive Apply 模式有助於解決資料同步抄寫過程中，發生無法正常同步的問題。在 Standard 模式下，IDR 會根據目標資料表的內容執行相應的操作。例如，只有當資料不存在時，才會執行 INSERT 操作；只有當資料已存在時。才會執行 UPDATE 或 DELETE 操作。如果 IDR 偵測到操作異常（例如，重複鍵值錯誤），為避免資料庫發生錯誤，IDR 會主動停止同步抄寫的訂閱。

      為了解決這些問題，Adaptive Apply 模式提供了「新增或更新資料（UPSERT）」操作。在此模式下，當 IDR 嘗試執行 INSERT 操作並偵測到重複鍵值錯誤時，它會將操作自動轉換為 UPDATE；而當執行 UPDATE 操作但找不到符合資料時，則會將其轉換為 INSERT；若執行 DELETE 操作但未找到符合資料，該操作將會被忽略。
      以下是 Adaptive Apply 模式常見的使用場景：

      • 當某個外部應用程式獨立於來源資料表修改目標資料表內容時。

      • 當使用者希望從資料庫交易日誌中還原訂閱資料表的內容時，可以透過將日誌位置設定為特定起點或時間點，並使用 Adaptive Apply 模式來填入空的目標資料表，確保其包含最新的資料。


    • 彙總模式（Summarization）
      • 在建置資料倉儲系統的過程中，我們通常需要透過撰寫 ETL Job將大量原始交易資料進行分組和彙總。例如，將每日的銷售資料依據不同產品進行分組，並將其匯總為每月或每季度的總銷售額。Summarization 模式可以幫助我們簡化這些數值欄位的加總運算，讓 IDR 在資料同步抄寫過程中直接在目標資料表完成這些資料的彙總。

    • 資料行合併（Row Consolidation）
      • 在 Standard 模式下，目標資料表中的每一筆資料只能接收來自來源資料表發生的新增、修改或刪除等異動操作，基本上，每筆資料實際上都由來源資料表「擁有」。然而，在某些資料同步需求中，如果需要將來自多個來源資料表的資料合併到目標資料表中的一筆資料中，則會因為來源資料表對資料行的所有權，導致同步抄寫失敗。

      為了解決這個問題，IDR 提供了以下兩種 Row Consolidation 模式，讓我們能夠更靈活地控制目標資料表中資料行的所有權：

      • 一對一合併（Consolidation One to One）
        在此模式下，IDR 允許我們將分散在不同來源資料表中的共用實體資料（例如業務人員、客戶或產品）合併到目標資料表的一筆資料中。

      • 一對多合併（Consolidation One to Many）
        此模式允許我們將來自查找表（Lookup Table）的資料異動套用到受影響的所有目標資料表。由於來源查找表上的一筆異動可能會影響到多筆目標資料表中的資料，透過此模式，除了保持目標資料表與主來源資料表的一致性外，還能確保目標系統中的各個輔助資料表與來源資料表的變更保持同步。


  5. 衝突偵測和解決方法（Conflict detection and resolution）
    6. 雙向資料同步抄寫涉及當來源系統發生異動時，IDR 會立即將異動同步至目標系統。同時，若目標系統也發生異動，IDR 也會將其即時同步回來源系統。如下圖所示，若 System A 與 System B 針對同一資料表進行雙向資料同步抄寫，則可能會發生遞迴抄寫的情況。


    IDR 內建的衝突偵測與解決機制用於防止雙向資料同步抄寫過程中，因來源與目標資料表的交易衝突而導致問題，尤其是當兩個系統同時更新相同資料表的記錄時。以下是 IDR 在同步抄寫期間主動偵測的衝突情境：

    • 在目標資料表中新增（Insert）一筆鍵值重複的資料（此操作違反單一鍵值的限制）。

    • 在目標資料表中修改（Update）一筆鍵值不存在的資料。

    • 在進行資料修改（Update）之前，來源資料表和目標資料表中該筆資料的內容不一致。

    • 在目標資料表中刪除（Delete）一筆鍵值不存在的資料。

    • 在進行資料刪除（Delete）之前，來源資料表和目標資料表中的該筆資料內容不一致。


    IDR 的衝突偵測和解決方法適用於 Standard 模式下配置的每個資料表欄位，以下是五種可用於解決衝突發生的作法。

    • 來源系統獲勝（Source Wins）：以來源系統的資料覆蓋目標系統，如果目標系統不存在該筆資料，則新增（Insert）該筆資料。這個作法有助於保持來源資料表和目標資料表之間的一致性。

    • 目標系統獲勝（Target Wins）：丟棄來源系統的該筆異動資料，保持目標系統的資料完整性。

    • 以最大值為優先（Largest Value Wins）：根據該筆資料中某個欄位的最大值來決定使用來源系統或目標系統的資料。例如，來源系統的時間戳記相較目標系統更新，則使用來源系統的資料覆蓋目標系統。由於空值（Null）會被視為最小值，因此若目標系統中不存在該筆資料，則來源系統的資料會被插入。如果來源與目標系統的欄位值相同，IDR 會採用「目標系統獲勝（Target Wins）」作法來解決衝突，即保持目標系統的資料不變。

    • 以最小值為優先（Smallest Value Wins）：根據該筆資料中某個欄位的最小值來決定使用來源系統或目標系統的資料。如果目標系統中不存在該筆資料，IDR 將使用空值（Null）作為最小值，並且不會在目標系統插入該筆資料。

    • 使用 User Exit 回傳的結果：IDR 根據使用者自定義的邏輯來解決資料衝突，並將 User Exit 回傳的結果套用於目標資料表。



版權聲明
文章內容未經授權，請勿進行任何形式的複製、修改或發佈本文內容，如需轉載或引用，請在使用時注明出處並取得授權。本文中提及的特定公司、產品、品牌名稱等僅為描述目的，其版權歸屬於相應的公司或擁有者。
Labels:

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)