OceanBase là CSDL phân tán native đã được kiểm chứng ở quy mô rất lớn (100% core Alipay, billing China Mobile Sơn Đông 13 tỷ CDR/ngày). Tuy nhiên, tại Việt Nam chưa có hệ thống production nào được công bố; mốc duy nhất là MOU với MB Bank ngày 02/10/2026. Khuyến nghị: áp dụng cho dự án mới và hệ thống rủi ro thấp (lịch sử cước, hợp nhất DB, ODS) trước; chỉ xem xét Billing/CRM lõi sau 12–18 tháng vận hành ổn định và PoC tải thật đạt chuẩn. Giữ OCS/Charging thời gian thực trên nền tảng hiện tại.

Mục lục

2. Vì sao chọn OceanBase thay vì Oracle, PostgreSQL, MySQL, MongoDB. 2

2.1 Năm khác biệt kiến trúc cốt lõi
2.2 Bảng so sánh
2.3 Khi nào KHÔNG nên dùng OceanBase

3. Case study trên thế giới và tại Việt Nam.. 3

3.1 Viễn thông
3.2 Tài chính, năng lượng, hàng không (bài toán tương tự viễn thông)
3.3 Đối chiếu với các nghiệp vụ viễn thông Việt Nam
3.4 Việt Nam

4. Nên áp dụng OceanBase như thế nào. 4

4.1 Mức độ phù hợp theo loại dự án
4.2 Nguyên tắc kiến trúc khi triển khai

5. Migration từ Oracle/PostgreSQL sang OceanBase. 5

5.1 Công cụ
5.2 Quy trình 7 bước
5.3 Ước lượng thời gian theo dung lượng
5.4 Truy vấn khảo sát Oracle nguồn
5.5 Tiêu chí go/no-go trước cutover

6. Rủi ro và câu hỏi cần hỏi vendor 7

Nguồn tham khảo

1. Lịch sử hình thành

OceanBase ra đời năm 2010 tại Taobao (Alibaba) do TS. Dương Chấn Khôn (Yang Zhenkun) khởi xướng. Sản phẩm trưởng thành qua bài toán thay Oracle ở Alipay, tách thành công ty độc lập năm 2020 và mở mã nguồn năm 2021. Hệ thống được thiết kế từ đầu như một CSDL quan hệ phân tán native, không phải lớp sharding đặt trên MySQL hay PostgreSQL.

Năm	Mốc	Ý nghĩa
2026	Mở trung tâm hỗ trợ toàn cầu tại Kuala Lumpur; ký MOU với MB Bank (02/10/2026)	Đẩy mạnh Đông Nam Á, lần đầu có đối tác ngân hàng lớn tại Việt Nam
2024	Ra mắt bản 4.3: columnar engine, vectorized execution	Tăng năng lực HTAP và OLAP
2022–2023	Bản 4.0/4.1: kiến trúc tích hợp đơn máy – phân tán (Paetica)	Chạy được cả quy mô nhỏ lẫn cụm lớn bằng một sản phẩm
2021	Mở mã nguồn (01/06/2021)	Có bản Community, hình thành hệ sinh thái
2020	Tách thành công ty độc lập; đạt 707 triệu tpmC TPC-C	Kỷ lục TPC-C trên cụm hơn 1.500 node
2019	Đứng đầu bảng TPC-C, vượt Oracle	Lần đầu được giới chuyên môn quốc tế công nhận
2018	Bản 2.0 có chế độ tương thích Oracle	Điều kiện để migrate hệ thống Oracle
2017	Bắt đầu phục vụ khách hàng bên ngoài, đầu tiên là Ngân hàng Nam Kinh	Thương mại hóa
2016	Bản 1.0 kiến trúc mới; 100% core DB Alipay chạy OceanBase trong Double 11 (giao dịch, thanh toán, hội viên, kế toán)	Khẳng định chất lượng financial-grade
2014	Alipay giao 1% lưu lượng giao dịch Double 11 để thử nghiệm	Bước ngoặt: bắt đầu thay Oracle
2013	Alipay quyết định bỏ Oracle; MySQL không đảm bảo nhất quán mạnh giữa primary và standby	OceanBase có cơ hội đầu tiên
2012	Hỗ trợ SQL	Trở thành RDBMS đa dụng
2010	Khởi động dự án, ứng dụng đầu tiên là Taobao Favorites	Ra đời

