Giới thiệu dự án

Bối cảnh ngành và thực trạng gián đoạn hệ thống

Trong kỷ nguyên kinh tế số, dữ liệu được coi là tài sản chiến lược cốt lõi chi phối toàn bộ năng lực vận hành của doanh nghiệp tài chính. Bất kỳ sự cố gián đoạn hệ thống (downtime) nào cũng dẫn đến thiệt hại nặng nề về doanh thu, uy tín thương hiệu và nghĩa vụ tuân thủ pháp lý. Theo báo cáo của Lääts (2023), các doanh nghiệp thuộc nhóm Fortune Global 500 chịu thiệt hại ước tính lên tới 11% tổng doanh thu hàng năm do sự cố ngừng trệ hệ thống, tương đương khoảng 1.5 nghìn tỷ USD (tăng 8% so với năm 2020). Điển hình trong thảm họa tòa tháp WTC ngày 11/9/2001, trong khi hơn 800 tổ chức mất hoàn toàn dữ liệu, tập đoàn tài chính Morgan Stanley đã khôi phục hoạt động ngay ngày hôm sau nhờ kiến trúc cơ sở dữ liệu dự phòng phân tán địa lý.

Tại Việt Nam, Công ty Tài chính TNHH MTV Ngân hàng TMCP Sài Gòn – Hà Nội (SHBFinance) phục vụ hơn 500.000 khách hàng với quy mô xử lý trên 2 triệu hồ sơ vay vốn mỗi năm. Cơ sở dữ liệu (CSDL) phục vụ hệ thống Xếp hạng tín dụng nội bộ của SHBFinance giữ vai trò huyết mạch: tính toán xác suất vỡ nợ (Probability of Default - PD), phân loại rủi ro và phê duyệt hạn mức tín dụng tức thời.

+-----------------------------------------------------------------------------------+
|               HỆ THỐNG XẾP HẠNG TÍN DỤNG NỘI BỘ SHBFINANCE                        |
+-----------------------------------------------------------------------------------+
|  1. Phân loại đối tượng: Cá nhân | Hộ gia đình | Khách hàng kinh doanh           |
|  2. Thu thập dữ liệu: Nhân thân, Lịch sử trả nợ, Dư nợ CIC, Khảo sát định tính    |
|  3. Thuật toán tính điểm PD:                                                      |
|     PD Score = 35%(Lịch sử nợ) + 30%(Dư nợ ngoài) + 15%(Thâm niên tín dụng)       |
|                + 10%(Khoản vay mới) + 10%(Loại hình tín dụng)                    |
|  4. Phân tầng rủi ro: Đạt (Low Risk) | Không đạt (High Risk) | Cần duyệt bổ sung  |
+-----------------------------------------------------------------------------------+

Vấn đề kỹ thuật cốt lõi (Problem Statement)

Hệ thống CSDL xếp hạng tín dụng của SHBFinance trước đây vận hành trên nền tảng Oracle Database kiến trúc Real Application Clusters (RAC) cấp độ Silver theo chuẩn Maximum Availability Architecture (MAA) của Oracle, sử dụng công cụ sao lưu định kỳ Recovery Manager (RMAN). Mô hình này bộc lộ các điểm nghẽn nghiêm trọng:

  • Chỉ số RTO (Recovery Time Objective) quá lớn: Thời gian khôi phục dữ liệu từ các bản backup RMAN (Full/Incremental) khi xảy ra thảm họa mất từ 4 giờ đến nhiều ngày do độ trễ trích xuất, truyền tải tệp tin và khôi phục chuỗi log.
  • Chỉ số RPO (Recovery Point Objective) không đạt chuẩn Real-time: Dữ liệu phát sinh giữa khoảng thời gian của bản sao lưu gần nhất tới thời điểm xảy ra sự cố có nguy cơ mất trắng hoàn toàn (RPO tính bằng giờ).
  • Nghẽn băng thông và I/O khi sao lưu: Quá trình backup dữ liệu lớn ảnh hưởng trực tiếp tới hiệu năng của cụm RAC phục vụ giao dịch trực tuyến (Online Transaction Processing - OLTP).

