Trong nhiều khối lượng công việc của SQL Server, đặc biệt là OLTP, nhật ký giao dịch của cơ sở dữ liệu có thể là một nút thắt cổ chai làm tăng thêm thời gian cần một giao dịch để hoàn thành. Hầu hết mọi người đều cho rằng hệ thống con I / O là nút thắt cổ chai thực sự, nó không thể theo kịp lượng nhật ký giao dịch được tạo bởi khối lượng công việc.
Độ trễ ghi nhật ký giao dịch
Độ trễ của các hoạt động ghi vào nhật ký giao dịch có thể được theo dõi bằng cách sử dụng sys.dm_io_virtual_file_stats DMV và tương quan với WRITELOG đợi đang xảy ra trên hệ thống. Tôi đã quay một video demo về phân tích nhật ký giao dịch I / O vào năm 2011 nên tôi sẽ không lặp lại tất cả những điều đó trong bài đăng này. Bạn có thể lấy video tại đây và mã demo tại đây (thích hợp để chạy trong sản xuất ngay lập tức).
Nếu độ trễ ghi cao hơn bạn mong đợi đối với hệ thống con I / O của mình thì hệ thống con I / O không thể theo kịp, như giả định chung. Điều đó có nghĩa là hệ thống con I / O cần được cải thiện? Không nhất thiết.
Trên nhiều hệ thống khách hàng, tôi nhận thấy rằng một tỷ lệ đáng kể các bản ghi nhật ký được tạo là không cần thiết và nếu bạn có thể giảm số lượng bản ghi nhật ký được tạo, bạn sẽ giảm số lượng nhật ký giao dịch được ghi vào đĩa. Điều này sẽ giúp giảm độ trễ ghi, do đó giảm thời gian hoàn thành giao dịch.
Có hai nguyên nhân chính khiến các bản ghi nhật ký không liên quan được tạo ra:các chỉ mục không hợp nhất không được sử dụng và các chỉ mục trở nên phân mảnh.
Chỉ mục không hợp nhất không được sử dụng
Bất cứ khi nào bản ghi được chèn vào bảng, bản ghi phải được chèn vào từng chỉ mục không phân biệt được xác định trên bảng (ngoại trừ các chỉ mục được lọc có bộ lọc thích hợp mà tôi sẽ bỏ qua từ thời điểm này). Điều này có nghĩa là các bản ghi nhật ký bổ sung được tạo, ít nhất một bản ghi cho mỗi chỉ mục không phân biệt, cho mỗi lần chèn bảng. Điều tương tự cũng áp dụng cho việc xóa một bản ghi trong một bảng - các bản ghi phù hợp phải được xóa khỏi tất cả các chỉ mục không hợp nhất. Đối với bản cập nhật cho bản ghi bảng, bản ghi chỉ mục không hợp nhất chỉ được cập nhật nếu (các) cột khóa chỉ mục không hợp nhất hoặc (các) cột được bao gồm là một phần của bản cập nhật.
Tất nhiên, các thao tác này là cần thiết để giữ cho mỗi chỉ mục không phân tán chính xác đối với bảng, nhưng nếu chỉ mục không phân tán không được sử dụng bởi khối lượng công việc, thì các thao tác và bản ghi nhật ký do chúng tạo ra là chi phí không cần thiết. Hơn nữa, nếu các chỉ mục không sử dụng này trở nên phân mảnh (mà tôi sẽ thảo luận ở phần sau của bài đăng này), thì các tác vụ duy trì chỉ mục thường xuyên cũng sẽ hoạt động trên chúng, tạo ra nhiều bản ghi nhật ký hơn (từ chỉ mục REBUILD hoặc REORGANIZE hoạt động) hoàn toàn không cần thiết.
Các chỉ mục không được sử dụng đến từ nhiều nguồn khác nhau, chẳng hạn như ai đó tạo nhầm chỉ mục cho mỗi cột trong bảng, ai đó tạo mọi chỉ mục do DMV chỉ mục bị thiếu đề xuất hoặc ai đó tạo tất cả các chỉ mục do Cố vấn điều chỉnh cơ sở dữ liệu đề xuất. Nó cũng có thể là do các đặc tính khối lượng công việc đã thay đổi và vì vậy những gì từng là chỉ mục hữu ích không còn được sử dụng nữa.
Dù chúng đến từ đâu, các chỉ mục không sử dụng nên được loại bỏ để giảm chi phí của chúng. Bạn có thể xác định chỉ mục nào không được sử dụng bằng sys.dm_db_index_usage_stats DMV và tôi khuyên bạn nên đọc các bài đăng của các đồng nghiệp của tôi Kimberly L. Tripp (tại đây) và Joe Sack (tại đây và tại đây), vì họ giải thích cách sử dụng DMV một cách chính xác.
Phân mảnh chỉ mục
Hầu hết mọi người nghĩ về phân mảnh chỉ mục như một vấn đề ảnh hưởng đến các truy vấn phải đọc một lượng lớn dữ liệu. Mặc dù đây là một trong những vấn đề mà phân mảnh có thể gây ra, nhưng phân mảnh cũng là một vấn đề do nó xảy ra như thế nào.
Sự phân mảnh được gây ra bởi một hoạt động được gọi là tách trang. Nguyên nhân đơn giản nhất của việc tách trang là khi bản ghi chỉ mục phải được chèn vào một trang cụ thể (vì giá trị khóa của nó) và trang không có đủ dung lượng trống. Trong trường hợp này, các hoạt động sau sẽ diễn ra:
- Một trang chỉ mục mới được phân bổ và định dạng
- Một số bản ghi từ trang đầy đủ được chuyển sang trang mới, do đó tạo không gian trống trong trang bắt buộc
- Trang mới được liên kết với cấu trúc chỉ mục
- Bản ghi mới được chèn trên trang bắt buộc
Tất cả các thao tác này tạo ra các bản ghi nhật ký và như bạn có thể tưởng tượng, điều này có thể nhiều hơn đáng kể so với yêu cầu để chèn một bản ghi mới trên một trang không yêu cầu chia trang. Trở lại năm 2009, tôi đã viết blog phân tích chi phí tách trang theo nhật ký giao dịch và nhận thấy một số trường hợp trong đó việc tách trang tạo ra nhật ký giao dịch nhiều hơn 40 lần so với chèn thông thường!
Bước đầu tiên để giảm chi phí bổ sung là loại bỏ các chỉ mục không sử dụng, như tôi đã mô tả ở trên, để chúng không tạo ra các phần tách trang. Bước thứ hai là xác định các chỉ mục còn lại đang bị phân mảnh (và do đó phải là trang bị chia tách) bằng cách sử dụng sys.dm_db_index_physical_stats DMV (hoặc Trình quản lý phân mảnh SQL Sentry mới) và chủ động tạo không gian trống trong chúng bằng cách sử dụng hệ số lấp đầy chỉ mục. Fillfactor hướng dẫn SQL Server để lại không gian trống trên các trang chỉ mục khi chỉ mục được tạo, xây dựng lại hoặc tổ chức lại để có không gian cho phép các bản ghi mới được chèn mà không yêu cầu chia trang, do đó cắt giảm các bản ghi nhật ký bổ sung được tạo.
Tất nhiên, không có gì miễn phí - sự cân bằng khi sử dụng hệ số lấp đầy là bạn phải chủ động cung cấp thêm không gian trong các chỉ mục để ngăn việc tạo thêm bản ghi nhật ký - nhưng đó thường là một sự đánh đổi tốt. Việc chọn một hệ số điền tương đối dễ dàng và tôi đã viết blog về điều đó tại đây.
Tóm tắt
Giảm độ trễ ghi của tệp nhật ký giao dịch không phải lúc nào cũng có nghĩa là chuyển sang hệ thống con I / O nhanh hơn hoặc tách tệp thành phần riêng của hệ thống con I / O. Với một số phân tích đơn giản về các chỉ mục trong cơ sở dữ liệu của bạn, bạn có thể giảm đáng kể số lượng bản ghi nhật ký giao dịch được tạo, dẫn đến giảm độ trễ ghi tương ứng.
Có những vấn đề khác, tế nhị hơn có thể ảnh hưởng đến hiệu suất nhật ký giao dịch và tôi sẽ khám phá những vấn đề đó trong một bài đăng trong tương lai.
