SQL Server luôn cung cấp khả năng nắm bắt các truy vấn trực tiếp trên cơ sở đặc biệt ở định dạng tập hợp hàng dễ sử dụng - đầu tiên là với SQL Server Profiler kế thừa, sau đó là qua Sự kiện mở rộng trong SSMS. Khả năng này rất có giá trị khi điều chỉnh hiệu suất vì các sự kiện truy vấn bao gồm các chỉ số CPU và IO rời rạc cũng như các tham số thời gian chạy, đây là chìa khóa để khắc phục các sự cố về hiệu suất truy vấn như dò tìm tham số. Hơn nữa, các sự kiện truy vấn chứa các yếu tố quan trọng khác như tên máy khách, tên ứng dụng, thông tin đăng nhập, ID tiến trình Windows, v.v.
Bạn luôn có thể truy xuất tổng hợp số liệu hiệu suất cho chuẩn hóa các truy vấn từ DMV hoặc Cửa hàng truy vấn, nhưng chúng chỉ chứa được biên dịch tham số và không có phần tử nào đã nói ở trên. Mặc dù điều này là hữu ích, nhưng nó không giống nhau. Ví dụ:nếu bạn cần xem tổ hợp thông số cụ thể được sử dụng bởi truy vấn đó đã có 2 tỷ lượt đọc hoặc tìm ứng dụng ngốn CPU hàng đầu trong 24 giờ qua, thì bạn đã không gặp may.
Cơ sở dữ liệu Azure SQL không được Hồ sơ kế thừa hỗ trợ và Microsoft đã vô hiệu hóa nhà cung cấp dịch vụ phát trực tuyến XEvents (sys.fn_MSxe_read_event_stream TVF) vì lý do độ tin cậy, vì vậy bạn không thể tạo phiên XE và "xem dữ liệu trực tiếp" bằng SSMS. Thông tin chi tiết về hiệu suất truy vấn trong Azure Portal được hỗ trợ bởi Query Store, vì vậy bạn chỉ có các truy vấn chuẩn hóa và dữ liệu hiệu suất tổng hợp, không phải các sự kiện truy vấn thực tế.
Vì vậy, trong một vài năm, chúng tôi đã gặp khó khăn - lựa chọn duy nhất để lập hồ sơ Cơ sở dữ liệu Azure SQL là tạo thủ công dấu vết XEvents ghi vào bộ đệm vòng hoặc mục tiêu tệp với Azure Storage, cả hai đều không tối ưu. Việc sử dụng bộ đệm vòng với các truy vấn T-SQL có thể gặp vấn đề do giới hạn XML được định dạng 4MB như được đề cập bởi Jonathan Kehayias ở đây và các mục tiêu tệp yêu cầu một lượng tương đối nhảy vòng và chi phí bổ sung. Cả hai đều yêu cầu truy vấn thủ công dữ liệu XE và do đó không chính xác "tồn tại" theo nghĩa truyền thống.
Nhập Mới Hồ sơ SQL Server
Khi tôi biết về phần mở rộng SQL Server Profiler cho Azure Data Studio, tôi rất vui khi thấy Microsoft cuối cùng đã cung cấp một giải pháp đồ họa để nắm bắt truy vấn trực tiếp trên Azure SQL Database. Thật không may, sự phấn khích của tôi chỉ tồn tại trong thời gian ngắn vì một vài lý do.
Đầu tiên, dấu vết “Chuẩn” đáng sợ từ Trình biên dịch kế thừa rõ ràng đã được sử dụng làm mô hình cho phiên XE của Trình biên dịch ADS cho Cơ sở dữ liệu Azure SQL , có tên là ADS_Standard_Azure theo mặc định. (Các phiên XE được sử dụng cho SQL Server đầy đủ cũng tương tự như vậy.) Như tôi đã viết blog vài năm trước và vẫn tin rằng, Dấu vết chuẩn là lý do chính khiến Hồ sơ kế thừa bị đánh giá thấp như vậy. Nó chứa nhiều sự kiện vô ích và không thể lọc được chẳng hạn như Bắt đầu hàng loạt SQL , đăng nhập và đăng xuất và kết quả là nó không thêm giá trị thực cho việc điều chỉnh hiệu suất. Hơn nữa, với kiến trúc theo dõi tập hợp hàng đồng bộ được sử dụng bởi Profiler kế thừa, khối lượng sự kiện cao có thể ảnh hưởng đến hiệu suất trên các hệ thống bận rộn. Vì lý do nào đó, thứ này sẽ không biến mất!
| | |
| Sự kiện theo dõi "Chuẩn" trong Hồ sơ kế thừa |
ADS Profiler “ADS_Standard_Azure” sự kiện XE |
Thứ hai, nó sử dụng bộ đệm vòng có kích thước tối đa 8MB hoặc 1000 sự kiện, tùy điều kiện nào đến trước. Bởi vì các sự kiện đăng nhập / đăng xuất là nhỏ, bạn thường sẽ đạt đến 1000 sự kiện trước khi đạt đến giới hạn 8MB hoặc thậm chí là giới hạn 4MB được định dạng XML. Tuy nhiên, với sự kết hợp vừa phải của các sự kiện SQL, XML của bộ đệm vòng sẽ vẫn từ 2 đến 3MB ở 1000 sự kiện trong thử nghiệm của tôi và vấn đề là toàn bộ bộ đệm này được kéo qua mạng mỗi khi tiện ích mở rộng Hồ sơ thăm dò để làm mới lưới của nó , là thời gian dài hơn sau mỗi 1 giây hoặc khoảng thời gian của cuộc thăm dò trước đó. Sau đó, XML được phân tích cú pháp phía máy khách bằng phần mở rộng ADS Profiler để xác định sự kiện nào là mới kể từ cuộc thăm dò cuối cùng và các sự kiện mới được thêm vào lưới.
Bộ đệm vòng lấp đầy gần như ngay lập tức ngay cả trên một máy chủ bận vừa phải và ảnh hưởng thực sự là bạn sẽ nhanh chóng kéo> 40 megabit mỗi giây trên mạng từ Cơ sở dữ liệu Azure SQL của mình . Điều này có nghĩa là 300 megabyte mỗi phút hoặc 18 gigabyte mỗi giờ!
Lần truy cập mạng từ tiện ích mở rộng Hồ sơ ADS (phạm vi 4 phút)
Nỗi sợ hãi ban đầu của tôi là điều này có thể dẫn đến các khoản phí phát sinh lớn trên hóa đơn Azure tiếp theo, tuy nhiên, khi xem xét các đăng ký Azure của chính chúng tôi, chúng tôi không thể xác nhận rằng lưu lượng mạng cho Azure SQL DB đã bị tính phí. SentryOne’s Mike Wood (b | t), một Azure MVP, đã dành hàng tuần để tìm câu trả lời và cuối cùng nhận được thông báo từ Microsoft rằng thực sự việc truy cập mạng hiện không bị tính phí cho Azure SQL DB, mặc dù điều này có thể thay đổi bất cứ lúc nào. Mặc dù vậy, việc kéo xuống 18GB dữ liệu truy vấn mỗi giờ dường như không có trách nhiệm và chắc chắn có thể gây ảnh hưởng đến phiên xem say sưa Netflix tiếp theo của bạn.
Mặc dù bạn có thể đặt bộ lọc thông qua giao diện người dùng Hồ sơ, điều này sẽ giúp xem xét dữ liệu dễ dàng hơn, nhưng nó sẽ không làm giảm lần truy cập mạng vì chúng hoạt động phía máy khách.
Phiên XE được cập nhật
Một giải pháp nhanh chóng để giảm gánh nặng mạng của ADS Profiler và làm cho dữ liệu dễ tiêu thụ hơn nhiều để điều chỉnh hiệu suất truy vấn là cập nhật ADS_Standard_Azure Phiên XE. Dưới đây là một tập lệnh sẽ:
- Xóa các sự kiện vô ích:
- sqlserver.attention
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
- Đặt ngưỡng thời lượng> 1 giây (1000000 micro giây) cho các sự kiện còn lại:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Giảm kích thước tối đa của bộ đệm vòng từ 1000 xuống 10 sự kiện
- Điều này sẽ không bao giờ hoạt động với dấu vết ban đầu vì 10 sự kiện sẽ được tạo trong mili giây và bộ đệm vòng sẽ định dạng lại quá nhanh khiến hầu hết các sự kiện bị mất. Tuy nhiên, với bộ lọc thời lượng 1 giây, luồng sự kiện sẽ thấp hơn nhiều và 10 sự kiện sẽ hoạt động tốt với khoảng thời gian bỏ phiếu 1 giây được ADS Profiler sử dụng.
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP TARGET package0.ring_buffer
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO Sau khi áp dụng tập lệnh để cập nhật phiên XE, firehose sẽ ngay lập tức giảm xuống mức nhỏ giọt:
Lần truy cập mạng giảm sau khi cập nhật phiên XE của ADS Profiler
Các lựa chọn thay thế có trọng lượng nhẹ hơn
SQL Sentry và đối tác SaaS SentryOne Monitor là những giải pháp duy nhất khác mà tôi biết để nắm bắt các truy vấn từ Cơ sở dữ liệu Azure SQL và chúng làm như vậy bằng cách sử dụng một cách tiếp cận sáng tạo có trọng lượng nhẹ hơn đáng kể so với phiên XE được tối ưu hóa ở trên cho ADS Profiler. Trong số các tính năng nâng cao khác, bạn có thể dễ dàng tổng hợp theo tên máy khách, ứng dụng và thông tin đăng nhập, đồng thời tự động nắm bắt các kế hoạch truy vấn để phân tích với Plan Explorer được tích hợp.
SentryOne Monitor hiển thị các kế hoạch và truy vấn đã chụp từ Cơ sở dữ liệu Azure SQL
Đang kết thúc
Microsoft đã tuyên bố rằng họ sẽ tiếp tục cải tiến phần mở rộng ADS Profiler và khi họ làm như vậy, tôi hy vọng rằng họ sẽ giải quyết được các vấn đề đã nêu ở trên. Tôi đã ghi lại vấn đề ở đây. Trong thời gian chờ đợi, tập lệnh được cập nhật sẽ mang lại trải nghiệm lập hồ sơ truy vấn an toàn hơn và thân thiện với băng thông hơn cho Cơ sở dữ liệu Azure SQL.
