Устранение неполадок Always On отработки отказа групп доступности

Примечание.

Чтобы автоматизировать анализ вручную, описанный в этой статье, см . раздел Использование AGDiag для диагностики событий работоспособности группы доступности.

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

Симптомы и последствия Always On проблемы работоспособности или отработки отказа

Always On реализует надежный мониторинг работоспособности с помощью различных механизмов для обеспечения работоспособности экземпляра Microsoft SQL Server, на котором размещаются основные реплика, базовый кластер и работоспособность системы. Рабочая нагрузка мгновенно прерывается при обнаружении проблемы работоспособности кластера Windows или Always On.

При обнаружении состояния работоспособности обычно происходит следующая последовательность событий. В этом инструменте устранения неполадок события работоспособности упоминаются в связи со следующими событиями:

• Реплики групп доступности и базы данных переходить с основной роли на роль разрешения.

• Базы данных группы доступности переходят в автономный режим и больше не доступны.

• Кластер Windows помечает кластеризованный ресурс группы доступности как сбой.

• Кластер Windows пытается вернуть роль группы доступности (в исходном или автоматическом реплика партнера по отработку отказа).

• Роль группы доступности успешно подключена к сети, если Always On и мониторинг работоспособности кластера Windows обнаруживает ее работоспособность.

В случае успешного выполнения реплики группы доступности и базы данных переходят на основную роль, а базы данных группы доступности будут подключены и доступны вашему приложению.

Приложения не могут получить доступ к базам данных группы доступности

При обнаружении состояния работоспособности группа доступности реплика и базы данных переходят на роль Разрешения, а базы данных группы доступности переводятся в автономный режим. После того как реплика в основной роли (на исходном сервере реплика или партнере по отработке отказа реплика сервере), реплика и базы данных снова перейдут в режим "в сети". В то время как реплика и базы данных разрешаются и находятся в автономном режиме, все приложения, которые пытаются получить доступ к этим базам данных группы доступности, завершаются ошибкой и создают сообщение "Ошибка 983": Unable to access availability database.... Эта ошибка также записывается в журнал ошибок Microsoft SQL Server, если SQL Server настроено для записи неудачных попыток входа:

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

Период, в течение которого группа доступности находится в роли Разрешения, прежде чем она вернется в режим "в сети" в основной роли, обычно длится всего несколько секунд или даже менее секунды.

Определение и диагностика Always On событий работоспособности группы доступности или отработки отказа

1. Определение Always On тенденций в области здравоохранения

Вы можете исследовать одно событие Always On работоспособности, или может возникнуть недавняя или продолжающаяся тенденция проблем со здоровьем, которые периодически прерывают работу. Следующие вопросы помогут вам сузить и сопоставить последние изменения в рабочей среде, которые могут быть связаны с этими проблемами работоспособности:

• Когда началась тенденция событий работоспособности Always On или кластера?
• Происходят ли события работоспособности в определенный день?
• Происходят ли события работоспособности в определенное время суток?
• Происходят ли события работоспособности в определенный день или неделю месяца?

При обнаружении тенденции проверка запланированное обслуживание в системе (хост-система в виртуальной среде), пакеты ETL и другие задания, которые могут коррелировать с этими событиями работоспособности. Если система является виртуальной машиной, изучите систему узла на наличие изменений, которые, возможно, были внесены во время сбоев.

Рассмотрите возможность нерегламентированных рабочих нагрузок, которые могут коррелировать со временем возникновения проблем со работоспособностью (например, при первом входе пользователей в систему или после возвращения пользователей из обеда).

Примечание.

Это хорошее время, чтобы рассмотреть план сбора данных о производительности в течение недели и месяца. Чтобы лучше понять, когда система загружена, можно измерить счетчики монитора производительности Windows, такие как Processor Information::% Processor Time, Memory::Available MBytesи MSSQLServer:SQL Statistics::Batch Requests/sec.

2. Просмотр журнала кластера

Журнал кластера Windows — это наиболее полный журнал для определения типа события работоспособности Always On или кластера, а также обнаруженного состояния работоспособности, вызвавшего событие. Чтобы создать и открыть журнал кластера, выполните следующие действия.

Используйте Windows PowerShell, чтобы создать журнал кластера Windows на узле кластера, на котором размещается основной реплика во время события работоспособности. Например, выполните следующий командлет в окне PowerShell с повышенными привилегиями, используя sql19agn1 в качестве имени сервера на основе SQL Server:

get-clusterlog -Node sql19agn1 -UseLocalTime     

Примечание.

