Phân tích MS SQL Server cho những người lần đầu tiên nhìn thấy nó

Chúng ta sẽ xem xét vấn đề gì?

Nếu máy chủ thông báo “không còn dung lượng trên ổ E” - thì không cần phân tích sâu. Chúng tôi sẽ không xem xét các lỗi, giải pháp hiển nhiên từ nội dung thư và Google sẽ ngay lập tức ném một liên kết tới MSDN cùng với giải pháp.

Hãy cùng xem xét các vấn đề mà Google không rõ ràng, chẳng hạn như hiệu suất giảm đột ngột hoặc không có kết nối. Xem xét các công cụ chính để tùy chỉnh và phân tích. Hãy xem vị trí của nhật ký và thông tin hữu ích khác. Trên thực tế, tôi sẽ cố gắng thu thập tất cả thông tin cần thiết trong một bài viết để bắt đầu nhanh chóng.

Trước hết

Chúng ta sẽ bắt đầu với những câu hỏi thường gặp nhất và xem xét chúng một cách riêng biệt.

Nếu cơ sở dữ liệu của bạn đột nhiên, không có lý do rõ ràng, bắt đầu hoạt động chậm chạp, nhưng bạn không thay đổi bất cứ điều gì - trước hết, hãy cập nhật thống kê và xây dựng lại chỉ mục.

Trên Internet, có rất nhiều phương pháp như thế này, các ví dụ về tập lệnh được cung cấp. Tôi sẽ giả định rằng tất cả các phương pháp đó là dành cho các chuyên gia. Tôi sẽ mô tả cách đơn giản nhất:bạn chỉ cần một con chuột để triển khai nó.

Viết tắt

SSMS là một ứng dụng của Microsoft SQL Server Management Studio. Bắt đầu từ phiên bản 2016, nó được cung cấp miễn phí trên trang web MS dưới dạng một ứng dụng độc lập. docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

Hồ sơ là một ứng dụng của “SQL Server Profiler” được cài đặt với SSMS.
Giám sát hiệu suất là một phần mềm của bảng điều khiển cho phép bạn theo dõi bộ đếm hiệu suất, ghi nhật ký và xem lịch sử của các phép đo.

Cập nhật thống kê bằng cách sử dụng “gói dịch vụ”:

chạy SSMS;
kết nối với một máy chủ được yêu cầu;
mở rộng cây trong Trình kiểm tra đối tượng:Quản lý \ Kế hoạch bảo trì (Kế hoạch dịch vụ);
nhấp chuột phải vào nút và chọn “Trình hướng dẫn kế hoạch bảo trì”;
trong trình hướng dẫn, hãy đánh dấu các tác vụ bắt buộc:xây dựng lại chỉ mục và cập nhật số liệu thống kê

bạn có thể đánh dấu cả hai nhiệm vụ cùng một lúc hoặc lập hai kế hoạch bảo trì với một nhiệm vụ trong mỗi nhiệm vụ (xem “các lưu ý quan trọng” bên dưới);
hơn nữa, chúng tôi kiểm tra một DB bắt buộc (hoặc một số cơ sở dữ liệu). Chúng tôi thực hiện điều này cho mỗi tác vụ (nếu hai tác vụ được chọn, sẽ có hai hộp thoại với sự lựa chọn của cơ sở dữ liệu);
Tiếp theo, Tiếp theo, Kết thúc.

Sau những hành động này, một “kế hoạch bảo trì” sẽ được tạo (không được thực thi). Bạn có thể chạy nó theo cách thủ công bằng cách nhấp chuột phải vào nó và chọn “Execute”. Ngoài ra, bạn định cấu hình khởi chạy thông qua SQL Agent.

Các lưu ý quan trọng:

Cập nhật thống kê là một hoạt động không chặn. Bạn có thể thực hiện nó ở chế độ làm việc.
Xây dựng lại chỉ mục là một hoạt động chặn. Bạn chỉ có thể chạy nó ngoài giờ làm việc. Có một ngoại lệ - phiên bản Enterprise của máy chủ cho phép thực hiện "xây dựng lại trực tuyến". Tùy chọn này có thể được bật trong cài đặt tác vụ. Xin lưu ý rằng có một dấu kiểm trong tất cả các phiên bản, nhưng nó chỉ hoạt động trong Enterprise.
Tất nhiên, các tác vụ này phải được thực hiện thường xuyên. Tôi đề xuất một cách dễ dàng để xác định tần suất bạn làm việc này:

- Với các sự cố đầu tiên, thực hiện kế hoạch bảo trì;

- Nếu có ích, hãy đợi cho đến khi sự cố xảy ra một lần nữa (thường là cho đến kỳ đóng hàng tháng tiếp theo / cách tính lương / v.v. của các giao dịch số lượng lớn);

- Khoảng thời gian kết quả của một hoạt động bình thường sẽ là điểm tham chiếu của bạn;

- Ví dụ:định cấu hình việc thực hiện kế hoạch bảo trì gấp đôi thường xuyên.

Máy chủ chạy chậm - Bạn nên làm gì?

Tài nguyên được máy chủ sử dụng

Giống như bất kỳ chương trình nào khác, máy chủ cần thời gian xử lý, dữ liệu trên đĩa, dung lượng RAM và băng thông mạng.

