Oracle CDC 1 — Tổng quan CDC thời gian thực với Oracle

CDC là gì và vì sao cần CDC?

Change Data Capture (CDC) là kỹ thuật phát hiện và ghi lại từng thay đổi dữ liệu (INSERT, UPDATE, DELETE) xảy ra trên một cơ sở dữ liệu nguồn, rồi chuyển các thay đổi đó tới hệ thống đích gần như tức thời (near-real-time). Thay vì định kỳ "chụp ảnh" toàn bộ bảng, CDC chỉ vận chuyển phần chênh lệch (delta).

Trong một ngân hàng điển hình, Core Banking chạy trên Oracle với hàng trăm triệu bản ghi. Nếu mỗi đêm phải SELECT * toàn bộ bảng giao dịch để nạp vào Data Warehouse, hệ quả là:

• Nguồn bị quá tải truy vấn vào cửa sổ batch, ảnh hưởng hệ thống nghiệp vụ.
• Dữ liệu ở đích trễ tới 24 giờ, không phục vụ được phát hiện gian lận hay báo cáo tức thời.
• Khó bắt được các bản ghi đã sửa rồi sửa lại trong ngày nếu chỉ so sánh trạng thái cuối.

CDC giải quyết cả ba vấn đề:

• Giảm tải nguồn: không quét bảng lớn; đọc thay đổi từ nhật ký (log) mà DB đã ghi sẵn.
• Near-real-time: độ trễ tính bằng giây, không phải giờ.
• Không đụng ứng dụng: phương pháp log-based không cần sửa schema hay code ứng dụng.

Các phương pháp CDC

Có ba nhóm phương pháp chính, đánh đổi khác nhau về độ trễ, tải nguồn và độ xâm lấn.

Vì sao log-based tốt nhất? Mọi thay đổi trong Oracle đã được ghi vào redo log để phục vụ recovery — CDC log-based chỉ "tái sử dụng" nguồn dữ liệu này. Nhờ đó nó không thêm tải query, không cần sửa ứng dụng, và nắm được thứ tự cam kết chính xác của giao dịch. Đây là lý do các nền tảng CDC nghiêm túc (GoldenGate, Debezium) đều dùng log-based.

Cơ chế nhật ký của Oracle

Để làm CDC log-based trên Oracle, cần hiểu vài thành phần cốt lõi.

Redo log và Archived redo log

• Online redo log: file luân phiên (redo log group) mà Oracle ghi mọi thay đổi khối dữ liệu trước khi commit hoàn tất. Đây là "sổ nhật ký sống" phục vụ crash recovery.
• Archived redo log: khi database chạy ở chế độ ARCHIVELOG, mỗi online redo log đầy sẽ được sao lưu thành file archive trước khi bị ghi đè. CDC cần các file này để không mất thay đổi khi log online đã bị tái sử dụng.

Kết luận thực dụng: CDC log-based trên Oracle yêu cầu database bật ARCHIVELOG mode. Nếu không, các thay đổi cũ sẽ mất khi redo online quay vòng.

SCN — System Change Number

SCN là một bộ đếm tăng dần đơn điệu, đóng vai trò "đồng hồ logic" của Oracle. Mỗi commit được gán một SCN, và mọi thay đổi trong redo log đều mang SCN. CDC dùng SCN để:

• Đánh dấu vị trí (offset/checkpoint): connector nhớ "đã đọc tới SCN nào" để khởi động lại đúng chỗ.
• Sắp thứ tự các thay đổi theo đúng trình tự cam kết.

LogMiner

LogMiner là công cụ tích hợp sẵn của Oracle (gói DBMS_LOGMNR) cho phép đọc và giải mã nội dung redo/archive log thành các câu SQL logic (bảng nào, thao tác gì, giá trị trước/sau). LogMiner miễn phí, đi kèm mọi Oracle Database. Đây là cơ chế mặc định mà Debezium dùng để bắt thay đổi.

Ví dụ khái niệm về việc nạp và truy vấn LogMiner (chỉ để minh hoạ cơ chế):

