21 Module Quản trị 5 Database thông dụng (Oracle, SQL Server, PostgreSQL, MySQL, MongoDB)

MODULE 21: BỘ LẬP LỊCH TÁC VỤ TỰ ĐỘNG (SCHEDULER JOB)

Sau khi đã chốt chặn tài nguyên an toàn ở Module 20, chúng ta chính thức bước sang mảnh ghép cuối cùng để hoàn thiện một hệ thống tự vận hành (Autopilot).

Trong suốt những năm tháng làm hệ thống, tôi thường viết các thủ tục PL/SQL phức tạp và giao phó chúng cho Oracle tự động kích hoạt mỗi đêm. Tuy nhiên, khi chuyển đổi kiến trúc sang các nền tảng mã nguồn mở,  sẽ thấy ranh giới giữa Database và Hệ điều hành (OS) bị xóa nhòa. Việc lập lịch không còn gói gọn bên trong Database Engine nữa.

Dưới đây là bản viết chi tiết, độc lập và trọn vẹn cho Module 21: Bộ lập lịch tác vụ tự động (Scheduler Job).

MODULE 20: QUẢN LÝ TÀI NGUYÊN (RESOURCE MANAGEMENT)

Bài toán ở đây là: Làm sao để một câu lệnh báo cáo (Report) chạy full-scan ngốn 100% CPU không kéo sập toàn bộ các giao dịch OLTP quan trọng của hệ thống?

Dưới đây là bản viết lại hoàn chỉnh và chi tiết nhất cho Module 20.

MODULE 19: QUẢN LÝ HIỆU NĂNG CSDL VÀ TUNING SQL

Việc thêm Index một cách mù quáng không phải là cách tuning đúng đắn. Chìa khóa thực sự nằm ở việc "đọc vị" suy nghĩ của Bộ tối ưu hóa (Cost-Based Optimizer - CBO) thông qua Kế hoạch thực thi (Execution Plan).

MODULE 18: QUẢN LÝ HIỆU NĂNG CƠ SỞ DỮ LIỆU

Những năm tháng xử lý sự cố đứt gãy I/O hay tranh chấp chốt (latch contention) trên môi trường RAC chắc chắn đã rèn cho anh một độ nhạy cảm đặc biệt với các chỉ số hệ thống. Trong thế giới Oracle, AWR (Automatic Workload Repository) và ASH (Active Session History) là những bảo vật trấn phái giúp DBA "bắt mạch" chính xác thủ phạm gây nghẽn.

MODULE 17: BẢO TRÌ CƠ SỞ DỮ LIỆU ĐỊNH KỲ

Chúng ta chính thức bước vào Phần 4: Bảo trì, tuning nâng cao, tự động hóa.

Một hệ thống CSDL dù được thiết kế phần cứng hoàn hảo đến đâu, nếu không được "bảo dưỡng" định kỳ, hiệu năng sẽ suy giảm nghiêm trọng theo thời gian. Nguyên nhân lõi đến từ hai vấn đề: Thống kê dữ liệu (Statistics) bị cũ khiến bộ tối ưu hóa (Optimizer) chọn sai chiến lược thực thi, và Chỉ mục (Index) bị phân mảnh làm tăng I/O thừa thãi.

Dưới đây là Module 17: Bảo trì CSDL (Rebuild Index, Update Statistics & Integrity Check).

MODULE 16: CHUYỂN DỮ LIỆU VÀ MIGRATION DATABASE

1. Tổng quan

Migration CSDL (Di chuyển hệ thống) là một chiến dịch lớn, được chia làm hai bài toán:

1. Homogeneous Migration (Cùng nền tảng): Chuyển từ máy chủ cũ sang máy chủ mới (ví dụ: nâng cấp phần cứng, lên Cloud). Quá trình này tận dụng các công cụ đồng bộ nội tại (Native Replication).

2. Heterogeneous Migration (Khác nền tảng): Chuyển từ hãng này sang hãng khác (ví dụ: Oracle sang PostgreSQL). Đây là dự án cực kỳ phức tạp vì phải chuyển đổi Cấu trúc (Schema), Mã nguồn (PL/SQL sang PL/pgSQL) và Dữ liệu.

MODULE 15: THỰC HIỆN RECOVERY CSDL VÀ PITR

