Nhật ký giao dịch SQL Server

Mọi cơ sở dữ liệu SQL Server đều chứa một hoặc nhiều tệp nhật ký giao dịch ngoài tệp dữ liệu. Các tệp nhật ký ghi lại tất cả các giao dịch và sửa đổi cơ sở dữ liệu được thực hiện bởi từng giao dịch.

Bài viết này tập trung vào nhật ký giao dịch và cách SQL Server ghi nhật ký sửa đổi dữ liệu để sử dụng dữ liệu cho việc khôi phục sự cố cơ sở dữ liệu.

Giới thiệu về tệp nhật ký giao dịch SQL Server

Như chúng ta nhớ, mỗi giao dịch là "tất cả hoặc không có gì". Nếu một phần của giao dịch không thành công, toàn bộ giao dịch không thành công và trạng thái cơ sở dữ liệu vẫn không thay đổi.

SQL Server lưu trữ bản ghi của mỗi giao dịch được thực hiện trên cơ sở dữ liệu vào tệp nhật ký. Nếu một số thảm họa dẫn đến việc máy chủ SQL ngừng hoạt động, nó sẽ sử dụng nhật ký giao dịch để khôi phục cơ sở dữ liệu về trạng thái nhất quán với tính toàn vẹn của dữ liệu.

Sau khi khởi động lại, SQL Server bắt đầu quá trình khôi phục sự cố. Nó đọc tệp nhật ký giao dịch để đảm bảo rằng tất cả dữ liệu hợp lệ được lưu trữ trong tệp dữ liệu và các giao dịch chưa được cam kết sẽ được khôi phục lại.

Trong quá trình hoạt động bình thường, SQL Server cũng sử dụng nhật ký giao dịch. Thông tin có trong tệp là cần thiết để xác định những gì SQL Server cần làm khi một giao dịch quay trở lại do lỗi hoặc câu lệnh ROLLBACK do người dùng chỉ định.

Cách máy chủ SQL sử dụng nhật ký giao dịch

Nhật ký giao dịch là một tệp vật lý có phần mở rộng là LDF . SQL Server tự động tạo nó cho bất kỳ cơ sở dữ liệu mới nào cùng với tệp dữ liệu chính (. MDF ) lưu trữ các đối tượng cơ sở dữ liệu và chính dữ liệu.

Bất cứ khi nào mã T-SQL thay đổi đối tượng cơ sở dữ liệu hoặc dữ liệu mà nó chứa, chi tiết về thay đổi được ghi lại dưới dạng bản ghi nhật ký trong tệp nhật ký giao dịch.

Bản ghi nhật ký chứa thông tin về một thay đổi cụ thể được thực hiện đối với cơ sở dữ liệu (ví dụ:chèn một hàng duy nhất). Do đó, chúng tôi sẽ có một loạt các bản ghi nhật ký để mô tả đầy đủ các tác động của một giao dịch.

Kiến trúc nhật ký giao dịch

Số thứ tự nhật ký

Bản ghi nhật ký có Số thứ tự nhật ký duy nhất, tự động tăng dần ( LSN ), cho phép chúng tôi tìm thấy bản ghi này trong nhật ký giao dịch. LSN mô tả sự thay đổi dữ liệu và chứa các thông tin sau:

hoạt động và hàng bị ảnh hưởng
phiên bản cũ và mới của dữ liệu
giao dịch đã thực hiện sửa đổi

LSN bao gồm ba số:

LSN =::

Mỗi trang tệp dữ liệu có LSN trong tiêu đề trang của nó để xác định bản ghi nhật ký gần đây nhất mà sự thay đổi được phản ánh trên trang. Điều này rất quan trọng để khôi phục sự cố.

Khi khôi phục sự cố chạy, nó sẽ so sánh các LSN của bản ghi nhật ký cho các giao dịch đã cam kết hoặc chưa cam kết với các LSN trong các trang tệp dữ liệu để xác định xem có bất kỳ thao tác làm lại hoặc hoàn tác nào được thực hiện trên các bản ghi nhật ký cụ thể đó hay không.

Khi bạn tạo cơ sở dữ liệu, một phương pháp hay là chỉ định kích thước của nhật ký giao dịch . Nếu bạn không làm điều này, SQL Server sẽ tự động tạo nhật ký giao dịch với kích thước mặc định.

Kích thước mặc định của nhật ký giao dịch của cơ sở dữ liệu mới lớn hơn 0,5MB hoặc 25% tổng kích thước của tất cả các tệp dữ liệu được tạo trong cùng một câu lệnh CREATE DATABASE.

Bạn phải rất cẩn thận vì các phần mới của nhật ký giao dịch luôn không được khởi tạo . Nếu bạn có câu lệnh CREATE DATABASE mà không chỉ định kích thước tệp nhật ký và bạn tạo, chẳng hạn như cơ sở dữ liệu 1TB, SQL Server sẽ tạo nhật ký giao dịch 250GB.

