IBM Guardium Kiến trúc của Database (SQL Server, Oracle) và các thành phần cốt lõi

Kiến trúc SQL Server​

A. Tổng quan về kiến trúc​

Kiến trúc SQL Server được chia thành 3 phân vùng lớn, hoạt động phối hợp nhịp nhàng với nhau để xử lý một yêu cầu từ client đến khi trả kết quả:

Protocol Layer ⇒ Relational Engine ⇒ Storage Engine

1. Tầng giao thức / giao tiếp (Protocol Layer / SQL Server Network Interface)​

Tầng này chịu trách nhiệm thiết lập và xử lý kết nối giữa Client và Server. SQL Server Network Interface (SNI) hỗ trợ 3 phương thức kết nối:

• TCP/IP: phương thức kết nối truyền thống thông qua địa chỉ IP của máy chủ, cho phép client kết nối từ xa qua Internet hoặc mạng LAN.
• Named Pipes: cho phép client kết nối với SQL Server trong cùng một mạng nội bộ mà không cần biết địa chỉ IP của server, chỉ cần biết tên pipe (thư mục) kết nối.
• Shared Memory: sử dụng khi client và server cùng nằm trên một máy vật lý duy nhất, giúp giao tiếp nhanh nhất vì không phải đi qua giao thức mạng.

2. Bộ xử lý truy vấn (Relational Engine)​

Đây là phân vùng tiếp nhận câu lệnh từ Client gửi lên và xử lý câu lệnh đó trước khi giao xuống Storage Engine. Luồng xử lý gồm 3 bước chính:

Câu lệnh SQL gửi đến ⇒ CMD Parser phân tích cú pháp ⇒ Optimizer lập kế hoạch thực thi ⇒ Query Executor thực thi và trả kết quả

• CMD Parser: phân tích cú pháp câu lệnh để đảm bảo câu lệnh viết đúng chuẩn, đồng thời dựng nên Query Tree (biểu diễn cấu trúc logic của câu truy vấn dưới dạng cây).
• Optimizer: dựa trên Query Tree, tìm ra Query Plan để lấy dữ liệu hiệu quả nhất (vd quét toàn bộ bảng hay dùng index). Mục tiêu của Optimizer là kế hoạch có chi phí thấp nhất (cost-based) tức tốn ít CPU, I/O, bộ nhớ nhất, chứ không nhất thiết là kế hoạch nhanh nhất trong mọi trường hợp.
• Query Executor: thực thi Query Plan, lấy dữ liệu từ Storage Engine và trả kết quả về cho Protocol Layer để gửi lại client.

3. Storage Engine​

Storage Engine chịu trách nhiệm lưu trữ và truy xuất dữ liệu trên hệ thống lưu trữ vật lý (Disk hoặc SAN), dữ liệu được tổ chức thành các data page kích thước 8 KB.
Khác với MySQL — nơi người dùng có thể tự chọn storage engine (InnoDB, MyISAM...) — SQL Server chỉ dùng một bộ máy lưu trữ cố định, tự quản lý việc trao đổi dữ liệu giữa bộ nhớ đệm và ổ đĩa vật lý.

Bên trong Storage Engine, 3 thành phần cốt lõi phối hợp với nhau:

• Access Method: tiếp nhận câu lệnh và phân loại để định tuyến xử lý:
  • Nếu là câu lệnh đọc dữ liệu (Select Statement) ⇒ chuyển thẳng tới Buffer Manager.
  • Nếu là câu lệnh ghi dữ liệu (Non-select Statement như Insert, Update, Delete) ⇒ chuyển qua Transaction Manager để ghi log trước khi thao tác với dữ liệu trong bộ nhớ.
• Buffer Manager: quản lý Buffer Pool (Data Cache) và Plan Cache.
  • Plan Cache: lưu lại các Query Plan đã sử dụng. Khi gặp lại câu lệnh cũ, SQL Server lấy ngay plan có sẵn thay vì phân tích và tối ưu lại từ đầu ⇒ tăng tốc độ xử lý.
  • Buffer Pool: chứa các data page. Khi cần dữ liệu, hệ thống kiểm tra Buffer Pool trước; nếu chưa có, nó nạp trang dữ liệu từ đĩa vật lý lên. Khi bộ nhớ đầy, các trang dữ liệu đã thay đổi nhưng chưa ghi xuống đĩa (dirty page) mới được đẩy xuống Data File.