Quy mô hiện tại: đến 2026, OceanBase phục vụ hơn 4.000 khách hàng, trong đó hơn 400 tổ chức tài chính và hơn 60% dùng cho hệ thống mission-critical.

2. Vì sao chọn OceanBase thay vì Oracle, PostgreSQL, MySQL, MongoDB

OceanBase chỉ đáng chọn khi bài toán cần đồng thời bốn thứ: mở rộng ngang không giới hạn, nhất quán mạnh ACID, RPO=0 đa trung tâm dữ liệu và tương thích SQL/PL-SQL với Oracle hoặc MySQL. Nếu hệ thống vừa vặn trong một cụm Oracle RAC hay một PostgreSQL có replica, OceanBase thường không mang lại lợi ích đủ lớn để bù chi phí chuyển đổi.

2.1 Năm khác biệt kiến trúc cốt lõi

1. Shared-nothing native. Mỗi node có SQL engine, transaction engine và storage engine riêng, không có single point of failure. Cụm có thể vượt 1.500 node, hơn 3 PB dữ liệu và bảng nghìn tỷ dòng.

2. Paxos + 2PC tích hợp. Log giao dịch được nhân bản qua Paxos tới nhiều bản sao. Giao dịch phân tán chỉ tốn một lần đồng bộ Paxos, nên RPO=0 và RTO < 30 giây ở cấp trung tâm dữ liệu.

3. Storage LSM-Tree nén cao. Dữ liệu chia thành baseline (SSTable, nén cột) và incremental (MemTable). Thực tế khách hàng báo tiết kiệm storage đáng kể, ví dụ Xiaomi giảm 42% storage và 50% server so với hệ thống cũ.

4. Multi-tenant. Một cụm chứa nhiều tenant cách ly tài nguyên, mỗi tenant chọn chế độ Oracle hoặc MySQL. Phù hợp hợp nhất (consolidation) hàng chục DB nhỏ.

5. HTAP một engine. Từ bản 4.3, row store và column store cùng tồn tại trên một node, có vectorized execution, phục vụ báo cáo thời gian thực mà không phải ETL sang DWH.

2.2 Bảng so sánh

Tiêu chí	OceanBase	Oracle (RAC/Exadata)	PostgreSQL	MySQL	MongoDB
Kiến trúc	Shared-nothing phân tán native	Shared-disk, scale-up là chính	Đơn máy + replica; phân tán cần Citus	Đơn máy + replica; phân tán cần Vitess/sharding	Document, sharding native
Mở rộng ghi	Ngang, online	Giới hạn bởi cụm RAC và storage chung	Dọc; ngang qua extension	Dọc; ngang qua sharding ứng dụng	Ngang
Nhất quán / RPO đa DC	Mạnh, RPO=0 qua Paxos	RPO=0 cần Data Guard đồng bộ, ảnh hưởng latency	Async mặc định; sync giảm hiệu năng	Semi-sync, có rủi ro mất dữ liệu	Có majority write, giao dịch đa document hạn chế hơn RDBMS
Tương thích Oracle PL/SQL	Cao (chế độ Oracle), không 100%	Gốc	Thấp, phải viết lại	Không	Không
HTAP	Có, một engine	Có (In-Memory option, trả phí)	Hạn chế	Hạn chế	Hạn chế
Chi phí license	Thấp hơn Oracle; có bản Community miễn phí	Rất cao (EE + RAC + options)	Miễn phí	Miễn phí	Community miễn phí; Enterprise trả phí
Hệ sinh thái, nhân lực tại VN	Rất mỏng	Rất dày	Khá	Dày	Khá
Độ chín công cụ vận hành	OCP, OMS, OMA; đang hoàn thiện	Rất chín (AWR, RMAN, GoldenGate, OEM)	Tốt	Tốt	Tốt

