Oracle 1 — Kiến trúc: Instance, SGA/PGA & tiến trình nền

Oracle Database là RDBMS thương mại lâu đời và thống trị mảng hệ thống trọng yếu (ngân hàng, viễn thông, ERP). Nhưng chính bề dày đó khiến kiến trúc của nó nhiều tầng thuật ngữ hơn hẳn các database mã nguồn mở. Trước khi viết PL/SQL, đọc EXPLAIN PLAN hay xử lý một sự cố "database treo", bạn cần một mô hình tinh thần đúng: bên trong một Oracle Database đang chạy thực sự có những gì.

Bài này dựng nền cho cả series. Nó trả lời những câu hỏi mà nếu không hiểu kiến trúc sẽ mãi mù mờ: vì sao dữ liệu vẫn an toàn khi mất điện giữa chừng? Vì sao "một database chậm" đôi khi lại là do vùng nhớ chia sẻ chứ không phải đĩa? Vì sao Oracle từ 21c trở đi bắt buộc dùng CDB/PDB? Nội dung bám theo Oracle 19c/21c/23ai — những phiên bản đang được dùng thực tế nhất hiện nay.

Ghi chú về ví dụ: SQL sandbox của Knowledge Base này chạy PostgreSQL, không phải Oracle. Vì vậy mọi đoạn lệnh Oracle dưới đây là minh hoạ cú pháp, không thực thi được trong sandbox. Chúng được đánh dấu rõ ràng.

Instance vs Database: hai khái niệm dễ nhầm nhất

Đây là điểm phân biệt quan trọng nhất và cũng bị hiểu sai nhiều nhất. Trong thế giới Oracle, "instance" và "database" không đồng nghĩa.

• Database = tập hợp các file vật lý trên đĩa. Đó là nơi dữ liệu thực sự nằm: các datafile (chứa dữ liệu bảng, chỉ mục), control file (siêu dữ liệu mô tả cấu trúc database), và online redo log (nhật ký thay đổi). Database là thứ tĩnh, tồn tại kể cả khi máy chủ tắt.

• Instance = bộ nhớ + tiến trình đang chạy trong RAM để phục vụ database đó. Cụ thể: vùng nhớ chia sẻ SGA cộng với tập các tiến trình nền (background processes). Instance là thứ động, mất đi khi bạn shutdown.

Công thức cần thuộc:

Instance  =  SGA  +  Background Processes        (bộ nhớ + tiến trình, trong RAM)
Database  =  Datafiles + Control files + Redo log (các file trên đĩa)

Instance "gắn" vào database qua ba bước khởi động:

1. NOMOUNT — cấp phát SGA, khởi động tiến trình nền. Instance đã sống, nhưng chưa biết gì về database.
2. MOUNT — instance đọc control file, nhận diện các datafile và redo log (nhưng chưa mở cho người dùng).
3. OPEN — mở datafile và redo log, database sẵn sàng phục vụ truy vấn.

Vì sao tách bạch quan trọng? Trong cấu hình Oracle RAC (Real Application Clusters), một database trên bộ lưu trữ chia sẻ có thể được phục vụ bởi nhiều instance chạy trên nhiều máy chủ cùng lúc — quan hệ một-nhiều. Chi tiết đó thuộc bài RAC & Data Guard, nhưng nó chỉ hợp lý khi bạn đã thấy instance và database là hai thực thể riêng.

SGA — vùng nhớ chia sẻ của cả instance

SGA (System Global Area) là vùng nhớ dùng chung mà mọi tiến trình của instance đều truy cập. Đây là trái tim hiệu năng: phần lớn công việc tối ưu Oracle xoay quanh việc dữ liệu và câu lệnh có nằm sẵn trong SGA hay phải đọc lại từ đĩa. Các thành phần chính:

• Database Buffer Cache — vùng đệm chứa các block dữ liệu đã đọc từ datafile. Khi một truy vấn cần một dòng, Oracle nạp cả block chứa nó vào đây. Lần đọc sau nếu block còn trong cache thì khỏi chạm đĩa (gọi là cache hit). Các block bị sửa đổi mà chưa ghi xuống đĩa gọi là dirty block (block bẩn).

