Основи на sys.dm_exec

Мониторингът на производителността и отстраняването на неизправности в SQL Server е обширна тема. В SQL Server 2005 динамичните изгледи за управление, известни също като DMV, бяха въведени и се превърнаха в основен помощен инструмент за диагностициране на проблеми с производителността на SQL Server. В същото време можем да използваме динамични изгледи за управление за Azure SQL база данни. Някои от тях могат да се различават от локалната база данни на SQL Server, но логиката на работа е същата. Microsoft има много добра документация за динамичните изгледи за управление. Единственото нещо, трябва да внимавате за версията и валидирането на продукта на динамичните изгледи за управление. Като sys.dm_exec_request е наличен за SQL Server 2008 и по-нови версии и за Azure SQL база данни, но sys.dm_db_wait_stats е валиден само за Azure SQL база данни.

В тази публикация ще говорим за основите на sys.dm_exec_request. sys.dm_exec_requests е динамичен изглед за управление, който връща само изпълняваните в момента заявки. Това означава, че когато стартирате заявка sys.dm_exec_requests, тя прави заявка за моментни снимки, която се изпълнява през това време и не включва никакви исторически данни. Следователно този изглед е много удобен за наблюдение на заявки в реално време. С други думи, той дава отговор на „какво се случва в моя сървър точно сега?“ Този изглед включва много подробности, но ще обсъдим най-важните.

идентификатор_на_сесия :Тази стойност определя идентификационен номер на сесията. В SQL Server идентификаторите на сесии, които са равни или по-малки от 50, са посветени на фоновия процес.

начален_час :Тази стойност определя началната дата и час на заявката.

състояние :Тази стойност определя състоянието на заявката. Наличните състояния са:

фон
работи
може да се изпълнява
спя
спряно

ИЗБЕРЕТЕ DISTINCT statusFROM sys.dm_exec_requestsWHERE session_id <>@@SPID

фон :Този тип състояние определя фоновите процеси. Някои от тях са LAZY WRITER, CHECKPOINT и LOG WRITER.