2.3 Khi nào KHÔNG nên dùng OceanBase

• DB dưới vài TB, tải vừa phải, một cụm Oracle RAC hoặc PostgreSQL đáp ứng được.

• Ứng dụng dùng sâu tính năng đặc thù Oracle: AQ, Spatial, Oracle Text, XML DB, Exadata Smart Scan, Edition-Based Redefinition, hoặc package hệ thống như DBMS_PIPE.

• Workload document/JSON thuần, schema thay đổi liên tục: MongoDB phù hợp hơn.

• Không có đội ngũ được đào tạo và không có hợp đồng hỗ trợ cấp vendor với SLA tại Việt Nam.

• Hệ thống thuộc danh mục hệ thống thông tin quan trọng về an ninh quốc gia mà chính sách chưa cho phép công nghệ từ nhà cung cấp nước ngoài này.

3. Case study trên thế giới và tại Việt Nam

Tham chiếu viễn thông mạnh nhất đều ở Trung Quốc: China Mobile Sơn Đông (billing 13 tỷ CDR/ngày) và Giang Tô (CRM, core 3 IDC). Tại Việt Nam, đến 23/10/2026 chưa có hệ thống production nào được công bố; mốc duy nhất là MOU với MB Bank ký ngày 02/10/2026.

3.1 Viễn thông

Khách hàng	Hệ thống	Quy mô / kết quả công bố
China Mobile Sơn Đông	Billing lõi, CRM/BOSS	13 tỷ bản ghi CDR/ngày; CRM/BOSS QPS > 20.000, TPS > 100.000, gần 10 TB; 3 IDC, RPO=0, không cần hệ DR riêng; PL/SQL từ Oracle chỉ sửa nhỏ, cutover trong 1 giờ
China Mobile Giang Tô	Core system, CRM	Hơn 60 triệu thuê bao; core DB trên 3 IDC (Vô Tích, Nam Kinh), 3 bản sao, thay minicomputer HP; CRM 10 TB từ DB nước ngoài chỉ còn 1,5 TB (giảm hơn 80%)
China Mobile (toàn tập đoàn)	Nhiều hệ thống tỉnh	Phục vụ khoảng 1/3 công ty tỉnh, gần 600 triệu thuê bao
China Unicom	Nhiều hệ thống lõi	Hơn 1.000 node, 300 hệ thống lõi
China Mobile Chiết Giang	Chưa công bố chi tiết hệ thống	Có trong danh sách khách hàng enterprise từ 2021

Đối chiếu: hệ thống đối soát liên mạng tập trung của China Mobile (40–50 tỷ bản ghi/tháng, phục vụ 31 tỉnh) lại chạy trên Kingbase, không phải OceanBase. Nghĩa là tại Trung Quốc, các nhà mạng dùng nhiều DB nội địa khác nhau cho từng mảng.

3.2 Tài chính, năng lượng, hàng không (bài toán tương tự viễn thông)

Khách hàng	Hệ thống	Kết quả công bố
Alipay	Giao dịch, thanh toán, tài khoản, kế toán	100% core DB từ 2016; đỉnh 61 triệu QPS dịp Double 11 2019
MYbank	Core banking	Triển khai 3 vùng 5 trung tâm, active geo-redundancy Hàng Châu – Thượng Hải
Ngân hàng Nam Kinh	Core Internet banking	Từ dưới 100.000 lên trên 1 triệu giao dịch/ngày; chi phí giảm từ 30–50 xuống 4 NDT/tài khoản
Sinopec	Thẻ nhiên liệu trả trước	Gộp 23 DB Oracle/Sybase thành 1 cụm; 30.000 cây xăng; storage giảm 8 lần; đẩy giao dịch từ gần 1 ngày xuống vài giây
China Insurance	Core bảo hiểm xe, 29 tỉnh	Hơn 100 hệ thống; RPO=0, RTO < 30s; SQL gần như không phải sửa
Zhongyuan Bank	30+ hệ thống từ Oracle RAC	Hơn 70 bài test trước khi chọn; hệ thống phụ thuộc sâu Oracle phải viết lại nhiều SQL
GCash (Philippines), DANA (Indonesia), TNG Digital (Malaysia)	Core ví điện tử	GCash chuyển core giao dịch và thanh toán; DANA gần 200 triệu người dùng, 3 zone