• Shared Pool — vùng đệm cho câu lệnh và siêu dữ liệu, gồm hai phần cốt lõi:

  • Library Cache: lưu câu lệnh SQL/PL/SQL đã phân tích cùng kế hoạch thực thi (execution plan). Nếu một câu lệnh giống hệt được chạy lại, Oracle tái dùng plan đã có — gọi là soft parse, tránh phải phân tích lại tốn kém (hard parse). Đây là lý do cốt lõi để dùng bind variable thay vì ghép chuỗi literal, sẽ bàn kỹ ở bài Tối ưu.
  • Data Dictionary Cache (row cache): lưu siêu dữ liệu về bảng, cột, quyền, ràng buộc — thứ mà optimizer phải tra liên tục.

• Redo Log Buffer — vùng đệm vòng nhỏ chứa các bản ghi redo (mô tả mọi thay đổi dữ liệu) trước khi được ghi xuống online redo log trên đĩa. Nền tảng của khả năng phục hồi.

• Large Pool — vùng cấp phát bộ nhớ lớn cho các tác vụ như sao lưu RMAN, I/O song song, kết nối shared server — để chúng không làm phân mảnh Shared Pool.

• Java Pool — bộ nhớ cho mã Java chạy trong database (Oracle JVM).

Kích thước SGA có thể quản lý tự động: ASMM (Automatic Shared Memory Management, qua tham số SGA_TARGET) tự cân đối giữa các pool trong SGA; AMM (Automatic Memory Management, qua MEMORY_TARGET) quản lý chung cả SGA lẫn PGA. Nhiều DBA khuyến nghị dùng ASMM và đặt PGA riêng để kiểm soát tốt hơn.

PGA — vùng nhớ riêng của từng server process

Trái ngược với SGA, PGA (Program Global Area) là vùng nhớ riêng tư, không chia sẻ, gắn với mỗi server process phục vụ một kết nối. Mỗi phiên có PGA riêng chứa:

• Sort area — bộ nhớ để sắp xếp (ORDER BY, GROUP BY, tạo index).
• Hash area — bộ nhớ cho phép nối kiểu hash join.
• Thông tin phiên, con trỏ (cursor), biến của phiên đó.

Nguyên tắc cần nhớ: dữ liệu chia sẻ nằm ở SGA, phần tính toán riêng của mỗi phiên nằm ở PGA. Nếu vùng sort/hash trong PGA không đủ, Oracle "tràn" ra temporary tablespace trên đĩa — chậm đi đáng kể, và đó là dấu hiệu cần chú ý khi tuning.

Tiến trình nền: ai làm việc gì

Instance có một tập tiến trình nền chạy ngầm để lo I/O, phục hồi và dọn dẹp. Có nhóm bắt buộc (thiếu một trong số này thì instance sẽ abort) và nhóm tuỳ chọn (chỉ bật khi cần tính năng tương ứng).

Nhóm bắt buộc gồm sáu tiến trình: PMON, SMON, DBWn, LGWR, CKPT và RECO.

• DBWn — Database Writer: ghi các dirty block từ Buffer Cache xuống datafile. Điểm quan trọng và phản trực giác: DBWn ghi chậm rãi, theo lô, không phải ngay khi commit. n nghĩa là có thể có nhiều tiến trình (DBW0, DBW1...).

• LGWR — Log Writer: ghi nội dung Redo Log Buffer xuống online redo log trên đĩa. LGWR ghi khi có COMMIT, khi buffer đầy 1/3, hoặc định kỳ. Đây là tiến trình then chốt của độ bền dữ liệu (xem phần redo bên dưới).

• CKPT — Checkpoint: khi xảy ra checkpoint, CKPT cập nhật header của control file và datafile với thông tin checkpoint (SCN — System Change Number), đồng thời báo hiệu DBWn ghi block xuống đĩa. Checkpoint xác định "điểm mốc" để giới hạn lượng redo cần đọc lại khi phục hồi.

• SMON — System Monitor: chịu trách nhiệm instance recovery (phục hồi tự động sau crash khi mở lại database), cùng nhiều việc dọn dẹp cấp hệ thống như gộp không gian trống, dọn segment tạm.

• PMON — Process Monitor: dọn dẹp khi một user process chết bất thường — giải phóng khoá, rollback giao dịch dang dở, trả lại tài nguyên. Từ các phiên bản mới, PMON uỷ thác phần lớn công việc dọn dẹp cho tiến trình CLMN (Cleanup Main) và các worker CLnn, nhưng vai trò khái niệm vẫn như trên.

• RECO — Recoverer: giải quyết các giao dịch phân tán "in-doubt" (giữa nhiều database).

Một số tiến trình tuỳ chọn hay gặp:

• ARCn — Archiver: khi database chạy ở chế độ ARCHIVELOG, ARCn sao chép online redo log đã đầy sang archived redo log trước khi chúng bị ghi đè. Đây là điều kiện bắt buộc để phục hồi tại một thời điểm bất kỳ (point-in-time recovery) và cho Data Guard.
• MMON / MMNL — Manageability Monitor: thu thập số liệu hiệu năng cho AWR (Automatic Workload Repository), sinh snapshot phục vụ chẩn đoán.

Dưới đây là sơ đồ tổng thể instance ↔ database:

Redo & Undo: hai nhật ký, hai mục đích khác nhau

Người mới rất hay nhầm redo với undo. Chúng là hai cơ chế riêng biệt, giải quyết hai bài toán khác nhau.

Redo — bảo đảm độ bền (durability)

Trước khi thay đổi một dữ liệu, Oracle ghi lại cách thực hiện thay đổi đó vào Redo Log Buffer, rồi LGWR ghi xuống online redo log trên đĩa. Điểm mấu chốt của durability nằm ở quy tắc write-ahead: khi bạn COMMIT, Oracle chỉ cần chắc rằng redo đã nằm an toàn trên đĩa — chưa cần datafile được cập nhật.

Đây là lý do cơ chế trông "kỳ lạ" nhưng cực nhanh: commit không phải đợi DBWn ghi block (I/O ngẫu nhiên, chậm), chỉ đợi LGWR ghi redo (I/O tuần tự vào file log, nhanh). Nếu mất điện ngay sau commit, dữ liệu trong Buffer Cache bốc hơi — nhưng khi mở lại database, SMON dùng redo log để dựng lại (roll forward) mọi thay đổi đã commit. Không mất một giao dịch nào đã báo thành công. Đó chính là chữ D trong ACID.

Online redo log gồm nhiều group ghi luân phiên (vòng tròn). Khi một group đầy, LGWR chuyển sang group kế; ở chế độ ARCHIVELOG, ARCn kịp sao lưu group vừa đầy trước khi nó bị ghi đè.

Undo — nhất quán đọc và rollback

Undo lưu hình ảnh cũ (before-image) của dữ liệu trước khi bị sửa, đặt trong undo tablespace. Nó phục vụ hai việc:

• Rollback: khi bạn ROLLBACK, Oracle dùng undo để khôi phục dữ liệu về trạng thái trước.
• Read consistency: khi giao dịch A đang đọc một bảng mà giao dịch B đang sửa (chưa commit), A không thấy thay đổi dang dở của B — thay vào đó Oracle dùng undo để dựng lại hình ảnh dữ liệu tại thời điểm A bắt đầu đọc. Nhờ vậy "người đọc không chặn người ghi, người ghi không chặn người đọc".

Cơ chế nhất quán đọc và mối liên hệ với các isolation level là chủ đề của bài Concurrency & undo.

So sánh nhanh để khỏi nhầm:

Redo  →  làm LẠI thay đổi (roll forward)  →  phục hồi sau crash, durability
Undo  →  làm NGƯỢC thay đổi (roll back)   →  rollback + read consistency

Cấu trúc lưu trữ: logic vs vật lý

Oracle tách bạch cấu trúc logic (khái niệm, người dùng thao tác) với cấu trúc vật lý (file thật trên đĩa) — cho phép mở rộng lưu trữ mà không đụng đến ứng dụng.

Hệ thống phân cấp logic, từ lớn đến nhỏ:

Tablespace  →  Segment  →  Extent  →  Block

• Block (Oracle block / data block) — đơn vị I/O nhỏ nhất, thường 8KB. Oracle luôn đọc/ghi theo block.
• Extent — một dãy các block liền kề, cấp phát cùng lúc.
• Segment — tập các extent tạo thành một đối tượng lưu trữ (một bảng, một index, một partition là một segment).
• Tablespace — nhóm logic chứa nhiều segment; ánh xạ tới một hoặc nhiều datafile vật lý.