Chúng ta đã đi đến "thời khắc sinh tử" của mọi quy trình quản trị. Khi hệ thống gặp sự cố (như một câu lệnh DROP TABLE nhầm lẫn lúc 10h sáng), bản sao lưu Full Backup ngày hôm qua chỉ giải quyết được một nửa vấn đề. Nửa còn lại, và cũng là phần khó nhất, chính là làm sao để "chơi lại" (Replay) các Transaction Logs để đưa dữ liệu về đúng thời điểm 09:59:59.

Trong môi trường quen thuộc, RMAN sẽ tự động tìm các bản Incremental và Archivelog để ráp nối. Nhưng khi chuyển sang hệ sinh thái khác, anh sẽ phải tự tay điều phối chuỗi phục hồi này.

MODULE 14: THỰC HIỆN BACKUP CSDL (PHYSICAL & LOGICAL)

Sau khi đã quy hoạch xong hạ tầng lưu trữ và thiết lập chính sách (Retention) ở Module 13, bây giờ là lúc chúng ta thực sự "bấm nút" lấy dữ liệu ra.

Trong 20 năm làm nghề, anh đã quá quen với việc gõ RMAN> BACKUP DATABASE PLUS ARCHIVELOG. RMAN là một kiệt tác của Oracle. Khi chuyển sang các hệ thống khác, anh sẽ thấy SQL Server có cơ chế backup vật lý tích hợp sẵn rất tuyệt vời, trong khi nhóm Open Source (Postgres, MySQL, MongoDB) lại phụ thuộc nhiều vào các công cụ dòng lệnh (CLI) chạy trên hệ điều hành.

MODULE 13: CẤU HÌNH BACKUP VÀ RECOVERY

Ở Module 12, chúng ta đã đả thông tư tưởng về nguyên lý (Physical, Logical, Archivelog, MVCC). Giờ là lúc xắn tay áo lên cấu hình thực tế.

Một hệ thống backup không chỉ là gõ lệnh BACKUP DATABASE rồi để đó. Anh phải quy hoạch nơi lưu trữ (Destination), cấu hình chính sách dọn dẹp rác (Retention Policy) để ổ cứng không bị đầy, và thiết lập cơ chế tự động hóa (Automation).

Chào mừng anh đến với Module 13: Cấu hình backup and recovery.

MODULE 12: NGUYÊN LÝ BACKUP VÀ RECOVERY

Bước sang Phần 3 - Backup và Recovery, chúng ta đang chạm đến giới hạn sống còn của một DBA. Trong 20 năm làm nghề, tôi đã trải qua những khoảnh khắc "toát mồ hôi" khi hệ thống sập và mọi hy vọng đều đặt vào bản backup.

"Backup không quan trọng, Restore mới quan trọng". Với Oracle, anh có một vũ khí hạng nặng là RMAN. Nhưng khi quản trị các hệ thống khác, khái niệm RMAN không tồn tại. Anh sẽ phải lắp ghép các công cụ native của OS và DB để tạo ra một chiến lược tương đương.

MODULE 11: TRIỂN KHAI AUDIT VÀ BẢO MẬT CSDL (TDE & AUDITING)

1. Tổng quan

Bảo mật cơ sở dữ liệu Enterprise xoay quanh hai trụ cột cốt lõi:

1. Data-at-Rest Encryption (TDE): Mã hóa file vật lý (.dbf, .mdf, .ibd) trên đĩa cứng. Ngăn chặn việc hacker hoặc nhân viên trộm ổ cứng mang về nhà mount lên server khác để đọc.

2. Auditing (Theo dõi vết): Ghi log lại mọi hành vi nhạy cảm (DDL, DML, Login thất bại). Hệ thống Audit chuẩn phải tách biệt quyền: DBA quản trị dữ liệu nhưng không được phép xóa log Audit.

MODULE 10: QUẢN TRỊ GIAO DỊCH ĐỒNG THỜI VÀ TỐI ƯU CSDL LỚN

1. Tổng quan

Kiểm soát đồng thời (Concurrency Control) là cách DBMS ngăn chặn các User giẫm chân lên nhau khi cùng sửa một dòng dữ liệu.

Với Oracle, nhờ kiến trúc lưu thông tin khóa (Lock) ngay trên Data Block vật lý, nó có thể xử lý hàng triệu giao dịch mà không tốn thêm RAM quản lý khóa. Tuy nhiên, ở các hệ thống khác, Lock được quản lý trên một vùng nhớ tập trung (Lock Manager). Khi RAM cạn kiệt, chúng sẽ tự động leo thang từ khóa dòng (Row Lock) lên khóa cả bảng (Table Lock), gây ra thảm họa hiệu năng.