3.3 Đối chiếu với các nghiệp vụ viễn thông Việt Nam

Không có công bố nào đi đúng tới từng nghiệp vụ như báo đỏ hay thẻ cào. Bảng dưới đây ánh xạ nghiệp vụ sang bằng chứng gần nhất và mức độ tin cậy.

Nghiệp vụ	Bằng chứng gần nhất	Mức bằng chứng
Quản lý thông tin khách hàng (CRM, hồ sơ thuê bao)	CRM Giang Tô, CRM/BOSS Sơn Đông	Mạnh
Tính cước, khóa sổ cước tháng	Billing Sơn Đông 13 tỷ CDR/ngày	Mạnh (một nhà mạng, nguồn vendor)
Quản lý công nợ, thu cước	Tài khoản, kế toán Alipay; core banking MYbank, Nam Kinh	Trung bình (tương đồng nghiệp vụ, khác ngành)
Báo đỏ, chặn cắt mở theo nợ	Chưa có công bố; bản chất là batch quét công nợ + tích hợp provisioning	Yếu
Thẻ cào, nạp tiền trả trước	Thẻ nhiên liệu Sinopec; ví điện tử GCash, DANA	Trung bình
Đối soát cước liên mạng, đối tác	Chưa có công bố OceanBase; China Mobile dùng Kingbase	Yếu
Big data, DWH, báo cáo	HTAP 4.3, columnar; chưa có case DWH viễn thông quy mô PB	Yếu đến trung bình

3.4 Việt Nam

• Cộng đồng: buổi meetup developer offline đầu tiên tại Hà Nội ngày 22/09/2026.

• Viễn thông (Viettel, VNPT, MobiFone): không tìm thấy công bố triển khai nào.

Lưu ý: hầu hết số liệu ở trên do OceanBase hoặc khách hàng tự công bố, chưa có kiểm toán độc lập. Đánh giá độc lập gần nhất là Gartner Peer Insights 2025, 4,8/5 trên 62 đánh giá từ ngân hàng, viễn thông và CNTT.

4. Nên áp dụng OceanBase như thế nào

Nên đưa OceanBase vào dự án mới hoặc hệ thống rủi ro thấp trước, để đội ngũ tích lũy 12–18 tháng kinh nghiệm vận hành, rồi mới tính đến Billing/CRM lõi. Không bắt đầu bằng OCS/Charging thời gian thực.

Ma trận chọn hệ thống áp dụng OceanBase

Góc dưới phải là nơi OceanBase phát huy thế mạnh (nén, multi-tenant, HTAP, mở rộng ngang) mà nếu có sự cố thì không làm gián đoạn doanh thu.

4.1 Mức độ phù hợp theo loại dự án

