Như bạn đã biết, trách nhiệm chính của người quản trị cơ sở dữ liệu nằm trong việc giám sát hoạt động của SQL Server và can thiệp vào thời gian xác định. Bạn có thể tìm thấy một số công cụ giám sát hiệu suất SQL Server trên thị trường nhưng đôi khi chúng tôi cần thông tin bổ sung về hiệu suất của SQL Server để chẩn đoán và khắc phục sự cố hiệu suất. Vì vậy, chúng ta phải có đủ thông tin về Chế độ xem quản lý động SQL Server để xử lý các vấn đề về SQL Server.
Chế độ xem quản lý động (DMV) là một khái niệm giúp chúng tôi khám phá các số liệu hiệu suất của SQL Server Engine. DMV lần đầu tiên được công bố trong phiên bản SQL Server 2005 và nó tiếp tục trong tất cả các phiên bản của SQL Server sau đó. Trong bài đăng này, chúng ta sẽ nói về DMV cụ thể mà người quản trị cơ sở dữ liệu phải có đủ thông tin. Đây là sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats hỗ trợ các số liệu cần thiết để chẩn đoán các vấn đề về hiệu suất của SQL Server. Nếu bạn gặp một số sự cố (CPU, Bộ nhớ, I / O, Khóa, Latch, v.v.) trong SQL Server Engine, dữ liệu sys.dm_os_wait_stats sẽ hướng dẫn chúng tôi xác định sự cố. Giám sát hoạt động trong SQL Server Management Studio bao gồm một bảng có tên là “ Nguồn tài nguyên chờ ”. “Sự chờ đợi của nguồn lực” lấy các chỉ số này từ một quy trình được lưu trữ đặc biệt. Tên thủ tục được lưu trữ tạm thời này là “ #am_generate_waitstats ”Và nó sử dụng sys.dm_os_wait_stats. Bạn có thể tìm thấy thủ tục lưu trữ tạm thời này trong “tempdb”. Tại thời điểm này, tôi muốn thêm một số lưu ý về thủ tục lưu trữ tạm thời. Bởi vì loại thủ tục được lưu trữ này không có cách sử dụng phổ biến.
Quy trình được lưu trữ tạm thời không khác với các thủ tục được lưu trữ vĩnh viễn. Nó có hai loại:cục bộ và toàn cầu giống như bảng tạm thời. Thủ tục được lưu trữ cục bộ vẫn hoạt động trong phiên hiện tại và bị loại bỏ sau khi phiên đóng. Nó có thể được tạo như thế này:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Thủ tục được lưu trữ toàn cầu cũng vẫn hoạt động trong tất cả các phiên và giảm xuống sau khi phiên đã tạo đóng lại. Thủ tục được lưu trữ toàn cầu có thể được tạo dưới dạng:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Mẹo: Khi chúng tôi mở Trình theo dõi hoạt động, nó sẽ tạo #am_generate_waitstats thủ tục được lưu trữ tạm thời và loại bỏ sau khi đóng.
Bây giờ chúng ta sẽ xem xét ý tưởng chính và chi tiết của sys.dm_os_wait_stats . Truy vấn dưới đây sẽ trả về tất cả dữ liệu về "Chờ thống kê" của SQL Server. Truy vấn này ở dạng thuần túy nhất. Thật bất tiện khi phát hiện các vấn đề với hình thức như vậy. Trong các phần sau, bạn sẽ tìm thấy các truy vấn hữu ích hơn sau đó là sys.dm_os_wait_stats. Bây giờ chúng tôi sẽ giải thích mô tả về các cột "Thống kê Chờ" của Máy chủ SQL:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
Cột wait_type chứa định nghĩa hoặc tên của thống kê chờ đợi. Dữ liệu cột wait_type có ý nghĩa quan trọng đối với chúng tôi vì định nghĩa của thống kê chờ chỉ ra lý do chính gây ra sự cố. Wait_tasks_count cho biết tần suất xuất hiện kiểu chờ trong SQL Server.
wait_time_ms cho biết tổng thời gian chờ đợi. Đơn vị đo là mili giây.
max_wait_time_ms cho biết thời gian chờ tối đa.
signal_wait_time_ms được mô tả trong MSDN là "Sự khác biệt giữa thời gian luồng chờ được báo hiệu và khi nó bắt đầu chạy". Đặc biệt giá trị cao của cột này báo hiệu áp suất CPU. Vì vậy, truy vấn đang đợi trong hàng đợi chạy được và sẵn sàng chạy nhưng CPU đang bận với các truy vấn khác. Vì lý do này, truy vấn đang chờ trong hàng đợi. Khi tài nguyên CPU có sẵn, CPU sẽ nhận được một truy vấn mới từ hàng đợi có thể chạy được và sẽ bắt đầu xử lý. Tóm lại, chúng tôi có thể mô tả signal_wait_time_ms là thời gian chờ trong hàng đợi có thể chạy được là trạng thái có thể chuyển sang chạy.
Mẹo: Trong phương pháp hay nhất, một số thống kê về thời gian chờ quan trọng nhất so với những thống kê khác. Chúng có thể được liệt kê là:
• PAGEIOLATCH_ *
• WRITELOG
• ASYNC_NETWORK_IO
• BẢNG XÁCH TAY
• CPU
• LCK_M_ *
• PREEMPTIVE_ *
• PAGELATCH_ *
Hãy xem Pinal Dave hoặc Paul S. Randal đợi các truy vấn thống kê. Họ đã loại bỏ một số loại thống kê chờ đợi trong các truy vấn của họ. Có thể loại bỏ các kiểu chờ tài nguyên dưới đây trong sys.dm_os_wait_stats truy vấn:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• CLR_AUTO_EVENT
• CLR_AUTO_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORORE_CMD
• DIRTY_PAGE_PUE_POLLCHER_POLLCHER_PAGE_POLPOLL /> • EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION_DEOT_NUE • HADR_LOGCAPTURE_WADRIT_NUEIFICIFICATION
• hadr_timer_task
• hadr_work_queue
• lazywriter_sleep
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTIVE_OS_DEVICEOPS
• PREEMPTIVE_OS_FILEOPS
• PREEMPTIVE_OS_GENERICOPS
• PREEMPTIVE_OS_LIBRARYOPS
• PREEMPTIVE_OS_PIPEOPS
• PREEMPTIVE_OS_QUERYIVEREGI PREEMSTRY
br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
• SLEEP_DCOMSTARTUP
• SLEEP_DCOMSTARTUP
SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH
• SQLTRACE_BUFFER_FLUSH
_INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
br /> • WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Mẹo: SQL Server bắt đầu thu thập dữ liệu DMV khi khởi động hoặc khởi động lại. SQL Server tự động đặt lại thống kê chờ khi khởi động lại và truy vấn bên dưới buộc đặt lại thống kê chờ kể từ khi SQL Server được khởi động lại lần cuối:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Ngoài ra, độ chính xác đo lường của thống kê chờ là điểm quan trọng. Tại thời điểm này, chúng ta có thể xem xét hai cách tiếp cận:
• Đặt lại thống kê chờ và thu thập thống kê chờ.
• Ghi lại hai “thống kê thời gian chờ” khác nhau và đo lường sự khác biệt về giá trị.
Theo tôi, nắm bắt và lưu trữ số liệu thống kê chờ cho bất kỳ cách tiếp cận bảng lịch sử nào là tốt hơn so với cách khác. Trong phương pháp này, bạn có thể đo khoảng thời gian đặc biệt và không làm mất số liệu thống kê chờ của dữ liệu lịch sử.
Bây giờ, chúng tôi sẽ tạo một ví dụ về việc thu thập thống kê chờ và hiển thị dữ liệu đã chụp trong Power BI với đồ họa.
Chúng tôi sẽ tạo một bảng lịch sử để lưu trữ thống kê chờ:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
Tập lệnh dưới đây chèn “thống kê chờ” vào bảng lịch sử. Nhưng bạn cần lập lịch truy vấn này trong SQL Server Agent để lưu trữ bảng lịch sử:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Sau khi dữ liệu lịch sử đã được lưu trữ, chúng tôi mở Power BI và phát triển bảng điều khiển thống kê chờ của chúng tôi.
Nhấp vào Nhận dữ liệu và chọn Máy chủ SQL :
Đặt cài đặt kết nối rồi ghi truy vấn vào Câu lệnh SQL (tùy chọn, yêu cầu cơ sở dữ liệu) . Nhấp vào OK .
Nhấp vào Nhập từ Thị trường
Tìm Sparkline của OKViz thành phần hình ảnh và Thêm Power BI
Thêm Sparkline vào bảng thiết kế Power BI và kéo và thả các cột tập dữ liệu như trong hình ảnh dưới đây:
Thêm hai thành phần bảng vào bộ lọc: SQLStartTime và WaitType . Cuối cùng, trang tổng quan sẽ như thế này:
Sự cố chờ tài nguyên chẩn đoán như thế nào:
Trong phần này, chúng tôi sẽ đề cập đến phương pháp và kỷ luật chẩn đoán các vấn đề về thống kê chờ. Đặc biệt, chúng ta phải tìm ra một điểm về số liệu thống kê chờ đợi:nó chỉ đơn giản xác định cấu trúc chính của vấn đề nhưng không bao giờ đưa ra chi tiết. Vì lý do này, chúng tôi cần nghiên cứu chi tiết chờ đợi và lý do. Do đó, "thống kê chờ" cho phép chúng tôi chuyển nghiên cứu của mình sang hướng này. Sau đó, chúng ta nên sử dụng các công cụ khác (PerfMon, Sự kiện mở rộng, công cụ giám sát của bên thứ 3, v.v.) và các DMV khác để xác định vấn đề chính xác.
Giả sử rằng, chúng tôi quan sát ASYNC_NETWORK_IO trong SQL Server, việc chờ đợi tài nguyên này có liên quan đến kết nối mạng chậm từ máy khách đến máy chủ. Nhưng thông tin này không giúp khắc phục lý do chính của sự cố vì chúng tôi có thể có một số cấu hình mạng giữa phía máy chủ và máy khách. Đối với ví dụ này, chúng ta cần xem xét:
• Các truy vấn tập hợp kết quả lớn
• Cấu hình thẻ giao diện mạng
• Cài đặt môi trường mạng giữa phía máy chủ và phía máy khách.
• Kiểm tra băng thông của bộ điều hợp mạng.
Như bạn có thể thấy trong ví dụ, chúng ta cần hoàn thành một số nhiệm vụ để xác định chính xác vấn đề. Số liệu thống kê chờ đợi không chỉ ra mục tiêu của vấn đề.
Kết luận
Trong bài đăng này, chúng tôi đã nói về khái niệm chính của chế độ xem quản lý động sys.dm_os_wait_stats. Đồng thời, chúng tôi đã thảo luận về tính đơn giản của cách sử dụng và những điểm quan trọng cần chú ý.
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.
