Chúng tôi đã thiết lập vận chuyển nhật ký đến máy chủ SQL thứ cấp ở chế độ Chờ / Chỉ đọc để giảm tải tất cả việc tạo báo cáo SSRS.
Điều này hoạt động tốt trong các hạn chế áp đặt bởi:
- Giết người dùng trong quá trình khôi phục nhật ký giao dịch (chúng tôi đã khắc phục điều này bằng cách thiết lập nhiều phiên bản và khôi phục nhật ký giao dịch gần đây nhất bằng cách sử dụng lịch trình vòng tròn)
- Dữ liệu đã hết hạn, nhiều nhất là khung thời gian được chỉ định bởi công việc sao lưu / khôi phục nhật ký giao dịch theo lịch trình.
Thật không may, lần đầu tiên bất kỳ / tất cả các thủ tục được lưu trữ được chạy, sau khi nhật ký giao dịch được khôi phục, sẽ mất nhiều thời gian hơn để hoàn thành so với bình thường. Tất cả các lần thực hiện tiếp theo của cùng một thủ tục được lưu trữ hoàn thành trong thời gian dự kiến. Nếu sau đó chúng tôi thực hiện một thủ tục được lưu trữ khác, lần đầu tiên nó chậm và tất cả các lần thực hiện tiếp theo sẽ hoàn thành trong thời gian dự kiến.
Để tham khảo, sự khác biệt trong thực thi là ~ 00: 02 thông thường so với ~ 01: 00 trong lần chạy đầu tiên.
Tôi giả sử điều này có liên quan đến số liệu thống kê thực hiện của máy chủ hoặc tham số thủ tục được lưu trữ đánh hơi / kế hoạch thực hiện được lưu trữ.
Có cách nào để khắc phục vấn đề này không? Hoặc là điều này vốn có để khôi phục nhật ký giao dịch?
Nếu đó chỉ là lần thực hiện đầu tiên của bất kỳ thủ tục được lưu trữ nào, chúng ta có thể giải quyết vấn đề này một cách dễ dàng bằng cách thực hiện bất kỳ thủ tục được lưu trữ nào khi khôi phục, nhưng nó dường như ảnh hưởng đến lần đầu tiên tất cả các thủ tục được lưu trữ được thực thi.
Tôi đã thử chạy count( * )trên 11 bảng quy trình được lưu trữ mà tôi đang sử dụng để kiểm tra các lần chạm. Lần chạy đầu tiên mất 00:32 và lần đếm tiếp theo (*) mất 00:00. Thật không may, điều này không có bất kỳ tác động nào trong lần chạy đầu tiên của thủ tục được lưu trữ.
Tôi không thấy bất kỳ kết quả nào trên máy chủ chính hoặc máy chủ phụ của mình để biết is_temporarysố liệu thống kê, trước hoặc sau khi thực hiện quy trình được lưu trữ.
Tôi hiện đang
sử dụng Kế hoạch
thực hiện truy vấn SQL Server 2012 : Kế hoạch thực hiện truy vấn thoạt nhìn có vẻ khác biệt đáng kể, tuy nhiên, khi lưu kế hoạch thực hiện và mở tệp .sqlplan được tạo, chúng hoàn toàn giống nhau. Sự khác biệt dường như đến từ các phiên bản khác nhau của SSMS tôi đang sử dụng, 2014 trên máy chủ chính và 2018 trên phụ. Khi xem kế hoạch thực hiện trên phụ, nó hiển thị bên dưới% của mỗi nút và chi phí thời gian ### của ### (##%) - không phải là những con số đó, cũng không phải là kế hoạch thực hiện thực tế thay đổi khi thực hiện thêm.
Tôi cũng bao gồm số liệu thống kê của khách hàng và chúng hiển thị gần như giống hệt nhau, sự khác biệt duy nhất là máy chủ chính thực thi với 1,4 giây Thời gian chờ trả lời của máy chủ và thứ cấp mất 81,3 giây.
Tôi thấy một số lượng lớn các khóa PAGEIOLATCH_SH từ lần thực hiện đầu tiên, như bạn dự đoán:
diff after first exec vs diff after second exec
waiting_tasks_count 10903 918
wait_time_ms 411129 12768 Một trong những điều kỳ lạ về tình huống này là, ngoại trừ phần nhiều trường hợp của thiết lập, chúng tôi đã có máy chủ SSRS sản xuất của chúng tôi đọc từ cơ sở dữ liệu chỉ chờ / đọc được cung cấp bởi nhật ký giao dịch định kỳ và không có kinh nghiệm những sự chậm lại trong lần thực hiện đầu tiên của một thủ tục được lưu trữ. Người dùng của chúng tôi bị khởi động mỗi khi nhật ký giao dịch được khôi phục, tuy nhiên, đó là vấn đề thiết lập ở trên được cho là sẽ giải quyết.