По умолчанию файл журнала создается в папке %WINDIR%\cluster\reports.

3. Найдите событие работоспособности в журнале кластера.

Always On использует несколько механизмов мониторинга работоспособности для мониторинга работоспособности группы доступности. В дополнение к событию работоспособности кластера Windows (в котором кластер Windows обнаруживает проблемы работоспособности узлов кластера), Always On имеет четыре различных типа проверок работоспособности:

• Служба SQL Server не запущена
• Время ожидания аренды SQL Server
• Время ожидания SQL Server работоспособности проверка
• Внутренняя проблема с работоспособностью SQL Server

Вы можете найти любой из этих Always On определенных событий работоспособности, выполнив поиск в журнале кластера по строке [hadrag] Resource Alive result 0. Эта строка сохраняется в журнале кластера при обнаружении любого из этих событий. Например:

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

С помощью средства можно найти все события работоспособности в журнале кластера, чтобы создать сводный отчет о Always On проблемах работоспособности. Это может быть полезно для выявления хронологических тенденций и определения того, является ли определенный вид Always On состояние здоровья повторяющимся. На следующем снимке экрана показано, как использовать текстовый редактор (в данном случае — NotePad++), чтобы найти все строки в журнале кластера, содержащие [hadrag] Resource Alive result 0 строку:

Определение типа проблемы работоспособности, которая вызвала отработку отказа

Чтобы определить тип проблем работоспособности, обнаруженных в журнале кластера основной реплика, сравните их с проблемами, описанными в следующих разделах.

Событие работоспособности кластера

Кластер Microsoft Windows отслеживает работоспособность рядовых серверов в кластере. Если обнаружена проблема работоспособности, рядовой сервер кластера может быть удален из кластера. Кроме того, ресурсы кластера (включая роль группы доступности, размещенную на удаленном рядовом сервере кластера) будут перемещены в партнер по отработку отказа группы доступности реплика, если настроена автоматическая отработка отказа.

Симптомы событий работоспособности кластера

Ниже приведен пример события работоспособности кластера в журнале кластера. Чтобы найти его, можно выполнить поиск по запросу Lost quorum или Cluster service has terminated так как может присутствовать во время изменения роли группы доступности или отработки отказа.

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

Другой способ определить это событие — выполнить поиск в системном журнале событий Windows:

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Диагностика события работоспособности кластера

Ошибки в журнале событий Windows (события 1135 и 1177) свидетельствуют о том, что сетевое подключение является причиной события. Это наиболее распространенная причина, по которой обнаруживается проблема работоспособности кластера. В следующем примере показано, что другие рядовые серверы кластера не могли взаимодействовать с этим сервером, на котором размещен основной реплика группы доступности, и что эта проблема вызвала удаление узла кластера из кластера:

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

В журнале кластера можно найти сведения о сбое подключения к узлу. В расположении в журнале кластера, где вы нашли Lost quorum, выполните поиск строк, таких как Failed to connect to remote endpoint, unreachableи is broken.

Разрешение события работоспособности кластера

Убедитесь, что мониторинг работоспособности кластера подходит для среды узла. Дополнительные сведения о группах доступности SQL Server Always On, размещенных в Microsoft Azure, см. в статье Общие сведения о отказоустойчивом кластере Windows Server — SQL Server на виртуальных машинах Azure.

Если это необходимо, обратитесь в службу поддержки высокой доступности Microsoft Windows, чтобы сообщить об инциденте в службе поддержки.

служба SQL Server не работает: событие работоспособности Always On

Always On мониторинга работоспособности можно определить, не работает ли служба SQL Server, на котором размещена основная реплика группы доступности.

Симптомы завершения работы службы SQL Server

Ниже приведен пример отчета журнала кластера для роли группы доступности "ag", которая указывает на сбой, так как QueryServiceStatusEx возвращается идентификатор 0процесса :

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

Диагностика и разрешение событий завершения работы службы SQL

Проверьте журнал системных событий Windows и SQL Server журнал ошибок на наличие непредвиденных SQL Server завершения работы.

Если SQL Server было завершено из-за завершения работы системы или завершения работы администратора, в журнале ошибок SQL Server отобразится следующая запись:

2023-03-10 09:38:46.73 spid9s SQL Server завершается в ответ на запрос "остановить" от Service Control Manager. Это только информационное сообщение. Никаких действий пользователя не требуется.

В журнале системных событий Windows будет отображаться следующая запись об ошибке:

Сведения 10.03.2023 9:41:06 AM Service Control Manager 7036 None Служба SQL Server (MSSQLSERVER) остановлена.

