Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Kiến thức cơ bản về sys.dm_exec_requests

Giám sát hiệu suất và khắc phục sự cố trong SQL Server là một chủ đề rộng lớn. Trong SQL Server 2005, các dạng xem quản lý động, còn được gọi là DMV’s, đã được giới thiệu và trở thành một công cụ trợ giúp cần thiết để chẩn đoán các vấn đề về hiệu suất của SQL Server. Đồng thời, chúng ta có thể sử dụng các dạng xem quản lý động cho Cơ sở dữ liệu Azure SQL. Một số trong số chúng có thể khác với cơ sở dữ liệu tại chỗ của SQL Server nhưng logic của công việc vẫn giống nhau. Microsoft có tài liệu rất tốt về chế độ xem quản lý động. Điều duy nhất, bạn cần phải cẩn thận về phiên bản và xác thực sản phẩm của các chế độ xem quản lý động. Chẳng hạn như sys.dm_exec_request có sẵn cho SQL Server 2008 và các phiên bản mới hơn và cho cơ sở dữ liệu Azure SQL nhưng sys.dm_db_wait_stats chỉ hợp lệ cho cơ sở dữ liệu Azure SQL.

Trong bài đăng này, chúng ta sẽ nói về những điều cơ bản của sys.dm_exec_request. sys.dm_exec_requests là một dạng xem quản lý động chỉ trả về các yêu cầu hiện đang thực thi. Có nghĩa là khi bạn chạy truy vấn sys.dm_exec_requests, nó sẽ chụp nhanh yêu cầu đang chạy trong thời gian đó và không bao gồm bất kỳ dữ liệu lịch sử nào. Do đó, chế độ xem này rất tiện dụng để theo dõi các yêu cầu thời gian thực. Nói cách khác, nó đưa ra câu trả lời cho "điều gì đang xảy ra trong máy chủ của tôi vừa rồi?" Chế độ xem này bao gồm rất nhiều chi tiết nhưng chúng ta sẽ thảo luận những chi tiết quan trọng nhất.

session_id :Giá trị này xác định số nhận dạng phiên. Trong SQL Server, các ID phiên bằng hoặc nhỏ hơn 50 được dành riêng cho quy trình nền.

start_time :Giá trị này xác định ngày và giờ bắt đầu của yêu cầu.

trạng thái :Giá trị này xác định trạng thái của yêu cầu. Các trạng thái có sẵn là:

  • nền
  • đang chạy
  • chạy được
  • đang ngủ
  • tạm ngừng
SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID

nền :Loại trạng thái này xác định các quy trình nền. Một số trong số đó là LAZY WRITER, CHECKPOINT và LOG WRITER.

select session_id, command, os_thread_id from sys.dm_exec_requests as r
 join sys.dm_os_workers as w on r.task_address = w.task_address
 join sys.dm_os_threads as t on t.thread_address = w.thread_address
 where session_id <= 50
 order by session_id

đang chạy :Loại trạng thái này xác định rằng yêu cầu đang được xử lý bởi CPU.

 select * from sys.dm_exec_requests where status='running'
 and session_id <>@@SPID

chạy được :Loại trạng thái này có thể được định nghĩa đơn giản là một yêu cầu đang chờ trong hàng đợi CPU để chạy. Nếu bạn phát hiện thấy nhiều tiến trình có thể chạy được trong sys.dm_exec_requests, đó có thể là dấu hiệu của áp lực CPU. Số liệu này không đủ để chẩn đoán vấn đề hiệu suất CPU này. Vì lý do này, chúng tôi cần hỗ trợ trường hợp này với nhiều bằng chứng hơn. Điều này rất quan trọng để chúng tôi chứng minh lý thuyết của mình. Chế độ xem quản lý động sys.dm_os_wait_stats bao gồm một cột là signal_wait_time_ms. Giá trị cột này có thể là một hỗ trợ để xác định sự cố CPU. Truy vấn sau đây cho chúng ta thấy phần trăm Signalwait. Nếu số liệu này có giá trị cao, rất có thể bạn đang gặp phải vấn đề về hiệu suất CPU. Bạn có thể đào sâu đánh giá của mình theo cách này.

---https://sqlserverperformance.wordpress.com/page/146/
---Glenn Berry's SQL Server Performance 

SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
              ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
              ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
              ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
FROM sys.dm_os_wait_stats;

bị đình chỉ :Loại trạng thái này xác định quá trình chờ đợi của một số tài nguyên. Nó có thể là I / O, LOCK và LATCH, v.v. Như đã đề cập ở trên, chúng tôi có thể sử dụng sys.dm_os_wait_stats chế độ xem quản lý động để phát hiện wait_time_ms.

đang ngủ :Có nghĩa là yêu cầu được kết nối với SQL Server nhưng hiện không chạy bất kỳ lệnh nào.

lệnh :Cột này xác định một loại lệnh đang được thực thi. Đồng thời, chúng ta có thể tìm thấy thông tin bổ sung cho các lệnh cụ thể là tỷ lệ hoàn thành. Theo sách trực tuyến, đây là;

ALTER INDEX REORGANIZE

Tùy chọn AUTO_SHRINK với ALTER DATABASE

CƠ SỞ DỮ LIỆU DỰ PHÒNG