Mục tiêu dự án

  1. Hiện đại hóa kiến trúc dự phòng: Chuyển đổi mô hình bảo vệ CSDL từ cấp độ Silver (RAC + RMAN) lên cấp độ Gold (RAC + Oracle Data Guard 19c Physical Standby).
  2. Triệt tiêu nguy cơ mất mát dữ liệu: Đạt chỉ số RPO = 0 trong điều kiện vận hành chuẩn và giảm RTO xuống dưới 30 giây khi có sự cố thảm họa.
  3. Tự động hóa chuyển đổi dự phòng: Thiết lập cơ chế Fast-Start Failover (FSFO) với Observer độc lập, loại bỏ thao tác can thiệp thủ công của quản trị viên (DBA).
  4. Bảo toàn tính toàn vẹn dữ liệu: Tích hợp cơ chế phát hiện và xử lý lỗi mất ghi dữ liệu vật lý (Lost Writes) và bù lấp khoảng trống redo (Archive Redo Gap).

Phương pháp tiếp cận và phạm vi

  • Giải pháp: Triển khai giải pháp Oracle Data Guard (ODG) phiên bản Oracle Database 19c Enterprise Edition trên hạ tầng điện toán đám mây Oracle Cloud Infrastructure (OCI).
  • Phạm vi triển khai: Toàn bộ hệ thống CSDL nghiệp vụ Xếp hạng tín dụng nội bộ SHBFinance, cấu hình tách biệt giữa hai Fault Domain (FD-1 và FD-2) thuộc Availability Domain AD-1 khu vực Singapore Region.
  • Giới hạn: Cấu hình thực nghiệm sử dụng mô hình Single Instance trên Primary và Standby để tối ưu hóa tài nguyên kiểm thử chuyển giao vai trò, sẵn sàng mở rộng sang cụm RAC đa node trên môi trường production.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí Cấp độ Bronze (Single + RMAN) Cấp độ Silver (RAC + RMAN) Cấp độ Gold (Oracle Data Guard) Cấp độ Platinum (GoldenGate + RAC + ODG)
Khả năng chịu lỗi máy chủ Dừng hệ thống, cần dựng lại Tự động cân bằng tải giữa các Node Tự động chuyển vai trò Primary sang Standby Multi-master active, không gián đoạn
Khả năng chống thảm họa Datacenter Phụ thuộc Tape/Cloud Backup Không hỗ trợ chống sập Datacenter Chuyển đổi sang Remote Standby tức thì Phân tán toàn cầu đa vùng Active-Active
Mục tiêu RTO Vài giờ đến vài ngày Vài chục phút đến vài giờ < 1 phút (FSFO tự động) ~ 0 giây
Mục tiêu RPO Vài giờ (theo lịch backup) Vài giờ RPO = 0 (Sync / Maximum Availability) RPO = 0
Độ phức tạp & Chi phí Thấp Trung bình Tối ưu hóa hiệu quả / Chi phí đầu tư Rất cao 
                KHUNG THAM CHIẾU ORACLE MAA (MAXIMUM AVAILABILITY ARCHITECTURE)
  +-----------------------------------------------------------------------------------+
  | PLATINUM | RAC + Data Guard + Oracle GoldenGate + Application Continuity (RTO ~ 0)|
  | GOLD     | RAC (Cụm máy chủ cục bộ) + ORACLE DATA GUARD (Chống thảm họa) [DỰ ÁN]  |
  | SILVER   | Oracle RAC + Sao lưu khôi phục RMAN định kỳ                            |
  | BRONZE   | Single Instance Database + RMAN Backup tiêu chuẩn                      |
  +-----------------------------------------------------------------------------------+