• Transaction Manager: quản lý các transaction làm thay đổi dữ liệu (INSERT, UPDATE, DELETE), đảm bảo tính nhất quán và toàn vẹn dữ liệu, thông qua:
  • Log Manager: ghi lại mọi thay đổi dữ liệu vào transaction log, phục vụ recovery và rollback transaction khi có lỗi hoặc sự cố.
  • Lock Manager: khóa các bản ghi/đối tượng dữ liệu để nhiều transaction không can thiệp lẫn nhau, đồng thời giúp phát hiện và ngăn deadlock — tình trạng hai hay nhiều transaction chờ nhau giải phóng lock, không thể tiếp tục.
  • Write-Ahead Logging (WAL): mọi thay đổi dữ liệu phải được ghi vào transaction log trước khi được ghi xuống đĩa, giúp bảo vệ dữ liệu khỏi mất mát khi hệ thống gặp sự cố.
  • Lazy Writer: tiến trình chạy nền, ghi các dirty page từ cache xuống đĩa để giải phóng bộ nhớ và duy trì hiệu năng hệ thống.

B. Cấu trúc lưu trữ vật lý​

Dữ liệu của SQL Server trên đĩa vật lý được tổ chức thông qua các loại file sau:

• Log file (.ldf): ghi lại toàn bộ nhật ký (transaction log) về các thay đổi dữ liệu.
• Data file (.mdf/.ndf): gồm primary file (.mdf — bắt buộc, duy nhất) và secondary file (.ndf — tùy chọn, có thể nhiều file).
• File Group: SQL Server cho phép nhóm nhiều data file vật lý lại thành một File Group để quản lý không gian lưu trữ một cách thuận tiện và hiệu quả hơn.

Kiến trúc logic của SQL Server​

Về mặt logic, các đối tượng của SQL Server được tổ chức theo thứ bậc:

Database: đơn vị lưu trữ độc lập trên một Server, có thể attach/detach tách rời khỏi Server.

Schema: một namespace logic bên trong Database, dùng để nhóm các object lại với nhau (schema mặc định là dbo).

Table: nơi lưu trữ dữ liệu thật.

View: một truy vấn được lưu lại, đóng vai trò như "bảng ảo", không lưu trữ dữ liệu thật.

Stored Procedure, Function: các khối lệnh T-SQL được lập trình sẵn, có thể gọi lại nhiều lần.

Synonym: bí danh (alias) trỏ đến một object khác, kể cả object nằm ở Database khác.

Mỗi Database tương ứng với một bộ file vật lý riêng (.mdf, .ldf...) và có metadata riêng biệt, độc lập với các Database khác trên cùng Server.

Hệ thống Data Catalog và Metadata​

SQL Server sở hữu hệ thống bảng danh mục dữ liệu (data catalog) chặt chẽ, giúp quản trị viên dễ dàng truy vấn thông tin hệ thống thông qua 2 schema lớn:

• sys (system schema): chứa các bảng/view hệ thống lưu thông tin hoạt động của SQL Server, vd sys.objects, sys.views, sys.procedures...
• INFORMATION_SCHEMA: cung cấp thông tin chi tiết, chuẩn hóa theo ANSI về cấu trúc dữ liệu, ví dụ INFORMATION_SCHEMA.TABLES, INFORMATION_SCHEMA.COLUMNS... từ đó có thể kiểm tra chi tiết các cột trong bảng, thời điểm tạo, tài khoản tạo hay lịch sử cập nhật cấu trúc bảng.

Kiến trúc Oracle Database​

A. Tổng quan​

1. Kiến trúc và cấu trúc​

• Về kiến trúc: mô tả mối quan hệ, vai trò của các thành phần và luồng xử lý dữ liệu trong Oracle Database.
• Về cấu trúc: mô tả các thành phần cấu thành nên Oracle Database, bao gồm Memory, Process và Storage.

Một hệ thống Oracle Database bao gồm 2 thành phần chính: Instance và Database.


Instance ⇒ tập hợp Memory Structure và Process Structure, được cấp phát khi Oracle khởi động, tồn tại tạm thời trong RAM.

