Trong quá trình theo dõi hiệu suất hoặc khắc phục sự cố như làm chậm hệ thống, có thể cần tìm hoặc nắm bắt các truy vấn có thời lượng cao, CPU cao hoặc tạo ra I / O quan trọng trong quá trình thực thi. Bạn có thể sử dụng DMV hoặc Cửa hàng truy vấn để nhận thông tin về hiệu suất truy vấn, nhưng thông tin trong cả hai nguồn là tổng hợp. Các DMV chỉ đại diện cho CPU, I / O, thời lượng, v.v. trung bình cho một truy vấn miễn là nó được lưu trong bộ nhớ cache. Cửa hàng truy vấn cũng cung cấp số liệu trung bình cho nhiều tài nguyên, nhưng nó được tổng hợp trong một khoảng thời gian xác định (ví dụ:30 phút hoặc một giờ). Tất nhiên, có các giải pháp giám sát của bên thứ 3 có nhiều khả năng cung cấp cho bạn tất cả những điều này và hơn thế nữa (như SentryOne), nhưng đối với bài đăng này, tôi muốn tập trung vào các công cụ gốc.
Nếu bạn muốn hiểu hiệu suất truy vấn cho các lần thực thi riêng lẻ để xác định chính xác truy vấn hoặc tập hợp các truy vấn có thể là vấn đề, thì tùy chọn dễ nhất là sử dụng Sự kiện mở rộng. Và một trong những cách nhanh nhất để bắt đầu là sử dụng XEvent Profiler, có sẵn thông qua SQL Server Management Studio (bắt đầu từ phiên bản 17.3):
Trình biên dịch XEvent trong SSMS
Sử dụng cơ bản
Có hai tùy chọn cho XEvent Profiler:Standard và TSQL. Để sử dụng một trong hai chỉ cần nhấp đúp vào tên. Phía sau hậu trường, một phiên sự kiện được xác định nội bộ sẽ được tạo (nếu nó chưa tồn tại) và bắt đầu, và Trình xem dữ liệu trực tiếp ngay lập tức mở ra với tiêu điểm. Lưu ý rằng sau khi bạn bắt đầu phiên, nó cũng sẽ xuất hiện bên dưới Quản lý | Sự kiện mở rộng | Phiên. Giả sử bạn có hoạt động chống lại máy chủ, bạn sẽ bắt đầu có các mục nhập hiển thị trong trình xem sau năm giây hoặc ít hơn.
Trình xem dữ liệu trực tiếp (sau khi nhấp đúp để bắt đầu phiên chuẩn)
Phiên Tiêu chuẩn và TSQL chia sẻ một số sự kiện, trong đó Tiêu chuẩn có nhiều sự kiện hơn trong tổng số. Dưới đây là danh sách các sự kiện cho từng sự kiện:
Standard TSQL sql_batch_starting sql_batch_starting sql_batch_completed rpc_starting rpc_completed logout logout login login existing_connection existing_connection attention
Nếu bạn đang tìm hiểu thông tin về việc thực thi truy vấn, chẳng hạn như thời gian truy vấn chạy trong bao lâu hoặc lượng I / O mà nó tiêu thụ, thì Tiêu chuẩn là một lựa chọn tốt hơn do có hai sự kiện đã hoàn thành. Đối với cả hai phiên, bộ lọc duy nhất là loại trừ các truy vấn hệ thống cho các sự kiện hàng loạt, rpc và sự kiện chú ý.
Xem và lưu dữ liệu
Nếu chúng tôi khởi động phiên Chuẩn và chạy một số truy vấn, trong trình xem, chúng tôi sẽ thấy sự kiện, văn bản truy vấn và thông tin hữu ích khác như cpu_time, logic_reads và thời lượng. Một trong những lợi ích của việc sử dụng rpc_completed và sql_batch_completed là tham số đầu vào hiển thị. Trong trường hợp có một thủ tục được lưu trữ có sự thay đổi lớn về hiệu suất, việc nắm bắt tham số đầu vào có thể cực kỳ hữu ích vì chúng ta có thể so khớp một quá trình thực thi mất nhiều thời gian hơn với một giá trị cụ thể được chuyển vào thủ tục được lưu trữ. Để tìm một tham số như vậy, chúng ta cần sắp xếp dữ liệu dựa trên thời lượng, điều này chúng ta không thể thực hiện khi nguồn cấp dữ liệu đang hoạt động. Để thực hiện bất kỳ loại phân tích nào, nguồn cấp dữ liệu phải được dừng lại.
Dừng nguồn cấp dữ liệu trong Trình xem trực tiếp
Giờ đây, các truy vấn của tôi không còn trôi qua một cách mờ mịt nữa, tôi có thể nhấp vào cột thời lượng để sắp xếp các sự kiện của mình. Lần đầu tiên tôi nhấp vào, nó sẽ sắp xếp theo thứ tự tăng dần và vì tôi lười và không muốn cuộn dưới cùng, tôi sẽ nhấp lại để sắp xếp theo thứ tự giảm dần.
Các sự kiện được sắp xếp theo thời lượng giảm dần
Giờ đây, tôi có thể xem tất cả các sự kiện mà tôi đã nắm bắt theo thứ tự thời lượng cao nhất đến thấp nhất. Nếu tôi đang tìm kiếm một quy trình được lưu trữ cụ thể bị chậm, tôi có thể cuộn xuống cho đến khi tôi tìm thấy nó (điều này có thể gây khó chịu) hoặc tôi có thể nhóm hoặc lọc dữ liệu. Việc nhóm ở đây dễ dàng hơn, vì tôi biết tên thủ tục được lưu trữ.
Object_name được hiển thị ở phần trên cùng của trình xem, nhưng nhấp vào bất kỳ sự kiện rpc_completed nào sẽ hiển thị tất cả các phần tử được chụp trong ngăn Chi tiết. Bấm chuột phải vào object_name, nó sẽ tô sáng nó và chọn Show Column in Table.
Thêm object_name vào trình xem dữ liệu
Trong ngăn trên cùng, bây giờ tôi có thể nhấp chuột phải vào object_name và chọn Group by Column này. Nếu tôi mở rộng các sự kiện trong usp_GetPersonInfo và sau đó sắp xếp lại theo thời lượng, thì bây giờ tôi thấy rằng việc thực thi với PersonID =3133 có thời lượng cao nhất.
Các sự kiện được nhóm theo object_name, usp_GetPersonInfo được sắp xếp theo thời lượng giảm dần
Để lọc dữ liệu:Sử dụng nút Bộ lọc…, tùy chọn menu (Sự kiện mở rộng | Bộ lọc…) hoặc CTRL + R để hiển thị cửa sổ giảm tập hợp kết quả dựa trên các trường khác nhau được hiển thị. Trong trường hợp này, chúng tôi đã lọc trên object_name =usp_GetPersonInfo, nhưng bạn cũng có thể lọc trên các trường như server_principal_name hoặc client_app_name, vì chúng đã được thu thập.
Cần chỉ ra rằng cả phiên Chuẩn hoặc TSQL đều không được ghi ra tệp. Trên thực tế, không có mục tiêu cho cả hai phiên sự kiện (nếu bạn không biết rằng bạn có thể tạo phiên sự kiện mà không có mục tiêu, thì bây giờ bạn đã biết). Nếu bạn muốn lưu dữ liệu này để phân tích thêm, bạn cần thực hiện một trong những thao tác sau:
- Dừng nguồn cấp dữ liệu và lưu kết quả đầu ra thành tệp qua menu Sự kiện mở rộng (Xuất sang | Tệp XEL…)
- Dừng nguồn cấp dữ liệu và lưu kết quả đầu ra vào một bảng trong cơ sở dữ liệu thông qua menu Sự kiện mở rộng (Xuất sang | Bảng…)
- Thay đổi phiên sự kiện và thêm event_file làm mục tiêu.
Tùy chọn 1 là đề xuất của tôi, vì nó tạo một tệp trên đĩa mà bạn có thể chia sẻ với những người khác và xem lại sau trong Management Studio để phân tích thêm. Trong Management Studio, bạn có khả năng lọc ra dữ liệu không liên quan, sắp xếp theo một hoặc nhiều cột, nhóm dữ liệu và thực hiện các phép tính (ví dụ:trung bình). Bạn có thể làm điều này nếu dữ liệu là một bảng, nhưng bạn phải viết TSQL; phân tích dữ liệu trong giao diện người dùng dễ dàng hơn và nhanh hơn.
Thay đổi các phiên trong hồ sơ XEvent
Bạn có thể sửa đổi các phiên sự kiện Chuẩn và TSQL và những thay đổi bạn thực hiện sẽ vẫn tồn tại thông qua các lần khởi động lại phiên bản. Tuy nhiên, nếu các phiên sự kiện bị dừng (sau khi bạn đã thực hiện sửa đổi), chúng sẽ đặt lại về mặc định. Nếu bạn thấy mình liên tục thực hiện các thay đổi tương tự, tôi khuyên bạn nên viết ra các thay đổi và tạo một phiên sự kiện mới cũng sẽ kéo dài qua các lần khởi động lại. Ví dụ:nếu chúng ta nhìn vào kết quả được thu thập cho đến nay, chúng ta có thể thấy rằng cả truy vấn adhoc và thủ tục được lưu trữ đều đã được thực thi. Và mặc dù thật tuyệt khi tôi có thể thấy các tham số đầu vào khác nhau cho các thủ tục được lưu trữ, nhưng tôi không thấy các câu lệnh riêng lẻ đang thực thi với tập hợp các sự kiện này. Để có được thông tin đó, tôi cần thêm sự kiện sp_statement_completed.
Hiểu rằng cả phiên sự kiện Tiêu chuẩn và TSQL đều được thiết kế nhẹ. Các sự kiện statement_completed sẽ kích hoạt thường xuyên hơn các sự kiện batch và rpc, do đó, có thể có nhiều chi phí hơn khi các sự kiện này là một phần của phiên sự kiện. Khi sử dụng các sự kiện tuyên bố, tôi rất khuyên bạn nên bao gồm các vị ngữ bổ sung. Xin nhắc lại, các sự kiện rpc và batch chỉ lọc ra các truy vấn hệ thống - không có vị từ nào khác. Nói chung, tôi cũng đề xuất các vị từ bổ sung cho những sự kiện này, đặc biệt là đối với khối lượng công việc lớn.
Nếu bạn lo lắng về việc chạy các phiên Tiêu chuẩn hoặc TSQL có gây ảnh hưởng đến hiệu suất trên hệ thống của mình hay không, hãy hiểu rằng Trình xem dữ liệu trực tiếp sẽ ngắt kết nối nếu nó tạo ra quá nhiều chi phí trên hệ thống. Đây là một sự an toàn tuyệt vời, nhưng tôi vẫn sẽ suy nghĩ khi sử dụng các phiên sự kiện này. Tôi tin rằng chúng là bước đầu tiên tuyệt vời để khắc phục sự cố, đặc biệt đối với những người mới sử dụng SQL Server hoặc Sự kiện mở rộng. Tuy nhiên, nếu bạn đang mở Trình xem dữ liệu trực tiếp và bạn rời khỏi máy của mình, thì phiên sự kiện sẽ tiếp tục chạy . Việc dừng hoặc đóng Trình xem dữ liệu trực tiếp sẽ dừng phiên sự kiện, đây là điều tôi khuyên bạn nên thực hiện khi bạn hoàn thành việc thu thập dữ liệu hoặc khắc phục sự cố.
Đối với các phiên sự kiện mà bạn muốn chạy trong một khoảng thời gian dài hơn, hãy tạo các phiên sự kiện riêng biệt ghi vào đích event_file và có các vị từ thích hợp. Nếu bạn cần thêm thông tin về cách bắt đầu với Sự kiện mở rộng, hãy xem phiên mà tôi đã tổ chức tại SQLBits vào năm ngoái về việc chuyển từ Hồ sơ sang Sự kiện mở rộng.