-- (minh hoạ Oracle — không chạy trong SQL Builder Postgres)
-- Bổ sung một file archive log vào phiên LogMiner
BEGIN
  DBMS_LOGMNR.ADD_LOGFILE(
    LogFileName => '/u01/oradata/arch/1_1234_567890.arc',
    Options     => DBMS_LOGMNR.NEW);
END;
/

-- Khởi động LogMiner với dictionary lấy từ redo log
BEGIN
  DBMS_LOGMNR.START_LOGMNR(
    Options => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
END;
/

-- Đọc các thay đổi đã giải mã
SELECT scn, timestamp, operation, seg_name, sql_redo
FROM   V$LOGMNR_CONTENTS
WHERE  seg_owner = 'CORE'
AND    operation IN ('INSERT','UPDATE','DELETE');

Supplemental logging — vì sao bắt buộc?

Mặc định, redo log của Oracle chỉ ghi đủ thông tin để recovery — thường chỉ ghi các cột thay đổi, và định danh hàng theo ROWID nội bộ. Điều đó chưa đủ cho CDC, vì phía đích cần biết hàng nào đã đổi theo khoá logic và giá trị đầy đủ.

Supplemental logging yêu cầu Oracle ghi thêm dữ liệu vào redo log để CDC tái tạo được thay đổi:

• Minimal supplemental logging: mức tối thiểu để LogMiner nhận diện đúng hàng.
• Identification key / PRIMARY KEY logging: ghi khoá chính để định danh hàng ổn định.
• ALL COLUMNS: ghi toàn bộ cột (cần cho một số kịch bản cần ảnh "before" đầy đủ).

-- (minh hoạ Oracle — không chạy trong SQL Builder Postgres)
-- Bật minimal supplemental logging ở cấp database
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

-- Ghi đầy đủ tất cả cột cho một bảng cụ thể
ALTER TABLE core.transactions
  ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Không bật supplemental logging là lỗi cấu hình phổ biến nhất khiến CDC "chạy nhưng thiếu cột / không xác định được hàng".

Hai hướng đưa dữ liệu Oracle ra Kafka

Có hai họ giải pháp trưởng thành để stream thay đổi Oracle sang Kafka.

1) Oracle GoldenGate

GoldenGate (OGG) là sản phẩm CDC thương mại của Oracle. Kiến trúc gồm:

• Extract: đọc redo/archive log, sinh ra "trail file" chứa các thay đổi.
• Replicat / Distribution: chuyển và áp dụng thay đổi tới đích.
• GoldenGate for Big Data: bộ handler để đẩy thay đổi ra Kafka, HDFS, cloud, v.v.

GoldenGate rất trưởng thành, hiệu năng cao, hỗ trợ nhiều nền tảng nguồn/đích và các tình huống phức tạp (multi-master, transformation). Đổi lại, nó tính phí license (cả OGG lẫn OGG for Big Data), và vận hành cần kỹ năng chuyên biệt.

2) Debezium Oracle connector

Debezium là nền tảng CDC mã nguồn mở (Apache 2.0), chạy như connector trên Kafka Connect. Với Oracle, Debezium có hai chế độ bắt thay đổi:

• LogMiner (mặc định): dùng DBMS_LOGMNR để đọc log. Miễn phí, không cần license bổ sung — đây là lựa chọn khởi đầu tự nhiên.
• XStream: dùng Oracle XStream API, hiệu năng/độ trễ tốt hơn ở tải rất cao, nhưng XStream yêu cầu license GoldenGate.

Điểm mấu chốt về licensing: XStream tính phí (cần license GoldenGate); LogMiner miễn phí. Do đó phần lớn triển khai Debezium bắt đầu bằng LogMiner, chỉ chuyển sang XStream khi thực sự chạm giới hạn hiệu năng và đã có license.

Kiến trúc tổng thể

Luồng chuẩn: ứng dụng ghi vào Oracle → thay đổi vào redo/archive log → CDC engine giải mã và phát thành sự kiện → Kafka lưu theo topic (thường mỗi bảng một topic) → các sink connector nạp vào Data Warehouse, hồ phân tích near-real-time, hoặc dịch vụ phát hiện gian lận.

