Новый процесс сбора информации об ожидании экземпляра в SQL Server 2016
Содержание:
1. Введение;
2. Сбор данных по ожиданиям экземпляра и по ожиданиям сеанса в SQL Server 2016;
3. Новый процесс сбора информации об ожидании экземпляра в SQL Server 2016 (Вы читаете данный раздел).
Как я разъяснил выше, теперь мы отмечаем изменение в поведении SQL Server 2016 (CTP 2.4), влияющее на результаты хорошо зарекомендовавшего себя запроса на сведения по статистике ожиданий, который мы использовали в течение долгого времени (см. скриншот ниже). В коде ниже представлено описание процесса, который будет осуществляться в системе SQL Server 2016.

Новый запрос для сбора статистических данных об ожидании экземпляра в системе SQL Server 2016 с использованием представления sys.dm_os_wait_stats
Возвращение суммарных статистических данных об ожидании конкретного сеанса приведено в коде ниже, а результаты на скриншоте ниже.
Вы наверняка обратили внимание на синтаксис параметра Template Parameter для указания на идентификатор sessionjd. Этот синтаксис дает возможность повторно использовать код и выгружать этот параметр либо с помощью кнопки в строке меню SSMS с надписью Query, либо с помощью комбинации клавиш Ctrl+Shift+M.
Здесь положение несколько осложняется ограничениями, связанными с этими оконными функциями, а также вследствие того факта, что после агрегирования нескольких сеансов в данный запрос мы получаем вероятность появления дубликатов wait_types. Это означает, что перед упомянутым запросом нужно предусмотреть дополнительный этап, обеспечивающий сбор всех ожиданий и способствующий агрегированию wait types с целью устранения этих дубликатов из оставшейся части запроса. Существует два пути решения задачи: с помощью временной таблицы или с использованием табличной переменной. В данном случае я склоняюсь к временным таблицам (см. код выше).
Обратите внимание: вставляя записи в данную временную таблицу (#WAITS), мы группируем их по имени базы данных (которое опять-таки вводится как Template Parameter) и по wait_type, с тем чтобы удалить дубликаты этих wait types перед обработкой оставшейся части запроса (см. скриншот выше).
Результаты выполнения трех опубликованных выше запросов свидетельствуют о том, что ожидания конкретного сеанса или набора сеансов не показательны для совокупного времени ожиданий самого экземпляра. Верно и обратное: статистические данные об ожидании экземпляра не показательны (хотя, по всей вероятности, входят в число факторов, определяющих ситуацию в отношении дефицита ресурсов, которая может возникнуть в ходе конкретного сеанса).
С выходом на рынок версии SQL Server 2016 перед нами встают новые проблемы и открываются новые возможности в том, что касается сбора статистических данных, которые помогут нам выполнять анализ настройки производительности. Я полагаю, что в преддверии выпуска продукта этот процесс будет доработан, и, возможно, проблемы, которые появляются в СТР-версии, будут решены еще до того, как SQL Server 2016 поступит в распоряжение потребителей.
1. Введение;
2. Сбор данных по ожиданиям экземпляра и по ожиданиям сеанса в SQL Server 2016;
3.
Как я разъяснил выше, теперь мы отмечаем изменение в поведении SQL Server 2016 (CTP 2.4), влияющее на результаты хорошо зарекомендовавшего себя запроса на сведения по статистике ожиданий, который мы использовали в течение долгого времени (см. скриншот ниже). В коде ниже представлено описание процесса, который будет осуществляться в системе SQL Server 2016.
Новый запрос для сбора статистических данных об ожидании экземпляра в системе SQL Server 2016 с использованием представления sys.dm_os_wait_stats
Возвращение суммарных статистических данных об ожидании конкретного сеанса приведено в коде ниже, а результаты на скриншоте ниже.
Вы наверняка обратили внимание на синтаксис параметра Template Parameter для указания на идентификатор sessionjd. Этот синтаксис дает возможность повторно использовать код и выгружать этот параметр либо с помощью кнопки в строке меню SSMS с надписью Query, либо с помощью комбинации клавиш Ctrl+Shift+M.
Возвращение суммарной статистики ожиданий для всех сеансов работы с конкретной базой данных
Здесь положение несколько осложняется ограничениями, связанными с этими оконными функциями, а также вследствие того факта, что после агрегирования нескольких сеансов в данный запрос мы получаем вероятность появления дубликатов wait_types. Это означает, что перед упомянутым запросом нужно предусмотреть дополнительный этап, обеспечивающий сбор всех ожиданий и способствующий агрегированию wait types с целью устранения этих дубликатов из оставшейся части запроса. Существует два пути решения задачи: с помощью временной таблицы или с использованием табличной переменной. В данном случае я склоняюсь к временным таблицам (см. код выше).
Обратите внимание: вставляя записи в данную временную таблицу (#WAITS), мы группируем их по имени базы данных (которое опять-таки вводится как Template Parameter) и по wait_type, с тем чтобы удалить дубликаты этих wait types перед обработкой оставшейся части запроса (см. скриншот выше).
Результаты выполнения трех опубликованных выше запросов свидетельствуют о том, что ожидания конкретного сеанса или набора сеансов не показательны для совокупного времени ожиданий самого экземпляра. Верно и обратное: статистические данные об ожидании экземпляра не показательны (хотя, по всей вероятности, входят в число факторов, определяющих ситуацию в отношении дефицита ресурсов, которая может возникнуть в ходе конкретного сеанса).
С выходом на рынок версии SQL Server 2016 перед нами встают новые проблемы и открываются новые возможности в том, что касается сбора статистических данных, которые помогут нам выполнять анализ настройки производительности. Я полагаю, что в преддверии выпуска продукта этот процесс будет доработан, и, возможно, проблемы, которые появляются в СТР-версии, будут решены еще до того, как SQL Server 2016 поступит в распоряжение потребителей.