Các tính năng không được dùng nữa để đưa ra khỏi hộp công cụ của bạn - Phần 2

Trong bài đăng cuối cùng của mình, tôi đã minh họa một lý do bạn nên ngừng sử dụng các bảng hệ thống không được dùng nữa như sysprocesses . Điều này không phải vì lý do hiệu suất, trực tiếp hay chỉ đơn giản là tuân theo các phương pháp hay nhất đã được ghi chép lại của Microsoft, mà xoay quanh các quyết định mà bạn có thể đưa ra khi bạn chỉ có quyền truy cập vào một số dữ liệu.

Lần này, tôi muốn nói về một tính năng được bao gồm trong các công cụ máy khách SQL Server mà chúng ta không nên sử dụng ngày nay - không chỉ vì nó không được dùng nữa mà quan trọng hơn, vì nó có khả năng làm sập hoàn toàn một máy chủ:

SQL Server Profiler

Kể từ SQL Server 2012 (và ở mức độ thấp hơn nhiều, kể từ SQL Server 2008), giải pháp linh hoạt và hoàn chỉnh nhất để giám sát các sự kiện trên phiên bản SQL Server là Sự kiện mở rộng. Mặt khác, kể từ khi nó được phát minh lần đầu tiên (gần đúng vào khoảng thời gian tôi bắt đầu sự nghiệp của mình), SQL Server Profiler đã là một trong những cách phổ biến nhất để vô tình đưa máy chủ xuống.

Cách đây không lâu, một chuyện như thế này đã xảy ra với chúng tôi. Một nhà phát triển đã thực hiện thay đổi đối với ứng dụng của họ để giảm số lượng chuyến đi khứ hồi mà họ đang thực hiện. Họ đã chạy ứng dụng cục bộ và trong môi trường phát triển của chúng tôi, sử dụng Profiler với một dấu vết đã lọc, để xác nhận các thay đổi của họ đang hoạt động như mong đợi. Tại thời điểm này, hãy để tôi nhắc nhở bạn rằng tài liệu chính thức cho SQL Server Profiler bao gồm cảnh báo sau:

Dù sao, khi họ triển khai phiên bản mới của ứng dụng cho sản xuất và nhắm mục tiêu máy chủ sản xuất với cùng một dấu vết được lọc, mọi việc không suôn sẻ như vậy. Bộ lọc ký tự đại diện của họ trên tên ứng dụng không tính đến các ứng dụng khác (có tên tương tự) cũng kết nối với máy chủ này và họ ngay lập tức bắt đầu thu thập nhiều thông tin hơn cửa sổ Hồ sơ đang mở của họ có thể xử lý. Điều này dẫn đến sự gia tăng nghiêm trọng về thời gian kết nối cho tất cả người dùng và ứng dụng kết nối với phiên bản đó. Sẽ là một cách nói thiếu khi nói rằng các khiếu nại đã được gửi đến.

Khi thủ phạm được xác định và chúng tôi nhận được phản hồi từ nhà phát triển, bạn có thể thấy rằng thời gian kết nối có xu hướng trở lại bình thường gần như ngay lập tức sau khi họ dừng theo dõi Hồ sơ của mình (nhấp để phóng to):

Thảm họa nhỏ trong trình biên dịch SQL Server

Đây chắc chắn là một tình huống mà câu lệnh cũ "đã làm việc trên máy của tôi" không có nghĩa là nó sẽ hoạt động tốt trên một máy chủ sản xuất bận rộn. Và sự cố này đã dẫn đến một cuộc trò chuyện sôi nổi xung quanh việc sửa đổi trình kích hoạt đăng nhập đã tồn tại trên tất cả các máy chủ trong môi trường của chúng tôi để chỉ đơn giản là chặn tên ứng dụng mà Hồ sơ đi qua trong chuỗi kết nối của nó.

Có thể đây không phải là vấn đề của Hồ sơ. (Nhưng nó giống như vậy.)

Tôi không ở đây để gợi ý rằng không thể sử dụng các công cụ giám sát khác, bao gồm Sự kiện mở rộng, không phù hợp để làm hỏng máy chủ theo cách tương tự (hoặc tệ hơn!). Có rất nhiều cơ hội để vô tình ảnh hưởng đến một phiên bản của SQL Server, theo những cách thực sự bất lợi, mà không cần chạm vào SQL Server Profiler.