Database ⇒ tập hợp các file vật lý trên Storage, dùng để lưu trữ dữ liệu và metadata của database, tồn tại lâu dài trên đĩa.

B. Phân tích chi tiết kiến trúc Oracle Database​

1. Kiến trúc Memory​

Bộ nhớ của Oracle được chia thành 2 vùng lớn: System Global Area (SGA) và Program Global Area (PGA).

1.1. Program Global Area (PGA)​

PGA ⇒ vùng bộ nhớ private (riêng), được cấp phát và sử dụng bởi một Oracle process duy nhất, không chia sẻ với process khác.


PGA tiêu chuẩn gồm 4 thành phần bộ nhớ chủ yếu:

• Private SQL Area: lưu dữ liệu riêng của câu lệnh SQL đang thực thi trong phiên đó, ví dụ thông tin về các bind variable.
• Cursor và SQL Area: chứa thông tin về các con trỏ (cursor) đang mở để xử lý tập kết quả truy vấn.
• Session Memory: lưu các session variable, thông tin đăng nhập và trạng thái của phiên làm việc hiện tại.
• Work Area: vùng nhớ phục vụ các thao tác xử lý dữ liệu tốn nhiều bộ nhớ như sắp xếp (ORDER BY, GROUP BY), băm (hash join), hoặc tạo bitmap.

1.2. System Global Area (SGA)​

SGA ⇒ vùng bộ nhớ shared (dùng chung) của Oracle Instance, được mọi Server Process và Background Process truy cập, bao gồm các thành phần:

1.2.1. Database Buffer Cache​

Oracle cần truy xuất dữ liệu ⇒ kiểm tra Database Buffer Cache ⇒ nếu data block đã có trong Buffer Cache ⇒ lấy dữ liệu trực tiếp từ Memory ⇒ trả kết quả.

Nếu data block chưa có trong Buffer Cache ⇒ Oracle đọc data block từ Data File trên Disk ⇒ đưa data block vào Database Buffer Cache ⇒ xử lý và trả kết quả ⇒ những lần truy xuất sau có thể lấy dữ liệu từ Memory thay vì Disk ⇒ tăng hiệu năng truy xuất.

1.2.2. Shared Pool​

SQL được gửi đến Oracle ⇒ Shared Pool tiếp nhận câu lệnh ⇒ Library Cache kiểm tra SQL/cursor đã tồn tại hay chưa ⇒ nếu có thể tái sử dụng thì dùng lại Execution Plan có sẵn ⇒ nếu chưa có thì Oracle phân tích câu lệnh — kiểm tra cú pháp, đối tượng được dùng và quyền truy cập thông qua Data Dictionary Cache ⇒ Oracle xác định Execution Plan tối ưu ⇒ lưu SQL và Execution Plan vào Library Cache ⇒ những lần thực hiện sau có thể tái sử dụng, giúp tăng hiệu năng.

1.2.3. Redo Log Buffer​

Thực hiện thao tác làm thay đổi dữ liệu (INSERT, UPDATE, DELETE) ⇒ Oracle tạo Redo Information mô tả thay đổi ⇒ lưu tạm vào Redo Log Buffer ⇒ LGWR ghi Redo Information từ buffer xuống Online Redo Log Files ⇒ phục vụ Database Recovery khi cần.

1.2.4. Large Pool​

Oracle thực hiện các tác vụ cần vùng nhớ lớn, dùng riêng ⇒ sử dụng Large Pool thay vì Shared Pool ⇒ phục vụ các hoạt động như RMAN Backup/Restore, Shared Server, Parallel Execution.

1.2.5. Java Pool​

Oracle thực hiện các tác vụ liên quan đến Java ⇒ sử dụng Java Pool ⇒ cấp bộ nhớ cho Java stored procedure và JVM chạy bên trong Oracle Database.

1.2.6. Streams Pool​

Oracle thực hiện các tác vụ liên quan đến Oracle Streams ⇒ sử dụng Streams Pool ⇒ cấp bộ nhớ cho các hoạt động streaming và replication dữ liệu.

2. Kiến trúc Process​

2.1. Các loại Process​