Loại hệ thống	Mức phù hợp	Chế độ tenant gợi ý	Điểm thiết kế bắt buộc
Lịch sử cước, tra cứu CDR	Rất phù hợp	Oracle hoặc MySQL	Partition theo tháng cước + hash theo thuê bao; tận dụng nén để giảm storage
Hợp nhất nhiều DB nhỏ (consolidation)	Rất phù hợp	Mỗi ứng dụng một tenant	Định mức CPU/memory theo tenant (unit config), tách tenant quan trọng
Dự án mới microservice (Order, Product Catalog, Customer theo TMF)	Phù hợp	MySQL	Mỗi domain một tenant hoặc database; tránh giao dịch xuyên service
ODS, báo cáo vận hành thời gian thực	Phù hợp	Cùng tenant hoặc read replica	Dùng columnar store bản 4.3+, tách tài nguyên OLAP khỏi OLTP
CRM, quản lý khách hàng	Phù hợp, cần PoC	Oracle (khi migrate)	Partition key = subscriber/customer id; table group cho các bảng hay join
Tính cước batch, khóa sổ cước tháng	Có điều kiện	Oracle	Test trọn chu kỳ khóa sổ; tránh UPDATE hàng loạt gây áp lực memstore; chia batch theo partition
Quản lý công nợ, báo đỏ	Có điều kiện	Oracle	Job quét nợ chạy song song theo partition; tích hợp provisioning cần idempotent
Thẻ cào, nạp tiền	Có điều kiện	Oracle hoặc MySQL	Xử lý hotspot (cùng serial, cùng số dư); khóa lạc quan + idempotency key
Đối soát cước	Có điều kiện	Oracle	Hưởng lợi từ HTAP, nhưng logic PL/SQL phức tạp cần đánh giá kỹ bằng OMA
OCS / Charging thời gian thực	Không khuyến nghị giai đoạn đầu	Không áp dụng	Yêu cầu latency rất thấp và ổn định; giữ nền tảng chuyên dụng hiện tại
DWH, Big data quy mô PB	Không phải lựa chọn chính	Không áp dụng	Dùng nền tảng chuyên OLAP/lakehouse; OceanBase chỉ làm ODS

4.2 Nguyên tắc kiến trúc khi triển khai

1. Topology: tối thiểu 3 zone. Với nhà mạng có 2 DC cùng thành phố + 1 DC khác vùng, đặt 2 bản sao ở 2 DC chính và 1 bản sao (hoặc arbitration) ở DC thứ ba để đạt RPO=0 khi mất một DC.

2. Thiết kế dữ liệu: chọn partition key theo truy cập chính, gom bảng hay join vào cùng table group để giảm giao dịch phân tán.

3. Tài nguyên: tách tenant OLTP và báo cáo; giới hạn bằng resource unit, không để báo cáo nặng ăn tài nguyên giao dịch.

4. Vận hành: dùng OCP để giám sát, backup vật lý và log archive lên object storage; diễn tập kill zone định kỳ hằng quý.

5. Phiên bản: chỉ dùng bản LTS vendor cam kết hỗ trợ dài hạn; khóa phiên bản trong hợp đồng.

6. Nhân lực: tối thiểu 4–6 DBA đạt chứng chỉ OceanBase trước go-live; giữ đội Oracle song song suốt giai đoạn chuyển đổi.

5. Migration từ Oracle/PostgreSQL sang OceanBase

Chuyển dữ liệu chỉ mất vài giờ đến vài ngày; phần tốn thời gian là đánh giá và sửa ứng dụng. Ước lượng tổng dự án: khoảng 3–4 tháng cho 1 TB, 5–7 tháng cho 5 TB, 7–10 tháng cho 10 TB, với downtime cutover từ vài phút đến khoảng 1 giờ nếu dùng đồng bộ tăng lượng.

5.1 Công cụ

Công cụ	Vai trò
OMA (Migration Assessment)	Quét schema, SQL, PL/SQL nguồn; báo cáo tỷ lệ tương thích và đề xuất chuyển đổi; replay tải để đánh giá hiệu năng
OMS (Migration Service)	Schema migration, full migration, đồng bộ tăng lượng DML/DDL, full verification, reverse increment để rollback
OCP (Cloud Platform)	Triển khai, giám sát, backup/restore cụm đích
obloader / obdumper, DataX	Nạp hoặc xuất offline qua file CSV/SQL khi không cần online

Lưu ý chế độ đích: Oracle phải sang tenant chế độ Oracle; theo tài liệu dịch vụ trên Alibaba Cloud, Oracle sang tenant MySQL không được hỗ trợ. PostgreSQL thường sang tenant MySQL; bản OMS Community có hỗ trợ nguồn PostgreSQL, nhưng PL/pgSQL, kiểu dữ liệu đặc thù (array, jsonb, range) và extension phải viết lại.

5.2 Quy trình 7 bước

1. Khảo sát nguồn (2–4 tuần): kiểm kê object, dung lượng, tính năng Oracle đặc thù, giao diện ra vào (DB link, GoldenGate, ETL). Truy vấn mẫu ở mục 5.4.