Task Manager sẽ giúp bạn đánh giá sự thiếu hụt của một tài nguyên nhất định trong lần ước lượng đầu tiên, bất kể điều đó nghe có vẻ khủng khiếp đến mức nào.

CPU Tải

Ngay cả một học sinh cũng có thể kiểm tra việc sử dụng trong Trình quản lý. Chúng tôi chỉ cần đảm bảo rằng nếu bộ xử lý được tải thì đó là quá trình sqlserver.exe.

Nếu đây là trường hợp của bạn, bạn cần phải đi đến phần phân tích hoạt động của người dùng để hiểu chính xác điều gì đã gây ra tải (xem bên dưới).

Đĩa Loa d

Nhiều người chỉ nhìn vào tải của CPU mà quên rằng DBMS là một kho lưu trữ dữ liệu. Khối lượng dữ liệu ngày càng lớn, hiệu suất bộ xử lý ngày càng tăng trong khi tốc độ ổ cứng cũng tương đương nhau. Với SSD thì tình hình tốt hơn, nhưng việc lưu trữ terabyte trên chúng thì rất tốn kém.

Hóa ra là tôi thường gặp các tình huống trong đó hệ thống đĩa trở thành nút cổ chai, thay vì CPU.

Đối với đĩa, các số liệu sau rất quan trọng:

độ dài hàng đợi trung bình (hoạt động I / O chưa xuất hiện, số lượng);
tốc độ đọc-ghi (tính bằng Mb / s).

Theo quy tắc, phiên bản máy chủ của Trình quản lý tác vụ (tùy thuộc vào phiên bản hệ thống), hiển thị cả hai. Nếu không, hãy chạy phần đính vào Màn hình hiệu suất (màn hình hệ thống). Chúng tôi quan tâm đến các quầy sau:

Đĩa vật lý (logic) / Thời gian đọc (ghi) trung bình
Đĩa vật lý (logic) / Độ dài hàng đợi đĩa trung bình
Đĩa / tốc độ đĩa vật lý (logic)

Để biết thêm chi tiết, bạn có thể đọc hướng dẫn sử dụng của nhà sản xuất, chẳng hạn tại đây:social.technet.microsoft.com/wiki/contents/articles/3214.monitoring-disk-usage.aspx.

Tóm lại:

Hàng đợi không được vượt quá 1. Cho phép xuất hiện các loạt ngắn nếu chúng nhanh chóng giảm xuống. Các đợt bùng nổ có thể khác nhau tùy thuộc vào hệ thống của bạn. Đối với một máy nhân bản RAID đơn giản của hai ổ cứng - hàng đợi hơn 10-20 là một vấn đề. Đối với một thư viện thú vị với siêu bộ nhớ đệm, tôi đã thấy các sự cố lên đến 600-800 được giải quyết ngay lập tức mà không gây ra sự chậm trễ.
Tỷ giá hối đoái thông thường cũng phụ thuộc vào loại hệ thống đĩa. Ổ cứng thông thường (máy tính để bàn) truyền với tốc độ 50-100 MB / s. Thư viện đĩa tốt - 500 MB / s và hơn thế nữa. Đối với các hoạt động ngẫu nhiên nhỏ, tốc độ ít hơn. Đây có thể là điểm tham chiếu của bạn.
Các tham số này phải được xem xét một cách tổng thể. Nếu thư viện của bạn truyền 50MB / s và một hàng đợi gồm 50 thao tác xếp hàng - rõ ràng là có gì đó không ổn với phần cứng. Nếu hàng đợi xếp hàng khi đường truyền gần đạt mức tối đa - rất có thể, các đĩa không đáng bị đổ lỗi - chúng chỉ không thể làm được nhiều hơn - chúng ta cần tìm cách giảm tải.
Tải trọng phải được kiểm tra riêng trên các đĩa (nếu có nhiều đĩa) và so sánh với vị trí của các tệp máy chủ. Trình quản lý Tác vụ có thể hiển thị các tệp được sử dụng tích cực nhất. Điều này có thể được sử dụng để đảm bảo rằng tải do DBMS gây ra.

Điều gì có thể gây ra sự cố hệ thống đĩa:

sự cố với phần cứng

bộ nhớ cache bị cháy hết, hiệu suất giảm đáng kể;
hệ thống đĩa được sử dụng bởi thứ khác;

Thiếu RAM. Hoán đổi. Bộ nhớ đệm bị giảm sút, hiệu suất giảm (xem phần về RAM bên dưới).
Tải lượng người dùng tăng lên. Cần phải đánh giá công việc của người dùng (truy vấn có vấn đề / chức năng mới / tăng số lượng người dùng / tăng lượng dữ liệu / v.v.).
Phân mảnh dữ liệu cơ sở dữ liệu (xem phần xây dựng lại chỉ mục ở trên), phân mảnh tệp hệ thống.
Hệ thống đĩa đã đạt đến khả năng tối đa của nó.

Trong trường hợp của tùy chọn cuối cùng - đừng vứt bỏ phần cứng cùng một lúc. Đôi khi, bạn có thể nhận được nhiều hơn một chút từ hệ thống nếu bạn tiếp cận vấn đề một cách khôn ngoan. Kiểm tra vị trí của các tệp hệ thống xem có tuân thủ các yêu cầu được khuyến nghị không:

