Приближается срок выпуска новой версии Microsoft SQL Server. Это означает, что мне предстоит изучение новых динамических административных представлений и функций. В этой серии статей я расскажу вам о своих открытиях. В первой статье мы рассмотрим новшества CTP 2.1, в частности одно из динамических административных представлений (DMV), которое обязательно должно войти в окончательную версию SQL Server 2016: dm_os_session_wait_stats.
Важно понимать, что CTP — не окончательный продукт и, скорее всего, будет отличаться от версии, предложенной потребителям. В своих статьях я постараюсь своевременно отражать изменения в динамических административных объектах по мере приближения даты выпуска.
DMV, исключенное из SQL 2016
Сравнение SQL Server 2014 и SQL Server 2016 CTP 2.1 показывает, что из следующей версии удалено лишь одно динамическое административное представление: sys.dm_db_xtp_merge_requests. Оно предоставляет информацию о запросах об объединении баз данных, поступающих от пользователей или формируемых внутри SQL Server.
Новые динамические административные представления в SQL Server 2016 CTP 2.1
Это не опечатка. В SQL Server 2016 CTP 2.1 нет новых динамических административных функций, только представления, и на момент подготовки данной статьи их всего 16:
- dm_column_store_object_pool;
- dm_db_column_store_row_group_operational_stats;
- dm_db_column_store_row_group_physical_stats;
- dm_db_rda_migration_status;
- dm_exec_compute_node_errors;
- dm_exec_compute_node_status;
- dm_exec_compute_nodes;
- dm_exec_distributed_request_steps;
- dm_exec_distributed_requests;
- dm_exec_distributed_sql_requests;
- dm_exec_dms_services;
- dm_exec_dms_workers;
- dm_exec_external_operations;
- dm_exec_external_work;
- dm_exec_function_stats;
- dm_exec_session_wait_stats.
В следующих статьях мы рассмотрим все эти представления, но пока сосредоточимся на последнем, которое выглядит самым многообещающим для ускорения обработки метаданных. Ничто не вызывает такого живого интереса у администратора, как словосочетание wait stats («статистика ожидания»).
Динамическое административное представление dm_exec_session_wait_stats содержит информацию, схожую с получаемой от действующего ныне представления dm_os_wait_stats, — метаданные, относящиеся к суммарному ожиданию ресурсов и процессора для всех действий в экземпляре SQL Server со времени ручной очистки статистики ожидания или последнего перезапуска служб SQL (в зависимости от того, какое событие произошло последним).
Отличие этого DMV от dm_os_wait_stats в том, что происходит разделение ожиданий по идентификатору session_id пользователя/системы. Это единственное различие между двумя представлениями. Поначалу можно подумать, что это превосходный новый ресурс для поиска причин, снижающих производительность (и он может им быть), но не надейтесь, что с его помощью удастся выполнить весь анализ, необходимый для настройки производительности. Тому есть несколько причин.
Возможно, он не подходит для нематериализованных сеансов.
Не все приложения поддерживают сеансы со своими базами данных. Если только речь идет не о сеансах (или группах сеансов) для приложения, которое поддерживает устойчивое соединение с SQL Server, вам не удастся извлечь пользу из дополнительного разбиения статистики ожидания на основе session_id. Когда пользователи жалуются на медленную работу базы данных, у вас есть повод задействовать dm_exec_session_wait_stats в процессе диагностики, если сеансов более не существует. По тем же причинам я избегаю использовать dm_exec_locks для диагностики блокирующих неполадок: происходят постоянные подвижки базовых данных, и полученные результаты немедленно устаревают.
Если вам приходится анализировать проблемы, связанные с приложением, поддерживающим состояния, то это динамическое административное представление выглядит перспективным. Вы можете выполнить объединение из dm_exec_session_wait_stats с dm_exec_sessions, чтобы определить сеансы для конкретного приложения или сеанс, который полезно проверить по столбцам в «родительском» DMV.
Установите соединение с dm_exec_sessions на session_id=session_id, а затем используйте dm_exec_sessions.host_name или program_name для фильтрации.
После этого можно выполнить что-нибудь похожее на следующий запрос, который возвращает всю сеансовую информацию об ожидании для конкретного приложения.
Это приводит к такой же ситуации, которая встречается при использовании прежнего представления dm_os_wait_stats: вы имеете дело с накапливаемыми метаданными.
Ожидания накапливаются для всех типов периодов активности
Это одна из причин, по которым я всегда рекомендую собирать статистику ожидания по временным интервалам, чтобы оптимизировать производительность. При этом составляется физическая таблица (обычно в базе данных, выделенной для всех административных задач и доступной только администраторам базы данных) для вставки результатов регулярно выполняемого сбора данных из определенного DMV с соответствующей временной меткой (и иногда уникальным идентификатором) для анализа в будущем. Это позволяет установить различия между двумя точками во времени, чтобы определить события, происходившие в определенный период. Эту информацию можно сохранить для анализа трендов, а когда потребность в ней отпадет — удалить.
При работе со статистикой ожидания существуют более удачные подходы, нежели непосредственный запрос представлений dm_os_wait_stats или dm_exec_session_wait_stats, так как оба эти представления собирают информацию за время после последнего удаления их статистики, что происходит при каждом перезапуске службы или выполняется вручную. Это означает, что за период непрерывной работы системы статистические данные отражают состояние ожиданий при всех типах системной нагрузки: обычная работа, периоды резервного копирования, дефрагментации индекса и т. д. Ожидания, обнаруженные на каждом этапе, будут разными и вызовут различные действия администратора в зависимости от полученных результатов. Например, в периоды действий по обслуживанию индекса можно заметить увеличенное время ожидания кратковременной блокировки, которого не бывает во время обычной активности; или ожидания резервного копирования и протоколирования, имеющего место во время резервного копирования. Это напоминает притчу о слепых, которые ощупывают слона.
Итак, приступая к рассказу о новых динамических административных представлениях, я показал, что было добавлено и удалено. Кроме того, мы познакомились с первым DMV, которое нам предстоит изучить: dm_exec_session_wait_stats. В следующей статье речь пойдет о том, как собирать разделенную на временные интервалы статистику ожидания для dm_exec_session_wait_stats.
Мы рассмотрим анализ сеансовой статистики ожидания с фильтрацией по имени программы, типу ожидания, пользователю и другим критериям. Кроме того, я представлю анализ сеансовой статистики ожидания для диапазона времени при сборе данных с разделением по интервалам. И наконец, мы познакомимся со следующим динамическим административным представлением, о котором речь пойдет далее.