изберете session_id, команда, os_thread_id от sys.dm_exec_requests като r присъединете към sys.dm_os_workers като w на r.task_address =w.task_address присъединете се към sys.dm_os_threads като t на t.thread_address =w.thread_address  
 
 
 тичане :Този тип състояние определя, че заявката се обработва от CPU.
  изберете * от sys.dm_exec_requests, където status='running' и session_id <>@@SPID
 
 
 
 изпълнение :Този тип състояние може просто да се дефинира като заявка, която чака в опашката на процесора за изпълнение. Ако откриете много изпълнявани процеси в sys.dm_exec_requests, това може да е симптом на натиск на процесора. Този показател не е достатъчен за диагностициране на този проблем с производителността на процесора. Поради тази причина трябва да подкрепим този случай с повече доказателства. Това е важно за нас, за да докажем нашата теория. Динамичният изглед за управление sys.dm_os_wait_stats включва колона, която е signal_wait_time_ms. Тази стойност на колоната може да помогне за определяне на проблема с процесора. Следната заявка ни показва процента на Signalwait. Ако този показател има висока стойност, най-вероятно сте изправени пред проблем с производителността на процесора. Можете да задълбочите прегледа си по този начин.
 ---https://sqlserverperformance.wordpress.com/page/146/---Ефективност на SQL сървъра на Glenn Berry 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) ASNUM_wait_ms 20,2))ОТ sys.dm_os_wait_stats;
 
 спряно :Този тип състояние определя процеса на изчакване на някакъв ресурс. Може да бъде I/O, LOCK и LATCH и т.н. Както бе споменато по-горе, можем да използваме sys.dm_os_wait_stats динамичен изглед за управление за откриване на wait_time_ms. 
 
 спя :Това означава, че заявката е свързана към SQL Server, но в момента не изпълнява никакви команди.
 
 команда :Тази колона дефинира тип команда, която се изпълнява. В същото време можем да намерим допълнителна информация за конкретни команди, която е коефициент на завършване. Според онлайн книгите, това са;
 
 ПРОМЕНИ ИНДЕКС РЕОРГАНИЗИРАНЕ
 
 Опция AUTO_SHRINK с ALTER DATABASE
 
 РЕЗЕРВНА БАЗА ДАННИ
 
 DBCC CHECKDB
 
 DBCC CHECKFILEGROUP
 
 DBCC ПРОВЕРКА
 
 DBCC INDEXDEFRAG
 
 DBCC SHRINKDATABASE
 
 DBCC SHRINKFILE
 
 ВЪЗСТАНОВЯВАНЕ
 
 ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ
 
 ОТКЛЮЧВАНЕ
 
 TDE КРИПИРАНЕ
 
 Демо :
  Свържете главната база данни и стартирайте архивирането за всяка база данни.BACKUP DATABASE WideWorldImporters TO DISK ='NUL'
 
 Съвет :Когато вземете резервното копие на базата данни на устройството „NUL“, SQL Server не записва архивен файл никъде и избягвате изтриването на тестов архивен файл. Но не използвайте тази команда във вашата производствена среда. Това може да доведе до прекъсване на LSN веригата.
 
 
 Изпълнете следната заявка:
 SELECT команда,percent_complete ,*FROM sys.dm_exec_requestsWHERE session_id <>@@SPID и session_id>50 и command='BACKUP DATABASE'
 
 sql_handle :Тази стойност дефинира SQL израза на заявката. Но тази стойност е в растерния формат. Поради тази причина трябва да използваме функцията с таблична стойност sys.dm_exec_sql_text, за да преобразуваме стойността в смислен текст.
 изберете session_id ,command , sqltxt.text ,database_idfrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) като sqltxtwhere session_id<>@@SPID50 
 
 
 идентификатор на база данни :Тази стойност определя коя база данни прави заявката. Можем да се присъединим към това поле с sys.databases, за да получим името на базата данни.
 изберете session_id ,command , sqltxt.text ,db.namefrom sys.dm_exec_requests reqCROSS ПРИЛОЖИ sys.dm_exec_sql_text(req.sql_handle) като sqltxtinner join sys.databases db on db@dabase_id=AND reb@tabase sessionreq. session_id>50
 
 тип_чакане :Тази стойност определя текущия тип чакане на заявката. Ако продължителността на изпълнението на заявката отнема повече от очакваното, можете да проверите и да определите типа на изчакване на заявката.
 
 
 
 ниво_изолация_на_транзакция :Тази стойност определя нивото на транзакцията на подадената заявка:
 
 0=Неопределено
 
 1=ReadUncommitted
 
 2=Прочетено завършено
 
 3=Повтарящо се
 
 4=Мобилно да се сериализира
 
 5=Моментна снимка
 изберете session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,CASE transaction_isolation_levelWHEN 0 THEN 'Unspecified'WHEN 1 THEN 'ReadUncomitted'WHEN'HEN'ReadUncomitted'WHEN'HAD'HPEWHEN'HAD 4 THEN 'Serializable'WHEN 5 THEN 'Snapshot'ENDAS isolation_level_namefrom sys.dm_exec_requests reqCROSS ПРИЛОЖИ sys.dm_exec_sql_text(req.sql_handle) като sqltxtinner join db on db session@databasessys.databases сесия 
 
 
 blocking_session_id :Това е идентификаторът на сесията, който блокира заявката. Ако тази колона е NULL, заявката не е блокирала никоя сесия.
 
 Демо :
  Отворете SQL Server Management Studio и изпълнете следната заявка.ПУСНЕТЕ ТАБЛИЦА, АКО СЪЩЕСТВУВА TestPerfomonGOCREATE TABLE TestPerfomon(ID INT ,Nm VARCHAR(100))INSERT INTO TestPerfomonVALUES(1,1)GOBEGIN TRANUPDATE TestPerfomon'2 'WHERE ID=1ИЗБЕРЕТЕ @@SPID КАТО blocking_session_id
 
 
 
 
 Отворете нов прозорец за заявка и изпълнете следната заявка.
 ЗАДАДЕТЕ НИВО НА ИЗОЛАЦИЯ НА ТРАНЗАКЦИЯТА SerializableBEGIN TRANUPDATE TestPerfomon SET Nm='3'WHERE ID=1
 
 Отворете друг нов прозорец за заявка и изпълнете тази DMV заявка.
 изберете session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,CASE transaction_isolation_levelWHEN 0 THEN 'Unspecified'WHEN 1 THEN 'ReadUncomitted'WHEN'HEN'ReadUncomitted'WHEN'HAD'HPEWHEN'HAD 4 THEN 'Serializable'WHEN 5 THEN 'Snapshot'ENDAS isolation_level_name ,blocking_session_idfrom sys.dm_exec_requests reqCROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as dxlt.sql_handle) as dqlt.sql_handle) as dqlt.sql_handle) as dqlt. session_id>50
 
 
 
 С тази демонстрация разбрахме причината, поради която втората заявка е блокирана и коя сесия е блокирала заявката. Когато стартирате sp_BlitzWho 65, можете да разберете подробностите за блокирането и подробностите за блокираната сесия.
 sp_BlitzWho 65
 
 В тази демонстрация извлечехме подробностите за блокиране и блокиране на сесии и в същото време получихме подробности за тези сесии. Това е много основна демонстрация, но показва как проблемът може да бъде разрешен.
 
 В тази публикация говорихме за sys.sys.dm_exec_requests. Този динамичен изглед за управление ни дава гъвкавостта да получим моментна снимка по време на текущата стъпка на заявка. Освен това тези подробности могат да ни помогнат или да ни насочат през процеса на откриване на проблема.
 
 Препратки 
  sys.dm_exec_requests (Transact-SQL)
 Наблюдение на Azure SQL база данни с помощта на динамични изгледи за управление
 sys.dm_db_wait_stats (Azure SQL база данни)
 
 
 
 Полезен инструмент:
 
 dbForge Monitor – добавка за Microsoft SQL Server Management Studio, която ви позволява да проследявате и анализирате производителността на SQL Server.

Основи на sys.dm_exec_requests

Полезен инструмент: