Giám sát Nhật ký Giao dịch

Trong năm qua, tôi đã viết blog nhiều lần trên SQLPerformance.com về các vấn đề hiệu suất nhật ký giao dịch (xem tại đây) và tôi đã hứa sẽ thảo luận về việc giám sát nhật ký giao dịch mà tôi sẽ thực hiện trong bài đăng này. Tôi sẽ trình bày một số chỉ số bạn có thể theo dõi, lý do bạn nên quan tâm và bất kỳ lời khuyên nào để giải quyết vấn đề đã nêu.

DMV

Cách dễ nhất để theo dõi độ trễ I / O của nhật ký giao dịch là sử dụng sys.dm_io_virtual_file_stats DMV. Bạn sẽ cần thực hiện một số phép toán để có được kết quả hữu ích và bạn có thể lấy một số mã mẫu trong tập lệnh VirtualFileStats.sql trong tệp zip demo này. Bạn thực sự muốn xem độ trễ ghi dưới 5 mili giây cho nhật ký giao dịch.

Đầu tháng 11, tôi đã viết blog về kết quả của một cuộc khảo sát cho thấy độ trễ của tệp dữ liệu tempdb và nhật ký giao dịch cho hơn 25.000 cơ sở dữ liệu trên khắp thế giới (xem tại đây), với 80% cơ sở dữ liệu đạt mức 5ms trở xuống cho độ trễ ghi nhật ký giao dịch.

Nếu độ trễ ghi của bạn cao hơn 5ms, bạn có thể:

• Làm việc để giảm lượng nhật ký được tạo và / hoặc số lượng nhật ký bị xóa xảy ra từ các giao dịch nhỏ, như tôi đã mô tả trong các bài đăng trước đó.
• Thực hiện theo một số bước khắc phục sự cố mà tôi mô tả trong bài đăng trên blog khảo sát ở trên.
• Di chuyển sang hệ thống con I / O nhanh hơn, hãy nhớ rằng nếu bạn quyết định sử dụng SSD, bạn cần sử dụng hai trong cấu hình RAID-1.

Một điều khác mà bạn có thể là theo dõi để đảm bảo rằng bạn không đạt đến giới hạn cố định là 32 I / O ghi chưa thanh toán cho từng nhật ký giao dịch của cơ sở dữ liệu trong 2008 R2 trở về trước (được nâng lên 2012 từ SQL Server 2012 trở đi). Bạn có thể thử làm điều này bằng cách xem Đĩa vật lý / Vị trí trung bình. Độ dài hàng đợi ghi trên đĩa, nhưng đó là cho toàn bộ ổ đĩa, không phải cho mỗi tệp, vì vậy nếu có bất kỳ điều gì khác trên ổ đĩa ngoài tệp nhật ký mà bạn quan tâm, điều đó sẽ không cung cấp cho bạn một con số hợp lệ. Cách tốt hơn là tổng hợp kết quả của sys.dm_io_pending_io_requests DMV, liệt kê tất cả các I / O nổi bật. Dưới đây là một số mã để làm điều đó:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Bạn có thể dễ dàng sửa đổi điều này để chỉ hiển thị kết quả cho các tệp nhật ký (lọc trên type_desc ='LOG' ) và chỉ dành cho ID cơ sở dữ liệu mà bạn quan tâm.

Nếu bạn nhận thấy rằng bạn đang đạt đến giới hạn 32 cho một cơ sở dữ liệu cụ thể, bạn có thể:

• Giảm số lần lưu nhật ký xảy ra bằng cách giảm số lượng giao dịch nhỏ và đề phòng những thứ như tách trang và các chỉ mục không sử dụng / trùng lặp bị thay đổi trong quá trình sửa đổi dữ liệu. Bạn có thể đọc thêm về cách tối ưu hóa log flushes trong bài đăng trên blog này
• Thử sử dụng hệ thống con I / O nhanh hơn
• Nâng cấp lên SQL Server 2012 hoặc cao hơn, trong đó giới hạn là 112
• Thử delayed durability feature DMV đã được thêm vào SQL Server 2014
• Phương án cuối cùng, hãy chia nhỏ khối lượng công việc qua nhiều cơ sở dữ liệu hoặc máy chủ

Nếu bạn muốn xem có bao nhiêu nhật ký giao dịch được tạo bởi các giao dịch của mình, bạn có thể sử dụng sys.dm_tran_database_transactions DMV, bằng mã tương tự như bên dưới:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Bạn có thể rất ngạc nhiên về số lượng nhật ký đang được tạo, đặc biệt là trong tempdb cho mã sử dụng các đối tượng tạm thời. Và tất nhiên, nhật ký giao dịch của tempdb có thể là một nút thắt cổ chai giống như đối với cơ sở dữ liệu người dùng.

Bộ đếm màn hình hiệu suất

Các bộ đếm hiệu suất liên quan đến nhật ký đều nằm trong đối tượng hiệu suất Cơ sở dữ liệu. Dưới đây là một số công cụ chính cần xem (với chính Performance Monitor hoặc sử dụng cảnh báo SQL Agent hoặc sử dụng sys.dm_os_performance_counters DMV hoặc trong công cụ giám sát bên thứ 3 yêu thích của bạn):

