Новое в SSMS: отчет о задержках групп доступности AlwaysOn
В SQL Server 2012 были представлены группы доступности AlwaysOn и панель инструментов групп доступности AlwaysOn в SQL Server Management Studio (SSMS). Эта панель инструментов может использоваться администраторами баз данных для просмотра текущего состояния группы доступности и ее реплик доступности и баз данных. Хотя панель управления может быть настроена для предоставления информации о задержках между первичной и вторичной репликами (может быть рассчитана с использованием значений Commit LSN, Sent LSN и harden LSN), это не дает понимания причины задержки. Чтобы понять причину задержки, требуется захват и анализ счетчиков расширенных событий и производительности. Эта деятельность может занять много времени и требует обширных знаний о расширенных событиях, связанных с Always On.
С выпуском новой версии SSMS 17.4 Microsoft представляет функцию сбора данных о задержках групп доступности (Latency) и отчетность, встроенную в панель инструментов групп доступности. Эта функция маскирует захват и анализ расширенных событий от конечного пользователя и предоставляет простой для понимания отчет, в котором подробно описывается время, затрачиваемое на разных этапах процесса LogTransport (переноса журнала) .
Для чего нужна эта функция?
Функция сбора данных Latency и связанные с ней отчеты позволяют администратору базы данных быстро распознавать узкое место в потоке переноса журнала между первичной и вторичной репликами группы доступности. Эта функция НЕ отвечает на вопрос «Существует ли задержка при развертывании группы доступности?» а скорее дает возможность понять причину задержки в развертывании группы доступности. Эта функциональность дает возможность сузить потенциальную причину задержки при развертывании группы доступности.
Как это работает?
Как видно ниже, доступ к функциям сбора данных о задержках групп доступности можно получить из панели групп доступности.
Когда администратор нажимает на ссылку «Collect Latency Data» («Сбор данных о задержках»), SSMS связывается со всеми репликами в доступности и выполняет следующие задачи.
1. Проверяет, работает ли агент SQL или нет. Для функционирования сбора данных о задержках необходимо, чтобы агент SQL работал по крайней мере по одной вторичной реплике и первичной реплике.
2. Создает задание агента SQL с именем «AlwaysOn_Latency_Data_Collection». Это задание имеет 7 шагов:
- Сбор данных о группе доступности. Эти данные сохраняются (до следующего перезапуска SQL Server или следующего выполнения задания) в таблице «AGInfo» в базе данных TempDB.
- Создание Сеанса расширенных событий для сбора данных группы доступности на реплике
- Ожидание завершения расширенного события. В настоящее время Microsoft проводит сбор продолжительностью 2 минуты. Хотя эту продолжительность можно изменить, Microsoft не рекомендует пользователям изменять это значение. Изменение продолжительности влияет на время, в течение которого выполняется сеанс расширенного события (и собираемые данные), и будет иметь прямое влияние на последующую фазу извлечения данных.
- Завершение сеанса расширенного события
- Извлечение данные XML из сеанса расширенного события во временную таблицу и последующий анализ информации о событиях XML в таблице «DMReplicaEvents» в базе данных TempDB
- Заполнение результатов, установленных для отчетов Latency.
- Завершение Сеанса расширенного события.
После завершенного выполнения задания на всех репликах информация о задержке может быть просмотрена с использованием новых отчетов о задержках, отчета о задержке первичной реплики (Primary Replica) и отчета о задержке вторичной реплики (Secondary Replica). Эти отчеты доступны в виде стандартных отчетов (Standard Reports) для групп доступности, как показано ниже.
Отчет о задержке первичной реплики
Отчет о задержке первичной реплики имеет 3 раздела. В первом разделе представлена информация о реплике для групп доступности (AG).
Роль реплики AlwaysOn (во время сбора данных)
|
Имя группы доступности |
Имя реплики доступности |
Роль |
|
LatencyDemo |
SQLNode2 |
PRIMARY |
|
LatencyDemo |
SQLNode1 |
SECONDARY |
Во втором разделе представлен графический вид среднего времени фиксации (Commit Time ) на первичной реплике и среднего удаленного уплотненного времени (Remote Harden Time) для всех вторичных реплик. Эта информация основана на значениях, перенастроенных командой hadr_db_commit_mgr_harden и hasr_receive_harden_lsn_message.
Третий и последний раздел отчета содержит численные значения продолжительности фиксирования, удаленного уплотнения, времени, затраченного на сжатие, и длительности отправки лог-блока.
Следующие значения отображаются в отчете о задержке первичной реплики:
- Commit Time - среднее время, потраченное на фиксацию транзакции на первичной реплике.
- Remote Harden Time - время, прошедшее между отправкой лог-блока во вторичную реплику и получением связанного с ним сообщения harden_lsn из вторичных реплик. Оно должно включать следующее:
- Время, затрачиваемое на отправку лог-блока на уровень UCS - передается в отчет первичной реплики
- Время, затрачиваемое на отправку лог-блока в Secondary по сети - НЕ передается ни в один из отчетов.
- Время, затрачиваемое на получение лог-блока с уровня UCS на вторичной реплике - передается в отчет о вторичной реплике.
- Время, затрачиваемое на распаковку лог-блока на вторичной реплике. - передается в отчет о первичной реплике
- Время, затрачиваемое на запись блока журнала на диск на вторичной реплике - передается в отчет о первичной реплике
- Время, затраченное на отправку подтверждения на уровень UCS на вторичной реплике - передается в отчет о первичной реплике
- Время, затраченное на отправку подтверждения на первичный сервер по сети - НЕ передается ни в один из отчетов
- Compression Time – время, затрачиваемое на сжатие блока журнала перед отправкой на вторичные реплики. В SQL Server 2016 и в более ранних версиях перенос журнала на синхронную вторичную реплику НЕ сжимается, тогда как перенос журнала в реплики Async сжимается.
- Local Flush Time – среднее время, затрачиваемое на запись блока журнала в файл LDF. Это значение вычисляется с использованием событий Log_Flush_Start и Log_Flush_Complete Extended.
- Send Time – время, затрачиваемое на отправку блока журнала на уровень UCS в SQL. Оно не включает время, затрачиваемое на сетевом уровне (т. е. при переходе между первичной и вторичной репликами)
Отчет о задержке вторичной реплики
Информация о задержке вторичной репликации обеспечивает разбивку времени, затрачиваемого на вторичную реплику во время переноса лог-блока. В этом отчете также есть 3 раздела, как показано ниже.
Следующие значения сообщаются в отчете о задержке вторичной реплики:
- Local Flush Time – Сред. время, затрачиваемое на запись блока журнала в файл LDF. Это значение вычисляется с использованием событий Log_Flush_Start и Log_Flush_Complete Extended.
- Decompression Time – время, затрачиваемое на распаковку лог-блока после его получения из первичной реплики. В SQL Server 2016 и выше перенос журнала на синхронную вторичную реплику НЕ сжимается, тогда как перенос журнала в реплики Async сжимается.
- Receive Time – время, затрачиваемое на получение лог-блока с уровня UCS и включение его для дальнейшей обработки.
- Send Time – время, затраченное на отправку сообщения подтверждения на уровень UCS в SQL. Оно не включает время, затрачиваемое на сетевом уровне (т. е. при переходе между первичной и вторичной репликами)
Примечание: на изображениях с примерами отчетов высокий уровень задержки вызван высокой задержкой движения между первичными и вторичными репликами. Эта демонстрационная установка включала серверы в разных географических регионах (запад США и США), со средней задержкой в 25 минут между двумя серверами.
Функция сбора данных о задержках групп доступности доступна только для учетных записей sysadmin (только для Windows Authenticated) и требует, чтобы текущая учетная запись пользователя принадлежала администратором для всех реплик.
Ограничения
Текущая реализация сбора данных Latency имеет следующие ограничения:
- Этот функционал может использоваться только для сбора данных о задержке для одной группы доступности в один момент времени.
- Имена объектов TempDB, используемых в нем, жестко запрограммированы. Это означает, что в любой момент может работать только одна коллекция.
- Данные о задержках хранятся в таблицах TempDB, что означает, что эта информация будет потеряна, если экземпляр SQL Server перезапустится с момента последнего захвата.
- Данные о задержках НЕ доступны прошедшим проверку подлинности SQL пользователям и логинам, даже если логин является администраторским на сервере.
- Учитывая, что функционал включен только для пользователей, прошедших проверку подлинности Windows, она не будет работать для развертывания групп доступности в рабочей группе или в междоменных развертываниях, где нет доверия между доменами.
- Этот функционал не работает для групп распределенной доступности.
- Этот функционал требует следующих минимальных версий для SQL Server:
- SQL Server 2017 RTM
- SQL Server 2016 SP1
- SQL Server 2014 SP2