Группы обеспечения доступности AlwaysOn может выступать в качестве СИНХРОНИЗАЦИИ после установки SQL Server 2014 CU5, CU4 SQL Server 2012 с пакетом обновления 2 или CU3 SQL Server 2012 с пакетом обновления 2

Проблемы

Рассмотрим следующий сценарий.

• На сервере с Microsoft SQL Server 2014 или Microsoft SQL Server 2012 с пакетом обновления 2 (SP2), на котором размещается вторичная реплика группы доступности, в рамках чередующегося обновления.

• Вы применили одно из следующих обновлений к установке SQL Server.

  • Накопительный пакет обновления 5 для SQL Server 2014

  • Накопительное обновление 4 для SQL Server 2012 с пакетом обновления 2

  • Накопительное обновление 3 для SQL Server 2012 с пакетом обновления 2

  Важно! Исправление, описанное в этой статье, заменяет эти накопительные обновления. Не устанавливайте эти обновления, если вы еще не сделали этого.

• Чтобы завершить установку накопительного обновления, перезапустите эту вторичную реплику.

• Вы перейдете к группе доступности, которая переносит обновленную реплику в основную роль.

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

• Дополнительные реплики выводятся как "не СИНХРОНИЗИРУются".

• Когда вы запрашиваете sys.dm_exec_requests, вы замечаете временную блокировку блокировки между сеансами пользователей и сеанс, команда которого выводится как "DB_STARTUP". Кроме того, вы можете заметить, что между командами контрольной точки и DB_STARTUP .

• Взаимоблокировки, связанные с сеансом, в котором восстановлена одна из баз данных доступности, записываются в журнал ошибок SQL Server. Эти журналы похожи на приведенные ниже. <date/time> spid<xx> Recovery is writing a checkpoint in database <dbname/dbid>. This isan informational message only. No user action is required.<date/time> spid<xx> Recovery completed for database <dbname/dbid> in <x> second(s) (analysis<x> ms, redo <x> ms, undo <x> ms.) This is an informational message only. No user action is required.…<date/time> spid<xx> Error: 1205, Severity: 13, State: 28.<date/time> spid<xx> Transaction (Process ID <xx>) was deadlocked on lock resources with anotherprocess and has been chosen as the deadlock victim. Rerun the transaction.

• Если база данных доступности включена для Microsoft SQL Server Service Broker, сообщения в базе данных доступности могут не обрабатываться успешно. Если запустить средство трассировки профилировщика, а затем вы захватите событие "Broker: сообщение о классификации", захватывается следующее событие:

  9791. Брокер отключен в базе данных отправителя

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

Причина

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

Решение

Чтобы устранить эту проблему, примените к нему критическое исправление по запросу .

3034679 Исправление: группы доступности AlwaysOn могут отображаться как не СИНХРОНИЗИРУЕМЫЕВажно! Вы должны применить это исправление для наложенного платежа вместо следующих накопительных обновлений:

• Накопительный пакет обновления 5 для SQL Server 2014

• Накопительное обновление 4 для SQL Server 2012 с пакетом обновления 2

• Накопительное обновление 3 для SQL Server 2012 с пакетом обновления 2

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

Обходное решение

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

1. Попробуйте выполнить указанные ниже действия в указанном порядке.

   Способ 1: Устранение доступа к базе данныхЕсли в базе данных возникают проблемы, упомянутые в разделе "симптомы", выполните одно или оба указанных ниже действия, чтобы устранить ситуацию блокировки.

   • Запрос sys.dm_exec_requests для обнаружения сеансов, в которых блокировка блокировки выполняется в базах данных доступности. Чтобы завершить сеансы, используйте инструкцию Kill .

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

   Если способ 1 не решает проблему, перейдите к способу 2.

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

   1. Отключите автоматический переход на другой ресурс группы доступности.

   2. Перезапустите затронутый экземпляр SQL Server, на котором размещается первичная реплика.

   3. Включите автоматический переход на другой ресурс группы доступности.

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

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".

Ссылки

Дополнительные сведения о накопительных обновлениях, которые подвержены этой проблеме, можно найти в следующих статьях базы знаний Майкрософт:

• Накопительный пакет обновления 5 для SQL Server 2014

• Накопительное обновление 4 для SQL Server 2012 с пакетом обновления 2 (SP2)

• Накопительный пакет обновления 3 для SQL Server 2012 с пакетом обновления 2 (SP2)