Эти периоды ожидания включают в себя все сеансы, в ходе которых передаются запросы на обработку; при этом нет никаких определений между пользовательскими сеансами и системными сеансами. Теперь, когда мы можем опрашивать динамическое административное представление, которое анализирует эту информацию на уровне сеанса, мы получаем возможность, которой у нас не было прежде.

Это очень важно для нас, потому что в процессе ожидания экземпляра мы получаем информацию о том, в чем этот экземпляр как единое целое усматривает ресурсные ограничения, исходя из обшей рабочей нагрузки. Периоды ожидания сеансов дают представление не только о том, в чем именно с точки зрения сеансов заключаются ограничения в отношении обращения к ресурсам. Эти ожидания позволяют понять, в чем состоит вклад, вносимый данным сеансом в общее ожидание экземпляра. В дополнение к этому (как вы увидите при рассмотрении трех запросов в конце статьи) рабочие нагрузки не всех сеансов ожидают возможности обращения к одним и тем же ресурсам, и, если данный экземпляр имеет высокий показатель по ожиданиям PAGEIOLATCH_EX, это не означает, что такой же показатель будет иметь каждый сеанс. Так что это новое динамическое административное представление позволяет осуществлять критический разбор связанных с быстродействием вопросов так, как не представлялось возможным при использовании sys.dm_os_wait_stats, реализованного в предыдущих версиях SQL Server. Дополнительная сложность состоит в том, что старый способ сбора статистики ожидания в SQL Server 2016 не работает. В процессе подготовки материалов для данной статьи я обнаружил кое-что любопытное для SQL Server 2016, во всяком случае в версии CTP 2.4: оказывается, старый добрый метод опроса представления sys.dm_os_wait_stats теперь возвращает повторяющиеся данные, а существующая методика расчета текущего процента от общего времени ожиданий не дает корректных результатов. Объясняется ли это изменениями в механизме решения проблем изоляции транзакций для базовых конструкций ожидания, проблемами параллелизма или все дело в каких-то иных изменениях, выполненных с целью создания, а также успешного сбора и организации отчетности по ожиданиям уровня сеанса, пока неясно. Но как бы то ни было, это означает, что нам придется изменить применяемый в SQL Server 2016 подход к проблеме сбора ожиданий (либо на уровне экземпляра, либо на уровне сеансов).


Старый метод оценки метаданных ожидания просто не будет работать. Когда мы выполняем существующий стандартный запрос, годами использовавшийся в той или иной форме многими организаторами презентаций (см. код ниже), мы получаем в системе SQL Server 2016 (CTP 2.4) результаты, показанные на скриншоте выше. Если вы посмотрите на элемент A, то увидите, что, как только вы доведете текущее значение процента до 100, начнется пересчет этого значения, а не выполнение правила, применяемого к предложению HAVING. В конечном итоге возникает вопрос B с повторяющимися записями.


При добавлении вспомогательного критерия подключения к W2.wait_type = W1.wait_type повторяющиеся записи (вопрос B) удаляются, но проблема, касающаяся сбоя при подсчете текущего процентного значения, остается. До выпуска данной версии SQL Server подобная реакция не отмечалась. Не было и повторяющихся записей, несмотря на самообъединение только на W2.rn <= W1.rn. Фактическое добавление дополнительного соединения в более ранних версиях SQL Server, предшествующих версиям 2016 CTP, сводит на нет ограничения указания HAVING.



Я дважды выполнил указанный запрос в системе SQL Server 2014: один раз без изменений, а второй раз с добавлением дополнительного соединения на wai_tjype (см. скриншоты выше).

Так что же нам делать? Конечно, внедрять новые решения.

---

<<К началу статьи