Về phía vật lý, một tablespace được lưu trên một hay nhiều datafile. Đây là lớp "keo" nối logic với vật lý: bạn quản lý theo tablespace, còn Oracle rải dữ liệu xuống các datafile.

Các tablespace hệ thống cần biết:

• SYSTEM — chứa data dictionary (siêu dữ liệu của toàn database). Bắt buộc.
• SYSAUX — tablespace phụ trợ cho SYSTEM, chứa dữ liệu của các thành phần như AWR.
• UNDO — chứa dữ liệu undo (before-image) nêu trên.
• TEMP — temporary tablespace, dùng khi sort/hash tràn khỏi PGA và cho bảng tạm.

Multitenant: kiến trúc CDB/PDB

Từ Oracle 12c, Oracle giới thiệu kiến trúc đa thuê bao (multitenant) và đến 21c trở đi nó trở thành kiến trúc duy nhất được hỗ trợ — kiến trúc non-CDB cũ đã desupported (khai tử) từ 21c. Với 19c/23ai, hiểu CDB/PDB là bắt buộc.

Ý tưởng cốt lõi:

• CDB (Container Database) — "database chứa". Nó sở hữu instance dùng chung: SGA, tiến trình nền, redo log, control file. Bên trong CDB có:

  • CDB$ROOT — container gốc, chứa siêu dữ liệu và các đối tượng Oracle dùng chung cho toàn CDB.
  • PDB$SEED — một PDB mẫu chỉ-đọc, dùng làm khuôn để tạo nhanh PDB mới.
  • Nhiều PDB (Pluggable Database) do người dùng tạo.

• PDB (Pluggable Database) — mỗi PDB là một "database ứng dụng" độc lập với data dictionary riêng, tablespace riêng, user và object riêng. Với ứng dụng, một PDB trông y hệt một database bình thường. Nhưng tất cả PDB dùng chung một instance (SGA, tiến trình nền) của CDB.

Điểm cần nhớ về tài nguyên: SGA và tiến trình nền là của CDB, chia sẻ cho mọi PDB — Buffer Cache, Shared Pool, redo buffer không tách riêng theo PDB. Để tránh vấn đề "hàng xóm ồn ào" (một PDB ngốn hết tài nguyên), Oracle cho phép đặt giới hạn SGA/PGA theo từng PDB và dùng Resource Manager.

Lợi ích của multitenant:

• Hợp nhất (consolidation): gom hàng chục database nhỏ vào một CDB, dùng chung một instance → tiết kiệm bộ nhớ và tiến trình đáng kể so với chạy hàng chục instance riêng.
• Plug/Unplug: có thể "rút" một PDB ra thành file rồi "cắm" sang một CDB khác — di chuyển database nhanh gọn như rút USB.
• Nâng cấp và vá lỗi theo CDB: nâng cấp một CDB là nâng cấp mọi PDB bên trong; hoặc unplug một PDB rồi cắm vào CDB phiên bản cao hơn để nâng cấp.
• Quản trị tập trung: sao lưu, giám sát ở cấp CDB.

Về giấy phép (để tránh hiểu nhầm ngoài thực địa): từ 19c, bạn được tạo tối đa 3 PDB do người dùng tạo mà không cần license Multitenant; từ PDB thứ 4 trở đi cần license Multitenant (trên môi trường Oracle Cloud có license included, giới hạn này nới rộng, tối đa tới hàng nghìn PDB).

Minh hoạ vài lệnh multitenant (cú pháp Oracle, không chạy trong sandbox Postgres):

-- (minh hoạ — cú pháp Oracle, không chạy trong sandbox Postgres)
-- Xem đang đứng ở container nào
SHOW CON_NAME;

-- Liệt kê các PDB trong CDB
SELECT name, open_mode FROM v$pdbs;

-- Chuyển sang một PDB cụ thể
ALTER SESSION SET CONTAINER = sales_pdb;

-- Tạo PDB mới từ PDB$SEED
CREATE PLUGGABLE DATABASE hr_pdb
  ADMIN USER hr_admin IDENTIFIED BY ***;

Use case thực tế

