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.