В журнале системных событий Windows отображается следующая запись об ошибке, если SQL Server неожиданно завершает работу:

Ошибка 10.03.2023 8:37:46 AM Service Control Manager 7034 None Служба SQL Server (MSSQLSERVER) неожиданно завершила работу. Это было сделано 1 раз.

Проверьте конец журнала ошибок SQL Server на наличие подсказок. Если журнал ошибок заканчивается внезапно, это означает, что он был принудительно завершен. Например, если SQL Server было завершено с помощью диспетчера задач, отчет об ошибках SQL Server не будет содержать никаких сведений о внутренних проблемах, которые могли привести к завершению процесса.

Если внутренняя проблема работоспособности SQL Server привела к неожиданному завершению SQL Server, в конце журнала ошибок SQL могут быть подсказки о возможном неустранимом исключении (включая создание диагностики файла дампа). Просмотрите подсказки и выполните необходимые действия. Если вы нашли файл дампа, обратитесь в службу поддержки Microsoft SQL Server и предоставьте SQL Server журнал ошибок и содержимое файла дампа для дальнейшего изучения.

Время ожидания аренды: событие работоспособности Always On

Always On использует механизм аренды для мониторинга работоспособности компьютера, на котором установлена SQL Server. Время ожидания аренды по умолчанию составляет 20 секунд.

Симптомы Always On событий истечения времени ожидания аренды

Ниже приведен пример выходных данных времени ожидания аренды Always On из журнала кластера. В этих строках можно найти время ожидания аренды в журнале кластера.

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

Дополнительные сведения об истечении времени ожидания аренды см. в разделе Механизм арендыстатьи Механика и рекомендации по аренде, кластеру и работоспособности проверка время ожидания для Always On групп доступности.

Диагностика и разрешение событий времени ожидания аренды Always On

Существует две main проблемы, которые могут вызвать истечение времени ожидания аренды:

• диагностика файла дампа SQL Server. При обнаружении SQL Server определенных внутренних событий работоспособности, таких как нарушение доступа, утверждение или взаимоблокировка планировщика, создается файл дампа диагностики (MDMP-файл) в папке SQL Server \LOG.

• Проблема с производительностью на уровне системы. Время ожидания аренды не обязательно указывает на проблему работоспособности SQL Server. Вместо этого он может указывать на общесистемную проблему работоспособности, которая также влияет на работоспособность сервера на основе SQL Server. Дополнительные инструкции по устранению неполадок см. в разделе MSSQLSERVER_19407.

1. диагностика файла дампа SQL Server

SQL Server может обнаружить внутреннюю проблему работоспособности, например нарушение доступа, утверждение или взаимоблокировку планировщиков. В этом случае программа создает файл мини-дампа (MDMP) в папке SQL Server \LOG процесса SQL Server для диагностики. Процесс SQL Server зависает на несколько секунд, пока файл мини-дампа записывается на диск. В течение этого времени все потоки в SQL Server процессе находятся в замороженном состоянии. Сюда входит поток аренды, отслеживаемый с помощью Always On мониторинга работоспособности. Таким образом, Always On может обнаружить время ожидания аренды.

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

Чтобы устранить эту проблему, необходимо изучить диагностику файла дампа на первопричину. Обратитесь в службу поддержки Microsoft SQL Server, чтобы предоставить SQL Server журнал ошибок и содержимое файла дампа для дальнейшего изучения.

2. Высокая загрузка ЦП или другие проблемы с производительностью системы

Время ожидания аренды указывает на проблему производительности, которая влияет на всю систему, включая SQL Server. Чтобы диагностировать системную проблему, Always On работоспособности диагностика сообщает данные монитора производительности в журнале кластера и включает событие времени ожидания аренды. Данные о производительности охватывают около 50 секунд, что приводит к событию истечения времени ожидания аренды, сообщая об использовании ЦП, свободной памяти и задержке на диске.

Ниже приведен пример сообщаемых данных о производительности, которые показывают время ожидания аренды в журнале кластера. В этом примере выходных данных приводится высокая общая загрузка ЦП, которая может быть связана с истечением времени ожидания аренды.

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

Если данные о производительности показывают высокую загрузку ЦП, низкое состояние памяти или высокую задержку диска во время истечения времени ожидания аренды, начните собирать Монитор производительности данные за весь день на основном реплика, чтобы исследовать эти симптомы. Записывая данные монитора производительности за более длительный период времени, вы можете лучше определять базовые и пиковые значения для этих ресурсов и отслеживать изменения в этих ресурсах при истечении времени ожидания аренды. При сборе этих данных определите, существуют ли определенные запланированные или нерегламентированные рабочие нагрузки в SQL Server, которые коррелируют с временем возникновения этих проблем с ресурсами и событиями работоспособности.

