Nhật ký giao dịch là gì?
Có một yêu cầu trong hệ thống cơ sở dữ liệu quan hệ là các giao dịch phải bền. Đây là "D" trong thuộc tính ACID của các giao dịch. Hệ thống phải đảm bảo rằng nếu một sự cố đột ngột xảy ra, giao dịch có thể được thực hiện lại. SQL Server đáp ứng yêu cầu này bằng cách ghi lại tất cả các giao dịch trong một tệp vật lý được gọi là tệp nhật ký giao dịch .
Về bản chất, mỗi khi giao dịch được cam kết, SQL Server sẽ ghi lại các thay đổi do giao dịch đó tạo ra trong nhật ký giao dịch. Ngay cả khi giao dịch không được lưu trong tệp dữ liệu, nó vẫn có trong nhật ký giao dịch và có thể được phát lại trong trường hợp xảy ra sự cố đột ngột.
Mô hình khôi phục và Nhật ký giao dịch
SQL Server hoạt động theo ba mô hình khôi phục - Đầy đủ, Ghi nhật ký hàng loạt và Đơn giản.
Trong chế độ Khôi phục hoàn toàn, TẤT CẢ các giao dịch đều được ghi lại. Do đó, cơ sở dữ liệu có thể được khôi phục hoàn toàn nếu xảy ra sự cố. Điều này cũng có nghĩa là bản sao lưu cơ sở dữ liệu có thể được khôi phục đến một thời điểm cụ thể nếu giao dịch hoặc bản sao lưu liên quan có sẵn. Trong các chế độ Khôi phục được ghi nhật ký hàng loạt và đầy đủ, nhật ký giao dịch bị cắt ngắn bất cứ khi nào có bản sao lưu nhật ký được thực hiện.
Trong chế độ Khôi phục đơn giản, TẤT CẢ các giao dịch vẫn được ghi lại. Tuy nhiên, thao tác ghi nhật ký giao dịch bị cắt bớt mỗi khi cơ sở dữ liệu thực thi điểm kiểm tra.
Điểm kiểm tra xảy ra khi SQL Server ghi bộ đệm bẩn vào tệp dữ liệu. Bộ đệm bẩn là các trang thiết yếu được lưu trữ trong bộ nhớ đã bị thay đổi bởi các giao dịch, chẳng hạn như trạng thái trong bộ nhớ không khớp với trạng thái trong đĩa. Tuy nhiên, chúng tôi sẽ không thảo luận về vấn đề này ở đây. Trong chế độ Khôi phục đơn giản, SQL Server nắm bắt tất cả những thay đổi này trong Nhật ký giao dịch để giữ chúng cho đến khi chúng được duy trì.
Cấu trúc nhật ký giao dịch
Nhật ký giao dịch là một tệp vật lý hiển thị trên lớp Hệ điều hành của máy chủ nơi lưu trữ cơ sở dữ liệu SQL Server. Mỗi cơ sở dữ liệu có một bản ghi giao dịch, nhưng có thể cấu hình nhiều hơn. Vấn đề là, có nhiều bản ghi SQL giao dịch không mang lại bất kỳ lợi thế hiệu suất nào. SQL Server ghi tuần tự vào nhật ký giao dịch - một tệp phải đầy trước khi tệp tiếp theo được sử dụng. Tuy nhiên, nhiều tệp nằm trên các đĩa riêng biệt có thể lưu trong ngày nếu tệp đầu tiên bị đầy.
Bên trong, tệp nhật ký giao dịch là một loạt các tệp nhật ký ảo. Kích thước và số lượng của những tệp đó ảnh hưởng đến thời gian cần thiết để sao lưu cơ sở dữ liệu hoặc đưa nó lên mạng. Luôn luôn là một ý tưởng hay để định kích thước nhật ký giao dịch phù hợp và đảm bảo cài đặt tự động tăng trưởng phù hợp với mức độ hoạt động dự kiến. Sau đó, tốc độ tăng tệp sẽ không xảy ra quá thường xuyên.
Điều gì làm cho nhật ký phát triển?
Hãy bắt đầu bằng cách tạo một cơ sở dữ liệu nhỏ bằng cách sử dụng mã trong Liệt kê 1. Tệp dữ liệu có kích thước 4MB, tệp nhật ký là 2MB để bắt đầu. Cơ sở dữ liệu sản xuất của bạn sẽ không bao giờ có kích thước như vậy, đặc biệt là với thực tiễn phổ biến là phân bổ trước . Chúng tôi chọn những kích thước như vậy chỉ cho mục đích trình diễn.
-- Listing 1: Create a Small Database
create database tranlogexperiment
on primary
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go
Trong cơ sở dữ liệu đó, chúng tôi tạo một bảng duy nhất cho các câu lệnh ngôn ngữ thao tác dữ liệu (DML) hơn nữa (Liệt kê 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
Bằng cách thực thi mã trong Liệt kê 3, chúng tôi kiểm tra và xác minh những gì chúng tôi đã làm.
-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';
select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');
Chú ý đến Kích thước tệp cột. Chúng tôi tiến hành gọi tăng trưởng nhật ký giao dịch bằng cách chạy INSERT và DELETE 100.000 lần (Liệt kê 4).
-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000
Liệt kê 4 chèn một hàng vào txn_log bảng và xóa cùng một hàng, lặp lại hành động này 100.000 lần.
Nhìn chung, bảng không phát triển do hoạt động này, nhưng nhật ký giao dịch tăng đáng kể. Khi chúng tôi lặp lại truy vấn trong Liệt kê 3 sau khi chạy câu lệnh DML từ Liệt kê 4, chúng tôi thấy nhật ký giao dịch đã phát triển đến mức nào:
Nhật ký giao dịch đã tăng từ 4MB lên 40MB do hoạt động này mặc dù kích thước tệp dữ liệu không thay đổi. Điều này cho chúng ta thấy rõ ràng rằng kích thước nhật ký giao dịch không liên quan nhiều đến kích thước dữ liệu. Tác động lên kích thước là từ hoạt động (DML) diễn ra trên cơ sở dữ liệu.
Làm cách nào để chúng tôi quản lý nhật ký giao dịch?
Quản trị viên cơ sở dữ liệu quản lý các phiên bản cài đặt IaaS SQL Server tại chỗ nên sao lưu thường xuyên các bản ghi giao dịch. Sẽ rất hữu ích nếu bạn có các cấu hình khôi phục sau thảm họa như Log Shipping hoặc AlwaysOn AG . Các cấu hình như vậy sẽ tự động sao lưu.
Ở chế độ khôi phục hoàn toàn, bản sao lưu nhật ký SQL Server sẽ cắt bớt các phần nhật ký giao dịch không còn cần thiết để khôi phục. Việc cắt bớt nhật ký sẽ xóa các tệp nhật ký ảo không hoạt động. Bằng cách này, nó xóa không gian trong nhật ký giao dịch để sử dụng lại.
Mã trong Liệt kê 6 hiển thị kích thước của nhật ký giao dịch và dung lượng trống mà chúng tôi có trong đó.
-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name],
name AS [Logical File Name],
type_desc,
size/128.0 AS [Current Size (MB)],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);
Chúng tôi cũng có thể thu nhỏ nhật ký giao dịch vật lý bằng cách sử dụng mã trong Liệt kê 7. Trước khi thu nhỏ, hãy đảm bảo có một bản sao lưu của nhật ký giao dịch. Trong quá trình sản xuất, tốt nhất bạn nên lên lịch sao lưu nhật ký để tránh tăng trưởng tệp nhật ký vật lý không kiểm soát và đảm bảo dữ liệu được bảo toàn. Với tùy chọn khôi phục thảm họa như Log Shipping hoặc AlwaysOn AG đã được định cấu hình, điều này đã được cấp.
Chúng tôi có thể truy vấn log_reuse_wait_desc trên sys.databases xem danh mục để xác định bất kỳ điều kiện nào ngăn nhật ký giao dịch bị thu nhỏ. Lưu ý rằng chúng tôi đã truy vấn cột này trong Liệt kê 3.
Các điều kiện đó có thể là một điểm kiểm tra đang chờ xử lý, một bản sao lưu nhật ký đang chờ xử lý, sao lưu hoặc khôi phục đang diễn ra, một giao dịch đang hoạt động trong thời gian dài và các hoạt động tương tự trong cơ sở dữ liệu.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Chúng tôi sử dụng mã trong Liệt kê 8 để sao lưu cơ sở dữ liệu. Trong trường hợp cụ thể của chúng tôi, trước tiên chúng tôi phải tạo một bản sao lưu đầy đủ vì các bản sao lưu nhật ký luôn tham chiếu đến một bản sao lưu đầy đủ. Bản sao lưu đầy đủ “cuối cùng” bắt đầu chuỗi khi xử lý khôi phục tại thời điểm.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Khi chạy cơ sở dữ liệu ở chế độ Khôi phục đơn giản, nhật ký giao dịch bị cắt ngắn ở mọi điểm kiểm tra . Trong chế độ này, không thể sao lưu nhật ký.
Vị trí của tệp nhật ký giao dịch phải được định kích thước phù hợp để phù hợp với các giao dịch dài hạn thỉnh thoảng xảy ra. Nếu không, nhật ký giao dịch vẫn có thể lấp đầy dung lượng ổ đĩa. Hình 4 cho thấy những gì xảy ra với nhật ký trong nội bộ khi một bản sao lưu được thực hiện. Lưu ý rằng tệp vật lý vẫn còn 40 MB, nhưng hiện chúng tôi có khoảng 37 MB dung lượng trống.
Điều gì xảy ra trong Chế độ khôi phục đơn giản?
Bây giờ, hãy để chúng tôi thiết lập tranlogexperiment cơ sở dữ liệu sang chế độ Khôi phục đơn giản.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Khi chúng tôi thực thi mã được trình bày trước đó trong Liệt kê 4, chúng tôi sẽ nhận được hành vi hơi khác một chút.
Hình 6 cho thấy sự tăng trưởng của nhật ký giao dịch trong chế độ Khôi phục đơn giản khi chúng ta thực thi mã trong Liệt kê 4. Kích thước của tệp nhật ký vật lý chỉ là 15 MB. Nó ít hơn một nửa so với mô hình Khôi phục đầy đủ trước đó. Ngoài ra, hãy lưu ý không gian trống là 11,5 MB.
Điều đó có nghĩa là có ít tăng trưởng nhật ký hơn?
Hình 7 cho thấy rằng trong khi phiên đang được thực thi, Máy chủ SQL của chúng tôi cũng thực hiện một số điểm kiểm tra. Điều này đã cắt ngắn nhật ký và tạo khoảng trống cho các giao dịch để tiếp tục nhật ký ngày càng tăng trong khoảng thời gian.
Kết luận
Nhật ký giao dịch là một thành phần cực kỳ quan trọng của cơ sở dữ liệu SQL Server. Nó tác động đến mọi thứ yêu cầu hoặc dựa vào khôi phục - sao lưu, khôi phục, khôi phục sau thảm họa, v.v. Bạn cũng có thể ghi lại hoạt động db.
Trong bài viết này, chúng tôi đã thảo luận về bản chất của nhật ký giao dịch, các khía cạnh của việc quản lý nó đúng cách và chứng minh hoạt động của DML trong cơ sở dữ liệu có chế độ Khôi phục đầy đủ hoặc Đơn giản tại chỗ. Tuy nhiên, còn nhiều điều cần tìm hiểu về nhật ký giao dịch. Các mục trong tài liệu tham khảo sẽ là một điểm khởi đầu tốt cho bạn.
Tham khảo s
- Nhật ký giao dịch
- Cơ sở dữ liệu và lưu trữ SQL Server
Cũng đọc
Tầm quan trọng của nhật ký giao dịch trong SQL Server
