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.
Chào mừng bạn đến với Module 15: Thực hiện recovery CSDL (Point-in-Time Recovery - PITR).
1. Tổng quan
Quá trình khôi phục thực chất luôn gồm 2 giai đoạn tách biệt mà anh cần phân định rõ:
RESTORE (Phục hồi vật lý): Chép đè các file từ bản Full Backup cũ (vd: đêm qua) trở lại hệ thống. Lúc này dữ liệu bị "cũ".
RECOVER (Phục hồi logic/Đồng bộ hóa): Áp dụng (Apply / Replay) các nhật ký giao dịch (Redo/WAL/Binlog) sinh ra từ lúc backup cho đến thời điểm anh muốn dừng lại.
2. Chi tiết các nội dung
A. Triết lý Phục hồi (Recovery Philosophy)
| Hệ thống | Bước RESTORE (Đổ bản Full) | Bước RECOVER (Áp dụng Log) | Lưu ý cực kỳ quan trọng cho DBA |
| Oracle | RESTORE DATABASE; | RECOVER DATABASE UNTIL TIME...; | Phải mở DB bằng lệnh ALTER DATABASE OPEN RESETLOGS; để cắt đứt chuỗi SCN cũ. |
| SQL Server | RESTORE DATABASE ... WITH NORECOVERY | RESTORE LOG ... WITH STOPAT = ... | Trạng thái NORECOVERY là chìa khóa. Nếu anh quên chữ này ở bản Full, DB sẽ mở online luôn và anh không thể đắp file Log lên được nữa. |
| PostgreSQL | Giải nén Base Backup ra thư mục Data. | Tạo file rỗng recovery.signal và cấu hình restore_command. | Bắt buộc phải cấu hình biến recovery_target_time trong postgresql.conf và start lại service. |
| MySQL | Restore file Dump hoặc dùng XtraBackup. | Dùng công cụ mysqlbinlog để trích xuất SQL từ Binlog. | Lệnh mysqlbinlog sẽ dịch file nhị phân thành các câu lệnh SQL để anh "chạy lại" (pipe) vào database. |
| MongoDB | Restore thư mục hoặc file BSON. | Dùng tham số --oplogReplay cùng với --oplogLimit. | Oplog phải bao trùm toàn bộ khoảng thời gian từ lúc bắt đầu backup đến thời điểm đích. |
B. "Cạm bẫy" Tail-Log Backup trong SQL Server
Đây là điểm khác biệt lớn nhất giữa kiến trúc Redo của Oracle và Transaction Log của SQL Server.
Giả sử lúc 10:00 hệ thống bị hỏng data file (.mdf), nhưng file log (.ldf) vẫn còn nguyên. Trong Oracle, tiến trình Crash Recovery sẽ tự động đọc Online Redo Log. Còn trong SQL Server, anh bắt buộc phải thực hiện một lệnh BACKUP LOG ... WITH NORECOVERY ngay tại thời điểm DB đang hỏng để lấy được đoạn log cuối cùng (Tail-log). Nếu không có nó, anh sẽ mất toàn bộ dữ liệu từ lần backup log gần nhất đến 10:00.
C. Câu lệnh Quản trị & Kết quả đầu ra (Thực hiện PITR về thời điểm 09:59:59)
Giả định: Một user vừa xóa nhầm dữ liệu lúc 10:00:00 sáng nay. Chúng ta cần quay ngược thời gian.
1. Oracle: Phục hồi qua RMAN
RMAN> RUN {
SET UNTIL TIME "TO_DATE('2026-02-25 09:59:59', 'YYYY-MM-DD HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
-- Kết quả: RMAN tự động tìm bản backup và các archivelog cần thiết, áp dụng và dừng chính xác tại giây 59.
2. SQL Server: Phục hồi bằng T-SQL theo chuỗi
USE master;
-- 1. Restore bản Full đêm qua (Giữ trạng thái NORECOVERY để đắp tiếp log)
RESTORE DATABASE sopirs_new FROM DISK = 'D:\Backup\Full.bak' WITH NORECOVERY, REPLACE;
-- 2. Đắp các file Log và dừng tại thời điểm chỉ định
RESTORE LOG sopirs_new FROM DISK = 'D:\Backup\Log_0800.trn' WITH NORECOVERY;
RESTORE LOG sopirs_new FROM DISK = 'D:\Backup\Log_1000.trn' WITH STOPAT = '2026-02-25 09:59:59', RECOVERY;
-- Kết quả: Database chuyển sang trạng thái ONLINE, dữ liệu trở về đúng 09:59:59.
3. PostgreSQL: Phục hồi qua cấu hình thư mục Data
Anh phải stop service, xóa sạch thư mục data hiện tại, giải nén bản Base Backup vào đó.
# 1. Tạo file tín hiệu báo cho Postgres biết đây là chế độ Recovery (Từ bản 12 trở lên)
touch /var/lib/pgsql/14/data/recovery.signal
# 2. Thêm các dòng sau vào postgresql.conf:
# restore_command = 'cp /mnt/nfs_backup/archive/%f %p'
# recovery_target_time = '2026-02-25 09:59:59'
# recovery_target_action = 'promote'
# 3. Start service: systemctl start postgresql-14
# Kết quả: Postgres sẽ đọc file recovery.signal, kéo các file WAL từ ổ mạng về, replay đến đúng giờ rồi tự động promote lên thành DB chính thức (xóa file signal).
4. MySQL / MariaDB: Replay Binlog
# 1. Restore bản Full
mysql -u root -p sales_db < /backup/sales_db_full.sql
# 2. Replay binlog đến trước thời điểm lỗi
mysqlbinlog --stop-datetime="2026-02-25 09:59:59" /var/lib/mysql/binlog.000012 | mysql -u root -p
# Kết quả: Mọi lệnh INSERT/UPDATE từ lúc backup đến 09:59:59 được chạy lại trên DB.
5. MongoDB: Restore kèm Oplog
mongorestore --host localhost --port 27017 --oplogReplay \
--oplogLimit "1708829999" /backup/mongo_dump/
# Lưu ý: oplogLimit sử dụng Unix Timestamp (tính bằng giây).
# Kết quả: Mongo sẽ đổ dữ liệu BSON, sau đó apply các phép tính từ oplog.bson dừng lại ngay trước timestamp giới hạn.
3. Tóm tắt lại nội dung của bài học
Nguyên tắc bất di bất dịch của phục hồi chuỗi (Log Chain): Nếu một file Log/WAL ở giữa bị hỏng hoặc mất, anh chỉ có thể phục hồi dữ liệu đến thời điểm ngay trước file hỏng đó.
Ở SQL Server, trạng thái
NORECOVERYlà yếu tố quyết định. Nó khóa database ở chế độ "đang phục hồi" (Restoring...) để sẵn sàng tiếp nhận các file Transaction Log tiếp theo. Chỉ khi nào anh dùngWITH RECOVERY, quá trình mới chốt sổ và mở DB.Ở PostgreSQL, sự hiện diện của file
recovery.signal(hoặcrecovery.confở các bản cũ trước 12) là mệnh lệnh để hệ thống Engine chuyển từ chế độ chạy bình thường sang chế độ săn tìm và Replay các file WAL.
4. Câu hỏi ôn tập
Hỏi (Oracle): Lệnh nào bắt buộc phải thực thi để mở một database sau khi quá trình Point-in-Time Recovery (Incomplete Recovery) hoàn tất?
Đáp:
ALTER DATABASE OPEN RESETLOGS;.
Hỏi (SQL Server): Nếu anh restore một bản Full Backup và quên không thêm mệnh đề
WITH NORECOVERY(mặc định SQL Server sẽ dùngWITH RECOVERY), hệ quả là gì nếu anh muốn đắp thêm file Transaction Log?Đáp: Database sẽ thực hiện bước Undo các giao dịch chưa commit, chốt sổ và mở ONLINE ngay lập tức. Anh không thể đắp thêm bất kỳ file Log nào nữa và buộc phải Restore lại bản Full từ đầu.
Hỏi (PostgreSQL): Tham số
recovery_target_action = 'promote'trong file cấu hình có ý nghĩa gì khi quá trình PITR đạt đến thời điểm mục tiêu?Đáp: Nó chỉ thị cho PostgreSQL tự động dừng quá trình khôi phục, xóa file
recovery.signal, và mở Database ở chế độ Đọc/Ghi bình thường (Promote thành Primary).
Hỏi (MySQL): Công cụ CLI nào được sử dụng để trích xuất các câu lệnh SQL từ file Binary Log và giới hạn theo thời gian (datetime) để phục vụ cho quá trình PITR?
Đáp: Công cụ
mysqlbinlog.
Hỏi (MongoDB): Khi sử dụng
mongorestoređể khôi phục về một thời điểm, tham số--oplogLimityêu cầu định dạng thời gian đầu vào là gì?Đáp: Unix Epoch Timestamp (tổng số giây tính từ 01/01/1970).
5. Bài tập thực hành (Xử lý tình huống khôi phục cơ bản)
Đề bài tình huống: Hệ thống DB UAT vừa bị hỏng do ổ cứng đầy, anh quyết định xóa sạch và đắp lại bản Full Backup đêm qua (không cần PITR, chỉ cần Restore bản Full). Hãy viết lệnh thực hiện Restore bản Full Backup vật lý (hoặc Logic) và mở DB sử dụng bình thường cho 5 hệ thống.
Đáp án:
1. Oracle: (Dùng RMAN, giả sử đã rớt xuống trạng thái MOUNT)
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;
2. SQL Server: (Dùng T-SQL khôi phục đè lên DB hiện tại và mở luôn)
RESTORE DATABASE sopirs_new
FROM DISK = 'D:\Backup\Full.bak'
WITH REPLACE, RECOVERY;
3. PostgreSQL: (Các bước OS)
# 1. Stop service
systemctl stop postgresql-14
# 2. Xóa sạch thư mục data cũ
rm -rf /var/lib/pgsql/14/data/*
# 3. Giải nén bản base backup vào lại thư mục
tar -xvf /backup/base_backup.tar.gz -C /var/lib/pgsql/14/data/
# 4. Start service (DB sẽ tự khởi động và dùng được ngay)
systemctl start postgresql-14
4. MySQL / MariaDB: (Đổ file dump SQL vào DB trống)
# Giả sử đã tạo sẵn schema rỗng sales_db
mysql -u root -p sales_db < /backup/sales_db_full.sql
5. MongoDB: (Restore thư mục BSON)
mongorestore --host localhost --port 27017 --drop /backup/mongo_dump/
# Tham số --drop sẽ xóa sạch collection cũ trước khi đổ data mới vào
Khép lại bài toán sống còn về Recovery, anh đã trang bị đủ "võ công" để bảo vệ an toàn cho bất kỳ loại CSDL nào.
Tiếp theo, ở Module 16: Chuyển dữ liệu, migration database, chúng ta sẽ đối mặt với một thách thức nâng cao hơn: Làm sao để bốc toàn bộ hệ thống cũ đẩy lên hạ tầng mới (hoặc Cloud) với thời gian Downtime bằng 0 (Zero Downtime Migration)
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
