Triệu chứng
Giả sử bạn có Một Nhóm Luôn Sẵn sàng (AG) trong SQL Server 2016 và 2017. Khi bạn xử lý một truy vấn đọc trên bản sao thứ cấp, hiệu suất có thể chậm hơn nhiều so với bản sao chính do thường xuyên DIRTY_PAGE_TABLE_LOCK đợi.
Nguyên nhân
Sự cố này xảy ra do sự bất đồng giữa truy vấn đọc và chuỗi hội thoại làm lại và vì bảng bị khóa.
Giải pháp
Bản sửa lỗi này được bao gồm trong các bản cập nhật sau đây dành cho SQL Server:
Bản cập nhật tích lũy 8 cho SQL Server 2017
Bản cập nhật Tích lũy 1 cho SQL Server 2016 Gói Dịch vụ 2
Bản cập nhật Tích lũy 9 cho SQL Server 2016 Gói Dịch vụ 1
Giới thiệu SQL Server dựng
Mỗi bản dựng mới dành SQL Server sẽ chứa tất cả các bản cập nhật nóng và bản sửa lỗi bảo mật trong bản dựng trước đó. Chúng tôi khuyên bạn nên cài đặt bản dựng mới nhất cho phiên bản SQL Server:
Cách giải quyết
Để khắc phục sự cố này, bạn có thể sử dụng một chuỗi hội thoại làm lại duy nhất thay vì một luồng làm lại song song bằng cách bật Theo dõi Cờ 3459.
Thông tin Bổ sung
Khi truy vấn chỉ đọc đang chạy trên một bản sao phụ có thể đọc được, các chuỗi truy vấn tìm cách áp dụng các thao tác làm lại nhật ký đang chờ xử lý và cần cộng tác với các luồng công nhân làm lại với các chờ DIRTY_PAGE_TABLE_LOCK , vốn có thể được tạo thường xuyên và làm chậm cả hiệu suất làm lại và truy vấn nếu có khối lượng công việc làm lại đồng thời. Sự cố hiệu suất liên quan đến DIRTY_PAGE_TABLE_LOCK wait được khắc phục trong bản phát hành cập nhật tích lũy cho SQL Server 2016 SP và SQL Server 2017 được đề cập trong bài viết này.
Để biết thêm thông tin, bạn có thể xem blog sau đây về mô hình và hiệu suất làm lại bản sao phụ của nhóm tính khả dụng.
Trạng thái
Microsoft đã xác nhận đây là sự cố trong các sản phẩm của Microsoft được liệt kê trong phần "Áp dụng cho".
Tham khảo
Tìm hiểu về thuật ngữ mà Microsoft sử dụng để mô tả các bản cập nhật phần mềm.
