Các lý do cho một kế hoạch bị thiếu từ bộ nhớ cache cho các thủ tục được lưu trữ là gì?
WITH RECOMPILE- SQL động
- Mã hóa
- Thay đổi dữ liệu quan trọng
- Cập nhật số liệu thống kê
- Còn gì nữa không
Gần đây tôi đã làm việc trên 2 máy chủ (SQL Server 2008 R2 và SQL Server 2012) gần đây không có kế hoạch trong bộ đệm cho các thủ tục lưu trữ rất tốn tài nguyên. Nhiều, có thể là tất cả, các câu lệnh bên trong các thủ tục được lưu trữ cũng không có kế hoạch trong bộ đệm. Một số thủ tục được lưu trữ thực thi khá thường xuyên như một vài lần mỗi giây.
Không có áp lực bộ nhớ nào. Một trong những máy chủ có phần cứng nhiều hơn mức cần thiết.
Tôi nghĩ rằng các gói bị thiếu là do tạo bảng tạm thời ở giữa các thủ tục được lưu trữ, nhưng dường như đó là thông tin cũ từ SQL Server 2000 hoặc trước đó. Bắt đầu với SQL Server 2005, các biên dịch lại xảy ra ở cấp độ câu lệnh cho các câu lệnh sau DDL. Điều đó có đúng trong mọi trường hợp hay nó vẫn có thể xảy ra trên các phiên bản mới hơn?
Điều gì khác có thể là thủ phạm cho các kế hoạch mất tích? Tôi đã đọc lướt qua một vài bài viết về chủ đề này, nhưng dường như không có gì phù hợp.
Tối ưu hóa cho khối lượng công việc adhoc được kích hoạt trên máy chủ tôi đang xem xét trong tuần này. Một trong những thủ tục được lưu trữ chỉ được thực hiện một lần một ngày. Tôi có mã cho cái đó. Tôi không có mã cho mã thực thi hơn 100 lần mỗi phút, nhưng tôi có thể lấy mã đó. Tôi sẽ không thể đăng mã, nhưng tôi có thể mô tả nó liên quan đến câu hỏi của tôi.
Tôi không tin bất cứ ai đang giải phóng bộ đệm thủ tục hoặc bỏ bộ đệm sạch. Khách hàng này đang sử dụng Solarwinds DPA như một trong những công cụ giám sát của họ. DPA đã nắm bắt một trong các kế hoạch thực hiện cho tuyên bố trong kho lưu trữ được gọi mỗi ngày một lần. Câu nói đó có số lượng đọc lớn do WHEREmệnh đề không thể nói được. Nếu DPA nắm bắt được tuyên bố, thì đó là một kế hoạch ước tính và đã ở trong bộ đệm của kế hoạch cùng một lúc. Chỉ là không có khi chúng tôi đang khắc phục sự cố. Tôi sẽ có họ bắt đầu đăng nhập sp_WhoIsActivevào một bảng.
Tôi đang sử dụng sp_BlitzCache. (Tôi làm việc cho Brent Ozar Unlimited) Điều này sẽ hiển thị kế hoạch cho toàn bộ thủ tục được lưu trữ cũng như các kế hoạch cho các tuyên bố riêng lẻ, nếu chúng tồn tại. Nếu chúng không tồn tại, nó có một cảnh báo "Chúng tôi không thể tìm thấy kế hoạch cho truy vấn này. Lý do có thể cho việc này bao gồm SQL động, RECOMPILEgợi ý và mã được mã hóa." Và cảnh báo đó là trên các tuyên bố quá.
TF 2371 không đúng chỗ. Tôi đang nhìn vào số liệu thống kê chờ đợi. Máy chủ khá chán. PLE là hơn 130.000.
Bây giờ tôi có mã cho 2 thủ tục lưu trữ hơn. Một trong số họ đang sử dụng SQL động exec (@sql)để người ta biết tại sao không có kế hoạch cho nó. Nhưng một cái khác, và đây là cái chạy hơn 100 lần mỗi phút, không có gì khác thường. Điều duy nhất nổi bật trong đó là các bảng tạm thời đang được tạo ở giữa hơn 1000 dòng mã. Nó cũng gọi một loạt các thủ tục lưu trữ con.
Về kế hoạch bộ nhớ đệm trong SQL Server 2008 , tôi không thấy bất kỳ chữ nào> = 8k, nhưng một trong các thủ tục được lưu trữ có một nhận xét về việc chèn hàng loạt ngay trước khi nó gọi một thủ tục được lưu trữ khác. Nhưng chèn số lượng lớn không xuất hiện trong quy trình lưu trữ bên ngoài mà tôi đang xem xét. Phần "Ngưỡng biên dịch lại" của bài viết rất thú vị. Những gì tôi đang thấy cho các bảng tạm thời là hàng tấn INSERT (có thể dẫn đến hàng triệu hàng), một số cập nhật và xóa. Vì vậy, rất nhiều dữ liệu thay đổi cho các bảng tạm thời. Hàng triệu.