Tiếp tục loạt bài viết về chốt, lần này tôi sẽ thảo luận về chốt APPEND_ONLY_STORAGE_INSERT_POINT và chỉ ra cách nó có thể là một nút thắt cổ chai lớn đối với khối lượng công việc cập nhật nặng mà một trong hai hình thức cô lập ảnh chụp nhanh đang được sử dụng.
Tôi thực sự khuyên bạn nên đọc bài đăng đầu tiên trong loạt bài trước bài viết này, để bạn có tất cả kiến thức nền tảng chung về chốt.
Chốt APPEND_ONLY_STORAGE_INSERT_POINT là gì?
Để giải thích chốt này, tôi cần giải thích một chút về cách hoạt động của tính năng cô lập ảnh chụp nhanh.
Khi bạn bật một trong hai hình thức lập phiên bản, SQL Server sử dụng một cơ chế được gọi là lập phiên bản để duy trì các phiên bản thay đổi trước của một bản ghi trong cửa hàng phiên bản trong tempdb. Điều này được thực hiện như sau:
- Một bản ghi được xác định là sắp được thay đổi.
- Bản ghi hiện tại được sao chép vào cửa hàng phiên bản.
- Bản ghi đã được thay đổi.
- Nếu bản ghi chưa có thẻ lập phiên bản 14 byte , một cái được thêm vào cuối bản ghi. Thẻ chứa dấu thời gian (không phải thời gian thực) và con trỏ đến phiên bản trước của bản ghi trong cửa hàng phiên bản.
- Nếu bản ghi đã có thẻ lập phiên bản, bản ghi đó sẽ được cập nhật với dấu thời gian và con trỏ cửa hàng phiên bản mới.
Dấu thời gian lập phiên bản cho toàn phiên bản được tăng lên bất cứ khi nào một câu lệnh hoặc lô mới bắt đầu hoặc một phiên bản mới của bản ghi được tạo, trong bất kỳ cơ sở dữ liệu nào có kích hoạt một trong hai hình thức cô lập ảnh chụp nhanh. Dấu thời gian này được sử dụng để đảm bảo truy vấn xử lý đúng phiên bản của bản ghi.
Ví dụ, hãy tưởng tượng một cơ sở dữ liệu đã kích hoạt tính năng đọc ảnh chụp nhanh đã cam kết, vì vậy mỗi câu lệnh được đảm bảo xem các bản ghi tại thời điểm câu lệnh bắt đầu. Dấu thời gian lập phiên bản được đặt cho thời điểm câu lệnh bắt đầu, vì vậy bất kỳ bản ghi nào mà nó gặp phải có dấu thời gian cao hơn đều là phiên bản "sai" và do đó, phiên bản "đúng", có dấu thời gian trước dấu thời gian của câu lệnh, phải được truy xuất từ kho phiên bản. Cơ chế của quá trình này không phù hợp với mục đích của bài đăng này.
Vì vậy, các phiên bản được lưu trữ vật lý trong cửa hàng phiên bản như thế nào? Toàn bộ bản ghi trước khi thay đổi, bao gồm cả các cột ngoài hàng, được sao chép vào cửa hàng phiên bản, được chia thành các phần 8.000 byte, có thể kéo dài hai trang nếu cần (ví dụ:2.000 byte ở cuối một trang và 6.000 byte ở sự bắt đầu của tiếp theo). Bộ nhớ dành cho mục đích đặc biệt này được tạo thành từ đơn vị phân bổ chỉ nối thêm và chỉ được sử dụng cho các hoạt động của cửa hàng phiên bản. Nó được gọi như vậy vì dữ liệu mới chỉ có thể được nối ngay sau khi kết thúc phiên bản đã nhập gần đây nhất. Đơn vị phân bổ mới được tạo thường xuyên và điều này cho phép việc dọn dẹp kho lưu trữ phiên bản thông thường trở nên rất hiệu quả — vì đơn vị phân bổ không cần thiết có thể đơn giản bị loại bỏ. Một lần nữa, cơ chế của điều đó nằm ngoài phạm vi của bài đăng này.
Và bây giờ chúng ta đi đến định nghĩa của chốt:bất kỳ luồng nào cần sao chép bản ghi thay đổi trước vào cửa hàng phiên bản cần biết vị trí của điểm chèn trong đơn vị cấp phát chỉ phần phụ hiện tại. Thông tin này được bảo vệ bởi chốt APPEND_ONLY_STORAGE_INSERT_POINT.
Làm thế nào để chốt trở thành nút cổ chai?
Đây là vấn đề:chỉ có một chế độ được chấp nhận trong đó chốt APPEND_ONLY_STORAGE_INSERT_POINT:Chế độ EX (độc quyền). Và như bạn sẽ biết khi đọc bài đăng giới thiệu cho loạt bài này, mỗi lần chỉ có một chủ đề có thể giữ chốt ở chế độ EX.
Kết hợp tất cả thông tin này lại với nhau:khi một hoặc nhiều cơ sở dữ liệu đã bật tính năng cô lập ảnh chụp nhanh và có khối lượng cập nhật đồng thời đủ cao cho các cơ sở dữ liệu đó, sẽ có rất nhiều phiên bản được tạo bởi các kết nối khác nhau và chốt này sẽ trở thành một chút tắc nghẽn, với kích thước nút cổ chai tăng lên khi khối lượng công việc cập nhật tăng lên khi liên quan đến việc lập phiên bản.
Hiển thị nút cổ chai
Bạn có thể dễ dàng tái tạo nút thắt cổ chai cho chính mình. Tôi đã làm như sau:
- Đã tạo một bảng với một loạt các cột số nguyên có tên là cXXX trong đó XXX là một số và một chỉ mục được nhóm trên cột nhận dạng int có tên là DocID
- Đã chèn 100.000 bản ghi, với các giá trị ngẫu nhiên cho tất cả các cột
- Đã tạo tập lệnh có vòng lặp vô hạn để chọn DocID ngẫu nhiên trong phạm vi từ 1 đến 10.000, chọn tên cột ngẫu nhiên và tăng giá trị cột lên 1 (do đó tạo phiên bản)
- Đã tạo chín tập lệnh giống hệt nhau, nhưng mỗi tập lệnh chọn từ một dải khóa cụm giá trị 10.000 giá trị khác nhau
- Đặt DELAYED_DURABILITY thành FORCED để giảm thời gian chờ WRITELOG (phải thừa nhận rằng bạn hiếm khi làm điều này, nhưng nó giúp làm trầm trọng thêm nút thắt cổ chai cho các mục đích demo)
Sau đó, tôi chạy tất cả mười tập lệnh đồng thời và đo lường các Phương pháp Truy cập:Tìm kiếm Chỉ mục / giây bộ đếm để theo dõi số lượng cập nhật đang diễn ra. Tôi không thể sử dụng Cơ sở dữ liệu:Yêu cầu hàng loạt / giây vì mỗi tập lệnh chỉ có một lô (vòng lặp vô hạn) và tôi không muốn sử dụng Giao dịch / giây vì nó có thể đếm các giao dịch nội bộ cũng như một gói mỗi bản cập nhật.
Khi tính năng cô lập ảnh chụp nhanh không được bật, trên máy tính xách tay Windows 10 chạy SQL Server 2019 của tôi, tôi nhận được khoảng 80.000 bản cập nhật mỗi giây trên mười kết nối. Sau đó, khi tôi chuyển cài đặt READ_COMMMITED_SNAPSHOT thành BẬT cho cơ sở dữ liệu và chạy lại thử nghiệm, thông lượng khối lượng công việc giảm xuống còn khoảng 60.000 bản cập nhật mỗi giây (thông lượng giảm 25%). Từ việc xem xét thống kê thời gian chờ, 85% trong số tất cả các lần chờ là LATCH_EX và từ việc xem xét thống kê chốt, 100% là cho APPEND_ONLY_STORAGE_INSERT_POINT.
Hãy nhớ rằng tôi đã thiết lập kịch bản để cho thấy nút thắt cổ chai ở mức tồi tệ nhất. Trong môi trường thực tế với khối lượng công việc hỗn hợp, hướng dẫn được chấp nhận chung cho việc giảm thông lượng khi sử dụng cách ly ảnh chụp nhanh là 10-15%.
Tóm tắt
Một lĩnh vực tiềm năng khác có thể bị ảnh hưởng bởi nút thắt cổ chai này là nhóm khả dụng có thể đọc được thứ hai. Nếu một bản sao cơ sở dữ liệu được đặt là có thể đọc được, tất cả các truy vấn chống lại nó sẽ tự động sử dụng cách ly ảnh chụp nhanh và tất cả các bản ghi nhật ký phát lại từ bản chính sẽ tạo ra các phiên bản. Với khối lượng công việc cập nhật đủ cao đến từ cơ sở dữ liệu chính và nhiều cơ sở dữ liệu được đặt thành có thể đọc được và việc làm lại song song là tiêu chuẩn cho các thứ hai của nhóm khả dụng, chốt APPEND_ONLY_STORAGE_INSERT_POINT có thể trở thành nút thắt cổ chai đối với nhóm khả dụng thứ cấp có thể đọc được, điều này có thể dẫn đến thứ cấp tụt hậu so với sơ cấp. Tôi chưa thử nghiệm điều này, nhưng nó giống hệt cơ chế mà tôi đã mô tả ở trên, vì vậy có vẻ như có khả năng xảy ra. Trong trường hợp đó, có thể tắt tính năng làm lại song song bằng cách sử dụng cờ theo dõi 3459, nhưng điều này có thể dẫn đến thông lượng tổng thể kém hơn trên thiết bị phụ.
Thật không may, gạt kịch bản nhóm khả dụng sang một bên, không sử dụng tính năng cô lập ảnh chụp nhanh là cách duy nhất để tránh hoàn toàn nút thắt cổ chai này, đây không phải là một lựa chọn khả thi nếu khối lượng công việc của bạn dựa vào ngữ nghĩa được cung cấp bởi tính năng cách ly ảnh chụp nhanh hoặc bạn cần nó để giảm bớt các vấn đề về chặn (vì cách ly ảnh chụp nhanh có nghĩa là các truy vấn đọc không có được khóa chia sẻ chặn các truy vấn thay đổi).
Chỉnh sửa:từ các nhận xét bên dưới, bạn * có thể * loại bỏ nút thắt cổ chai bằng cách sử dụng ADR trong SQL Server 2019 nhưng sau đó hiệu suất kém hơn nhiều do chi phí ADR. Trường hợp chốt trở thành nút cổ chai do khối lượng công việc cập nhật cao hoàn toàn không phải là trường hợp sử dụng hợp lệ cho ADR.