Vì nhật ký phải được khởi tạo bằng 0, nó không sử dụng tính năng khởi tạo tệp tức thì. Tính năng này đã được thêm vào SQL Server 2005 để cho phép các tệp dữ liệu được tạo hoặc phát triển gần như ngay lập tức.

Chúng tôi có thể thấy điều gì đang xảy ra khi chúng tôi TẠO CƠ SỞ DỮ LIỆU - quá trình khởi tạo bằng không xảy ra đối với nhật ký của chúng tôi bằng cách sử dụng cờ theo dõi 3004 in thông báo về không khởi tạo và cờ theo dõi 3605 cho phép in các thông báo nhật ký đó bằng cờ theo dõi 3004.

Bản trình diễn sau đây cho thấy cách bạn có thể thấy việc giảm tải tệp nhật ký đang diễn ra.

1. Thực thi tập lệnh sau để đảm bảo rằng chúng tôi không có cơ sở dữ liệu được gọi là DBTest2014

USE master;
GO
 
IF DATABASEPROPERTY(N'DBTest2014', N'Version')>0
  BEGIN
    ALTER DATABASE DBTest2014 SET SINGLE_USER
      WITH ROLLBACK IMMEDIATE;
    DROP DATABASE DBTest2014;
  END
GO

2. Bật cờ theo dõi để xem không khởi tạo

DBCC TRACEON (3605, 3004, -1);
GO
3. Flush the error log
EXEC sp_cycle_errorlog;
GO

3. Tạo cơ sở dữ liệu

CREATE DATABASE DBTest2014 ON PRIMARY (
  NAME = N'DBTest2014',
  FILENAME = N'D:\DBTest2014_data.mdf')
LOG ON (
  NAME= N'DBTest2014_log',
  FILENAME= N'D:\DBTest2014_log.ldf',
  SIZE = 10MB,
  FILEGROWTH = 10 MB);
GO

4. Đọc tệp nhật ký lỗi

EXEC sys.xp_readerrorlog;
GO

Tệp nhật ký ảo

Nhật ký giao dịch được chia nội bộ thành một loạt các phần được gọi là tệp nhật ký ảo ( VLF ) để đơn giản hóa việc quản lý.

Bất cứ khi nào một bản ghi giao dịch được tạo, nó sẽ cung cấp một số lượng VLF nhất định. Các VLF mới được tạo không hoạt động và không được sử dụng. Một VLF đang hoạt động không thể được sử dụng lại cho đến khi nó không hoạt động bằng cách xóa nhật ký.

Tuy nhiên, có một ngoại lệ - VLF đầu tiên trong cơ sở dữ liệu mới luôn hoạt động vì bất kỳ nhật ký giao dịch nào cũng phải có ít nhất một VLF đang hoạt động.

Mọi tệp nhật ký cũng có trang tiêu đề tệp mất 8KB ở đầu tệp nhật ký giao dịch. Trang tiêu đề tệp lưu trữ siêu dữ liệu về tệp, chẳng hạn như cài đặt kích thước và tăng trưởng tự động.

Số lượng và kích thước của VLF trong phần mới của nhật ký giao dịch được xác định bởi SQL Server. Không thể định cấu hình nó .

Nếu kích thước mới được thêm vào là:

<1MB không thích hợp để thảo luận
<64MB sẽ có 4 VLF mới (mỗi VLF là 1/4 kích thước tăng trưởng)
64MB đến 1GB sẽ có 8 VLF mới (mỗi VLF là 1/8 kích thước tăng trưởng)
> 1GB sẽ có 16 VLF mới (mỗi VLF là 1/16 của kích thước tăng trưởng)

Điều này áp dụng cho nhật ký giao dịch được tạo ban đầu và cho mỗi lần tăng trưởng thủ công hoặc tự động xảy ra. Khi bạn biết công thức về số lượng VLF tiềm năng và kích thước tiềm năng của chúng, nó sẽ giúp quản lý nhật ký. Quá ít hoặc quá nhiều VLF có thể gây ra các vấn đề về hiệu suất với các hoạt động trong nhật ký giao dịch.

Số thứ tự VLF

Mọi VLF đều có một số thứ tự để xác định duy nhất VLF trong nhật ký giao dịch. Số thứ tự tăng lên một mỗi khi hệ thống quản lý nhật ký kích hoạt VLF tiếp theo. Chuỗi số thứ tự cung cấp tập hợp VLF hiện đang hoạt động.

Phần bắt đầu của phần hoạt động của nhật ký giao dịch bắt đầu bằng một VLF có số thứ tự thấp nhất và vẫn đang hoạt động. Các VLF không hoạt động có số thứ tự, nhưng chúng không phải là một phần của phần nhật ký hoạt động.