MODULE 9: QUẢN TRỊ UNDO VÀ CƠ CHẾ MVCC

Nhắc đến Undo, chúng ta đang nói đến "trái tim" của sự bền bỉ và tính nhất quán (Read Consistency) trong cơ sở dữ liệu. Với Oracle DBA, ám ảnh lớn nhất luôn là lỗi huyền thoại ORA-01555 (Snapshot too old).

MODULE 8: QUẢN TRỊ SPACE, TUNING KHÔNG GIAN, PARTITION VÀ INDEX

Khi làm việc với các hệ thống lõi có khối lượng giao dịch khổng lồ, việc cấp phát ổ đĩa (Module 7) mới chỉ là phần vỏ. Vấn đề thực sự nằm ở bên trong: Dữ liệu bị phân mảnh (Fragmentation), Bảng quá lớn gây chậm I/O (cần Partition), và Tối ưu hóa chỉ mục (Index Tuning).

Đặc biệt với những kiến trúc đặc thù như MVCC của PostgreSQL hay Clustered Index của SQL Server, cách chúng ta "dọn dẹp" rác và quy hoạch không gian sẽ quyết định trực tiếp đến sinh tử của hiệu năng.

MODULE 7: QUẢN TRỊ STORAGE, TUNING QUY HOẠCH LƯU TRỮ

1. Tổng quan

Quy hoạch lưu trữ (Storage Provisioning) là cách chúng ta ánh xạ các đối tượng logic (Table, Index) xuống đĩa cứng vật lý (SSD/HDD) để tối ưu hóa I/O.

Trong khi Oracle dùng Tablespace, các hệ thống khác có những cách tiếp cận riêng biệt (từ Filegroup của SQL Server, Thư mục của Postgres, đến cơ chế nén WiredTiger của MongoDB). Nắm vững kiến trúc này giúp anh tránh được hiện tượng thắt cổ chai I/O khi hệ thống phình to.

MODULE 6: QUẢN TRỊ USER, ROLE VÀ SCHEMA

1. Tổng quan

Với Oracle, nguyên lý cơ bản là User = Schema. Khi anh tạo một User, Oracle tự động tạo một Schema cùng tên để chứa các Object (Table, View, Proc).

Tuy nhiên, khi bước sang SQL Server hay PostgreSQL, khái niệm này bị phá vỡ hoàn toàn. Các hệ thống này tách bạch rõ ràng giữa Người đăng nhập (Login/Role), Người dùng trong DB (User) và Vùng chứa đối tượng (Schema).

MODULE 5: CẤU HÌNH MẠNG VÀ KẾT NỐI CSDL

1. Tổng quan

Trong Oracle, Listener là một tiến trình chạy tách biệt (tnslsnr). Nếu Listener sập, các kết nối hiện tại vẫn sống nhưng kết nối mới sẽ thất bại.

Trái lại, ở SQL Server, PostgreSQL, MySQL và MongoDB, cơ chế "lắng nghe" (Bind/Listen) được tích hợp thẳng vào tiến trình lõi (Engine/Daemon). Nếu tiến trình lõi sập, toàn bộ kết nối mạng cũng ngắt ngay lập tức.

Bài học này giúp anh ánh xạ cách cấu hình IP, Port và cơ chế cho phép Client truy cập.

MODULE 4: CHI TIẾT QUẢN LÝ, CÀI ĐẶT VÀ PATCH INSTANCE CSDL

1. Tổng quan

Việc cài đặt CSDL không chỉ là bấm "Next", mà là quy trình chuẩn bị môi trường OS, quy hoạch thư mục lưu trữ, khởi tạo nhân CSDL và thiết lập bảo mật ban đầu. Anh sẽ thấy sự đối lập rất lớn giữa sự đồ sộ của Oracle và sự tinh gọn của các hệ thống mã nguồn mở.

MODULE 3: CÁC CÔNG CỤ QUẢN LÝ CSDL (GUI & CLI)

1. Tổng quan

Hệ sinh thái công cụ quản trị được chia làm 2 trường phái rõ rệt:

• Đồ họa (GUI): Dùng để theo dõi hiệu năng (Performance Monitoring), cấu hình trực quan, xem biểu đồ Execution Plan. SQL Server sở hữu công cụ GUI mạnh mẽ nhất trong thế giới RDBMS.

• Dòng lệnh (CLI): Dùng để tự động hóa (Bash/PowerShell script), chạy các file SQL dung lượng khổng lồ, hoặc cứu hộ khi server bị quá tải đến mức không thể mở nổi giao diện.