Както знаете, основната отговорност на администратора на базата данни се крие в наблюдението на производителността на SQL Server и намесата в определено време. Можете да намерите няколко инструмента за наблюдение на производителността на SQL Server на пазара, но понякога се нуждаем от допълнителна информация за производителността на SQL Server, за да диагностицираме и отстраняваме проблемите с производителността. Така че трябва да имаме достатъчно информация за изгледите за динамично управление на SQL Server, за да се справим с проблемите относно SQL Server.
Динамичният изглед за управление (DMV) е концепция, която ни помага да открием показателите за производителност на SQL Server Engine. DMV беше обявен за първи път във версията на SQL Server 2005 и продължи във всички версии на SQL Server след това. В тази публикация ще говорим за конкретен DMV, чийто администратор на база данни трябва да има достатъчно информация. Това е sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats поддържа основни показатели за диагностициране на проблеми с производителността на SQL Server. Ако имате някакви проблеми (CPU, памет, I/O, заключване, заключване и т.н.) в SQL Server Engine, данните sys.dm_os_wait_stats ни насочват да дефинираме проблема. Мониторът на активността в SQL Server Management Studio включва панел, наречен „Ресурс чака “. „Ресурсът чака“ получава тези показатели от специална съхранена процедура. Това временно име на съхранената процедура е „#am_generate_waitstats ” и използва sys.dm_os_wait_stats. Можете да намерите тази временна съхранена процедура в “tempdb”. На този етап бих искал да добавя някои бележки относно временната съхранена процедура. Тъй като този тип съхранена процедура няма обичайна употреба.
Временно съхранената процедура не се различава от постоянно съхраняваните процедури. Има два вида:локални и глобални като временни таблици. Локалната съхранена процедура остава активна в текущата сесия и отпада след затваряне на сесията. Може да се създаде така:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Глобалната съхранена процедура също остава активна във всички сесии и отпада след затварянето на създадената сесия. Глобалната съхранена процедура може да бъде създадена като:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Съвет: Когато отворим монитора на активността, той създава #am_generate_waitstats временна съхранена процедура и я пуска след затварянето.
Сега ще разгледаме основната идея и подробности за sys.dm_os_wait_stats . Заявката по-долу ще върне всички данни за SQL Server „Изчакайте статистика“. Тази заявка е в най-чистата форма. Откриването на проблеми с такава форма е неудобно. В следващите раздели ще намерите по-полезни заявки от sys.dm_os_wait_stats. Сега ще обясним описанието на колоните „Статистика за чакане“ на SQL Server:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
Колоната тип_чакане съдържа дефиницията или името на статистиката за чакане. Данните в колоната wait_type са значими за нас, защото дефиницията на статистиката за чакане, която показва основната причина за проблема. waiting_tasks_count указва честотата на изчакване в SQL Server.
wait_time_ms показва общото време на изчакване. Мерната единица е милисекунда.
max_wait_time_ms показва максималното време за изчакване.
signal_wait_time_ms е описано в MSDN като „Разлика между времето, в което чакащата нишка е била сигнализирана и когато е започнала да се изпълнява“. Особено високата стойност на тази колона показва налягането на процесора. Така че заявката чака в опашката за изпълнение и е готова за изпълнение, но процесорът е зает с други заявки. Поради тази причина заявката чака в опашката. Когато ресурсът на CPU е наличен, CPU ще получи нова заявка от опашката за изпълнение и ще започне да обработва. Накратко, можем да опишем signal_wait_time_ms като време за изчакване в опашката, която може да се изпълнява, което е състояние, което може да се изпълнява.
Съвет: В най-добрата практика няколко статистики за чакане са по-важни от останалите. Те могат да бъдат изброени като:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• ПРЕДВАРИТЕЛНО_*
• PAGELATCH_*
Обърнете внимание на Pinal Dave или Paul S. Randal, чакайте за запитвания за статистика. Те елиминираха няколко типа статистически данни за чакане в своите заявки. Типовете изчакване на ресурсите по-долу могат да бъдат елиминирани в sys.dm_os_wait_stats запитвания:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
>• AL CKLREV_MAN
• AL CKLREV_AU>
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_DBM_MUTEX
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_DBM_MUTEX
• DBMIRROR_DBM_MUTEX />• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION_HADR /•CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
CLOGUE_DECUE
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
••AUDR.
• 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_QUERYREGISTRY
• PREEMPTIVE_OS_VERIFYTRUST
• PREEMPTIVE_OS_WAITFORSINGLEOBJECT
• PREEMPTIVE_OS_WRITEFILEGATHER
• 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_BPOOL_FLUSH
• SLEEP_BPOOL_FLUSH
• SLEEP_SDBSTARTUP
• COM SLEEP_DBSTARTUP
•COM SLEEP_DBSTARTUP
• SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER
• SQLTRACE_BUFFER_ _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKEPT_CLOSE
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
•CKRYWAIT
•CKRYWAIT
•CKWAIT
•CKWAIT
•CKWAIT
• br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Съвет: SQL Server започва да събира DMV данни при стартиране или рестартиране. SQL Server автоматично нулира статистическите данни за чакане при рестартиране и заявката по-долу принуждава да нулира статистиката за чакане от последното рестартиране на SQL Server:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Освен това, точността на измерване на статистиката за чакане е ключов момент. В този момент можем да разгледаме два подхода:
• Нулирайте статистическите данни за изчакване и си припомнете статистиката за чакане.
• Заснемате две различни „статистически данни за времето за изчакване“ и измерете разликата в стойностите.
Според мен улавянето и съхраняването на статистически данни за изчакване за всеки подход към таблицата с история е по-добър от другия. С този метод можете да измервате особено времеви интервал и да не губите статистика за изчакване на исторически данни.
Сега ще направим извадка от заснемането на статистически данни за чакане и ще покажем заснетите данни в Power BI с графики.
Ще създадем таблица на историята, за да съхраняваме статистически данни за чакане:
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]
Скриптът по-долу вмъква „статистика за чакане“ в таблицата с историята. Но трябва да планирате тази заявка в SQL Server Agent за съхраняване на таблица с история:
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) След като историческите данни бъдат съхранени, отваряме Power BI и разработваме нашето табло за статистика за чакане.
Кликнете върху Получаване на данни и изберете SQL сървър :
Задайте настройките на връзката и след това напишете заявката в SQL израз (по избор, изисква база данни) . Щракнете върху OK .
Кликнете върху Импортиране от Marketplace
Намерете Sparkline от OKViz визуален компонент и Добавяне Power BI
Добавете Sparkline към панела за дизайн на Power BI и плъзнете и пуснете колони от набор от данни, както е на изображението по-долу:
Добавете два компонента на таблицата за филтриране:SQLStartTime и WaitType . И накрая, таблото за управление трябва да бъде така:
Как да се диагностицира проблем с изчакването на ресурса:
В този раздел ще споменем методологията и дисциплината за диагностициране на проблеми със статистиката за чакане. По-специално, трябва да разберем една точка относно статистиката за чакане:тя просто дефинира основната структура на проблема, но никога не дава подробности. Поради тази причина трябва да проучим подробности и причини за изчакване. Следователно „статистиката на чакането“ ни позволява да обърнем изследванията си в тази посока. След това трябва да използваме други инструменти (PerfMon, разширени събития, инструменти за наблюдение на трети страни и т.н.) и други DMV, за да дефинираме точните проблеми.
Ако приемем, че наблюдаваме ASYNC_NETWORK_IO в SQL Server, това изчакване на ресурс е свързано с бавна мрежова връзка от страна на клиент към сървър. Но тази информация не помага за отстраняване на основната причина за проблема, тъй като може да имаме няколко мрежови конфигурации между сървъра и клиентската страна. За този пример трябва да погледнем:
• Големи заявки за набор от резултати
• Конфигурации на мрежова интерфейсна карта
• Настройки на мрежовата среда между страните на сървъра и страната на клиента.
• Проверете честотната лента на мрежовия адаптер.
Както можете да видите в примера, трябва да изпълним някои задачи, за да дефинираме точния проблем. Статистиката за изчакване не показва целта на проблема.
Заключения
В тази публикация говорихме за основната концепция на динамичния изглед за управление sys.dm_os_wait_stats. В същото време обсъдихме простотата на използване и важните моменти, на които е необходимо да се обърне внимание.
Полезен инструмент:
dbForge Monitor – добавка за Microsoft SQL Server Management Studio, която ви позволява да проследявате и анализирате производителността на SQL Server.