2. Đánh giá OMA (2–4 tuần): chạy OMA trên schema và SQL lấy từ AWR/V$SQL; phân loại object tự chuyển được, cần sửa, phải viết lại.

3. Thiết kế đích (2–4 tuần): chọn partition key, table group, sizing tenant, topology 3 zone.

4. Sửa ứng dụng (1–6 tháng): sửa PL/SQL, SQL, driver; đây là bước quyết định tiến độ.

5. Chuyển dữ liệu: OMS chạy schema → full → đồng bộ tăng lượng liên tục, ứng dụng vẫn chạy trên Oracle.

6. Kiểm thử và chạy song song (4–8 tuần): full verification của OMS, đối soát nghiệp vụ (tổng cước, số dư, công nợ theo kỳ), replay tải, ít nhất một chu kỳ khóa sổ cước thật.

7. Cutover và rollback: dừng ghi nguồn, chờ tăng lượng bằng 0, chuyển kết nối; bật reverse increment để Oracle luôn đồng bộ ngược, sẵn sàng quay lại trong thời gian bảo hành.

5.3 Ước lượng thời gian theo dung lượng

Cơ sở tính: OMS công bố tốc độ full migration khoảng 100 MB/s mỗi tác vụ, tức khoảng 0,35 TB/giờ. Thực tế cộng thêm tạo index, LOB và giới hạn mạng, nên nhân hệ số 1,5–2; có thể chạy song song nhiều tác vụ theo nhóm bảng.

Dung lượng nguồn	Full load (1 tác vụ)	Full load (song song 3–4 tác vụ)	Full verification	Tổng dự án (gồm sửa ứng dụng, kiểm thử)	Downtime cutover
1 TB	4–6 giờ	1,5–2 giờ	2–4 giờ	3–4 tháng	5–30 phút
5 TB	20–30 giờ	6–10 giờ	8–16 giờ	5–7 tháng	15–60 phút
10 TB	40–60 giờ	12–20 giờ	16–30 giờ	7–10 tháng	30–60 phút

Đây là ước lượng kỹ thuật, không phải cam kết vendor. Ba yếu tố có thể làm lệch đáng kể: số lượng và độ phức tạp PL/SQL, tỷ lệ LOB, và băng thông giữa hai DC. Khi nạp nhanh khối lượng lớn, memstore của OceanBase có thể đầy nhanh hơn tốc độ compaction, cần giới hạn tốc độ ghi hoặc tăng memory tenant. Dung lượng đích thường nhỏ hơn nhiều nhờ nén; ví dụ CRM Giang Tô 10 TB chỉ còn 1,5 TB.

5.4 Truy vấn khảo sát Oracle nguồn

-- 1. Dung lượng theo schema (bỏ schema hệ thống)
SELECT owner, ROUND(SUM(bytes)/1024/1024/1024, 1) AS size_gb
FROM   dba_segments
WHERE owner NOT IN ('SYS','SYSTEM','SYSAUX','XDB','MDSYS','CTXSYS',
                     'ORDSYS','WMSYS','OUTLN','DBSNMP','AUDSYS')
GROUP BY owner
ORDER BY size_gb DESC;

-- 2. Số object theo loại
SELECT owner, object_type, COUNT(*) AS cnt
FROM   dba_objects
WHERE owner IN (:app_schemas)
GROUP BY owner, object_type
ORDER BY owner, cnt DESC;

-- 3. Khối lượng code PL/SQL (số dòng)
SELECT owner, type, COUNT(DISTINCT name) AS objects, COUNT(*) AS lines
FROM   dba_source
WHERE owner IN (:app_schemas)
GROUP BY owner, type
ORDER BY lines DESC;