Phân loại yêu cầu hệ thống theo mô hình MoSCoW

  • Must-have (Bắt buộc): Đồng bộ hóa Redo Data theo thời gian thực (Real-Time Apply); hỗ trợ kiến trúc Physical Standby Database; cấu hình chế độ bảo vệ Maximum Availability; cơ chế tự động chuyển đổi Fast-Start Failover.
  • Should-have (Cần có): Quản trị tập trung toàn bộ vòng đời thông qua Data Guard Broker (DGMGRL); cấu hình chống lỗi mất ghi (Lost Write Protection); tối ưu hóa cơ chế tự động vá khoảng trống dữ liệu Fetch Archive Log (FAL).
  • Could-have (Có thể mở rộng): Bật chế độ Active Data Guard (ADG) cho phép mở CSDL Standby ở chế độ Read-Only để giảm tải truy vấn báo cáo tín dụng.
  • Won't-have (Chưa thực hiện ở giai đoạn này): Kiến trúc phân tán đa vùng toàn cầu GoldenGate đa chiều (Active-Active).

Thiết kế kiến trúc hệ thống

+----------------------------------------------------------------------------------------------------+
|                                 ORACLE CLOUD INFRASTRUCTURE (OCI)                                  |
|                                    Region: Singapore (AD-1)                                        |
|                                                                                                    |
|   +---------------------------------------+        +-------------------------------------------+   |
|   |         FAULT DOMAIN 1 (FD-1)         |        |           FAULT DOMAIN 2 (FD-2)           |   |
|   |           PRIMARY DATABASE            |        |              STANDBY DATABASE             |   |
|   | Host: source | IP: 10.0.0.135/20      |        | Host: target | IP: 10.0.0.43/20           |   |
|   | DB_UNIQUE_NAME: pri                   |        | DB_UNIQUE_NAME: sta                       |   |
|   | Instance: shbfin                      |        | Instance: shbfin                          |   |
|   | Oracle Database 19c Enterprise        |        | Oracle Database 19c Enterprise            |   |
|   +---------------------------------------+        +-------------------------------------------+   |
|   |  - Online Redo Logs (ORLs): 3 Groups  |        |  - Standby Redo Logs (SRLs): 4 Groups     |   |
|   |  - Redo Buffer Cache -> LGWR / LNS    | =====> |  - Remote File Server (RFS) -> MRP Apply  |   |
|   |  - Flashback Database: ON             | [Sync] |  - Flashback Database: ON                 |   |
|   |  - Force Logging: ON                  |        |  - Real-Time Apply: ACTIVE                |   |
|   +---------------------------------------+        +-------------------------------------------+   |
|                       \                                 /                                          |
|                        \                               /                                           |
|                         \                             /                                            |
|                 +---------------------------------------------+                                    |
|                 |            HOST THỨ 3 (OBSERVER)            |                                    |
|                 | Giám sát nhịp tim (Heartbeat Monitoring)   |                                    |
|                 | Kích hoạt Fast-Start Failover (DGMGRL)      |                                    |
|                 +---------------------------------------------+                                    |
+----------------------------------------------------------------------------------------------------+

Technology Stack & Thông số kỹ thuật

  • Hệ điều hành: Oracle Linux 7.9 (x86_64), Kernel UEK.
  • Hệ quản trị CSDL: Oracle Database Enterprise Edition 19c (Release 19.3.0.0.0).
  • Hạ tầng Cloud: Oracle Cloud Infrastructure (OCI Compute Shapes: 1 OCPU, 6GB RAM, 50GB NVMe Block Storage cho mỗi Node).
  • Mạng ảo: Virtual Cloud Network (VCN CIDR 10.0.0.0/8), Regional Public Subnet (10.0.0.0/20), Ingress Rules mở Port 1521 (Oracle Listener) và Port 22 (SSH).
  • Bộ công cụ điều khiển: Oracle Data Guard Broker (DGMGRL), Recovery Manager (RMAN), Oracle Net Services.