DBCC CHECKDB

DBCC CHECKFILEGROUP

DBCC CÓ THỂ KIỂM TRA

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

PHỤC HỒI

KHÔI PHỤC CƠ SỞ DỮ LIỆU

ROLLBACK

THAM GIA TDE

Bản trình diễn :

  • Kết nối cơ sở dữ liệu chính và bắt đầu sao lưu cho bất kỳ cơ sở dữ liệu nào.
    BACKUP DATABASE WideWorldImporters TO DISK ='NUL'

    Mẹo :Khi bạn thực hiện sao lưu cơ sở dữ liệu vào thiết bị “NUL”, SQL Server không ghi tệp sao lưu ở bất kỳ đâu và bạn tránh được việc xóa tệp sao lưu thử nghiệm. Nhưng không sử dụng lệnh này trong môi trường sản xuất của bạn. Nó có thể gây ra phá vỡ chuỗi LSN.

Thực hiện truy vấn sau:

SELECT command,percent_complete ,*
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID
and session_id>50 and command='BACKUP DATABASE'

sql_handle :Giá trị này xác định câu lệnh SQL của yêu cầu. Nhưng giá trị này ở định dạng bitmap. Vì lý do này, chúng tôi cần sử dụng hàm định trị bảng sys.dm_exec_sql_text để chuyển đổi giá trị thành văn bản có nghĩa.

select session_id ,command , sqltxt.text ,database_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
where session_id<>@@SPID AND session_id>50

database_id :Giá trị này xác định cơ sở dữ liệu nào thực hiện yêu cầu. Chúng ta có thể nối trường này với sys.databases để lấy tên cơ sở dữ liệu.

select session_id ,command , sqltxt.text ,db.name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

wait_type :Giá trị này xác định kiểu chờ hiện tại của yêu cầu. Nếu thời lượng thực thi truy vấn lâu hơn dự kiến, bạn có thể kiểm tra và xác định loại truy vấn chờ.

transaction_isolation_level :Giá trị này xác định cấp độ giao dịch của truy vấn đã gửi:

0 =Không xác định

1 =ReadUncomitted

2 =Đã đọc

3 =Lặp lại

4 =Serializable

5 =Ảnh chụp nhanh

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

blocks_session_id :Nó là id của phiên đang chặn yêu cầu. Nếu cột này là NULL, yêu cầu không chặn bất kỳ phiên nào.

Bản trình diễn :

  • Mở SQL Server Management Studio và thực hiện truy vấn sau.
    DROP TABLE IF EXISTS TestPerfomon
    GO
    CREATE TABLE TestPerfomon
    (ID INT ,
    Nm VARCHAR(100))
    
    INSERT INTO TestPerfomon
    VALUES(1,1)
    GO
    BEGIN TRAN
    UPDATE TestPerfomon SET Nm='2'
    WHERE ID=1
    
    SELECT @@SPID AS blocking_session_id

Mở cửa sổ truy vấn mới và thực hiện truy vấn sau.

SET TRANSACTION ISOLATION LEVEL Serializable
BEGIN TRAN
UPDATE TestPerfomon SET Nm='3'
WHERE ID=1

Mở một cửa sổ truy vấn mới và chạy truy vấn DMV này.

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name ,
blocking_session_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

Với phần trình diễn này, chúng tôi đã tìm ra lý do tại sao truy vấn thứ hai bị chặn và phiên nào bị chặn yêu cầu. Khi bạn chạy sp_BlitzWho 65, bạn có thể tìm hiểu chi tiết về quá trình chặn và chi tiết về phiên bị chặn.

sp_BlitzWho 65

Trong phần trình diễn này, chúng tôi đã truy xuất chi tiết về các phiên bị chặn và bị chặn, đồng thời, chúng tôi có được thông tin chi tiết về các phiên này. Đây là một minh chứng rất cơ bản nhưng nó cho thấy vấn đề có thể được giải quyết như thế nào.

Trong bài đăng này, chúng tôi đã nói về sys.sys.dm_exec_requests. Chế độ xem quản lý động này cung cấp cho chúng tôi sự linh hoạt để có được ảnh chụp nhanh trong giai đoạn hiện tại của một yêu cầu. Ngoài ra, những dữ liệu chi tiết này có thể hỗ trợ hoặc hướng dẫn chúng tôi trong quá trình phát hiện ra vấn đề.

Tài liệu tham khảo

  • sys.dm_exec_requests (Transact-SQL)
  • Giám sát Cơ sở dữ liệu Azure SQL bằng cách sử dụng các chế độ xem quản lý động
  • sys.dm_db_wait_stats (Cơ sở dữ liệu Azure SQL)

Công cụ hữu ích:

dbForge Monitor - phần bổ trợ cho Microsoft SQL Server Management Studio cho phép bạn theo dõi và phân tích hiệu suất SQL Server.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Chú ý đến các ước tính

  2. Hạn chế tính linh hoạt của dữ liệu trong cơ sở dữ liệu NoSQL

  3. 30 câu hỏi phỏng vấn truy vấn SQL hàng đầu bạn phải thực hành vào năm 2022

  4. BẢNG SQL

  5. Tham số Sniffing Primer