-- 4. Phụ thuộc vào package hệ thống rủi ro cao
SELECT referenced_name, COUNT(*) AS cnt
FROM   dba_dependencies
WHERE owner IN (:app_schemas)
AND    referenced_owner = 'SYS'
AND    referenced_name IN ('DBMS_AQ','DBMS_AQADM','DBMS_PIPE','DBMS_ALERT',
                           'UTL_FILE','UTL_HTTP','UTL_SMTP','DBMS_SCHEDULER',
                           'DBMS_JOB','DBMS_SQL','DBMS_LOB','DBMS_CRYPTO',
                           'DBMS_XMLGEN')
GROUP BY referenced_name
ORDER BY cnt DESC;

-- 5. DB link và hàng đợi AQ
SELECT owner, db_link, host FROM dba_db_links;
SELECT owner, name, queue_table FROM dba_queues WHERE owner IN (:app_schemas);

-- 6. Bảng không có primary key (ảnh hưởng đồng bộ tăng lượng)
SELECT t.owner, t.table_name, t.num_rows
FROM   dba_tables t
WHERE t.owner IN (:app_schemas)
AND    NOT EXISTS (SELECT 1 FROM dba_constraints c
                   WHERE c.owner = t.owner AND c.table_name = t.table_name
                   AND c.constraint_type = 'P')
ORDER BY t.num_rows DESC NULLS LAST;

-- 7. Dung lượng LOB
SELECT l.owner, l.table_name, l.column_name,
       ROUND(SUM(s.bytes)/1024/1024/1024, 1) AS lob_gb
FROM   dba_lobs l JOIN dba_segments s
       ON s.owner = l.owner AND s.segment_name = l.segment_name
WHERE l.owner IN (:app_schemas)
GROUP BY l.owner, l.table_name, l.column_name
ORDER BY lob_gb DESC;

-- 8. Tốc độ sinh redo (định cỡ đồng bộ tăng lượng)
SELECT TRUNC(first_time, 'HH24') AS hour,
       ROUND(SUM(blocks*block_size)/1024/1024/1024, 1) AS redo_gb
FROM   v$archived_log
WHERE first_time > SYSDATE - 7 AND dest_id = 1
GROUP BY TRUNC(first_time, 'HH24')
ORDER BY redo_gb DESC FETCH FIRST 24 ROWS ONLY;

5.5 Tiêu chí go/no-go trước cutover

• ☐ OMS full verification: 0 bản ghi lệch trên toàn bộ bảng.

• ☐ Đối soát nghiệp vụ: tổng cước, số dư, công nợ theo kỳ khớp 100% giữa hai hệ thống.

• ☐ Hiệu năng: TPS ≥ hệ thống cũ; P99 latency tăng không quá 20% trên tải replay.

• ☐ Chạy trọn ít nhất một chu kỳ khóa sổ cước tháng trên OceanBase song song.

• ☐ Diễn tập mất một zone: RPO = 0, RTO < 30 giây, ứng dụng tự kết nối lại.

• ☐ Reverse increment về Oracle đã bật và đã thử quay lại thành công.

• ☐ Runbook vận hành, backup/restore đã diễn tập; DBA trực 24/7 có chứng chỉ.

6. Rủi ro và câu hỏi cần hỏi vendor

Rủi ro lớn nhất không nằm ở kỹ thuật mà ở thiếu tham chiếu trong nước, thiếu nhân lực và chính sách cho hệ thống thông tin quan trọng.

Rủi ro	Mức	Biện pháp
Chưa có case production tại Việt Nam	Cao	Bắt đầu ở hệ thống rủi ro thấp; yêu cầu reference visit tại nhà mạng Trung Quốc hoặc ví điện tử ASEAN
Chính sách, chủ quyền công nghệ với hệ thống thông tin quan trọng	Cao	Xin ý kiến cơ quan chủ quản trước PoC; đánh giá điều khoản truy cập từ xa, cập nhật, mã nguồn ký quỹ
Tương thích PL/SQL không 100%	Trung bình–cao	Chạy OMA trên code thật trước khi ký hợp đồng; đưa tỷ lệ tương thích vào điều khoản nghiệm thu
Nhân lực vận hành mỏng	Cao	Đào tạo và chứng chỉ trước go-live; hợp đồng hỗ trợ 24/7 có kỹ sư onsite
Hỗ trợ vendor ở xa (trung tâm Kuala Lumpur)	Trung bình	SLA phản hồi P1 bằng văn bản; đối tác triển khai trong nước
Hotspot, giao dịch phân tán làm giảm hiệu năng	Trung bình	Thiết kế partition, table group từ đầu; replay tải thật
Hệ sinh thái downstream (CDC, ETL, BI)	Trung bình	Kiểm tra kết nối OMS/Flink CDC tới Kafka, DWH hiện có trong PoC