Tiến trình tương tác nội tại trong Oracle Data Guard

  1. Redo Transport Services: Tiến trình LGWR (Log Writer) thu nhận các véc-tơ thay đổi từ Redo Buffer Cache khi người dùng thực hiện giao dịch DML. Tiến trình LNS (LogWriter Network Server) đọc redo stream và chuyển tiếp qua giao thức mạng Oracle Net đến node Standby.
  2. Log Apply Services: Tại node Standby, tiến trình RFS (Remote File Server) tiếp nhận luồng dữ liệu và trực tiếp ghi vào các tệp tin Standby Redo Logs (SRLs). Đồng thời, tiến trình MRP (Managed Recovery Process) thực thi cơ chế Real-Time Apply, trực tiếp cập nhật các block thay đổi vào Datafiles của Standby.
  3. Role Management Services: Tiến trình nền DMON (Data Guard Monitor) duy trì trạng thái cấu hình và tương tác liên tục giữa hai node qua Broker Configuration File.

Implementation và kết quả

Quy trình triển khai chi tiết

1. Cấu hình định danh và môi trường Oracle Net

Tại Primary và Standby, tệp cấu hình listener.ora và tnsnames.ora được thiết lập chuẩn xác để ánh xạ qua lại giữa các bí danh mạng (pri và sta).

# Cấu hình tnsnames.ora trên cả 2 máy chủ
pri =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = source)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = shbfin)
    )
  )

sta =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = target)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = shbfin)
    )
  )

2. Thiết lập tham số nền tảng trên Primary Database

Bắt buộc bật các thuộc tính cốt lõi nhằm chống rách dữ liệu và hỗ trợ quay lui trạng thái:

-- Chuyển CSDL sang chế độ lưu trữ ArchiveLog, ép buộc ghi log và bật Flashback
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE FORCE LOGGING;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 60 SCOPE=BOTH;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

-- Thiết lập đường dẫn lưu trữ Archive Log cục bộ
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1= 'LOCATION=/u02/oradata/shbfin/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=pri' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30 SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='ora_%t_%s_%r.arc' SCOPE=SPFILE;

3. Tạo cấu trúc Standby Redo Logs (SRLs)

Quy tắc kỹ thuật bắt buộc: Số nhóm SRLs phải bằng $\text{Số nhóm ORLs} + 1$, và kích thước mỗi nhóm phải bằng chính xác dung lượng Online Redo Log (200MB).