Также следует записывать счетчики, сообщающие об использовании системных ресурсов, в том числе следующее:

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

Время ожидания проверка работоспособности: событие работоспособности Always On

Когда группа доступности реплика переходит в основную роль, Always On мониторинг работоспособности устанавливает локальное подключение ODBC к экземпляру SQL Server. Хотя Always On подключены и отслеживаются, если SQL Server не отвечает через подключение ODBC в течение периода, установленного для времени ожидания проверка работоспособности группы доступности (по умолчанию — 30 секунд), активируется событие времени ожидания проверка работоспособности. В этой ситуации группа доступности переходит с основной роли на роль Resolveing и инициирует отработку отказа, если она настроена для этого.

Дополнительные сведения о работоспособности проверка тайм-аутах см. в разделе "Работоспособность проверка операции с истечением времени ожидания"статьи Механика и рекомендации по аренде, кластеру и работоспособности проверка время ожидания для Always On групп доступности.

Вот Always On работоспособности проверка время ожидания, как указано в журнале кластера:

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

Диагностика и устранение Always On события времени ожидания проверка работоспособности

В следующем разделе показано, как просмотреть журналы SQL Server на наличие событий "хлебного крошки", которые могут быть найдены и которые коррелируют с Always On работоспособности проверка время ожидания, которое обнаруживается и сообщается. Журналы, которые здесь проверяются, включают журнал кластера (где подтверждено время ожидания проверка работоспособности), system_health журналы расширенных событий и SQL Server журналы ошибок (оба находятся в папке SQL Server \LOG) и журнал системных событий Windows. Используйте эти и другие журналы для поиска коррелирующих событий, которые могут помочь вам область причину проверка времени ожидания работоспособности.

1. Проверьте наличие событий планировщика, не являющихся результатом

Время ожидания Always On работоспособности проверка часто возникает из-за "невыдающихся" событий в SQL Server. Когда SQL Server обнаруживает, что поток не дал результатов в планировщике, он сообщит о том, что произошло событие планировщика, не дающее результатов. Если в том же планировщике отображаются другие задачи, которые не получают время ЦП, это основной признак невыдающегося планировщика. Такое поведение может привести к задержке выполнения этих задач и "нехватке" рабочих нагрузок, назначенных определенному планировщику времени ЦП.

Чтобы проверка для событий планировщика, не являющихся результатом, выполните следующие действия.

1. Проверьте журналы SQL Server system_health расширенных событий, чтобы определить, сообщалось ли о событии планировщика, не являющемся результатом, во время Always On работоспособности проверка события времени ожидания. Невозмохдаемые события, которые могут быть указаны ниже.

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. Откройте SQL Server журналы расширенных событий работоспособности системы на основном реплика время ожидания предполагаемого проверка работоспособности.

3. В SQL Server Management Studio (SSMS) перейдите в раздел Открыть файл >и выберите Объединить расширенные файлы событий.

4. Нажмите кнопку Добавить.

5. В диалоговом окне Открытие файла перейдите к файлам в каталоге SQL Server \LOG.

6. Нажмите и удерживайте нажатой клавишу CONTROL, а затем выберите файлы, имена которых начинаются с system_health_xxx.xel.

7. Нажмите кнопку Открыть>ОК.

8. Отфильтруйте результаты. Щелкните правой кнопкой мыши событие под столбцом имени и выберите Фильтр по этому значению.

   

9. Определите фильтр для сортировки строк, в которых значения в столбце yieldname содержат , как показано на следующем снимке экрана. При этом возвращаются все виды событий, которые могли быть записаны в system_health журналах.

   

10. Сравните метки времени, чтобы узнать, были ли события, не являющиеся результатом во время проверка времени ожидания работоспособности. Ниже приведено время ожидания работоспособности проверка, как указано в журнале кластера:

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    Вы видите, что во время проверка времени ожидания работоспособности произошли события, не являющиеся результатом.

    

Если обнаружены события, не являющиеся результатом, проверка причину события, не дающего выход. Обратитесь в службу поддержки SQL Server, чтобы изучить события, не являющиеся результатом.

2. Проверьте журнал ошибок SQL Server

Проверьте журнал ошибок SQL Server, чтобы сопоставить события во время проверка времени ожидания работоспособности. Эти события могут предоставлять "хлебные крошки", которые предлагают дальнейшие шаги по область первопричины проверка времени ожидания работоспособности.

