Trong bài đăng trước của tôi về việc sắp xếp hợp lý các hoạt động của nhật ký giao dịch, tôi đã thảo luận về hai trong số những nguyên nhân phổ biến nhất khiến các bản ghi nhật ký bổ sung được tạo ra:trọng số chết từ các chỉ mục không phân tán không sử dụng và các hoạt động chia trang (gây ra phân mảnh chỉ mục). Giả sử bạn đã đọc bài đăng đó, tôi đã đề cập rằng có nhiều vấn đề phức tạp hơn có thể gây bất lợi cho hiệu suất nhật ký giao dịch và tôi sẽ đề cập đến những vấn đề này ở đây.
Nhiều, Nhiều giao dịch nhỏ
SQL Server thường xuyên sẽ chuyển một phần của nhật ký giao dịch vào đĩa. Xả nhật ký xảy ra bất cứ khi nào:
- Bản ghi nhật ký cam kết giao dịch được tạo.
- Bản ghi nhật ký hủy giao dịch được tạo vào cuối quá trình khôi phục giao dịch.
- 60KB bản ghi nhật ký đã được tạo kể từ lần xóa nhật ký trước đó.
Lưu lượng nhật ký nhỏ nhất có thể là một khối nhật ký 512 byte. Nếu tất cả các giao dịch trong một khối lượng công việc là rất nhỏ (ví dụ:chèn một hàng bảng nhỏ) thì sẽ có rất nhiều lần đăng nhật ký có kích thước tối thiểu xảy ra. Quá trình xả nhật ký được thực hiện không đồng bộ, để cho phép thông lượng nhật ký giao dịch tốt, nhưng có giới hạn cố định là 32 I / Os xả nhật ký đồng thời tại bất kỳ thời điểm nào (được nâng lên 112 trên SQL Server 2012).
Điều này có thể có hai tác động:
- Trên hệ thống con I / O hoạt động chậm, khối lượng ghi nhật ký giao dịch nhỏ có thể lấn át hệ thống con I / O dẫn đến ghi có độ trễ cao và suy giảm thông lượng nhật ký giao dịch sau đó. Tình huống này có thể được xác định bằng độ trễ ghi cao đối với tệp nhật ký giao dịch trong đầu ra của sys.dm_io_virtual_file_stats (xem các liên kết demo ở đầu bài viết trước)
- Trên hệ thống con I / O hiệu suất cao, quá trình ghi có thể hoàn thành cực kỳ nhanh chóng, nhưng giới hạn 32 I / O đăng nhập đồng thời tạo ra một nút thắt cổ chai khi cố gắng làm cho các bản ghi nhật ký lâu bền trên đĩa. Tình huống này có thể được xác định bằng độ trễ ghi thấp và số lượng gần như không đổi của nhật ký giao dịch chưa ghi gần 32 trong kết quả tổng hợp của sys.dm_io_pend_io_requests (xem các liên kết demo tương tự).
Trong cả hai trường hợp, thực hiện các giao dịch lâu hơn (điều này rất phản trực quan!) Có thể giảm tần suất gửi nhật ký giao dịch và tăng hiệu suất. Ngoài ra, trong trường hợp số 1, việc chuyển sang hệ thống con I / O hiệu suất cao hơn có thể hữu ích - nhưng có thể dẫn đến trường hợp số 2. Với trường hợp số 2, nếu các giao dịch không thể được thực hiện lâu hơn, thì giải pháp thay thế duy nhất là chia khối lượng công việc trên nhiều cơ sở dữ liệu để đạt được giới hạn cố định là 32 I / Os log-flush đồng thời hoặc nâng cấp lên SQL Server 2012 trở lên.
Tự động tăng trưởng nhật ký giao dịch
Bất cứ khi nào không gian mới được thêm vào nhật ký giao dịch, nó phải được khởi tạo bằng 0 (viết ra các số 0 để ghi đè phần sử dụng trước đó của đĩa), bất kể tính năng khởi tạo tệp tức thì có được bật hay không. Điều này áp dụng cho việc tạo, phát triển thủ công và tự động phát triển nhật ký giao dịch. Trong khi quá trình khởi tạo bằng không đang diễn ra, các bản ghi nhật ký không thể được chuyển vào nhật ký, do đó, tự động tăng trưởng trong khối lượng công việc đang thay đổi dữ liệu có thể dẫn đến thông lượng giảm đáng kể, đặc biệt nếu kích thước tự động tăng trưởng được đặt là lớn ( nói gigabyte hoặc để ở mức mặc định 10%).
Do đó, nên tránh tự động tăng trưởng, nếu có thể bằng cách cho phép xóa nhật ký giao dịch để luôn có không gian trống có thể được sử dụng lại cho các bản ghi nhật ký mới. Việc xóa nhật ký giao dịch (còn được gọi là cắt ngắn nhật ký giao dịch, không nên nhầm lẫn với việc thu nhỏ nhật ký giao dịch) được thực hiện bằng cách sao lưu nhật ký giao dịch khi sử dụng chế độ khôi phục Toàn bộ hoặc Ghi nhật ký hàng loạt và bằng các điểm kiểm tra khi sử dụng chế độ khôi phục Đơn giản.
Việc xóa nhật ký chỉ có thể xảy ra nếu không có gì yêu cầu xóa các bản ghi nhật ký trong phần nhật ký giao dịch. Một vấn đề phổ biến ngăn cản việc xóa nhật ký là có các giao dịch kéo dài. Cho đến khi một giao dịch cam kết hoặc quay trở lại, tất cả các bản ghi nhật ký từ đầu giao dịch trở đi là bắt buộc trong trường hợp giao dịch quay trở lại - bao gồm tất cả các bản ghi nhật ký từ các giao dịch khác xen kẽ với các bản ghi từ giao dịch đã hoạt động lâu dài. Ví dụ:các giao dịch kéo dài có thể là do thiết kế kém, mã đang chờ con người nhập vào hoặc sử dụng không đúng cách các giao dịch lồng nhau. Tất cả những điều này có thể tránh được khi chúng được xác định là một vấn đề.
Bạn có thể đọc thêm về điều này tại đây và tại đây.
Tính năng sẵn có cao
Một số tính năng có tính khả dụng cao cũng có thể trì hoãn việc xóa nhật ký giao dịch:
- Các nhóm khả dụng và nhân bản cơ sở dữ liệu khi chạy không đồng bộ có thể tạo hàng đợi các bản ghi nhật ký chưa được gửi đến bản sao cơ sở dữ liệu dự phòng. Các bản ghi nhật ký này phải được lưu giữ cho đến khi chúng được gửi đi, làm chậm quá trình xóa nhật ký giao dịch.
- Sao chép giao dịch (và cả Thay đổi thu thập dữ liệu) dựa vào công việc Tác nhân đọc nhật ký để quét nhật ký giao dịch theo định kỳ cho các giao dịch sửa đổi bảng có trong ấn bản sao chép. Nếu Tác nhân đọc nhật ký bị chậm lại vì bất kỳ lý do gì hoặc được thực hiện có chủ đích để chạy không thường xuyên, tất cả các bản ghi nhật ký chưa được quét bởi công việc phải được lưu giữ xung quanh, làm chậm quá trình xóa nhật ký giao dịch.
Khi chạy ở chế độ đồng bộ, phản chiếu cơ sở dữ liệu và các nhóm khả dụng có thể gây ra các vấn đề khác với cơ chế ghi nhật ký. Sử dụng phản chiếu cơ sở dữ liệu đồng bộ làm ví dụ, bất kỳ giao dịch nào cam kết trên máy chính không thể thực sự quay trở lại người dùng hoặc ứng dụng cho đến khi tất cả các bản ghi nhật ký mà nó tạo ra đã được gửi thành công đến máy chủ nhân bản, thêm độ trễ cam kết trên máy chủ. Nếu quy mô giao dịch trung bình dài và độ trễ ngắn, điều này có thể không đáng chú ý, nhưng nếu giao dịch trung bình rất ngắn và thời gian trễ khá dài, điều này có thể có ảnh hưởng đáng kể đến lưu lượng công việc. Trong trường hợp đó, mục tiêu hiệu suất của khối lượng công việc cần phải được thay đổi, công nghệ có tính khả dụng cao được chuyển sang chế độ không đồng bộ hoặc băng thông mạng và tốc độ giữa cơ sở dữ liệu chính và cơ sở dữ liệu dự phòng phải được tăng lên.
Ngẫu nhiên, cùng một loại vấn đề có thể xảy ra nếu bản thân hệ thống con I / O được sao chép đồng bộ - với độ trễ tiềm ẩn cho tất cả các lần ghi mà SQL Server thực hiện.
Tóm tắt
Như bạn có thể thấy, hiệu suất nhật ký giao dịch không chỉ là việc tạo thêm các bản ghi nhật ký giao dịch - có nhiều yếu tố môi trường cũng có thể có ảnh hưởng sâu sắc.
Điểm mấu chốt là tình trạng và hiệu suất của nhật ký giao dịch là điều tối quan trọng để duy trì hiệu suất khối lượng công việc tổng thể. Trong hai bài đăng này, tôi đã trình bày chi tiết các nguyên nhân chính gây ra các vấn đề về hiệu suất nhật ký giao dịch, vì vậy hy vọng bạn có thể xác định và khắc phục bất kỳ vấn đề nào mà bạn gặp phải.
Nếu bạn muốn tìm hiểu thêm về các hoạt động trong nhật ký giao dịch và điều chỉnh hiệu suất, tôi khuyên bạn nên xem khóa đào tạo trực tuyến 7,5 giờ của tôi về ghi nhật ký, khôi phục và nhật ký giao dịch, có sẵn thông qua Pluralsight.