Tăng trưởng nhật ký

Bạn không muốn thấy bộ đếm này tăng lên vì điều đó cho biết có điều gì đó đang xảy ra trong cơ sở dữ liệu khiến nhiều nhật ký giao dịch được tạo hơn so với dung lượng hiện tại. Điều đó ngụ ý rằng nhật ký giao dịch không thể xóa, vì vậy bạn nên điều tra nguyên nhân bằng cách truy vấn trường log_reuse_wait_desc của sys.databases và thực hiện bất kỳ hành động nào được yêu cầu (xem chủ đề Sách trực tuyến Các yếu tố có thể trì hoãn việc cắt bớt nhật ký để biết thêm chi tiết). Một số mã ví dụ sẽ là:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Bất cứ khi nào tăng trưởng nhật ký xảy ra, phần mới được phân bổ của nhật ký giao dịch phải được xóa sạch, cộng với nhiều Tệp nhật ký ảo được thêm vào - cả hai đều có thể gây ra sự cố như tôi đã viết blog trước đây.

Nhật ký bị thu hẹp

Trừ khi bạn là người thực hiện thao tác thu nhỏ để đưa nhật ký giao dịch ngoài tầm kiểm soát trở lại trong tầm kiểm soát, bạn sẽ không muốn thấy bộ đếm này tăng lên. Nếu ai đó chỉ thu hẹp nhật ký giao dịch mà không có lý do chính đáng, nó có thể sẽ phát triển trở lại, gây ra sự cố như tôi đã viết blog trước đây.

Phần trăm nhật ký được sử dụng

Bạn nên theo dõi bộ đếm này và lo lắng nếu giá trị tăng cao hơn 90%, vì điều đó cho thấy rằng sự tăng trưởng nhật ký có thể sắp xảy ra và nhật ký giao dịch không thể xóa chính xác, như tôi đã thảo luận ở trên.

Nhật ký chờ đợi / giây

Bạn muốn giá trị này giữ nguyên hoặc giảm xuống. Nếu nó tăng lên, điều đó có nghĩa là bạn có nút thắt cổ chai của hệ thống phụ I / O hoặc nút cổ chai bên trong cơ chế xả nhật ký vì bạn đang xả nhiều phần nhỏ của nhật ký. Sự gia tăng ở đây cũng có thể tương quan với việc đạt được 32 I / Os nổi bật cho nhật ký. Xem thảo luận về sys.dm_io_pending_io_requests ở trên để biết thêm chi tiết.

Log Bytes Flush / sec và Log Flushes / sec

Hai bộ đếm này cho phép bạn tìm ra kích thước bản ghi trung bình, bằng cách chia bộ đếm thứ nhất cho bộ đếm thứ hai. Kết quả sẽ là một giá trị trong khoảng từ 512 đến 61440 (kích thước tối thiểu và tối đa của một bản ghi nhật ký, tương ứng). Giá trị càng thấp càng có nhiều khả năng tương quan với việc tăng Số chờ đợi bản ghi / giây. Một lần nữa, hãy xem cuộc thảo luận về sys.dm_io_pending_io_requests ở trên để biết thêm chi tiết.

Sự kiện mở rộng

Đối với những người nâng cao hơn trong số các bạn, có một số Sự kiện mở rộng mà bạn có thể sử dụng để xem những gì đang diễn ra với nhật ký. Tôi khuyên bạn nên bắt đầu bằng cách sử dụng mẫu Theo dõi IO Tệp Nhật ký Cơ sở dữ liệu trong SQL Server 2012 SSMS. Bạn có thể đạt được điều này bằng cách đi tới Trình khám phá đối tượng và sau đó đến phiên bản của bạn -> Quản lý -> Sự kiện mở rộng và nhấp chuột phải vào Phiên để chọn Trình hướng dẫn phiên mới. Trong Cửa sổ xuất hiện, hãy nhập tên phiên và chọn mẫu theo dõi từ trình đơn thả xuống. Sau đó nhấn Ctrl + Shift + N và phiên sẽ được chuyển sang cửa sổ truy vấn. Rất tiếc, chi tiết về mọi thứ trong đó nằm ngoài phạm vi của bài đăng này, nhưng phần mô tả mẫu khá dễ hiểu:

Ngoài ra còn có một Sự kiện mở rộng mới trong SQL Server 2012 có tên là transaction_log có thể được sử dụng để thực hiện tất cả các loại phân tích thú vị về những gì các bản ghi nhật ký đang được tạo. Đó chắc chắn là chủ đề tôi sẽ đề cập trong một bài đăng trong tương lai.

Tóm tắt

Với tất cả thông tin ở trên, bạn sẽ có thể đưa ra một hệ thống giám sát nhật ký giao dịch khá tốt. Tình trạng nhật ký giao dịch là điều tối quan trọng để đảm bảo khối lượng công việc của bạn hoạt động như bình thường và tôi hy vọng bốn bài đăng trong loạt bài này (cộng với tất cả các liên kết khác) đã giúp bạn cải thiện hiệu suất tổng thể của môi trường SQL Server của bạn.