Benjamin Nevarez là một nhà tư vấn độc lập có trụ sở tại Los Angeles, California, người chuyên về điều chỉnh và tối ưu hóa truy vấn SQL Server. Anh ấy là tác giả của “Điều chỉnh &Tối ưu hóa Truy vấn SQL Server 2014” và “Bên trong Trình Tối ưu hóa Truy vấn SQL Server” và là đồng tác giả của “Nội bộ SQL Server 2012”. Với hơn 20 năm kinh nghiệm trong lĩnh vực cơ sở dữ liệu quan hệ, Benjamin cũng đã từng là diễn giả tại nhiều hội nghị SQL Server, bao gồm PASS Summit, SQL Server Connections và SQLBits. Có thể tìm thấy blog của Benjamin tại http://www.benjaminnevarez.com và bạn cũng có thể liên hệ với anh ấy bằng e-mail qua địa chỉ quản trị viên tại benjaminnevarez dot com và trên twitter tại @BenjaminNevarez.
Bạn đã bao giờ tìm thấy kế hoạch hồi quy sau khi nâng cấp SQL Server và muốn biết kế hoạch thực thi trước đó là gì chưa? Bạn đã bao giờ gặp sự cố về hiệu suất truy vấn do truy vấn bất ngờ có kế hoạch thực thi mới chưa? Tại Hội nghị thượng đỉnh PASS vừa qua, Conor Cunningham đã khám phá ra một tính năng SQL Server mới, có thể hữu ích trong việc giải quyết các vấn đề về hiệu suất liên quan đến những thay đổi này và những thay đổi khác trong kế hoạch thực thi.
Tính năng này, được gọi là Cửa hàng truy vấn, có thể giúp bạn giải quyết các vấn đề về hiệu suất liên quan đến thay đổi kế hoạch và sẽ sớm có trên SQL Azure và phiên bản tiếp theo của SQL Server. Mặc dù dự kiến sẽ có trên Phiên bản Doanh nghiệp của SQL Server, nhưng vẫn chưa biết liệu nó sẽ có sẵn trên Phiên bản Chuẩn hay bất kỳ phiên bản nào khác hay không. Để hiểu những lợi ích của Cửa hàng truy vấn, hãy để tôi nói ngắn gọn về quy trình khắc phục sự cố truy vấn.
Tại sao Truy vấn chậm?
Khi bạn đã phát hiện ra rằng vấn đề hiệu suất là do truy vấn chậm, bước tiếp theo là tìm hiểu lý do. Rõ ràng là không phải mọi vấn đề đều liên quan đến thay đổi kế hoạch. Có thể có nhiều lý do khiến một truy vấn đang hoạt động tốt bỗng nhiên bị chậm. Đôi khi điều này có thể liên quan đến việc chặn hoặc sự cố với các tài nguyên hệ thống khác. Một cái gì đó khác có thể đã thay đổi nhưng thách thức có thể là tìm ra điều gì. Nhiều khi chúng tôi không có đường cơ sở về việc sử dụng tài nguyên hệ thống, thống kê thực thi truy vấn hoặc lịch sử hiệu suất. Và thường thì chúng tôi không biết kế hoạch cũ là gì. Có thể xảy ra trường hợp một số thay đổi, chẳng hạn như dữ liệu, lược đồ hoặc tham số truy vấn, đã khiến bộ xử lý truy vấn tạo ra một kế hoạch mới.
Thay đổi kế hoạch
Tại phiên họp, Conor đã sử dụng công cụ Trình tối ưu hóa truy vấn cơ sở dữ liệu Picasso, mặc dù không đề cập đến nó bằng tên, để cho biết lý do tại sao các kế hoạch trong cùng một truy vấn lại thay đổi và giải thích thực tế rằng các kế hoạch khác nhau có thể được chọn cho cùng một truy vấn dựa trên tính chọn lọc của các vị từ của chúng. Anh ấy thậm chí còn đề cập rằng nhóm tối ưu hóa truy vấn sử dụng công cụ này, được phát triển bởi Viện Khoa học Ấn Độ. Một ví dụ về hình ảnh hóa (nhấp để phóng to):
Trình hiển thị truy vấn tối ưu hóa cơ sở dữ liệu Picasso
Mỗi màu trong sơ đồ là một phương án khác nhau và mỗi phương án được chọn dựa trên tính chọn lọc của các vị từ. Một thực tế quan trọng là khi ranh giới bị vượt qua trong biểu đồ và một kế hoạch khác được chọn, hầu hết các trường hợp chi phí và hiệu suất của cả hai kế hoạch phải giống nhau, vì độ chọn lọc hoặc số hàng ước tính chỉ thay đổi một chút. Điều này có thể xảy ra chẳng hạn khi một hàng mới được thêm vào bảng đủ điều kiện cho vị từ đã sử dụng. Tuy nhiên, trong một số trường hợp, chủ yếu là do các hạn chế trong mô hình chi phí của trình tối ưu hóa truy vấn, trong đó nó không thể lập mô hình một thứ gì đó chính xác, nên kế hoạch mới có thể có sự khác biệt lớn về hiệu suất so với kế hoạch trước đó, tạo ra vấn đề cho ứng dụng của bạn. Nhân tiện, các kế hoạch được hiển thị trên sơ đồ là kế hoạch cuối cùng được chọn bởi trình tối ưu hóa truy vấn, đừng nhầm lẫn điều này với nhiều lựa chọn thay thế mà trình tối ưu hóa phải xem xét để chỉ chọn một.
Theo ý kiến của tôi, một thực tế quan trọng mà Conor không đề cập trực tiếp, đó là việc thay đổi kế hoạch do thoái lui sau những thay đổi về bản cập nhật tích lũy (CU), gói dịch vụ hoặc nâng cấp phiên bản. Mối quan tâm chính xuất hiện trong tâm trí với những thay đổi bên trong trình tối ưu hóa truy vấn là hồi quy kế hoạch. Nỗi sợ hãi về việc hồi quy kế hoạch đã được coi là trở ngại lớn nhất đối với các cải tiến của trình tối ưu hóa truy vấn. Hồi quy là các vấn đề được đưa ra sau khi áp dụng một bản sửa lỗi cho trình tối ưu hóa truy vấn và đôi khi được gọi là "hai hoặc nhiều sai lầm tạo nên một quyền" cổ điển. Điều này có thể xảy ra khi, chẳng hạn, hai ước tính sai, một ước tính quá cao một giá trị và ước tính thứ hai đánh giá thấp giá trị đó, loại bỏ lẫn nhau, may mắn là đưa ra một ước tính tốt. Hiện chỉ sửa một trong các giá trị này có thể dẫn đến một ước tính không tốt, có thể tác động tiêu cực đến việc lựa chọn phương án, gây ra hồi quy.
Cửa hàng truy vấn làm gì?
Conor đã đề cập đến việc Cửa hàng truy vấn thực hiện và có thể trợ giúp những việc sau:
- Lưu trữ lịch sử của các kế hoạch truy vấn trong hệ thống;
- Nắm bắt hiệu suất của từng kế hoạch truy vấn theo thời gian;
- Xác định các truy vấn “gần đây trở nên chậm hơn”;
- Cho phép bạn thực hiện các kế hoạch một cách nhanh chóng; và,
- Đảm bảo rằng điều này hoạt động trên các lần khởi động lại máy chủ, nâng cấp và biên dịch lại truy vấn.
Vì vậy, tính năng này không chỉ lưu trữ các kế hoạch và thông tin hiệu suất truy vấn liên quan mà còn có thể giúp bạn dễ dàng buộc một kế hoạch truy vấn cũ, trong nhiều trường hợp có thể giải quyết vấn đề về hiệu suất.
Cách sử dụng Cửa hàng truy vấn
Bạn cần bật Cửa hàng truy vấn bằng cách sử dụng ALTER DATABASE CURRENT SET QUERY_STORE = ON; tuyên bố. Tôi đã thử nó trong đăng ký SQL Azure hiện tại của mình, nhưng câu lệnh trả lại lỗi vì có vẻ như tính năng này chưa khả dụng. Tôi đã liên hệ với Conor và anh ấy nói với tôi rằng tính năng này sẽ sớm ra mắt.
Khi Cửa hàng truy vấn được bật, nó sẽ bắt đầu thu thập các kế hoạch và truy vấn dữ liệu hiệu suất và bạn có thể phân tích dữ liệu đó bằng cách xem các bảng trong Cửa hàng truy vấn. Tôi hiện có thể thấy các bảng đó trên SQL Azure nhưng vì tôi không thể kích hoạt Cửa hàng truy vấn, danh mục trả về không có dữ liệu.
Bạn có thể chủ động phân tích thông tin thu thập được để hiểu những thay đổi về hiệu suất truy vấn trong ứng dụng của mình hoặc trong trường hợp bạn gặp sự cố về hiệu suất trở về trước. Sau khi xác định được sự cố, bạn có thể sử dụng các kỹ thuật điều chỉnh truy vấn truyền thống để cố gắng khắc phục sự cố hoặc bạn có thể sử dụng sp_query_store_force_plan thủ tục được lưu trữ để bắt buộc một kế hoạch trước đó. Kế hoạch phải được bắt buộc trong Cửa hàng truy vấn, điều đó rõ ràng có nghĩa là nó là một kế hoạch hợp lệ (ít nhất là khi nó được thu thập; sau này sẽ có nhiều hơn) và nó đã được tạo bởi trình tối ưu hóa truy vấn trước đó. Để bắt buộc một gói, bạn cần có plan_id , có sẵn trong sys.query_store_plan mục lục. Sau khi bạn xem xét các chỉ số khác nhau được lưu trữ, rất giống với những chỉ số được lưu trữ, chẳng hạn như trong sys.dm_exec_query_stats , bạn có thể đưa ra quyết định tối ưu hóa cho một số liệu cụ thể, chẳng hạn như CPU, I / O, v.v. Sau đó, bạn có thể chỉ cần sử dụng một câu lệnh như sau:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Điều này nói với SQL Server buộc kế hoạch 1 trên truy vấn 1. Về mặt kỹ thuật, bạn có thể làm điều tương tự bằng cách sử dụng hướng dẫn kế hoạch, nhưng nó sẽ phức tạp hơn và bạn sẽ phải thu thập và tìm kế hoạch cần thiết ngay từ đầu.
Cửa hàng truy vấn hoạt động như thế nào?
Trên thực tế, việc buộc một kế hoạch sử dụng các hướng dẫn kế hoạch trong nền. Conor đã đề cập rằng “khi bạn biên dịch một truy vấn, chúng tôi ngầm định thêm một gợi ý KẾ HOẠCH SỬ DỤNG với phân đoạn của kế hoạch XML được liên kết với câu lệnh đó.” Vì vậy, bạn không cần sử dụng hướng dẫn kế hoạch nữa. Cũng nên nhớ rằng, giống như việc sử dụng hướng dẫn kế hoạch, không đảm bảo có chính xác kế hoạch bắt buộc nhưng ít nhất phải có một cái gì đó tương tự với nó. Để có lời nhắc về cách hoạt động của hướng dẫn kế hoạch, hãy xem bài viết này. Ngoài ra, bạn nên biết rằng có một số trường hợp buộc một kế hoạch không hoạt động, ví dụ điển hình là khi lược đồ đã thay đổi, tức là nếu một kế hoạch được lưu trữ sử dụng một chỉ mục nhưng chỉ mục đó không còn tồn tại. Trong trường hợp này, SQL Server không thể ép buộc kế hoạch, sẽ thực hiện tối ưu hóa bình thường và nó sẽ ghi lại thực tế rằng việc buộc hoạt động kế hoạch không thành công trong sys.query_store_plan danh mục.
Kiến trúc
Mỗi khi SQL Server biên dịch hoặc thực thi một truy vấn, một thông báo sẽ được gửi đến Cửa hàng truy vấn. Điều này được hiển thị tiếp theo.
Tổng quan về quy trình cửa hàng truy vấn
Thông tin biên dịch và thực thi trước tiên được lưu trong bộ nhớ và sau đó được lưu vào đĩa, tùy thuộc vào cấu hình Cửa hàng truy vấn (dữ liệu được tổng hợp theo INTERVAL_LENGTH_MINUTES , mặc định là một giờ và được chuyển vào đĩa theo DATA_FLUSH_INTERVAL_SECONDS tham số). Dữ liệu cũng có thể được chuyển vào đĩa nếu có áp lực bộ nhớ trên hệ thống. Trong mọi trường hợp, bạn sẽ có thể truy cập tất cả dữ liệu, cả trong bộ nhớ và đĩa, khi bạn chạy sys.query_store_runtime_stats danh mục.
Danh mục
Dữ liệu thu thập được vẫn tồn tại trên đĩa và được lưu trữ trong cơ sở dữ liệu người dùng nơi Cửa hàng truy vấn được bật (và cài đặt được lưu trữ trong sys.database_query_store_options . Các danh mục của Cửa hàng Truy vấn là:
sys.query_store_query_text | Thông tin văn bản truy vấn |
sys.query_store_query | Văn bản truy vấn cộng với gói đã sử dụng ảnh hưởng đến các tùy chọn SET |
sys.query_store_plan | Các kế hoạch thực thi, bao gồm cả lịch sử |
sys.query_store_runtime_stats | Thống kê thời gian chạy truy vấn |
sys.query_store_runtime_stats_interval | Thời gian bắt đầu và kết thúc cho các khoảng thời gian |
sys.query_context_settings | Thông tin cài đặt ngữ cảnh truy vấn |
Lượt xem Cửa hàng Truy vấn
Thống kê thời gian chạy thu thập toàn bộ số liệu, bao gồm giá trị trung bình, cuối cùng, tối thiểu, tối đa và độ lệch chuẩn. Đây là tập hợp đầy đủ các cột cho sys.query_store_runtime_stats :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Các cột trong sys.query_store_runtime_stats
Dữ liệu này chỉ được ghi lại khi quá trình thực thi truy vấn kết thúc. Cửa hàng truy vấn cũng xem xét SET của truy vấn tùy chọn, có thể ảnh hưởng đến việc lựa chọn kế hoạch thực hiện, vì chúng ảnh hưởng đến những thứ như kết quả đánh giá các biểu thức không đổi trong quá trình tối ưu hóa. Tôi đề cập đến chủ đề này trong một bài viết trước.
Kết luận
Đây chắc chắn sẽ là một tính năng tuyệt vời và tôi muốn thử càng sớm càng tốt (nhân tiện, bản trình diễn của Conor hiển thị “SQL Server 15 CTP1” nhưng những bit đó không được công bố rộng rãi). Cửa hàng truy vấn có thể hữu ích cho các bản nâng cấp có thể là phiên bản CU, gói dịch vụ hoặc SQL Server, vì bạn có thể phân tích thông tin được Cửa hàng truy vấn thu thập trước và sau đó để xem có truy vấn nào bị thoái lui hay không. (Và nếu tính năng có sẵn trong các phiên bản thấp hơn, bạn thậm chí có thể thực hiện việc này trong tình huống nâng cấp SKU.) Biết được điều này có thể giúp bạn thực hiện một số hành động cụ thể tùy thuộc vào vấn đề và một trong những giải pháp đó có thể là buộc kế hoạch trước đó như đã giải thích trước đây.