Nhưng Profiler nổi tiếng với loại triệu chứng này vì cách nó tiêu thụ dữ liệu. Đó là một giao diện người dùng với một lưới hiển thị các hàng mới khi nó nhận được chúng; thật không may, nó làm cho SQL Server đợi trong khi nó hiển thị chúng trước khi cho phép SQL Server truyền nhiều hàng hơn. Hành vi này tương tự như cách SQL Server Management Studio có thể làm chậm các truy vấn và gây ra ASYNC_NETWORK_IO cao đợi khi nó cố gắng kết xuất một lượng lớn đầu ra vào lưới của chính nó. Đó là một sự đơn giản hóa (và không nên nhầm lẫn với cách SQL Trace cơ bản có thể được thực hiện để hoạt động, mà Greg Gonzalez (@SQLsensei) giải thích trong "Don't Fear the Trace"), nhưng nó chính xác là điều dẫn đến loại kịch bản được hiển thị ở trên:nút thắt cổ chai đó có tác động phân tầng đối với bất kỳ quy trình nào khác đang cố gắng thực hiện bất kỳ điều gì trong cùng một đường dẫn mã như những gì bạn đang theo dõi (bao gồm cả việc cố gắng thiết lập kết nối).

Sợ các sự kiện kéo dài?

Đừng như vậy. Đã đến lúc tất cả chúng ta từ bỏ Hồ sơ và nắm lấy hiện tại . Không thiếu các hướng dẫn và hướng dẫn trên mạng, bao gồm QuickStart của chính Microsoft và một số bài viết ngay tại đây trên trang web này.

Nếu bạn có các dấu vết hiện có mà bạn dựa vào, Jonathan Kehayias (@SQLPoolBoy) có một tập lệnh thực sự tiện dụng để chuyển đổi một dấu vết hiện có thành Sự kiện mở rộng. Bạn vẫn có thể thoải mái định cấu hình theo dõi ban đầu với Giao diện người dùng Hồ sơ, nếu đó là nơi bạn cảm thấy thoải mái nhất; chỉ cần làm điều đó mà không cần kết nối với máy chủ sản xuất. Bạn có thể đọc về tập lệnh đó tại đây và xem một số bài viết về Sự kiện mở rộng khác của Jonathan tại đây.

Nếu bạn đang gặp khó khăn với trải nghiệm người dùng, bạn không đơn độc mà có một số câu trả lời:

• Erin Stellato (@erinstellato) từ lâu đã là một người ủng hộ ngoạn mục cho Sự kiện mở rộng và thường tự hỏi tại sao mọi người lại miễn cưỡng từ bỏ Profiler và SQL Trace nói chung. Cô ấy có một số thông tin chi tiết (và truyền cảm hứng cho rất nhiều bình luận) trong bài đăng năm 2016 của cô ấy, "Tại sao BẠN tránh Sự kiện mở rộng?"; có lẽ có một số thông tin chi tiết về việc liệu lý do cầm cự của bạn có còn (như) hợp lệ vào năm 2021.
  
• Có một Hồ sơ XEvent được tích hợp trong các phiên bản SSMS hiện đại, với phần mở rộng tương đương cho Azure Data Studio. Mặc dù, một cách khó hiểu, họ gọi phần mở rộng này - trong tất cả những thứ mà người ta có thể tưởng tượng - SQL Server Profiler . Erin cũng có một vài suy nghĩ về sự lựa chọn đó.
  
• Erik Darling (@erikdarlingdata) đã tạo sp_HumanEvents để giảm bớt khó khăn khi chuyển sang Sự kiện mở rộng. Erik mô tả về một trong những người "bám sát vào điểm" yêu thích của tôi về sp_HumanEvents như sau:"Nếu bạn muốn một cách đơn giản để lập hồ sơ số liệu truy vấn, số liệu thống kê chờ, chặn, biên dịch hoặc biên dịch lại với Sự kiện mở rộng, thì đây chính là kỳ lân của bạn."