Không trộn các tệp hệ điều hành với tệp dữ liệu cơ sở dữ liệu. Lưu trữ chúng trên các phương tiện vật lý khác nhau để hệ thống không cạnh tranh với DBMS cho I / O.
Cơ sở dữ liệu bao gồm hai loại tệp:dữ liệu (* .mdf, * .ndf) và nhật ký (* .ldf).
Các tệp dữ liệu, như một quy luật, chủ yếu được sử dụng để đọc. Nhật ký phục vụ cho việc viết (trong đó việc viết là liên tiếp). Do đó, bạn nên lưu trữ nhật ký và dữ liệu trên các phương tiện vật lý khác nhau để việc ghi nhật ký không làm gián đoạn việc đọc dữ liệu (theo quy luật, thao tác ghi được ưu tiên hơn thao tác đọc).
MS SQL có thể sử dụng "bảng tạm thời" để xử lý truy vấn. Chúng được lưu trữ trong cơ sở dữ liệu hệ thống tempdb. Nếu tải nhiều tệp của cơ sở dữ liệu này, bạn có thể thử hiển thị nó trên phương tiện vật lý riêng biệt.

Tóm tắt vấn đề với vị trí tệp, sử dụng nguyên tắc “chia để trị”. Đánh giá tệp nào được truy cập và cố gắng phân phối chúng đến các phương tiện khác nhau. Ngoài ra, hãy sử dụng các tính năng của hệ thống RAID. Ví dụ:đọc RAID-5 nhanh hơn ghi - điều này tốt cho các tệp dữ liệu.

Hãy cùng khám phá cách truy xuất thông tin về hiệu suất của người dùng:ai tạo ra thứ gì và lượng tài nguyên được sử dụng

Tôi đã chia các nhiệm vụ kiểm tra hoạt động của người dùng thành các nhóm sau:

Nhiệm vụ phân tích yêu cầu cụ thể.
Nhiệm vụ phân tích tải từ ứng dụng trong các điều kiện cụ thể (ví dụ:khi người dùng nhấp vào nút trong ứng dụng của bên thứ ba tương thích với cơ sở dữ liệu).
Nhiệm vụ phân tích tình hình hiện tại.

Hãy xem xét từng chi tiết trong số chúng.

Cảnh báo

Việc phân tích hiệu suất đòi hỏi sự hiểu biết sâu sắc về cấu trúc và nguyên lý hoạt động của máy chủ cơ sở dữ liệu và hệ điều hành. Đó là lý do tại sao chỉ đọc những bài báo này sẽ không khiến bạn trở thành người chuyên nghiệp.

Các tiêu chí được xem xét và bộ đếm trong hệ thống thực phụ thuộc rất nhiều vào nhau. Ví dụ, tải trọng HDD cao thường do thiếu RAM. Ngay cả khi bạn tiến hành một số phép đo, điều này vẫn chưa đủ để đánh giá vấn đề một cách hợp lý.

Mục đích của bài viết là giới thiệu những điều cần thiết về các ví dụ đơn giản. Bạn không nên coi các khuyến nghị của tôi như một hướng dẫn. Tôi khuyên bạn nên sử dụng chúng làm nhiệm vụ đào tạo có thể giải thích luồng suy nghĩ.

Tôi hy vọng rằng bạn sẽ học được cách hợp lý hóa kết luận của mình về hiệu suất máy chủ trong các số liệu.

Thay vì nói "máy chủ chạy chậm", bạn sẽ cung cấp các giá trị cụ thể của các chỉ số cụ thể.

Phân tích P rõ ràng R cưỡi ngựa

Điểm đầu tiên khá đơn giản, chúng ta hãy xem xét nó một cách ngắn gọn. Chúng tôi sẽ xem xét một số vấn đề ít rõ ràng hơn.

Ngoài kết quả truy vấn, SSMS cho phép truy xuất thông tin bổ sung về việc thực thi truy vấn:

Bạn có thể nhận được kế hoạch truy vấn bằng cách nhấp vào nút "Hiển thị Kế hoạch Thực thi Ước tính" và "Bao gồm Kế hoạch Thực thi Thực tế". Sự khác biệt giữa chúng là kế hoạch ước tính được xây dựng mà không cần thực thi truy vấn. Do đó, thông tin về số lượng hàng được xử lý sẽ được ước tính. Trong kế hoạch thực tế, sẽ có cả dữ liệu ước tính và thực tế. Sự khác biệt lớn của các giá trị này cho thấy rằng thống kê không có liên quan. Tuy nhiên, việc phân tích kế hoạch là một chủ đề cho một bài báo khác - cho đến nay, chúng tôi sẽ không đi sâu hơn.
Chúng tôi có thể nhận được các phép đo chi phí bộ xử lý và hoạt động ổ đĩa của máy chủ. Để làm điều này, cần phải bật tùy chọn SET. Bạn có thể làm điều đó trong hộp thoại 'Tùy chọn truy vấn' như sau:

Hoặc với các lệnh SET trực tiếp trong truy vấn:

      SET STATISTICS IO ON
      SET STATISTICS TIME ON
      SELECT * FROM Production.Product p
      JOIN Production.ProductDocument pd ON p.ProductID = pd.ProductID
      JOIN Production.ProductProductPhoto ppp ON p.ProductID = ppp.ProductID

Do đó, chúng tôi sẽ nhận được dữ liệu về thời gian biên dịch và thực thi, cũng như số lượng hoạt động của đĩa.

Time of SQL Server parsing and compilation:
CPU time = 16 ms, elapsed time = 89 ms.
 
SQL Server performance time:
CPU time = 0 ms, time spent = 0 ms.
 
SQL Server performance time:
CPU time = 0 ms, time spent = 0 ms.
(32 row(s) affected)
The «ProductProductPhoto» table. The number of views is 32, logic reads – 96, physical reads 5, read-ahead reads 0, lob of logical reads 0, lob of physical reads 0, lob of read-ahead reads 0.
The ‘Product’ table. The number of views is 0, logic reads – 64, physical reads – 0, read-ahead reads – 0, lob of logical reads – 0, lob of physical reads – 0, lob of readahead reads – 0.
The «ProductDocument» table. The number of views is 1, logical reads – 3, physical reads – 1, read-ahead reads -, lob of logical reads – 0, lob of physical reads – 0, lob of readahead reads – 0.
Time of SQL activity:
CPU time = 15 ms, spent time = 35 ms.

Tôi muốn thu hút sự chú ý của bạn đến thời gian biên dịch, số lần đọc logic 96 và số lần đọc vật lý 5. Khi thực hiện cùng một truy vấn lần thứ hai và sau đó, số lần đọc vật lý có thể giảm và có thể không cần biên dịch lại. Do thực tế này, thường xảy ra trường hợp truy vấn được thực thi nhanh hơn trong lần thứ hai và lần sau so với lần đầu tiên. Như bạn hiểu, lý do là trong bộ đệm dữ liệu và các kế hoạch truy vấn đã biên dịch.

Nút «Bao gồm Thống kê Khách hàng» hiển thị thông tin về trao đổi mạng, số lượng hoạt động đã thực hiện và tổng thời gian thực hiện, bao gồm cả chi phí trao đổi và xử lý mạng của khách hàng. Ví dụ cho thấy rằng cần nhiều thời gian hơn để thực hiện truy vấn lần đầu tiên:

Trong SSMS 2016, có nút «Bao gồm Thống kê Truy vấn Trực tiếp». Nó hiển thị hình ảnh như trong trường hợp của kế hoạch truy vấn nhưng có chứa các chữ số không thuộc nhóm được xử lý, các chữ số này sẽ thay đổi trên màn hình trong khi thực hiện truy vấn. Hình ảnh rất rõ ràng - các mũi tên nhấp nháy và các con số đang chạy, bạn có thể thấy ngay thời gian bị lãng phí ở đâu. Nút này cũng hoạt động cho SQL Server 2014 trở lên.

Tóm lại:

Kiểm tra chi phí CPU bằng cách BẬT THỜI GIAN THỐNG KÊ.
Hoạt động trên đĩa:ĐẶT THỐNG KÊ IO ON. Đừng quên rằng đọc logic là một hoạt động đọc được hoàn thành trong bộ nhớ cache của đĩa mà không cần truy cập vật lý vào hệ thống đĩa. “Đọc thực tế” mất nhiều thời gian hơn.
Đánh giá khối lượng lưu lượng truy cập mạng bằng cách sử dụng «Bao gồm số liệu thống kê về khách hàng».
Phân tích thuật toán thực hiện truy vấn theo kế hoạch thực thi bằng cách sử dụng «Bao gồm kế hoạch thực thi thực tế» và «Bao gồm thống kê truy vấn trực tiếp».

Phân tích tải ứng dụng

Ở đây chúng ta sẽ sử dụng SQL Server Profiler. Sau khi khởi chạy và kết nối với máy chủ, cần phải chọn các sự kiện nhật ký. Để làm điều này, hãy chạy hồ sơ với một mẫu theo dõi tiêu chuẩn. Trên General trong tab Sử dụng mẫu , chọn Tiêu chuẩn (mặc định) và nhấp vào Chạy .

Cách phức tạp hơn là thêm / thả bộ lọc hoặc sự kiện vào / từ mẫu đã chọn. Các tùy chọn này có thể được tìm thấy trên tab thứ hai của menu hộp thoại. Để xem đầy đủ các sự kiện và cột có thể có để chọn, hãy chọn nút Hiển thị tất cả sự kiện và Hiển thị tất cả các cột hộp kiểm.

Chúng tôi sẽ cần những sự kiện sau:

Các thủ tục được lưu trữ \ RPC:Đã hoàn thành
TSQL \ SQL:BatchCompleted

Các sự kiện này giám sát tất cả các lệnh gọi SQL bên ngoài tới máy chủ. Chúng xuất hiện sau khi hoàn thành quá trình xử lý truy vấn. Có những sự kiện tương tự theo dõi sự khởi động của SQL Server:

Thủ tục được lưu trữ \ RPC:Đang bắt đầu
TSQL \ SQL:BatchStarting

Tuy nhiên, chúng tôi không cần các thủ tục này vì chúng không chứa thông tin về tài nguyên máy chủ được sử dụng để thực hiện truy vấn. Rõ ràng là thông tin đó chỉ có sẵn sau khi hoàn thành quá trình thực thi. Do đó, các cột có dữ liệu về CPU, Đọc, Ghi trong sự kiện * Bắt đầu sẽ trống.

Các sự kiện sau đây cũng có thể quan tâm đến chúng tôi, tuy nhiên, chúng tôi sẽ không kích hoạt chúng cho đến nay:

Thủ tục được lưu trữ \ SP:Bắt đầu (* Đã hoàn thành) giám sát cuộc gọi nội bộ tới thủ tục đã lưu trữ không phải từ máy khách mà trong yêu cầu hiện tại hoặc thủ tục khác.
Thủ tục được Lưu trữ \ SP:StmtStarting (* Đã hoàn thành) theo dõi phần bắt đầu của mỗi câu lệnh trong thủ tục được lưu trữ. Nếu có một chu trình trong thủ tục, số sự kiện của các lệnh trong chu trình sẽ bằng số lần lặp trong chu trình.
TSQL \ SQL:StmtStarting (* Đã hoàn thành) giám sát việc bắt đầu mỗi câu lệnh trong SQL-batch. Nếu có một số lệnh trong truy vấn của bạn, mỗi lệnh sẽ chứa một sự kiện. Do đó, nó hoạt động đối với các lệnh nằm trong truy vấn.

Những sự kiện này thuận tiện cho việc theo dõi quá trình thực thi.

Bởi C các cột

Các cột để chọn là rõ ràng khỏi tên nút. Chúng tôi sẽ cần những thứ sau:

Dữ liệu văn bản, Dữ liệu nhị phân chứa văn bản truy vấn.
CPU, Số lần đọc, Số lần ghi, Thời lượng hiển thị dữ liệu về mức tiêu thụ tài nguyên.
StartTime, EndTime là thời gian bắt đầu và kết thúc quá trình thực thi. Chúng thuận tiện cho việc phân loại.

Thêm các cột khác dựa trên sở thích của bạn.

Bộ lọc cột… mở hộp thoại để định cấu hình bộ lọc sự kiện. Nếu bạn quan tâm đến hoạt động của người dùng cụ thể, bạn có thể đặt bộ lọc theo số SID hoặc tên người dùng. Thật không may, trong trường hợp kết nối ứng dụng thông qua máy chủ ứng dụng với việc kéo các kết nối, việc giám sát người dùng cụ thể trở nên phức tạp hơn.

Bạn có thể sử dụng bộ lọc để chỉ lựa chọn các truy vấn phức tạp (Thời lượng> X), các truy vấn gây ra ghi nhiều (Viết> Y), cũng như lựa chọn nội dung truy vấn, v.v.

Chúng ta cần gì nữa từ trình biên dịch? Tất nhiên, kế hoạch thực hiện!

Cần phải thêm sự kiện «Hồ sơ thống kê XML Performance \ Showplan» vào truy tìm. Trong khi thực hiện truy vấn của chúng tôi, chúng tôi sẽ nhận được hình ảnh sau:

Văn bản truy vấn:

Kế hoạch thực hiện:

Và đó không phải là tất cả

Có thể lưu dấu vết vào tệp hoặc bảng cơ sở dữ liệu. Cài đặt theo dõi có thể được lưu trữ dưới dạng mẫu cá nhân để chạy nhanh. Bạn có thể chạy theo dõi mà không cần trình biên dịch, đơn giản bằng cách sử dụng mã T-SQL và các thủ tục sp_trace_create, sp_trace_setevent, sp_trace_setstatus, sp_trace_getdata. Bạn có thể tìm thấy một ví dụ ở đây. Cách tiếp cận này có thể hữu ích, chẳng hạn, để bắt đầu tự động lưu trữ một dấu vết vào một tệp theo lịch trình. Bạn có thể có một đỉnh cao lén lút tại trình biên dịch để xem cách sử dụng các lệnh này. Bạn có thể chạy hai dấu vết và trong một dấu vết theo dõi những gì xảy ra khi dấu vết thứ hai bắt đầu. Kiểm tra để đảm bảo rằng không có bộ lọc nào theo cột “Tên ứng dụng” trên chính trình cấu hình.

Danh sách các sự kiện được trình biên dịch giám sát rất lớn và không giới hạn ở việc nhận văn bản truy vấn. Có những sự kiện theo dõi quét toàn bộ, biên dịch lại, tự động duyệt, bế tắc và nhiều hơn nữa.

Phân tích hoạt động của người dùng trên máy chủ

Có những tình huống khác nhau. Một truy vấn có thể bị treo trên "thực thi" trong một thời gian dài và không rõ liệu nó có được hoàn thành hay không. Tôi muốn phân tích riêng truy vấn có vấn đề; tuy nhiên, trước tiên chúng ta phải xác định truy vấn là gì. Sẽ vô ích nếu bạn nắm bắt nó bằng một hồ sơ - chúng tôi đã bỏ lỡ sự kiện bắt đầu và không rõ phải đợi bao lâu để quá trình hoàn tất.

Hãy cùng tìm hiểu

Bạn có thể đã nghe nói về "Activity Monitor". Các phiên bản cao hơn của nó có chức năng thực sự phong phú. Nó có thể giúp chúng ta như thế nào? Activity Monitor bao gồm nhiều tính năng hữu ích và thú vị. Chúng tôi sẽ nhận được mọi thứ chúng tôi cần từ các chế độ xem và chức năng của hệ thống. Bản thân màn hình rất hữu ích vì bạn có thể đặt trình biên dịch trên đó và xem nó thực hiện những truy vấn nào.

Chúng tôi sẽ cần:

dm_exec_sessions cung cấp thông tin về các phiên của những người dùng được kết nối. Trong bài viết của chúng tôi, các trường hữu ích là các trường xác định người dùng (tên_kích_thước, tên_thời_ gian_nghiệp, tên_người_nghiệp, tên_chương_trình,…) và các trường có thông tin về tài nguyên đã sử dụng (cpu_time, đọc, ghi, dung lượng bộ nhớ,…)
dm_exec_requests cung cấp thông tin về các truy vấn được thực thi tại thời điểm này.
session_id là số nhận dạng của phiên để liên kết với chế độ xem trước đó.
start_time là thời gian chạy chế độ xem.
là một trường chứa một loại lệnh được thực thi. Đối với các truy vấn của người dùng, nó là chọn / cập nhật / xóa /
sql_handle, statement_start_offset, statement_end_offset cung cấp thông tin để truy xuất văn bản truy vấn:handle, cũng như vị trí bắt đầu và kết thúc trong văn bản của truy vấn, có nghĩa là phần hiện đang được thực thi (đối với trường hợp truy vấn của bạn chứa một số lệnh).
plan_handle là phần xử lý của kế hoạch đã tạo.
blocks_session_id cho biết số lượng phiên đã gây ra chặn nếu có các khối ngăn cản việc thực thi truy vấn
wait_type, wait_time, wait_resource là các trường có thông tin về lý do và khoảng thời gian chờ đợi. Đối với một số kiểu chờ, chẳng hạn như khóa dữ liệu, cần phải chỉ ra thêm một mã cho tài nguyên bị chặn.
phần trăm_complete là phần trăm hoàn thành. Thật không may, nó chỉ khả dụng cho các lệnh có tiến trình dự đoán rõ ràng (ví dụ:sao lưu hoặc khôi phục).
cpu_time, đọc, ghi, logic_reads, powers_query_memory là chi phí tài nguyên.
dm_exec_sql_text (sql_handle | plan_handle), sys.dm_exec_query_plan (plan_handle) là các hàm lấy văn bản và kế hoạch thực thi. Dưới đây, chúng tôi sẽ xem xét một ví dụ về việc sử dụng nó.
dm_exec_query_stats là một thống kê tóm tắt về việc thực thi các truy vấn. Nó hiển thị truy vấn, số lần thực thi và khối lượng tài nguyên đã sử dụng.

Những lưu ý quan trọng

Danh sách trên chỉ là một phần nhỏ. Danh sách đầy đủ của tất cả các chế độ xem và chức năng của hệ thống được mô tả trong tài liệu. Ngoài ra, có một hình ảnh đẹp cho thấy một sơ đồ liên kết giữa các đối tượng chính.

Văn bản truy vấn, kế hoạch của nó và thống kê thực thi là dữ liệu được lưu trữ trong bộ đệm thủ tục. Chúng có sẵn trong quá trình thực hiện. Khi đó, tính khả dụng không được đảm bảo và phụ thuộc vào tải bộ đệm. Có, bộ nhớ cache có thể được làm sạch theo cách thủ công. Đôi khi, nó được khuyến khích khi kế hoạch thực hiện bị "lật tẩy". Tuy nhiên, có rất nhiều sắc thái.

Trường "lệnh" là vô nghĩa đối với các yêu cầu của người dùng, vì chúng ta có thể lấy toàn bộ văn bản. Tuy nhiên, nó rất quan trọng để thu thập thông tin về các quy trình hệ thống. Theo quy định, chúng thực hiện một số tác vụ nội bộ và không có văn bản SQL. Đối với các quy trình như vậy, thông tin về lệnh là gợi ý duy nhất về loại hoạt động.

Trong các bình luận cho bài viết trước, có một câu hỏi về những gì máy chủ liên quan đến khi nó không hoạt động. Câu trả lời có lẽ sẽ nằm trong ý nghĩa của trường này. Trong thực tế của tôi, trường "lệnh" luôn cung cấp một cái gì đó khá dễ hiểu cho các quy trình hệ thống đang hoạt động:autoshrink / autogrow / checkpoint / logwriter / v.v.

Cách sử dụng

Chúng ta sẽ sang phần thực hành. Tôi sẽ cung cấp một số ví dụ về việc sử dụng nó. Khả năng của máy chủ không bị giới hạn - bạn có thể nghĩ về các ví dụ của riêng mình.

Ví dụ 1. Quá trình nào sử dụng CPU / đọc / ghi / bộ nhớ

Đầu tiên, hãy xem các phiên sử dụng nhiều tài nguyên hơn, ví dụ:CPU. Bạn có thể tìm thấy thông tin này trong sys.dm_exec_sessions. Tuy nhiên, dữ liệu trên CPU, bao gồm cả đọc và ghi, là tích lũy. Nó có nghĩa là con số chứa tổng số cho tất cả thời gian kết nối. Rõ ràng là người dùng đã kết nối một tháng trước và không bị ngắt kết nối sẽ có giá trị cao hơn. Nó không có nghĩa là chúng làm quá tải hệ thống.

Mã có thuật toán sau có thể giải quyết vấn đề này:

Thực hiện một lựa chọn và lưu trữ nó trong một bảng tạm thời
Chờ một lúc
Thực hiện lựa chọn lần thứ hai
So sánh các kết quả này. Sự khác biệt của chúng sẽ chỉ ra chi phí đã bỏ ra ở bước 2.
Để thuận tiện, sự khác biệt có thể được chia cho khoảng thời gian của bước 2 để có được "chi phí mỗi giây" trung bình.