• Chẩn đoán "database chậm" đúng chỗ: khi hệ thống chậm, mô hình kiến trúc cho bạn hướng điều tra thay vì đoán mò. Tỷ lệ cache hit của Buffer Cache thấp → nghẽn I/O đọc. Nhiều hard parse → Shared Pool bị áp lực, nên xem lại bind variable. Chờ đợi trên log file sync → nghẽn ở LGWR/redo. Sort tràn xuống TEMP → PGA nhỏ. Không có mô hình này, mọi con số AWR đều vô nghĩa.

• Quyết định chế độ ARCHIVELOG: hệ thống trọng yếu (ngân hàng, thanh toán) bắt buộc ARCHIVELOG để phục hồi point-in-time và chạy Data Guard. Hiểu vai trò ARCn và archived redo giúp bạn cân đối giữa an toàn dữ liệu và chi phí lưu trữ log.

• Hợp nhất hạ tầng bằng multitenant: một tổ chức có 40 ứng dụng, mỗi ứng dụng một database non-CDB → 40 instance, 40 bộ SGA và tiến trình nền, tốn RAM khổng lồ. Gom thành vài CDB, mỗi CDB chứa nhiều PDB → giảm mạnh chi phí bộ nhớ, quản trị tập trung, di chuyển ứng dụng bằng plug/unplug khi cần scale.

• Lập kế hoạch dung lượng: hiểu tablespace → segment → extent → block giúp dự báo tăng trưởng, đặt datafile auto-extend hợp lý, và biết vì sao một DELETE không tự trả lại dung lượng cho OS (segment không co lại tự động).

So sánh nhanh với PostgreSQL

Nếu bạn đã đọc PostgreSQL kiến trúc, sự khác biệt về mô hình process/memory rất đáng chú ý:

Khía cạnh          Oracle                          PostgreSQL
-----------------  ------------------------------  -----------------------------
Mô hình tiến trình Server process mỗi kết nối       Backend process mỗi kết nối
                   (+ tuỳ chọn shared server)       (postmaster fork)
Vùng nhớ chia sẻ   SGA (buffer cache, shared pool)  shared_buffers, WAL buffers
Vùng nhớ riêng     PGA (sort/hash area)             work_mem mỗi backend
Nhật ký redo       Online/archived redo log         WAL (write-ahead log)
Cơ chế đọc nhất quán Undo tablespace (before-image)  MVCC — nhiều phiên bản dòng
                                                     ngay trong bảng
Đa thuê bao        CDB/PDB (native, bắt buộc)       Database/schema (không có
                                                     PDB thật sự)

Điểm khác biệt lớn nhất về read consistency: Oracle giữ before-image trong undo tablespace tách riêng, còn PostgreSQL lưu nhiều phiên bản của dòng ngay trong bảng (MVCC), kéo theo nhu cầu VACUUM. Hai triết lý khác nhau cho cùng một mục tiêu: đọc không chặn ghi.

Ghi nhớ

• Instance = SGA + tiến trình nền (RAM); Database = datafile + control file + redo log (đĩa). Instance mount/open database; một database có thể được nhiều instance phục vụ (RAC).
• SGA chia sẻ (Buffer Cache, Shared Pool, Redo Log Buffer, Large/Java Pool); PGA riêng mỗi server process (sort/hash area). ASMM quản SGA, AMM quản cả hai.
• Sáu tiến trình bắt buộc: DBWn, LGWR, CKPT, SMON, PMON, RECO. DBWn ghi block bẩn xuống datafile chậm rãi; LGWR ghi redo ngay khi commit — đó là mấu chốt hiệu năng của commit.
• Redo làm lại (durability, roll forward); Undo làm ngược (rollback + read consistency). Commit chỉ cần redo an toàn trên đĩa, không cần datafile được cập nhật.
• Logic: tablespace → segment → extent → block; vật lý: datafile. SYSTEM/SYSAUX/UNDO/TEMP là các tablespace hệ thống.
• Multitenant bắt buộc từ 21c: CDB chứa CDB$ROOT, PDB$SEED và nhiều PDB dùng chung một instance. Non-CDB đã desupported.

Bài tiếp theo đi vào PL/SQL — ngôn ngữ thủ tục chạy ngay trong database này. Sau đó là Tối ưu & optimizer, Concurrency & undo và RAC & Data Guard.