• User Process ⇒ process do người dùng tạo ra ⇒ gửi yêu cầu kết nối và các câu lệnh SQL đến Oracle Database ⇒ nằm phía Client, không thuộc Instance.
• User Process kết nối đến Oracle Instance ⇒ Oracle tạo hoặc gán một Server Process để xử lý yêu cầu ⇒ Server Process thực thi SQL và tương tác với SGA.
• Server Process ⇒ phục vụ trực tiếp cho User Process ⇒ sử dụng PGA riêng cho chính nó, đồng thời truy cập SGA dùng chung của Instance ⇒ xử lý câu lệnh và trả kết quả về cho User Process.
• Background Process ⇒ các tiến trình chạy nền do Oracle quản lý ⇒ đảm nhiệm các nhiệm vụ như ghi dữ liệu, ghi redo, khôi phục (recovery), giám sát hệ thống ⇒ giữ cho Oracle Instance hoạt động ổn định.

2.2. Các Background Process quan trọng​

2.2.1. Database Writer DBWn​

Database Buffer Cache ⇒ chứa các data block đã được đọc từ Datafile ⇒ khi dữ liệu trong block bị thay đổi ⇒ block trở thành dirty block ⇒ dirty block cần được ghi trở lại Datafile.

Dirty block ⇒ được DBWn ghi từ Database Buffer Cache xuống Datafile ⇒ dữ liệu trong Memory được đồng bộ với Database trên Disk.

DBWn không chỉ ghi khi Buffer Cache đầy — nó còn ghi khi có quá nhiều dirty block, khi xảy ra Checkpoint, khi cần giải phóng buffer để nạp block mới, hoặc trong một số tình huống khác.

Checkpoint xảy ra ⇒ CKPT cập nhật thông tin checkpoint ⇒ báo cho DBWn ⇒ DBWn ghi các dirty block liên quan xuống Datafile.

2.2.2. Log Writer — LGWR​

DML làm thay đổi dữ liệu ⇒ Oracle tạo Redo Information ⇒ lưu vào Redo Log Buffer ⇒ LGWR ghi Redo Information xuống Online Redo Log Files.

Transaction thực hiện COMMIT ⇒ LGWR ghi Redo liên quan xuống Online Redo Log Files ⇒ đảm bảo Redo đã được ghi an toàn ⇒ Oracle mới xác nhận COMMIT thành công.

LGWR còn được kích hoạt ghi khi Redo Log Buffer đạt khoảng 1/3 dung lượng, hoặc theo chu kỳ thời gian — tuy nhiên không nên ghi nhớ máy móc là cứ đúng 3 giây ghi một lần, vì thời điểm LGWR ghi phụ thuộc nhiều điều kiện khác nhau.

Online Redo Log hiện tại đầy ⇒ xảy ra Log Switch ⇒ Oracle chuyển sang Redo Log Group tiếp theo ⇒ LGWR tiếp tục ghi Redo vào group mới.

Nguyên tắc quan trọng: LGWR luôn ghi Redo xuống đĩa trước khi DBWn được phép ghi dirty block tương ứng xuống Datafile — đây chính là cơ chế Write-Ahead Logging.

2.2.3. Checkpoint — CKPT​

Checkpoint xảy ra ⇒ CKPT ghi/cập nhật Checkpoint SCN vào Control File và Datafile Header ⇒ đồng thời báo cho DBWn ghi các dirty block cần thiết xuống Datafile.

CKPT ⇒ đánh dấu một mốc mà Oracle dùng để xác định trạng thái cần recovery ⇒ giúp giảm lượng Redo cần xử lý khi Instance Recovery.

Checkpoint SCN được ghi vào Control File và Datafile Header ⇒ Oracle dùng thông tin SCN này để theo dõi và đảm bảo tính nhất quán phục vụ Recovery.

2.2.4. Process Monitor — PMON​

Server Process/User Process bị lỗi hoặc kết nối bị ngắt bất thường ⇒ PMON phát hiện ⇒ thực hiện cleanup các tài nguyên liên quan ⇒ giải phóng tài nguyên/process state không còn dùng ⇒ giúp Instance tiếp tục hoạt động bình thường.

PMON ⇒ ngoài việc cleanup process lỗi ⇒ còn tham gia đăng ký/thông báo thông tin Instance với Listener trong cơ chế Dynamic Service Registration.

Tóm gọn: process chết bất thường ⇒ PMON dọn dẹp ⇒ giải phóng tài nguyên.

2.2.5. System Monitor — SMON​