if object_id('tempdb..#tmp') is NULL
BEGIN
        SELECT * into #tmp from sys.dm_exec_sessions s
        PRINT 'wait for a second to collect statistics at the first run '
        -- we do not wait for the next launches, because we compare with the result of the previous launch
        WAITFOR DELAY '00:00:01';
END
if object_id('tempdb..#tmp1') is not null drop table #tmp1

declare @d datetime
declare @dd float
select @d = crdate from tempdb.dbo.sysobjects where id=object_id('tempdb..#tmp')

select * into #tmp1 from sys.dm_exec_sessions s
select @dd=datediff(ms,@d,getdate())
select @dd AS [time interval, ms]

SELECT TOP 30 s.session_id, s.host_name, db_name(s.database_id) as db, s.login_name,s.login_time,s.program_name,
       s.cpu_time-isnull(t.cpu_time,0) as cpu_Diff, convert(numeric(16,2),(s.cpu_time-isnull(t.cpu_time,0))/@dd*1000) as cpu_sec,
       s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0) as totIO_Diff, convert(numeric(16,2),(s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0))/@dd*1000) as totIO_sec,
       s.reads-isnull(t.reads,0) as reads_Diff, convert(numeric(16,2),(s.reads-isnull(t.reads,0))/@dd*1000) as reads_sec,
       s.writes-isnull(t.writes,0) as writes_Diff, convert(numeric(16,2),(s.writes-isnull(t.writes,0))/@dd*1000) as writes_sec,
       s.logical_reads-isnull(t.logical_reads,0) as logical_reads_Diff, convert(numeric(16,2),(s.logical_reads-isnull(t.logical_reads,0))/@dd*1000) as logical_reads_sec,
       s.memory_usage, s.memory_usage-isnull(t.memory_usage,0) as [mem_D],
      s.nt_user_name,s.nt_domain
from #tmp1 s
LEFT join #tmp t on s.session_id=t.session_id
order BY
cpu_Diff desc
--totIO_Diff desc
--logical_reads_Diff desc

drop table #tmp
GO
select * into #tmp from #tmp1
drop table #tmp1

Tôi sử dụng hai bảng trong mã:#tmp - cho lựa chọn đầu tiên và # tmp1 - cho lựa chọn thứ hai. Trong lần chạy đầu tiên, tập lệnh tạo và điền #tmp và # tmp1 vào khoảng thời gian một giây, sau đó thực hiện các tác vụ khác. Với các lần chạy tiếp theo, tập lệnh sử dụng kết quả của lần thực hiện trước đó làm cơ sở để so sánh. Do đó, khoảng thời gian của bước 2 sẽ bằng khoảng thời gian bạn chờ đợi giữa các lần chạy tập lệnh.

Hãy thử thực hiện nó, ngay cả trên máy chủ sản xuất. Tập lệnh sẽ chỉ tạo 'bảng tạm thời' (có sẵn trong phiên hiện tại và bị xóa khi bị vô hiệu hóa) và không có chuỗi.

Những người không thích thực hiện một truy vấn trong MS SSMS có thể bọc nó trong một ứng dụng được viết bằng ngôn ngữ lập trình yêu thích của họ. Tôi sẽ chỉ cho bạn cách thực hiện việc này trong MS Excel mà không cần một dòng mã nào.

Trong menu Dữ liệu, hãy kết nối với máy chủ. Nếu bạn được nhắc chọn một bảng, hãy chọn một bảng ngẫu nhiên. Nhấp vào Tiếp theo và Kết thúc cho đến khi bạn thấy hộp thoại Nhập dữ liệu. Trong cửa sổ đó, bạn cần nhấp vào Thuộc tính. Trong Thuộc tính, cần phải thay thế một loại lệnh bằng giá trị SQL và chèn truy vấn đã sửa đổi của chúng tôi vào trường Văn bản lệnh.

Bạn sẽ phải sửa đổi truy vấn một chút:

Thêm «ĐẶT SỐ TÀI KHOẢN BẬT»
Thay thế các bảng tạm thời bằng các bảng biến
Độ trễ sẽ kéo dài trong vòng 1 giây. Các trường có giá trị trung bình là không bắt buộc

Truy vấn được sửa đổi cho Excel

SET NOCOUNT ON;
declare @tmp table(session_id   smallint primary key,login_time datetime,host_name nvarchar(256),program_name nvarchar(256),login_name nvarchar(256),nt_user_name       nvarchar(256),cpu_time  int,memory_usage        int,reads       bigint,writes   bigint,logical_reads    bigint,database_id      smallint)

declare @d datetime;
select @d=GETDATE()

INSERT INTO @tmp(session_id,login_time,host_name,program_name,login_name,nt_user_name,cpu_time,memory_usage,reads,writes,logical_reads,database_id)
SELECT session_id,login_time,host_name,program_name,login_name,nt_user_name,cpu_time,memory_usage,reads,writes,logical_reads,database_id
from sys.dm_exec_sessions s;

WAITFOR DELAY '00:00:01';

declare @dd float;
select @dd=datediff(ms,@d,getdate());

SELECT 
        s.session_id, s.host_name, db_name(s.database_id) as db, s.login_name,s.login_time,s.program_name,
        s.cpu_time-isnull(t.cpu_time,0) as cpu_Diff,
        s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0) as totIO_Diff,
        s.reads-isnull(t.reads,0) as reads_Diff,
        s.writes-isnull(t.writes,0) as writes_Diff,
        s.logical_reads-isnull(t.logical_reads,0) as logical_reads_Diff,
        s.memory_usage, s.memory_usage-isnull(t.memory_usage,0) as [mem_Diff],
        s.nt_user_name,s.nt_domain
