Оттеглени функции, които да извадите от кутията си с инструменти – част 1

Microsoft няма навика да отрича нещата в наши дни, но когато го правят, това е с причина – и със сигурност не е, защото искат да направят живота ви по-труден. Напротив, почти винаги е така, защото са разработили по-добри и по-модерни начини за решаване на същите проблеми.

Но навиците са трудни за преодоляване; питай ме откъде знам. Твърде често виждам хора, които се придържат към по-стар начин за изпълнение на някаква задача, въпреки че съществува по-добър начин.

Бих искал да споделя няколко скорошни примера, които помагат да се илюстрира как използването на оттеглените функции на SQL Server продължава да ни дразни. В тази първа част искам да говоря за...

системни процеси

Системната таблица sys.sysprocesses беше заменен още в SQL Server 2005 от набор от динамични изгледи за управление (DMV), най-вече sys.dm_exec_requests , sys.dm_exec_sessions и sys.dm_exec_connections . Официалната документация за sys.sysprocesses предупреждава:

Скошен пример

Наскоро един от нашите екипи разследваше проблем със забавянето на четеца на регистрационни файлове. Ние обръщаме много внимание на латентността тук, заедно с всички дългосрочни транзакции, поради въздействието надолу по веригата върху технологиите, които използват четеца на журнали – като групи за наличност и репликация на транзакции. Първите ни предупреждения обикновено се забелязват на табло за управление, което изобразява латентността на четеца на регистрационни файлове спрямо продължителността на транзакцията (ще обясня моментите във времето, които отбелязах с t0 и t1 накратко):

Те определиха, да кажем в момент t0 , че определена сесия е имала отворена транзакция, блокираща процеса на четене на регистрационни файлове. Те първо провериха изхода на DBCC INPUTBUFFER , за да се опита да определи какво е направила тази сесия за последно, но резултатите просто показват, че те са издали и други партиди по време на транзакцията си:

event_type       parameters   event_info
--------------   ----------   ---------------
Language Event   0            SET ROWCOUNT 0;

Обърнете внимание, че DBCC INPUTBUFFER също има по-способен заместител в съвременните версии:sys.dm_exec_input_buffer . И въпреки че няма изрично предупреждение за оттегляне, официалната документация за DBCC командата има това нежно побутване:

След като не получиха нищо от входния буфер, те поискаха sys.sysprocesses :

SELECT 
  spid, 
  [status], 
  open_tran, 
  waittime, 
  [cpu], 
  physical_io, 
  memusage, 
  last_batch
FROM sys.sysprocesses 
WHERE spid = 107;

Резултатите бяха също толкова безполезни, поне по отношение на определянето на това какво е правила сесията, за да запази транзакцията им отворена и да наруши четеца на регистрационни файлове:

Откроявам physical_io колона, защото тази стойност предизвика дискусия за това дали искат да рискуват да убият спящата сесия. Мисленето беше, че в случай че всички тези физически I/O са записани, убиването на транзакцията може да доведе до продължително и разрушително връщане назад – потенциално да влоши проблема. Няма да поставям реални времена за това, но нека просто кажем, че това се превърна в продължителен разговор и остави системата в това състояние от време t0 до време t1 на графиката по-горе.

Защо това е проблем

Проблемът в този конкретен случай е, че те са прекарали това време в обмисляне на решение, основано на непълна информация. Това I/Os чете или пише? Ако потребителят има отворена транзакция и просто е прочел много данни, има много по-малко въздействие от връщането на тази транзакция назад, отколкото ако те са променени много данни. Така че вместо sys.sysprocesses , нека видим какво е по-модерното DMV, sys.dm_exec_sessions , може да ни покаже за тази сесия:

SELECT 
  session_id, 
  [status], 
  open_transaction_count, 
  cpu_time, 
  [reads], 
  writes, 
  logical_reads, 
  last_request_start_time,
  last_request_end_time
FROM sys.dm_exec_sessions 
WHERE session_id = 107;

Резултати:

Тук виждаме, че sys.dm_exec_sessions разделя физическия I/O отделно на четене и запис. Това ни позволява да вземем много по-информирано решение, много по-бързо от t1 - t0 , относно потенциалното въздействие на връщане назад. Ако входно/изходното е записано и в зависимост от това колко високо е числото, може да се поколебаем още малко и може би да прекараме времето си в опити да намерим потребителя (за да можем да му ударим кокалчетата или да ги попитаме защо имат отворена транзакция ). Ако знаем, че е предимно четене, вместо това можем да се наклоним към прекратяване на сесията и принудително връщане на транзакцията.

Разбира се, sys.sysprocesses има dbid и waittime . Но dbid така или иначе е ненадежден и незначително полезен, особено за запитвания за кръстосани бази данни; има много по-добра информация в sys.dm_tran_locks . Информация за чакане (време и последно изчакване) може да се намери в sys.dm_exec_requests , но много по-подробна информация се предлага в sys.dm_exec_session_wait_stats (добавено в SQL Server 2016). Извинение, което чух много, беше, че sys.dm_exec_sessions липсваше open_tran , но open_transaction_count беше добавен обратно в SQL Server 2012. Така че има много малка причина дори да мислим за използването на sys.sysprocesses днес.

Ако искате да разберете колко често sys.sysprocesses е посочен от последното рестартиране на SQL Server, можете да изпълните тази заявка срещу броячите на производителността DMV:

SELECT instance_name, cntr_value
  FROM sys.dm_os_performance_counters
  WHERE [object_name] LIKE N'%:Deprecated Features%'
    AND instance_name = N'sysprocesses' 
  ORDER BY cntr_value DESC;

Ако наистина искате да избегнете сън тази вечер или просто обичате непрекъснато да добавяте към списъка с неща, за които се тревожите, премахнете предиката срещу instance_name . Това ще ви даде страшна представа на високо ниво за това колко неща работят вашите екземпляри, които в крайна сметка ще трябва да промените.

Междувременно изтеглете sp_WhoIsActive , изключително полезна съхранена процедура на Адам Мачаник за наблюдение и отстраняване на неизправности в процесите на SQL Server в реално време. Разположихме тази съхранена процедура във всеки екземпляр в нашата среда и вие също трябва, независимо какви други инструменти за наблюдение от висок клас също може да използвате.

Следващия път

В част 2 ще говоря малко за SQL Server Profiler, приложение, което хората използват повече поради познаване, отколкото нещо друго – без да осъзнават колко опасно може да бъде.