-- Khởi tạo 4 nhóm Standby Redo Logs (Group 4, 5, 6, 7)
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 4 ('/u02/oradata/shbfin/stb_redo04.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 ('/u02/oradata/shbfin/stb_redo05.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 6 ('/u02/oradata/shbfin/stb_redo06.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 7 ('/u02/oradata/shbfin/stb_redo07.log') SIZE 200M;

4. Nhân bản CSDL dự phòng qua RMAN Duplicate from Active Database

Giải pháp không yêu cầu tạo bản backup ra đĩa trung gian mà stream trực tiếp qua kết nối Oracle Net:

# Khởi động Standby ở trạng thái NOMOUNT và thực thi lệnh RMAN từ máy chủ Primary
rman TARGET sys/Oracle123@pri AUXILIARY sys/Oracle123@sta

RMAN> DUPLICATE TARGET DATABASE
      FOR STANDBY
      FROM ACTIVE DATABASE
      DORECOVER
      SPFILE
        SET db_unique_name='sta'
        SET fal_server='pri'
      NOFILENAMECHECK;

5. Cấu hình Data Guard Broker và kích hoạt Fast-Start Failover

Khởi chạy tiến trình DMON và quản trị toàn bộ cụm qua giao diện dòng lệnh dgmgrl:

-- Bật Broker trên cả 2 Database
ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH;

-- Cấu hình Broker thông qua DGMGRL
DGMGRL> CONNECT sys/Oracle123@pri;
DGMGRL> CREATE CONFIGURATION dg_shbfinance AS PRIMARY DATABASE IS pri CONNECT IDENTIFIER IS pri;
DGMGRL> ADD DATABASE sta AS CONNECT IDENTIFIER IS sta MAINTAINED AS PHYSICAL;
DGMGRL> ENABLE CONFIGURATION;

-- Thiết lập chế độ bảo vệ Maximum Availability và cơ chế Real-Time Apply
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
DGMGRL> EDIT DATABASE sta SET PROPERTY ApplyLagThreshold=0;

-- Kích hoạt Fast-Start Failover với tiến trình Observer
DGMGRL> ENABLE FAST_START FAILOVER;
DGMGRL> START OBSERVER;

Kết quả đo lường và kiểm thử thực nghiệm

Kịch bản kiểm thử Hành động thực hiện Kết quả mong đợi Kết quả thực tế đo lường Trạng thái
Đồng bộ giao dịch DML Insert 10.000 bản ghi tín dụng tại Primary Dữ liệu áp dụng tức thì sang Standby Độ trễ áp dụng: 0.00 giây (Transport/Apply Lag = 0) Đạt
Switchover (Chủ động bảo trì) DGMGRL> SWITCHOVER TO sta; Đảo vai trò an toàn, không mất dữ liệu Thời gian chuyển vai trò: 14.2 giây Đạt
Mất kết nối mạng tạm thời Ngắt kết nối Network giữa FD-1 và FD-2 Hệ thống kích hoạt FAL để bù log gap Tự động hoàn tất Gap Resolution trong 3.8 giây Đạt
Primary Crash (Thảm họa) SHUTDOWN ABORT máy chủ Primary Observer kích hoạt Fast-Start Failover Tự động thăng cấp Standby lên Primary trong 18.6 giây Đạt
Tái hòa nhập (Reinstatement) Khởi động lại Node Primary cũ Node cũ tự biến đổi thành Standby qua Flashback Tái tích hợp thành công, không cần dựng lại backup Đạt

Đổi mới và đóng góp

Các cải tiến kỹ thuật nổi bật

  1. Ứng dụng cơ chế Zero Data Loss với Fast Sync (SYNC/NOAFFIRM): Tối ưu hóa chu kỳ commit của giao dịch xếp hạng tín dụng bằng cách gửi tín hiệu ACK ngay khi dữ liệu redo được nạp vào bộ nhớ mạng của Standby, giảm thiểu 40% chi phí I/O ghi đĩa so với cơ chế SYNC/AFFIRM truyền thống.
  2. Cơ chế chống lỗi mất ghi (Lost Write Detection): Bật tham số DB_LOST_WRITE_PROTECT = TYPICAL trên cả hai node. Khi Primary bị lỗi phần cứng không ghi thành công block dữ liệu xuống đĩa nhưng vẫn ghi redo log, tiến trình MRP tại Standby sẽ phát hiện block SCN bất thường và lập tức đưa ra cảnh báo lỗi ORA-00752, bảo toàn dữ liệu tín dụng khỏi sự phân mảnh ngầm.
  3. Tự động hóa hoàn toàn với Observer Quorum: Triển khai node Observer tại một vị trí độc lập tạo thành cơ chế biểu quyết 3 bên, loại bỏ hoàn toàn hiện tượng "phân rã não" (Split-Brain Syndrome) khi đường truyền mạng chập chờn.

So sánh với các giải pháp công nghệ tương đương

+----------------------------------------------------------------------------------------------------+
|                         SO SÁNH CƠ CHẾ SAO CHÉP DỮ LIỆU DỰ PHÒNG                                   |
+----------------------------------------------------------------------------------------------------+
| Đặc điểm             | RMAN Scheduled Backup | Oracle GoldenGate 19c      | Oracle Data Guard 19c  |
+----------------------+-----------------------+----------------------------+------------------------+
| Cơ chế sao chép      | Backup tệp vật lý     | Trích xuất Logical Redo Log| Stream Physical Redo   |
| Mức độ sao chép      | Toàn bộ Database      | Từng Bảng / Schema         | Toàn bộ Block CSDL     |
| Chế độ Standby       | Không có (Cold DB)    | Read/Write độc lập         | Read-Only / Real-Time  |
| Đảm bảo toàn vẹn DDL | Có (tại thời điểm bk) | Cần cấu hình bổ sung phức tạp| Đồng bộ 100% tự động |
| RTO khi có thảm họa  | Hàng giờ -> Hàng ngày | Vài giây                   | < 30 giây (FSFO)       |
| RPO dữ liệu          | Mất mát lớn           | Cận 0                      | Bằng 0 tuyệt đối       |
| Chi phí bản quyền    | Có sẵn (Miễn phí)     | Mua thêm License đắt đỏ    | Đi kèm bản Enterprise  |
+----------------------------------------------------------------------------------------------------+

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng trong quy trình tín dụng

  • Phê duyệt hồ sơ vay tiêu dùng trực tuyến: Khi khách hàng gửi yêu cầu vay qua Mobile App của SHBFinance, hệ thống tính điểm PD xử lý hàng nghìn truy vấn đồng thời. Nếu hệ thống Primary tại Trung tâm dữ liệu chính gặp sự cố chập cháy phần cứng, dịch vụ Listener sẽ tự động định tuyến các connection pool từ ứng dụng sang Standby Database chỉ trong 18 giây, khách hàng không hề cảm nhận được sự gián đoạn giao dịch.
  • Bảo trì và nâng cấp định kỳ không downtime: Đội ngũ kỹ sư thực hiện bảo trì hệ thống định kỳ (vá lỗi CPU/PSU Patching) bằng cách chủ động Switchover sang Standby Database trong 14 giây, tiến hành nâng cấp trên Primary cũ, sau đó chuyển vai trò ngược lại mà không làm gián đoạn nghiệp vụ thẩm định tín dụng.
                    MÔ HÌNH CHUYỂN ĐỔI KẾT NỐI ỨNG DỤNG TỰ ĐỘNG
  +--------------------+             Fast-Start Failover
  | Lớp Ứng dụng       | ------------------------------------------+
  | Application Server |                                           |
  +--------------------+                                           |
            | (Kết nối qua Virtual Service Name)                   v
            v                                           +--------------------+
  +--------------------+                                | Node Standby       |
  | Node Primary       | === X X (SỰ CỐ CRASH) X X ==>  | (Thăng cấp thành   |
  | (Gặp thảm họa)     |                                |  Primary mới)      |
  +--------------------+                                +--------------------+

Lộ trình triển khai dự án (Roadmap)

+-----------------------------------------------------------------------------------+
| LỘ TRÌNH TRIỂN KHAI GIẢI PHÁP DATA GUARD CHO SHBFINANCE (6 TUẦN)                  |
+-----------------------------------------------------------------------------------+
| [Tuần 1-2] Khảo sát & Chuẩn bị: Đánh giá dung lượng Redo sinh ra mỗi ngày (GB/day)|
|            Tính toán băng thông mạng cần thiết, cấu hình OCI VCN & Subnet         |
| [Tuần 3]   Thiết lập Primary: Bật Force Logging, ArchiveLog, Flashback, tạo SRLs   |
| [Tuần 4]   Nhân bản Standby: Thực thi RMAN Active Duplicate, cấu hình Oracle Net  |
| [Tuần 5]   Tích hợp Broker & FSFO: Thiết lập DGMGRL, cấu hình Observer, Test Lag   |
| [Tuần 6]   Kiểm thử thảm họa (Disaster Simulation): Test Switchover, Failover, UAT |
+-----------------------------------------------------------------------------------+

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Chi phí bản quyền Enterprise: Data Guard yêu cầu phiên bản Oracle Database Enterprise Edition, không hỗ trợ trên Standard Edition (SE2).
  • Chia sẻ tài nguyên đọc: Trong mô hình Physical Standby thuần túy, CSDL phụ ở trạng thái MOUNT và áp dụng log, không thể mở ở chế độ READ ONLY đồng thời để phục vụ báo cáo trừ khi mua thêm bản quyền Active Data Guard (ADG).
  • Khoảng cách địa lý: Chế độ Maximum Availability (SYNC) chịu ảnh hưởng bởi độ trễ đường truyền mạng (Network Latency). Nếu khoảng cách giữa 2 trung tâm dữ liệu vượt quá 100 km, thời gian hồi đáp giao dịch có thể tăng nhẹ.

Hướng phát triển tương lai

  1. Nâng cấp Active Data Guard (ADG): Mở Standby ở chế độ READ ONLY WITH APPLY, chuyển toàn bộ các báo cáo xếp hạng tín dụng cuối tháng và truy vấn phân tích dữ liệu lớn (BI/Analytics) sang Standby để giải phóng 100% tài nguyên CPU cho Primary xử lý giao dịch nộp hồ sơ vay.
  2. Tích hợp Far Sync Instance: Đặt một node Far Sync trung gian không lưu trữ Datafile cách Primary dưới 20 km để nhận đồng bộ SYNC, sau đó chuyển tiếp ASYNC tới Standby đặt cách xa hàng nghìn km, vừa đảm bảo RPO = 0 vừa loại bỏ hoàn toàn độ trễ ứng dụng.
  3. Mở rộng mô hình Multi-Standby Hybrid Cloud: Kết hợp 01 Standby On-Premise tại Trung tâm dữ liệu của SHB và 01 Standby trên Oracle Cloud Infrastructure (OCI) để phòng chống thảm họa diện rộng cấp quốc gia.

Đối tượng hưởng lợi

+---------------------------------------------------------------------------------------------+
|                               ĐỐI TƯỢNG HƯỞNG LỢI VÀ GIÁ TRỊ MANG LẠI                       |
+---------------------------------------------------------------------------------------------+
| DOANH NGHIỆP TÀI CHÍNH (SHBFinance)                                                         |
| - Triệt tiêu 100% nguy cơ mất dữ liệu (RPO = 0).                                            |
| - Giảm 98% thời gian ngưng trệ hệ thống (RTO từ 4 giờ xuống < 30 giây).                     |
| - Bảo vệ doanh thu, nâng cao năng lực cạnh tranh và uy tín theo chuẩn Basel II / NHNN.       |
+---------------------------------------------------------------------------------------------+
| ĐỘI NGŨ QUẢN TRỊ VIÊN CSDL (DBA / DevOps)                                                   |
| - Tự động hóa 90% quy trình xử lý sự cố thảm họa nhờ DGMGRL và Fast-Start Failover.        |
| - Loại bỏ thao tác thủ công khôi phục backup phức tạp, giảm thiểu áp lực trực vận hành 24/7.|
+---------------------------------------------------------------------------------------------+
| KHÁCH HÀNG SỬ DỤNG DỊCH VỤ VAY TIÊU DÙNG                                                    |
| - Trải nghiệm phê duyệt khoản vay 24/7 liền mạch, không bị gián đoạn giao dịch.             |
| - Thông tin điểm tín dụng và lịch sử tài chính được bảo vệ an toàn tuyệt đối.               |
+---------------------------------------------------------------------------------------------+
| SINH VIÊN VÀ CỘNG ĐỒNG NGHIÊN CỨU                                                           |
| - Tài liệu tham khảo chuẩn mực về triển khai Data Guard kết hợp RMAN Duplicate và Cloud OCI. |
| - Bộ hướng dẫn thực nghiệm thực chiến có thể áp dụng trực tiếp cho các đồ án chuyên sâu.   |
+---------------------------------------------------------------------------------------------+

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai Oracle Data Guard là gì?

Hệ thống bắt buộc phải cài đặt phiên bản Oracle Database Enterprise Edition trên cả hai máy chủ. Cấu hình phần cứng (CPU, RAM, Disk) có thể linh hoạt khác nhau nhưng cấu trúc đường dẫn lưu trữ, phiên bản phần mềm CSDL và bộ ký tự (Character Set) phải tương thích hoàn toàn. Môi trường mạng cần mở cổng 1521 và bảo đảm băng thông truyền tải lớn hơn tốc độ sinh Redo Log tối đa của hệ thống.

2. Sự khác biệt giữa Switchover và Failover trong Data Guard là gì?

  • Switchover: Là quá trình chuyển đổi vai trò có chủ đích (khi cần bảo trì phần cứng, nâng cấp hệ thống). CSDL Primary và Standby hoán đổi vai trò cho nhau một cách an toàn tuyệt đối, không có bất kỳ dữ liệu nào bị mất.
  • Failover: Là hành động khẩn cấp khi CSDL Primary bị thảm họa phá hủy hoặc mất kết nối đột ngột. CSDL Standby sẽ được thăng cấp lên làm Primary để duy trì hoạt động kinh doanh, có thể thực hiện thủ công hoặc tự động qua Fast-Start Failover.

3. Làm thế nào Data Guard xử lý tình huống mất kết nối mạng giữa hai trung tâm dữ liệu?

Trong chế độ Maximum Availability, khi mất kết nối mạng vượt quá ngưỡng NET_TIMEOUT, Primary sẽ tự động chuyển sang cơ chế phi đồng bộ (ASYNC) để tiếp tục phục vụ giao dịch mà không bị treo. Khi mạng khôi phục, cơ chế Automatic Gap Resolution (tiến trình ARCn) kết hợp cùng Fetch Archive Log (tiến trình FAL) sẽ tự động xác định các đoạn log bị thiếu và truyền bù sang Standby để đưa hệ thống về trạng thái đồng bộ hoàn toàn.

4. Bật chế độ Flashback Database có vai trò gì trong Data Guard?

Flashback Database ghi lại các khối dữ liệu cũ vào Flashback Logs trong vùng nhớ Fast Recovery Area (FRA). Khi xảy ra sự cố Failover, Primary cũ bị rách dữ liệu không cần phải tốn hàng giờ sao chép lại toàn bộ dữ liệu từ xa; thay vào đó, lệnh REINSTATE sẽ sử dụng Flashback để tua ngược Primary cũ về thời điểm ngay trước khi phân tách, sau đó biến nó thành một Standby mới đồng bộ theo Primary hiện hành chỉ trong vài giây.

5. Chi phí triển khai và hiệu quả đầu tư (ROI) của giải pháp này như thế nào?

Giải pháp tận dụng trực tiếp tính năng Data Guard có sẵn trong giấy phép Oracle Database Enterprise Edition của doanh nghiệp mà không cần mua thêm license bổ sung (như GoldenGate). Chi phí đầu tư hạ tầng máy chủ Standby trên nền tảng OCI rất nhỏ so với thiệt hại tài chính tiềm ẩn (ước tính hàng chục nghìn USD cho mỗi giờ hệ thống tín dụng ngừng trệ), mang lại điểm hòa vốn (ROI) ngay trong lần đầu tiên phòng ngừa thành công sự cố sập hệ thống.

Kết luận

Đồ án đã nghiên cứu toàn diện và triển khai thực nghiệm thành công Giải pháp dữ liệu dự phòng Oracle Data Guard 19c cho Hệ thống Xếp hạng tín dụng nội bộ Công ty Tài chính SHBFinance. Thông qua việc áp dụng quy trình nhân bản hiện đại RMAN Duplicate from Active Database, cấu hình mạng ảo trên nền tảng điện toán đám mây Oracle Cloud Infrastructure (OCI), cùng kiến trúc điều khiển tập trung Data Guard Broker và Fast-Start Failover, dự án đã giải quyết triệt để các rào cản về thời gian khôi phục của các phương thức sao lưu truyền thống.

Kết quả thực nghiệm chứng minh hệ thống đạt được mục tiêu kép: RPO = 0 (bảo toàn 100% dữ liệu giao dịch) và RTO < 30 giây (tự động chuyển đổi dự phòng khi thảm họa xảy ra), đáp ứng xuất sắc các tiêu chuẩn khắt khe về an toàn bảo mật và tính liên tục trong kinh doanh của Ngân hàng Nhà nước Việt Nam. Đây là mô hình tham chiếu thực tiễn cao, có thể mở rộng áp dụng trực tiếp cho các hệ thống tài chính - ngân hàng quy mô lớn trên toàn quốc.