Oracle Instance bị lỗi hoặc mất điện ⇒ Instance shutdown bất thường ⇒ khi Database khởi động lại ⇒ SMON thực hiện Instance Recovery ⇒ dùng Redo để Roll Forward khôi phục các thay đổi cần thiết ⇒ sau đó Roll Back các transaction chưa commit ⇒ Database trở về trạng thái nhất quán.

SMON ⇒ ngoài Instance Recovery ⇒ còn thực hiện một số tác vụ system-level cleanup và quản lý temporary segment trong một số trường hợp.

Luồng quan trọng nhất: Instance Failure ⇒ Database Startup ⇒ SMON ⇒ Instance Recovery ⇒ Database trở về trạng thái nhất quán.

2.2.6. Archiver — ARCn​

LGWR ghi Redo ⇒ Redo được ghi lần lượt vào các Online Redo Log Group ⇒ khi Redo Log Group hiện tại đầy ⇒ xảy ra Log Switch ⇒ chuyển sang Redo Log Group tiếp theo.

Nếu Database chạy ở ARCHIVELOG mode ⇒ Redo Log Group cũ cần được lưu lại trước khi bị ghi đè ⇒ ARCn đọc Online Redo Log ⇒ sao chép nội dung sang Archived Redo Log ⇒ Redo Log Group cũ được giải phóng để tái sử dụng.

Vd: Group 1 đầy ⇒ Log Switch ⇒ chuyển sang Group 2 ⇒ ARCn archive Group 1 ⇒ Group 1 được đánh dấu có thể tái sử dụng sau khi đáp ứng điều kiện cần thiết. Tương tự, Group 2 đầy ⇒ Log Switch ⇒ chuyển sang Group 3 ⇒ ARCn archive Group 2 ⇒ quá trình tiếp tục luân phiên.

Lưu ý: ARCn chỉ hoạt động khi Database ở ARCHIVELOG mode.

2.2.7. Manageability Monitor — MMON​

Oracle Database hoạt động ⇒ MMON thu thập các performance metrics và thông tin thống kê ⇒ lưu trữ để phục vụ theo dõi hiệu năng ⇒ hỗ trợ Automatic Workload Repository (AWR) và các cơ chế quản lý hiệu năng của Oracle.

Tóm gọn: Database hoạt động ⇒ MMON thu thập performance metrics ⇒ lưu/ghi nhận thông tin hiệu năng ⇒ phục vụ monitoring và performance tuning.

3. Kiến trúc Storage​

3.1. Cấu trúc lưu trữ logic​

Data Block ⇒ đơn vị lưu trữ nhỏ nhất của Oracle Database ⇒ chứa dữ liệu của bảng, index... ⇒ được lưu bên trong Datafile.

Extent ⇒ một tập hợp các Data Block liên tiếp, được cấp phát cho một đối tượng ⇒ khi một Segment cần thêm không gian ⇒ Oracle cấp phát thêm Extent.

Segment ⇒ tập hợp các Extent thuộc về một Database Object, ví dụ Table Segment, Index Segment ⇒ Segment đại diện cho toàn bộ không gian mà object đó sử dụng.

Tablespace ⇒ đơn vị lưu trữ logic lớn hơn, chứa một hoặc nhiều Segment ⇒ được tạo thành từ một hoặc nhiều Datafile.

Tổng kết theo thứ bậc: Tablespace ⇒ Datafile ⇒ Segment ⇒ Extent ⇒ Data Block.

3.2. Các loại file trong Oracle Database​

3.2.1. Parameter File​

Parameter File ⇒ lưu các tham số cấu hình của Instance, ví dụ số lượng process tối đa, kích thước vùng nhớ, vị trí Control File... ⇒ khi Instance khởi động ⇒ Oracle đọc Parameter File để biết cách khởi tạo Instance.

Tóm gọn: Parameter File ⇒ cung cấp thông tin cấu hình ⇒ Oracle Instance được khởi tạo.

3.2.2. Password File​

Password File ⇒ lưu thông tin xác thực dành cho một số administrative user, đặc biệt phục vụ kết nối quản trị như SYSDBA/SYSOPER.

Khi Database chưa OPEN ⇒ chưa thể xác thực quản trị hoàn toàn dựa trên Database ⇒ Password File cung cấp cơ chế xác thực nằm ngoài Database.