Phần hiện hoạt của nhật ký có các bản ghi nhật ký được SQL Server yêu cầu vì một số lý do.

Khi bạn tạo cơ sở dữ liệu mới lần đầu tiên, số thứ tự VLF sẽ không bắt đầu bằng 1. Chúng bắt đầu bằng bất kỳ số thứ tự VLF cao nhất nào trong nhật ký giao dịch cơ sở dữ liệu mô hình, cộng với 1 . Không thể dùng hết số thứ tự VLF. SQL Server có mã sẽ buộc phiên bản phải tắt nếu số thứ tự VLF bao quanh bằng 0 (nếu số thứ tự VLF tiếp theo nhỏ hơn số trước đó).

VLF và khối nhật ký

Trong các VLF, có các khối nhật ký có kích thước khác nhau. Kích thước tối thiểu của khối nhật ký là 512 byte và khối nhật ký tăng lên đến kích thước tối đa là 60 KB . Kích thước được đặt khi một trong các trường hợp sau xảy ra:

Một giao dịch tạo một bản ghi nhật ký để cam kết kết thúc việc hủy bỏ một giao dịch
Kích thước khối nhật ký đạt 60KB mà không cần cam kết hoặc hủy bỏ giao dịch

Có các bản ghi nhật ký bên trong một khối nhật ký (được tô màu trên sơ đồ). Bản ghi nhật ký cũng có kích thước khác nhau. Biểu đồ cho thấy rằng các bản ghi nhật ký từ nhiều giao dịch đồng thời có thể tồn tại trong cùng một khối nhật ký. Các bản ghi nhật ký được lưu trữ theo thứ tự được viết tương tự như tệp trang dữ liệu.

Mọi VLF đều chứa một tiêu đề VLF với thông tin sau:

Cho dù VLF đang hoạt động hay không.
Số thứ tự nhật ký khi VLF được tạo.
Các bit chẵn lẻ hiện tại cho tất cả các khối 512 byte trong VLF.

Các bit chẵn lẻ bắt đầu ở 64 trong lần đầu tiên sử dụng VLF. Nếu VLF không hoạt động, nhưng được kích hoạt lại thêm, các bit chẵn lẻ sẽ trở thành 128. Các bit này được sử dụng trong quá trình khôi phục sự cố.

Kiểm tra chi tiết nhật ký giao dịch - DBCC LOGINFO

Cách duy nhất để xem cấu trúc nhật ký giao dịch là sử dụng DBCC LOGINFO không có giấy tờ yêu cầu. Cú pháp của lệnh là:

DBCC LOGINFO [({'dbname | dbid'})]

Nếu bạn không chỉ định dbname và dbid , nó sẽ kết xuất cho bạn nội dung nhật ký cho cơ sở dữ liệu hiện tại.

Kết quả là một hàng cho mỗi VLF có trong nhật ký giao dịch cho cơ sở dữ liệu đó. Các trường được trả về là:

RecoveryUnitId - được thêm vào SQL Server 2012 nhưng hiện không được sử dụng
FileId - ID tệp nhật ký giao dịch trong cơ sở dữ liệu.
Kích thước tệp - Kích thước VLF tính bằng byte.
StartOffset - khoảng bù bắt đầu của VLF trong tệp nhật ký giao dịch, tính bằng byte
FSeqNo - Số thứ tự VLF
Trạng thái - Cho dù VLF đang hoạt động hay không (0 =không hoạt động, 2 =hoạt động, 1 - không được sử dụng)
Chẵn lẻ - các bit chẵn lẻ hiện tại (64 hoặc 128 hoặc 0 nếu VLF chưa bao giờ hoạt động)
CreateLSN - LSN khi VLF được tạo (0 =VLF được tạo khi tệp nhật ký giao dịch được tạo ban đầu). Tất cả các VLF khác được thêm vào sau khi tạo tệp nhật ký giao dịch lần đầu sẽ có CreateLSN khác không.

Chúng tôi có thể thực thi lệnh sau cho DBTest2014 cơ sở dữ liệu mà chúng tôi đã tạo trước đó:

DBCC LOGINFO (N'DBTest2014');
GO

Xem kết quả:

DBCC SQLPERF (LOGSPACE)

Cách duy nhất trong Transact-SQL để kiểm tra lượng nhật ký được sử dụng là DBCC SQLPERF. Cú pháp của lệnh là:

DBCC SQLPERF
(
     [ LOGSPACE ]
     |
          [ "sys.dm_os_latch_stats" , CLEAR ]
     |
     [ "sys.dm_os_wait_stats" , CLEAR ]
)
     [WITH NO_INFOMSGS ]

Lệnh trả về một tập hợp kết quả với một hàng trên mỗi cơ sở dữ liệu: