Hỏi &Đáp từ loạt hội thảo trên web về Parameter Sniffing của chúng tôi

Hai thứ Tư vừa qua, chúng tôi đã tổ chức một loạt hội thảo trên web gồm hai phần xử lý các vấn đề về độ nhạy thông số:

Thủ tục, Tham số, Sự cố được Lưu trữ…
Kimberly L. Tripp và Aaron Bertrand
ngày 24 tháng 1
Bạn đã bỏ lỡ? Đăng ký để xem nó ngay bây giờ!
Đánh hơi tham số xử lý bằng SentryOne
Aaron Bertrand, Kimberly L. Tripp và Andy Mallon
ngày 31 tháng 1
Bạn đã bỏ lỡ? Xem ngay bây giờ!

Một số câu hỏi được đưa ra trong cả hai hội thảo trên web và tôi nghĩ tôi sẽ biên dịch chúng và trả lời chúng tại đây (một số câu trả lời đến từ Andy trong hội thảo trên web).

Trong một vấn đề mà chúng tôi đã gặp gần đây, chúng tôi thấy các kế hoạch bị loại bỏ khỏi bộ nhớ cache rất nhanh chóng. Chúng tôi không thực hiện bất kỳ điều gì bạn mô tả (DBCC FREEPROCCACHE vân vân.); áp lực bộ nhớ cũng có thể gây ra điều này?

Có, áp lực bộ nhớ có thể là một yếu tố (xem bài đăng này) và tôi biết có một số nghiên cứu về các vấn đề tiềm ẩn với việc quản lý bộ nhớ của SQL Server trong vấn đề này.

Từ một người tham dự:"Không phải là một câu hỏi, mà là một nhận xét cho người dùng hỏi về số lần bộ nhớ cache kế hoạch của anh ấy bị trống. Chúng tôi cũng gặp phải vấn đề đó và thực sự, đó là áp lực về bộ nhớ. Chúng tôi đã định cấu hình sai bộ nhớ máy chủ tối đa, đó là đã sửa bằng cách sử dụng công thức được đề cập ở đây và sau đó chúng tôi có thủ tục từ bài viết này chạy cứ sau 10 phút (chúng tôi có rất nhiều SQL động, chỉ được sử dụng một lần). "

Điều gì sẽ xảy ra nếu bạn sử dụng OR trong mệnh đề where thay vì AND , vấn đề có tiếp diễn không?

Thông thường nếu bạn sử dụng OR trong loại mẫu này, bạn sẽ nhận được tất cả các hàng mọi lúc, trừ khi mọi thông số đơn lẻ được điền bằng các giá trị lọc các hàng. Điều này thay đổi ngữ nghĩa của truy vấn từ "tất cả những điều này phải đúng" thành "bất kỳ điều nào trong số những điều này đều có thể đúng." Tuy nhiên, kế hoạch được biên dịch cho tập hợp thông số đầu tiên sẽ vẫn được lưu vào bộ nhớ đệm và tồn tại cho các lần thực thi trong tương lai, cho dù mệnh đề của bạn có sử dụng AND hay không hoặc OR .

Đó có phải là 1=1 gắn cờ một cách tiếp cận tốt? Tốt hơn là chỉ thêm các tham số được cung cấp và do đó tránh 1=1 xấu xí ?

1=1 hầu như bị SQL Server bỏ qua, nhưng cho phép thêm tất cả các mệnh đề điều kiện bằng AND để bạn không phải đối xử với * đầu tiên * một cách khác biệt. Đây là giải pháp thay thế:
SET @IncludedWhereClauseYet bit = 0;
SET @sql = N'SELECT cols FROM dbo.Table';
 
IF @param1 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  BEGIN
    SET @sql += N' WHERE ';
    SET @IncludedWhereClauseYet = 1;
  END
  ELSE
  BEGIN
    SET @sql += N' AND ';
  END
  SET @sql += N' @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  ...
END
...
1=1 cho phép bạn đơn giản hóa, bằng cách cho phép bạn luôn đặt trước bất kỳ mệnh đề nào bằng AND . Đoạn mã trên trở thành:
SET @sql = N'SELECT cols FROM dbo.Table WHERE 1 = 1';
 
IF @param1 IS NOT NULL
BEGIN
  SET @sql += N' AND @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  SET @sql += N' AND @param2 = @param2';
END
Bạn có thể sử dụng một mệnh đề ban đầu khác để tránh tất cả các điều kiện, như WHERE PrimaryKey > 0 hoặc WHERE PrimaryKey IS NOT NULL và sau đó mọi mệnh đề tiếp theo có thể bắt đầu bằng AND . Nhưng 1=1 , tuy xấu nhưng lại vô hại, và IMHO cũng xấu không kém việc thêm một mệnh đề * thực * nhưng vô nghĩa, ngoại trừ việc mệnh đề * thực * có thể ảnh hưởng đến kế hoạch.

Hãy nhớ rằng khi bạn đang xây dựng mã T-SQL với T-SQL, bạn có hai khía cạnh "xấu xí" để nghĩ đến - đôi khi bạn sẽ khắc phục sự cố mã ở trên và đôi khi bạn sẽ khắc phục sự cố truy vấn xuất phát từ nó. Hãy cẩn thận về việc hy sinh một người vì lợi ích của người kia.

CÁI GÌ?! Tôi hoàn toàn bỏ lỡ điều đó… WITH RECOMPILE . Tôi đã nghĩ rằng điều đó làm trống kế hoạch, nhưng nó chỉ để nó yên cho lần thực hiện này… điều đó rất quan trọng cần biết!

Chỉ cần đảm bảo rằng bạn cũng nhận thức được những mặt trái của nó.
Hãy xem bài đăng tuyệt vời này của Paul White.

OPTION OPTIMIZE FOR @parametername UNKNOWN không còn được ưa thích trong các phiên bản SQL gần đây hơn?

Tôi không nghĩ rằng nó tốt hơn hay tệ hơn trong các phiên bản hiện đại so với khi nó được giới thiệu lần đầu tiên trong SQL Server 2008. Theo như tôi biết, ngay cả với tất cả các thay đổi đối với trình tối ưu hóa và ước tính cardinality, bit đó vẫn hoạt động theo cùng một cách.

Có bất kỳ tải nào trên máy chủ không, nếu tôi bật tính năng thu thập thống kê Thủ tục và thống kê Truy vấn trong SentryOne?

Bộ sưu tập thống kê Thủ tục &Truy vấn phải được bật theo mặc định. Tất cả việc thu thập dữ liệu đều đi kèm với một khoản chi phí, nhưng SQL Sentry khá cẩn thận về việc thu thập phải trả bao nhiêu chi phí.

Tìm kiếm trên RS không sử dụng nó như một vị từ còn lại, nó đang tìm kiếm một thứ khác mà tôi không thể thấy.

Cảm ơn, tôi sẽ truy cập lại ví dụ đó và viết blog riêng về các bản demo, đảm bảo bao gồm bất kỳ chi tiết liên quan nào không rõ ràng từ sơ đồ kế hoạch.

Có đúng không khi thêm một số cột cần thiết dưới dạng INCLUDE s không thực sự làm cho chỉ mục hiệu quả hơn vì tra cứu khóa sẽ không bị loại bỏ? Tôi nghĩ rằng tỷ lệ phần trăm sẽ không thay đổi trừ khi bạn thực sự loại bỏ tra cứu khóa.

Đúng, đúng, đó là sự thật. Truy vấn ban đầu là một ví dụ sai tối quan trọng, sử dụng SELECT * và một chỉ mục thiếu một số cột vô vọng. Điểm tôi đang cố gắng đưa ra là tab Phân tích chỉ mục khuyến khích bạn cả (a) cải thiện truy vấn và (b) tạo chỉ mục bao trùm. Điểm số ở đó để lôi kéo bạn thực hiện một trong hai hoặc cả hai - nếu bạn thay đổi truy vấn để bạn cần ít cột hơn, thì chỉ mục cũng tiến gần đến việc bao gồm cả truy vấn. Nếu bạn định tạo một chỉ mục mới, riêng biệt, bao hàm, bạn cũng có thông tin về những cột nào được yêu cầu để bao gồm truy vấn cụ thể này. Về mặt kỹ thuật, bạn nói đúng, việc thêm một cột bao gồm nhưng vẫn yêu cầu tra cứu 4 cột khác sẽ không làm cho truy vấn cụ thể này hoạt động tốt hơn bất kỳ và sẽ không làm cho chỉ mục tốt hơn, nhưng nó chỉ ra rằng bạn ' đang tiến gần hơn. Hy vọng là bạn không dừng lại ở việc chỉ thêm một cột bao gồm và bỏ qua phần còn lại. Chúng tôi không biết khi nào bạn sẽ dừng lại, vì vậy tôi không biết rằng có một giải pháp hoàn hảo - chúng tôi chắc chắn không muốn nản lòng người dùng làm cho các chỉ mục của họ phù hợp hơn cho các truy vấn của họ.

Tại sao chúng ta thấy các truy vấn sử dụng tham số tên và tham số họ được tóm tắt trong một câu lệnh chỉ sử dụng tham số họ?

CẬP NHẬT: Đây là cố ý. Nhóm trong Hiển thị Tổng số nhóm cùng một thủ tục được gọi với tất cả các kết hợp tham số khác nhau. Vì vậy, trước tiên bạn có thể sử dụng nó để xác định thông số nào có xu hướng gây ra hiệu suất kém nhất, sau đó, hãy xem xét xem có sai lệch dữ liệu hay không. Ví dụ:một tham số dẫn đến tìm kiếm đối với một cột không được lập chỉ mục, có thể sẽ nổi lên đầu khá đáng tin cậy và bạn có thể thấy điều đó kết hợp với các tham số khác được truyền và cũng được so sánh với tất cả các lệnh gọi mà tham số đó không có ' t đã qua.

Sau khi đã nói tất cả những điều đó, chúng tôi sẽ tìm cách tinh chỉnh hành vi nhóm này khi chúng tôi hoàn tất các thay đổi hiện đang diễn ra cho màn hình SQL Top.

Có tài liệu nào về cách sử dụng hướng dẫn kế hoạch không? Tôi hiện không biết làm thế nào để làm điều đó.

Đây là một cái gì đó khác mà tôi muốn viết blog về nó, nhưng Microsoft có một số chủ đề ở đây trong thời gian chờ đợi (và xem tất cả các liên kết liên quan trong thanh bên).

Tôi có cần kích hoạt thứ gì đó để có được Biểu đồ lịch sử truy vấn không?

Không, điều này sẽ được bật trên tất cả các phiên bản hiện đại của ứng dụng khách SentryOne. Nếu bạn không thấy nó, hãy thử Tools > Reset Layout; nếu cách đó không hiệu quả, hãy liên hệ với [email protected].

Có trường hợp nào khi buộc kế hoạch tốt được biết đến gần đây nhất bằng cách sử dụng Cửa hàng truy vấn khi một hồi quy kế hoạch được tìm thấy là một ý tưởng tồi không? Điều đó có xu hướng che giấu các vấn đề được giải quyết tốt hơn bằng cách thay đổi tuyên bố như bạn đã trình bày không?

Ép buộc một kế hoạch thường là một phương án cuối cùng và tôi có xu hướng dành nó cho những trường hợp mà bạn thực sự không thể sửa được câu lệnh (hoặc thay đổi chỉ mục). Việc ép buộc một kế hoạch luôn có thể dẫn đến hành vi sai lầm, bởi vì con người vẫn đưa ra lựa chọn đó và bạn có thể thực hiện nó dựa trên thông tin xấu. Hồi quy có thể là do thay đổi kế hoạch, nhưng nếu bạn đánh giá đó là hồi quy vì thời gian chạy lâu hơn, bạn đã điều tra các lý do có thể có khác chưa? Ví dụ:giả sử hệ thống đã được khởi động lại hoặc có chuyển đổi dự phòng và có một gói mới vì gói cũ đã bị loại bỏ và có thể số liệu thống kê cũng đã thay đổi trong thời gian chờ đợi, nhưng bây giờ truy vấn chạy lâu hơn không phải vì gói kém hơn mà là thay vì bộ đệm trống. Vì vậy, tôi chắc chắn sẽ không đề nghị bắt buộc một kế hoạch cho mọi hồi quy.

SentryOne không phải lúc nào cũng nắm bắt dữ liệu hoặc thông số, vì vậy tôi không có đủ thông tin. Làm cách nào để đảm bảo SentryOne luôn nắm bắt các thông số và kế hoạch thực thi?

Bạn thực sự không thể bởi vì tất cả điều này phụ thuộc vào cách các truy vấn của bạn được thực thi, cách chúng tôi nắm bắt chúng và tốc độ chạy của chúng. Thường thì các truy vấn của bạn không chạy đủ lâu để được ghi lại đầy đủ và chúng tôi phải dựa vào các chế độ xem thống kê thủ tục / truy vấn tổng hợp của SQL Server, các chế độ này không thu thập thông tin tham số. Bạn có thể thay đổi cài đặt thu thập cho Nguồn SQL hàng đầu để thu thập nhiều hơn và thường xuyên hơn, nhưng bạn cần cân bằng lượng dữ liệu bạn thu thập với lượng thông tin bổ sung mà nó mua cho bạn.

Tôi có thể truy vấn thông tin để có thể tự động hóa và tạo báo cáo không?

Chúng tôi không có bất cứ điều gì sẵn sàng để bạn thực hiện việc này, nhưng hãy để tôi đưa nó trở lại nhóm và xem chúng tôi có thể đưa ra những phương án nào. Một điều tôi thích thú với hội thảo trên web này là xây dựng Điều kiện tư vấn để nắm bắt các loại hồi quy mà chúng tôi đang tìm kiếm, nhưng thời gian đã trở thành một yếu tố.

Làm cách nào để chúng tôi quyết định khi nào sử dụng OPTION (RECOMPILE) , như mỗi ngày, chúng tôi nhận được các kế hoạch khác nhau cho các thông số khác nhau?

Tôi muốn nói rằng hãy bắt đầu với các truy vấn dao động nhiều nhất với độ nhạy của tham số. Nếu tôi có một truy vấn đôi khi mất 2 giây nhưng đôi khi mất 30 và một truy vấn khác nằm trong khoảng từ 4 giây đến 6 giây, thì
tôi sẽ tập trung vào truy vấn đầu tiên.

Cái nào tốt hơn nên sử dụng, OPTION (RECOMPILE) hoặc QUERYTRACEON , trong trường hợp đánh hơi tham số.

Tôi thích OPTION (RECOMPILE) Vì hai lý do. Một, nó tự ghi lại; không ai đọc mã sẽ thắc mắc nó đang làm gì, nhưng không phải ai đọc mã cũng sẽ ghi nhớ các số TF như 4136. Hai là nó không yêu cầu quyền cao - hãy thử sử dụng QUERYTRACEON như một con chim peon.

Có thể cảnh báo hoặc báo cáo về các thủ tục mất nhiều thời gian hơn bình thường không? Quan tâm nhất đến các thủ tục đếm cao.

Hoàn toàn có thể, bạn có thể sử dụng Điều kiện tư vấn, nhưng nó có thể hơi phức tạp vì - đối với các thủ tục thậm chí đôi khi chạy dưới ngưỡng thu thập - bạn sẽ cần phải so sánh các ảnh chụp nhanh thống kê thủ tục DMV. Tôi cũng đã thêm lời nhắc vào blog về điều này, vì đây là điều mà tôi đã giúp khách hàng triển khai trong quá khứ.

Microsoft đang đặt Tự động điều chỉnh làm mặc định cho Cơ sở dữ liệu Azure SQL, bao gồm cả sửa kế hoạch tự động. Đó có vẻ là một ý kiến hay đối với bạn?

Tôi sẽ bảo lưu phán quyết cho đến khi tôi (hoặc một số khách hàng) đã thử nghiệm với nó. Quyết định làm thế nào để điều chỉnh là đủ thách thức cho người phàm; Việc viết phần mềm để điều chỉnh cho bạn có vẻ ít nhất là một thách thức, nếu không muốn nói là hơn thế. Khi Andy nhìn thấy câu hỏi này, anh ấy đã nói với tôi rằng nó khiến anh ấy nhớ đến SQL Server 2000 - chiêu tiếp thị sau đó là nó có khả năng tự điều chỉnh đến mức chúng tôi sẽ không cần DBA nữa. Tuyên bố đó vẫn chưa có tuổi.

Có thể chọn hai dấu chấm trên biểu đồ Lịch sử truy vấn và so sánh sẽ rất tuyệt.

Tôi đồng ý.
Hãy theo dõi.