Tóm gọn: Database chưa mở ⇒ vẫn cần Admin đăng nhập để startup/mount/open Database ⇒ Password File hỗ trợ xác thực Administrative User.

3.2.3. Control File​

Control File ⇒ chứa metadata quan trọng để Oracle quản lý Database, ví dụ tên Database, Database identifier, thông tin Datafile, Redo Log File, Checkpoint information...

Instance khởi động ⇒ đọc Parameter File ⇒ biết vị trí Control File ⇒ đọc Control File ⇒ nắm được cấu trúc vật lý của Database.

3.2.4. Datafile​

Datafile ⇒ file vật lý lưu trữ dữ liệu của Database trên Disk ⇒ chứa các Data Block ⇒ các block này được Oracle đọc từ Datafile ⇒ đưa vào Database Buffer Cache ⇒ xử lý trên Memory.

Datafile lưu dữ liệu lâu dài trên Disk, trong khi Database Buffer Cache chỉ lưu tạm thời các Data Block đang được sử dụng trên Memory.

3.2.5. Redo Log File​

Database thực hiện thay đổi ⇒ Oracle tạo Redo Information ⇒ lưu vào Redo Log Buffer ⇒ LGWR ghi xuống Online Redo Log File.

Redo Log File ⇒ lưu thông tin về các thay đổi của Database (phát sinh từ hoạt động của User lẫn hoạt động nội bộ của Oracle) ⇒ phục vụ Recovery khi xảy ra sự cố.

3.2.6. Archived Log File​

Online Redo Log Group đầy ⇒ Log Switch ⇒ nếu Database ở ARCHIVELOG mode ⇒ ARCn sao chép Redo Log Group cũ ⇒ tạo Archived Redo Log ⇒ lưu lại lịch sử Redo.

Archived Log không đơn thuần là "bản sao Redo Log File" — nó là bản sao nội dung của Redo Log Group đã được archive, lưu trữ lâu dài hơn, phục vụ Media Recovery, Backup và Point-in-Time Recovery.

3.2.7. Backup File​

Database cần backup ⇒ Oracle/DBA dùng công cụ như RMAN ⇒ tạo các Backup File ⇒ lưu bản sao cần thiết của Database/Control File/Archived Log... ⇒ sử dụng khi cần Restore/Recovery.

4. Trạng thái khởi động của Oracle Database​

Oracle Database khởi động tuần tự qua 4 trạng thái:

SHUTDOWN ⇒ NOMOUNT ⇒ MOUNT ⇒ OPEN

4.1. SHUTDOWN​

SHUTDOWN ⇒ Oracle Instance không hoạt động ⇒ SGA chưa được cấp phát, Background Process chưa chạy ⇒ Database chưa được mở.

4.2. NOMOUNT​

STARTUP NOMOUNT ⇒ Oracle đọc Parameter File ⇒ lấy thông tin cấu hình và vị trí Control File ⇒ cấp phát SGA ⇒ khởi động Background Process ⇒ Oracle Instance được tạo ⇒ chưa đọc Control File ⇒ Database chưa được Mount.

Tóm gọn: Parameter File ⇒ Memory + Background Process ⇒ Instance được khởi động ⇒ NOMOUNT.

4.3. MOUNT​

Từ NOMOUNT ⇒ Oracle dùng thông tin từ Parameter File ⇒ tìm đến Control File ⇒ đọc Control File ⇒ Instance biết cấu trúc vật lý của Database ⇒ Database được Mount.

MOUNT ⇒ Control File đã được mở, Oracle biết Datafile và Redo Log File nằm ở đâu ⇒ nhưng chưa cho User truy cập dữ liệu.

4.4. OPEN​

Từ MOUNT ⇒ Oracle kiểm tra trạng thái Database, đảm bảo tính nhất quán ⇒ nếu Database cần Instance Recovery ⇒ dùng Redo Log để recovery ⇒ hoàn tất Recovery ⇒ OPEN Database ⇒ User có thể truy cập dữ liệu.

Tóm gọn: MOUNT ⇒ kiểm tra thông tin Recovery/SCN ⇒ nếu Database cần Recovery ⇒ SMON thực hiện Instance Recovery bằng Redo ⇒ Recovery hoàn tất ⇒ OPEN.