Câu hỏi bắt buộc gửi vendor:

1. Danh sách khách hàng viễn thông đang chạy billing/CRM production: tên hệ thống, ngày go-live, TPS đỉnh, dung lượng, số sự cố P1 trong 12 tháng.

2. Kết quả OMA trên schema và SQL thật của đơn vị: tỷ lệ object, PL/SQL chuyển tự động.

3. Phiên bản LTS đề xuất, thời gian hỗ trợ, chính sách nâng cấp.

4. SLA hỗ trợ tại Việt Nam: thời gian phản hồi P1, kỹ sư onsite, đối tác triển khai.

5. Mô hình license (theo core, theo tenant), tổng chi phí 5 năm so với Oracle hiện tại.

6. Cam kết bảo mật: luồng telemetry, truy cập từ xa, ký quỹ mã nguồn, kiểm định an ninh.

Nguồn tham khảo

• OceanBase – Milestones

• OceanBase – About

• dbdb.io – OceanBase

• OceanBase blog – origin story

• VLDB 2022 – OceanBase: A 707 Million tpmC Distributed Relational Database

• VLDB 2023 – Paetica integrated architecture

• OceanBase 4.3 release

• Alibaba Cloud – OceanBase architecture

• Xiaomi – OceanBase

• China Mobile Shandong

• China Mobile Jiangsu

• AIBase – OceanBase in telecom

• Business Wire 2021 – OceanBase enterprise customers

• Kingbase – China Mobile inter-network billing

• Sinopec fuel card

• Zhongyuan Bank

• Alibaba Cloud – Customer use cases

• PEdaily – China Insurance

• OceanBase INFINITY Jakarta 2024

• The Asian Banker – Malaysia support center 2026

• TechNode – OceanBase & MB Bank MOU

• LinkedIn – Vietnam OBsession #1

• TechNode – Gartner Peer Insights 2025

• OMS Enterprise – Data migration

• OMS Community – Overview (100 MB/s)

• OMS Community – PostgreSQL source

• Alibaba Cloud – Oracle → OceanBase migration types

• OceanBase – Data migration notice (memstore)

=============================
TƯ VẤN: Click Here hoặc Hotline/Zalo 090.29.12.888
=============================
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội

=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty

Thứ Sáu, 23 tháng 10, 2026

Nghiên cứu tổng thể OceanBase cho doanh nghiệp Viễn thông

1. Lịch sử hình thành

2. Vì sao chọn OceanBase thay vì Oracle, PostgreSQL, MySQL, MongoDB

2.1 Năm khác biệt kiến trúc cốt lõi

2.2 Bảng so sánh

2.3 Khi nào KHÔNG nên dùng OceanBase

3. Case study trên thế giới và tại Việt Nam

3.1 Viễn thông

3.2 Tài chính, năng lượng, hàng không (bài toán tương tự viễn thông)

3.3 Đối chiếu với các nghiệp vụ viễn thông Việt Nam

3.4 Việt Nam

4. Nên áp dụng OceanBase như thế nào

4.1 Mức độ phù hợp theo loại dự án

4.2 Nguyên tắc kiến trúc khi triển khai

5. Migration từ Oracle/PostgreSQL sang OceanBase

5.1 Công cụ

5.2 Quy trình 7 bước

5.3 Ước lượng thời gian theo dung lượng

5.4 Truy vấn khảo sát Oracle nguồn

5.5 Tiêu chí go/no-go trước cutover

6. Rủi ro và câu hỏi cần hỏi vendor

Nguồn tham khảo

ĐỌC NHIỀU