Новые динамические административные представления в SQL Server 2016. Введение. Часть I
Содержание:
1.Введение (Вы читаете данный раздел);
2. Сбор данных по ожиданиям экземпляра и по ожиданиям сеанса в SQL Server 2016;
3. Новый процесс сбора информации об ожидании экземпляра в SQL Server 2016.
В SQL Server 2016 появилось совершенно новое представление sys.dm_exec_session_wait_stats. По своей сути, оно очень похоже на уже существующие sys.dm_os_wait_stats: служит главным образом для возвращения информации об ожидании на момент отклика процессора на текущий запрос, инициатором которого является запрос от пользовательского сеанса. Однако между ними есть очень важное различие: новое представление возвращает данную информацию с сеансовым уровнем детализации.
Это чрезвычайно интересно, поскольку, включая идентификатор sessionid в формате одного из возвращаемых столбцов, данное представление дает нам возможность подключения ко множеству других динамических административных объектов, которые отображают session id в форме одного из своих столбцов. В дополнение к возможности выявления ограниченных ресурсов для проведения сеанса теперь мы можем использовать идентификатор sessionid для подключения к представлению sys.dm_ exec_requests с целью агрегирования статистики ожидания в уровень запроса. Кроме того, мы можем выполнять аналогичные действия с использованием уровня журнала регистрации транзакций через представление sys.dm_trans_session_transactions (промежуточное динамическое административное представление, устанавливающее отношения между идентификаторами session_id и transaction_id в системе SQL Server).
Статистика ожидания
После добавления в представление sys.dm_ exec_sessions столбца database_id в версии SQL Server 2014 мы можем агрегировать ожидания для всех сеансов, связанных с той или иной конкретной базой данных. До выхода в свет версии SQL Server 2014, для того чтобы возвратить идентификатор database_ id или использовать его в качестве фильтра, требовалось объединить представления sys.dm_exec_sessions и sys.dm_exec_request. А это означает, что результаты можно было получать только для сеансов с активными запросами — серьезный недостаток, с точки зрения тех, кто работает с метаданными. Просто удивительно: на то, чтобы прийти к мысли о включении статистики ожидания уровня сеанса, ушло целых шесть версий SQL, если вести отсчет от момента создания динамических административных объектов. Достаточно беглого взгляда на sys. sysprocesses, чтобы понять, что эти сведения были доступны потребителю еще до появления динамического административного объекта (см. скриншот выше):
Отсюда следует, что данная информация записывалась на уровне сеансов и даже более вероятно, что на уровне запросов, поскольку запросы выполнялись процессором Query Engine, но предъявлялись пользователю или администратору баз данных лишь после агрегирования на уровне экземпляра. Причем мы могли видеть эту информацию с другим уровнем детализации только в представлениях sys.dni_exec_sessions и sys. dm_exec_requests и только в виде отдельных "ответов" (а не агрегированных значений на протяжении жизненного цикла сеанса или запроса).
Как было показано в многочисленных статьях, журналах, книгах и презентациях, эта статистика ожиданий является накопительной. Чтобы разобраться с существующим состоянием ожиданий, мы должны приложить некоторые усилия. Результаты представления sys.dm_exec_wait_stats возвращают сведения об ожидании с момента последнего запуска или перезапуска служб. Это означает, что мы видим результаты всех периодов деятельности: нормальные сроки загрузки и обслуживания, когда вполне вероятно скачкообразное увеличение времени ожидания OLEDB вследствие выполнения запросов по представлению sys.dm_db_index_ physical_stats, чтобы получить сведения о фрагментации индексов, необходимые для обслуживания индексов. Кроме того, мы получаем статистику ожидания, связанную с такими периодами, когда какой-нибудь сотрудник из отдела кадров выполняет нестандартный запрос с целью получения всех сведений о найме сотрудников компании (поскольку он опять забыл включить в свой запрос действительную дату начала). Здесь я склоняюсь к тому, чтобы осуществлять "нарезку" по времени всей своей коллекции статистических данных ожидания. Я имею в виду периодическое получение в соответствии с определенным графиком дампов представления sys. dm_os_wait_stats, включающего столбец date stamp, и перенос этих данных в физическую таблицу в базе данных, предназначенную для хранения сведений о задачах администрирования и обслуживания или данных на каждом из моих экземпляров. Это позволяет сокращать периоды ожидания, удерживая их в определенных пределах, а не все нагрузки с того момента, когда службы были перезапущены. Затруднения с выполнением этого процесса продолжались вплоть до выпуска SQL Server 2016.
1.
2. Сбор данных по ожиданиям экземпляра и по ожиданиям сеанса в SQL Server 2016;
3. Новый процесс сбора информации об ожидании экземпляра в SQL Server 2016.
В SQL Server 2016 появилось совершенно новое представление sys.dm_exec_session_wait_stats. По своей сути, оно очень похоже на уже существующие sys.dm_os_wait_stats: служит главным образом для возвращения информации об ожидании на момент отклика процессора на текущий запрос, инициатором которого является запрос от пользовательского сеанса. Однако между ними есть очень важное различие: новое представление возвращает данную информацию с сеансовым уровнем детализации.
Это чрезвычайно интересно, поскольку, включая идентификатор sessionid в формате одного из возвращаемых столбцов, данное представление дает нам возможность подключения ко множеству других динамических административных объектов, которые отображают session id в форме одного из своих столбцов. В дополнение к возможности выявления ограниченных ресурсов для проведения сеанса теперь мы можем использовать идентификатор sessionid для подключения к представлению sys.dm_ exec_requests с целью агрегирования статистики ожидания в уровень запроса. Кроме того, мы можем выполнять аналогичные действия с использованием уровня журнала регистрации транзакций через представление sys.dm_trans_session_transactions (промежуточное динамическое административное представление, устанавливающее отношения между идентификаторами session_id и transaction_id в системе SQL Server).
Статистика ожидания
После добавления в представление sys.dm_ exec_sessions столбца database_id в версии SQL Server 2014 мы можем агрегировать ожидания для всех сеансов, связанных с той или иной конкретной базой данных. До выхода в свет версии SQL Server 2014, для того чтобы возвратить идентификатор database_ id или использовать его в качестве фильтра, требовалось объединить представления sys.dm_exec_sessions и sys.dm_exec_request. А это означает, что результаты можно было получать только для сеансов с активными запросами — серьезный недостаток, с точки зрения тех, кто работает с метаданными. Просто удивительно: на то, чтобы прийти к мысли о включении статистики ожидания уровня сеанса, ушло целых шесть версий SQL, если вести отсчет от момента создания динамических административных объектов. Достаточно беглого взгляда на sys. sysprocesses, чтобы понять, что эти сведения были доступны потребителю еще до появления динамического административного объекта (см. скриншот выше):
SELECT spid
, lastwaittype
FROM sys.sysprocessesОтсюда следует, что данная информация записывалась на уровне сеансов и даже более вероятно, что на уровне запросов, поскольку запросы выполнялись процессором Query Engine, но предъявлялись пользователю или администратору баз данных лишь после агрегирования на уровне экземпляра. Причем мы могли видеть эту информацию с другим уровнем детализации только в представлениях sys.dni_exec_sessions и sys. dm_exec_requests и только в виде отдельных "ответов" (а не агрегированных значений на протяжении жизненного цикла сеанса или запроса).
Как было показано в многочисленных статьях, журналах, книгах и презентациях, эта статистика ожиданий является накопительной. Чтобы разобраться с существующим состоянием ожиданий, мы должны приложить некоторые усилия. Результаты представления sys.dm_exec_wait_stats возвращают сведения об ожидании с момента последнего запуска или перезапуска служб. Это означает, что мы видим результаты всех периодов деятельности: нормальные сроки загрузки и обслуживания, когда вполне вероятно скачкообразное увеличение времени ожидания OLEDB вследствие выполнения запросов по представлению sys.dm_db_index_ physical_stats, чтобы получить сведения о фрагментации индексов, необходимые для обслуживания индексов. Кроме того, мы получаем статистику ожидания, связанную с такими периодами, когда какой-нибудь сотрудник из отдела кадров выполняет нестандартный запрос с целью получения всех сведений о найме сотрудников компании (поскольку он опять забыл включить в свой запрос действительную дату начала). Здесь я склоняюсь к тому, чтобы осуществлять "нарезку" по времени всей своей коллекции статистических данных ожидания. Я имею в виду периодическое получение в соответствии с определенным графиком дампов представления sys. dm_os_wait_stats, включающего столбец date stamp, и перенос этих данных в физическую таблицу в базе данных, предназначенную для хранения сведений о задачах администрирования и обслуживания или данных на каждом из моих экземпляров. Это позволяет сокращать периоды ожидания, удерживая их в определенных пределах, а не все нагрузки с того момента, когда службы были перезапущены. Затруднения с выполнением этого процесса продолжались вплоть до выпуска SQL Server 2016.
