2 lý do nên lưu trữ Data file và Log file trên...

2 lý do nên lưu trữ Data file và Log file trên những đĩa cứng khác nhau

Khi tạo mới một database, mặc định SQL Server sẽ tạo 2 file là Data file (.MDF) và Log file (.LDF). Nếu bạn không thay đổi gì thì SQL Server sẽ tạo 2 file này trong cùng một thư mục DATA nằm ở thư mục cài đặt SQL Server; ví dụ với SQL Server 2008 là “C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA”. Lời khuyên quan trọng từ Microsoft và các chuyên gia SQL Server là bạn nên lưu trữ tách biệt 2 file này ở 2 đĩa cứng vật lý (Physical drive) khác nhau.

Vì sao nên làm như vậy? Câu trả lời là điều này giúp năng cao hiệu năng xử lý dữ liệutăng khả năng phục hồi khi sự cố xảy ra. Cùng tìm hiểu 2 lợi ích này từ phân tích bên dưới.

Hiệu năng xử lý dữ liệu

Tìm hiểu một chút về cách thức lưu trữ của SQL Server, chúng ta sẽ biết rằng Data file được truy xuất theo cơ chế ngẫu nhiên (random), còn Log file được truy xuất theo cơ chế tuần tự (serial). Với thao tác SELECT, hầu như không có mối liên hệ nào trong truy xuất dữ liệu của Data file và Log file. Vì với SELECT thì SQL Server không cần truy xuất Log file mà chỉ cần đọc dữ liệu từ Data file.

Tuy nhiên, khi tiến hành các thao tác cập nhật INSERT/UPDATE/DELETE, SQL Server cần ghi nhận mọi thay đổi vào các record trong Log file trước khi tiến hành thay đổi dữ liệu thật sự trong Data file. Nghĩa là đĩa cứng cần xử lý I/O cho cả Data file và Log file. Vì thế, nếu Data file và Log file nằm trên cùng đĩa cứng thì hiệu năng xử lý sẽ bị hạn chế rất nhiều do spindle của đĩa cứng phải thay đổi vị trí liên tục để đáp ứng đồng thời I/O của 2 loại file này.

Nếu mỗi file nằm trên một đĩa cứng khác nhau, quá trình truy xuất Data file và Log file là hoàn toàn độc lập về khía cạnh vật lý (đĩa cứng). Do đó hiệu năng xử lý sẽ cải thiện đáng kể.

Free eBook: Download ebook 8 lưu ý quan trọng khi sao lưu & phục hồi SQL Server. Những kinh nghiệm hữu ích giúp bạn sao lưu an toàn và đảm bảo khả năng phục hồi khi sự cố mất dữ liệu xảy ra với database SQL Server.

Khả năng phục hồi dữ liệu

Với các RDBMS như SQL Server thì Log file đóng vai trò cực kỳ quan trọng. Bất cứ thao tác nào cần thay đổi dữ liệu nào đều phải được ghi nhận vào Log file trước khi tiến hành thay đổi thật sự lên Data file. Do đó, với Log file, SQL Server biết được tất cả thao tác đã làm thay đổi dữ liệu. Nên giúp SQL Server có thể tiến hành lại những thao tác này (redo) để khôi phục (recovery) nếu lỗi xảy ra với database.

Nếu database đang hoạt động và có sự cố nào đó bất thình lình xảy ra gây hư hỏng hoặc thậm chí mất hẳn Data file. Bạn có thể phục hồi database từ bản sao lưu Full database (và các bản sao lưu Differential database, Transaction log liền kề sau đó). Nếu bạn vừa tiến hành sao lưu ngay trước khi sự cố xảy ra. Hẳn nhiên quá trình phục hồi từ các bản sao lưu này có thể giúp bạn khôi phục database về thời điểm ngay trước sự cố. Nhưng đây là may mắn ít khi xảy ra. Tình huống thường gặp là lần sao lưu gần nhất đã cách thời điểm sự cố một khoàng thời gian không nhỏ (VD: sự cố xảy ra lúc 16h45 hôm nay, còn bản sao lưu gần nhất là 18h00 đêm hôm qua). Điều này có nghĩa khi phục hồi database từ bản sao lưu gần nhất, bạn vẫn bị mất lượng dữ liệu phát sinh từ thời điểm sao lưu gần nhất đến thời điểm có sự cố.

Vậy có cách nào để phục hồi database trở về thời điểm ngay trước khi sự cố xảy ra (chẳng hạn 1 giây trước đó)?  Câu trả lời là CÓ THỂ. Với điều kiện Log file của database vẫn còn.

Lúc đó, bạn có thể tiến hành sao lưu Log file này (SQL Server gọi là Tail-log backup). Vì Log file này chứa tất cả thao tác đã thay đổi lên dữ liệu kể từ thời điểm sao lưu Transaction log gần nhất đến thời điểm sự cố xảy ra. Nên từ bản sao lưu Tail-log backup này, bạn có thể phục hồi database trở về thời điểm ngay trước sự cố.

Bạn không nên hiểu nhầm rằng không thể tiến hành sao lưu Transaction log của database khi Data file của database đó không còn. Thực tế, bạn vẫn có thể sao lưu Log file bằng lệnh BACKUP LOG với tùy chọn NO_TRUNCATE:

BACKUP LOG ERP
TO DISK = ‘E:\SQLBackupData\DATABASE_ERP_TAIL_LOG.bak’
WITH NO_TRUNCATE
GO

Đến đây, chắc hẳn bạn đã hiểu rõ vì sao nên lưu trữ Log file ở ổ đĩa (tốt nhất là đĩa cứng Physical drive) khác với Data file. Việc này nhằm giúp Log file có thể không bị ảnh hưởng khi lỗi xảy ra với Data file. Tất nhiên nếu sự cố làm mất cả Data file và Log file thì bạn chỉ có thể phục hồi dữ liệu trở về thời điểm ở bản sao lưu gần nhất.

Thông tin: Nếu vì hạn chế về hardware khiến bạn không thể lưu Data file và Log file trên những đĩa cứng vật lý (Physical drive) khác nhau nhằm giúp tăng hiệu năng truy xuất. Bạn vẫn nên lưu trên những ổ đĩa khác nhau (VD: Data file lưu ở ổ C, Log file lưu ở ổ D) để lỗi xảy ra với ổ C nhưng có thể không ảnh hưởng đến ổ D. Lúc đó, bạn vẫn còn Log file để tiến hành phục hồi.

Để di dời Log file sang thư mục mới (ở một đĩa cứng khác với Data file), bạn tham khảo thêm bài viết Di dời Log file sang thư mục khác.

# Giải pháp sao lưu dữ liệu toàn diện cho SQL Server

Giúp giảm RPO từ 24 giờ xuống 30 phút

Với khả năng sao lưu offsite tự động cùng công nghệ In-File Delta, zBackup giúp bạn dễ dàng sao lưu Transaction Log với tần suất 30 phút/lần. Nhờ đó, bất kỳ lúc nào sự cố xảy ra với SQL Server, bạn đều có thể phục hồi dữ liệu trở về thời điểm cách xa nhất 30 phút trước.

Xem cách zBackup sao lưu SQL Server ››