So sánh GoldenGate vs Debezium

Tóm gọn lựa chọn: nếu tổ chức đã đầu tư GoldenGate hoặc cần khả năng doanh nghiệp phức tạp và tải rất lớn, GoldenGate là lựa chọn an toàn. Nếu ưu tiên chi phí, đã vận hành Kafka và muốn bắt đầu nhanh, Debezium + LogMiner là điểm khởi đầu hợp lý — có thể nâng cấp lên XStream sau này khi cần (kèm license).

Use case ngân hàng

CDC là xương sống của nhiều bài toán dữ liệu trong ngân hàng:

• Đồng bộ Core Banking → Data Warehouse: thay batch đêm bằng dòng chảy near-real-time. DWH luôn "tươi", báo cáo cuối ngày không còn phải chờ cửa sổ ETL dài.
• Operational Data Store (ODS): một bản sao gần thời gian thực của dữ liệu vận hành, để các hệ thống downstream (CRM, đối soát, hạn mức) truy vấn mà không đụng vào Core.
• Phát hiện gian lận (fraud detection): mỗi giao dịch phát sinh một sự kiện Kafka; hệ thống streaming (ví dụ Kafka Streams / Flink) chấm điểm rủi ro trong vài giây thay vì phát hiện sau nhiều giờ.
• Near-real-time analytics & cảnh báo: dashboard dòng tiền, cảnh báo hạn mức, giám sát tuân thủ cập nhật liên tục.

Điểm chung: nguồn Core Banking là Oracle, không được phép chịu tải query nặng và không được sửa ứng dụng — chính là bối cảnh lý tưởng cho CDC log-based.

Lộ trình series lab

Series này sẽ đi từ nền tảng tới triển khai chạy được:

1. Bài 1 (bài này) — Tổng quan CDC, cơ chế log Oracle, so sánh GoldenGate vs Debezium.
2. Bài 2 — Chuẩn bị Oracle: bật ARCHIVELOG, cấu hình supplemental logging, tạo user CDC và cấp quyền.
3. Bài tiếp theo — Dựng Kafka + Kafka Connect + Debezium Oracle connector (LogMiner), tạo topic theo bảng.
4. Bài tiếp theo — Định dạng sự kiện Debezium (before/after, op, schema), xử lý snapshot ban đầu và streaming.
5. Bài tiếp theo — Sink ra Data Warehouse và bài toán near-real-time analytics, giám sát và xử lý sự cố.

Tóm tắt

• CDC ghi lại từng thay đổi dữ liệu và chuyển tới đích near-real-time, giúp giảm tải nguồn, giảm độ trễ và không đụng ứng dụng.
• Ba phương pháp CDC: query-based, trigger-based và log-based; log-based tốt nhất vì tái dùng nhật ký DB, tải thấp, bắt đủ I/U/D và đúng thứ tự.
• Oracle log-based dựa trên redo/archive log, SCN làm đồng hồ logic, LogMiner để giải mã log, và supplemental logging bắt buộc để CDC định danh hàng và lấy đủ cột.
• Hai hướng ra Kafka: GoldenGate (thương mại, trưởng thành) và Debezium (mã nguồn mở; LogMiner miễn phí, XStream cần license GoldenGate).
• Trong ngân hàng, CDC phục vụ đồng bộ Core Banking → DWH/ODS, phát hiện gian lận và analytics near-real-time.

Tự kiểm tra

1. Vì sao phương pháp log-based được coi là ít xâm lấn và ít tải nhất so với query-based và trigger-based?
2. SCN đóng vai trò gì trong việc checkpoint và sắp thứ tự thay đổi của CDC?
3. Tại sao CDC log-based trên Oracle yêu cầu database bật ARCHIVELOG mode?
4. Supplemental logging giải quyết vấn đề gì mà redo log mặc định không đáp ứng?
5. Debezium dùng LogMiner và XStream khác nhau thế nào về license và khi nào nên cân nhắc XStream?
6. Nêu hai use case ngân hàng mà CDC mang lại giá trị rõ rệt so với batch đêm.

Đọc tiếp

Oracle CDC 2 — Chuẩn bị Oracle