Например, в следующей записи журнала показано, что в журнале кластера произошло время ожидания проверка работоспособности:

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

В журнале ошибок SQL Server в течение нескольких секунд после истечения времени ожидания проверка работоспособности SQL Server сообщает, что обнаружена серьезная задержка ввода-вывода:

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

Просмотрите журнал системных событий на наличие возможных системных подсказок, которые могут быть связаны с событием проверка времени ожидания работоспособности. При просмотре журнала системных событий Windows может обнаружиться проблема ввода-вывода, о ней сообщалось в то же время для того же проверка времени ожидания работоспособности:

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

работоспособность SQL Server: событие работоспособности Always On

Always On отслеживает различные типы событий работоспособности SQL Server. Хотя в ней размещается основная реплика группы доступности, SQL Server непрерывно выполняетсяsp_server_diagnostics, которая сообщает о работоспособности SQL Server с помощью различных компонентов. При обнаружении sp_server_diagnostics каких-либо проблем работоспособности сообщает об ошибке для этого конкретного компонента, а затем отправляет результаты обратно в процесс обнаружения работоспособности Always On. При сообщении об ошибке роль группы доступности отображает состояние сбоя и возможную отработку отказа, если для этого настроена группа доступности.

Симптомы Always On SQL Server событий здоровья

Ниже приведен пример проблемы работоспособности SQL Server, о чем sp_server_diagnostics сообщается в журнале кластера. SQL Server сообщает о состоянии ошибки в системном компоненте для Always On мониторинга работоспособности, а группа доступности contoso-ag переходит в состояние сбоя.

Примечание.

При SQL Server проблеме работоспособности создается отчет, аналогичный отчету о работоспособности проверка времени ожидания. Оба события работоспособности сообщают .Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel Различие для события работоспособности SQL Server заключается в том, что он сообщает, что компонент SQL Server изменился с "предупреждение" на "ошибка".

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

Диагностика и устранение событий работоспособности SQL Server

Тип проблемы работоспособности, о которую сообщает SQL Server работоспособности, должен определять направление анализа первопричин.

По умолчанию при развертывании группы доступности FAILURE_CONDITION_LEVEL устанавливается как три. Это активирует мониторинг некоторых, но не всех профилей работоспособности SQL Server. На уровне по умолчанию Always On активирует событие работоспособности, когда SQL Server создает слишком много файлов дампа, нарушение доступа к записи или потерянный спин-блок. Задание группы доступности до уровня 4 или 5 расширит типы отслеживаемых SQL Server проблем работоспособности. Дополнительные сведения о мониторах SQL Server работоспособности Always On см. в статье Настройка гибкой политики автоматической отработки отказа для группы доступности — SQL Server Always On.

Чтобы определить конкретную проблему работоспособности Always On, выполните следующие действия.

1. Откройте журналы расширенных событий диагностики кластера SQL Server на основном реплика до момента возникновения предполагаемого события работоспособности SQL Server.

2. В SSMS перейдите в раздел Открыть файл>, а затем выберите Объединить расширенные файлы событий.

3. Нажмите Добавить.

4. В диалоговом окне Открытие файла перейдите к файлам в каталоге SQL Server \LOG.

5. Нажмите клавишу CONTROL, выберите файлы, имена которых совпадают <servername>_<instance>_SQLDIAG_xxx.xel, а затем нажмите кнопку Открыть>ОК.

   

   В SSMS появится новое окно с вкладками, содержащее расширенные события, как показано на следующем снимке экрана.

6. Чтобы изучить проблему работоспособности SQL Server, найдите component_health_result объект , значение которого state_desc равно error. Ниже приведен пример события системного компонента, которое сообщило об ошибке в Always On мониторинга работоспособности:

   

7. Дважды щелкните столбец данных в нижней области. Откроется подробные данные компонентов в новой области окна SSMS для просмотра. Вот как выглядят данные системных компонентов:

   

   Обратите внимание, что данные totalDumprequests=186 указывают на то, что на этом SQL Server было создано слишком много диагностических событий файла дампа. По этой причине системный компонент сообщил об ошибке. Когда Always On мониторинг работоспособности получает это состояние ошибки, он активирует событие работоспособности группы доступности. Вы также можете убедиться, что из данных, предоставленных в системных компонентах, не обнаружено нарушений доступа на запись или потерянных спин-блокировок.

   Если это необходимо, обратитесь в службу поддержки SQL Server, чтобы открыть обращение в службу поддержки, чтобы получить дополнительную помощь в поиске первопричины этих внутренних SQL Server проблем со здоровьем.