from sys.dm_exec_sessions s
left join @tmp t on s.session_id=t.session_id

Kết quả:

Khi dữ liệu xuất hiện trong Excel, bạn có thể sắp xếp nó khi cần. Để cập nhật thông tin, hãy nhấp vào ‘Làm mới’. Trong cài đặt sổ làm việc, bạn có thể đặt "tự động cập nhật" trong một khoảng thời gian cụ thể và "cập nhật khi bắt đầu". Bạn có thể lưu tệp và chuyển cho đồng nghiệp của mình. Do đó, chúng tôi đã tạo ra một công cụ thuận tiện và đơn giản.

Ví dụ 2. Một phiên sử dụng tài nguyên vào việc gì?

Bây giờ, chúng ta sẽ xác định xem các phiên sự cố thực sự làm gì. Để thực hiện việc này, hãy sử dụng sys.dm_exec_requests và các hàm để nhận văn bản truy vấn và kế hoạch truy vấn.

Truy vấn và kế hoạch thực thi theo số phiên

DECLARE @sql_handle varbinary(64)
DECLARE @plan_handle varbinary(64)
DECLARE @sid INT
Declare @statement_start_offset int, @statement_end_offset INT, @session_id SMALLINT

-- for the information by a particular user – indicate a session number
SELECT @sid=182

-- receive state variables for further processing
IF @sid IS NOT NULL
SELECT @sql_handle=der.sql_handle, @plan_handle=der.plan_handle, @statement_start_offset=der.statement_start_offset, @statement_end_offset=der.statement_end_offset, @session_id = der.session_id
FROM sys.dm_exec_requests der WHERE [email protected]

-- print the text of the query being executed 
DECLARE @txt VARCHAR(max)
IF @sql_handle IS NOT NULL
SELECT @txt=[text] FROM sys.dm_exec_sql_text(@sql_handle)
PRINT @txt
-- output the plan of the batch/procedure being executed
IF @plan_handle IS NOT NULL
select * from sys.dm_exec_query_plan(@plan_handle)
-- and the plan of the query being executed within the batch/procedure
IF @plan_handle IS NOT NULL
SELECT dbid, objectid, number, encrypted, CAST(query_plan AS XML) AS planxml
from sys.dm_exec_text_query_plan(@plan_handle, @statement_start_offset, @statement_end_offset)

Chèn số phiên vào truy vấn và chạy nó. After execution, there will be plans on the Results tab (the first one is for the whole query, and the second one is for the current step if there are several steps in the query) and the query text on the Messages tab. To view the plan, you need to click the text that looks like the URL in the row. The plan will be opened in a separate tab. Sometimes, it happens that the plan is opened not in a graphical form, but in the form of XML-text. This may happen because the MS SSMS version is lower than the server. Delete the “Version” and “Build” from the first row and then save the result XML to a file with the .sqlplan extension. After that, open it separately. If this does not help, I remind you that the 2016 studio is officially available for free on the MS website.

It is obvious that the result plan will be an estimated one, as the query is being executed. Still, it is possible to receive some execution statistics. To do this, use the sys.dm_exec_query_stats view with the filter by our handles.

Add this information at the end of the previous query

-- plan statistics 
IF @sql_handle IS NOT NULL
SELECT * FROM sys.dm_exec_query_stats QS WHERE [email protected]_handle

As a result, we will get the information about the steps of the executed query:how many times they were executed and what resources were spent. This information is added to the statistics only after the execution process is completed. The statistics are not tied to the user but are maintained within the whole server. If different users execute the same query, the statistics will be total for all users.

Example 3. Can I see all of them?

Let’s combine the system views we considered with the functions in one query. It can be useful for evaluating the whole situation.

-- receive a list of all current queries
SELECT LEFT((SELECT [text] FROM sys.dm_exec_sql_text(der.sql_handle)),500) AS txt
--,(select top 1 1 from sys.dm_exec_query_profiles where session_id=der.session_id) as HasLiveStat
,der.blocking_session_id as blocker, DB_NAME(der.database_id) AS База, s.login_name, *
from sys.dm_exec_requests der
left join sys.dm_exec_sessions s ON s.session_id = der.session_id
WHERE der.session_id<>@@SPID
-- AND der.session_id>50

The query outputs a list of active sessions and texts of their queries. For system processes, usually, there is no query; however, the command field is filled up. You can see the information about blocks and waits, and mix this query with example 1 in order to sort by the load. Still, be careful, query texts may be large. Their massive selection can be resource-intensive and lead to a huge traffic increase. In the example, I limited the result query to the first 500 characters but did not execute the plan.

Conclusion

It would be great to get Live Query Statistics for an arbitrary session. According to the manufacturer, now, monitoring statistics requires many resources and therefore, it is disabled by default. Its enabling is not a problem, but additional manipulations complicate the process and reduce the practical benefit.

In this article, we analyzed user activity in the following ways:using possibilities MS SSMS, profiler, direct calls to system views. All these methods allow estimating costs on executing a query and getting the execution plan. Each method is suitable for a particular situation. Thus, the best solution is to combine them.