Після застосування SQL Server 2014 CU5, SQL Server 2012 SP2 CU4 або SQL Server 2012 SP2 CU3 може з'явитися повідомлення про те, що групи доступності НЕ СИНХРОНІЗУЮТЬСЯ.

Ознаки

Нижче описано такий сценарій.

• Комп'ютер працює під керуванням Microsoft SQL Server 2014 або Microsoft SQL Server 2012 із пакетом оновлень 2 (SP2) на сервері, де розміщено додаткову репліку групи доступності в рамках постійного оновлення.

• До інсталяції SQL Server застосовано одне з таких оновлень:

  • SQL ServerSQL Server 2014 Cumulative Update 5
  • SQL Server 2012 із пакетом оновлень 2 (сукупний пакет оновлень 4)
  • SQL ServerSQL Server 2012 із пакетом оновлень 2 (SP2), сукупний пакет оновлень 3

  Увага! Виправлення, згадане в цій статті, замінює ці сукупні оновлення. Не інсталюйте ці оновлення, якщо ви ще цього не зробили. 

• Щоб завершити інсталяцію сукупного пакета оновлень, перезавантажте цю додаткову репліку.

• Помилка групи доступності, яка переміщує оновлену додаткову репліку на основну.

У цьому сценарії може виникнути одна або кілька з наведених нижче проблем на сервері, на якому запущено SQL Server і на якому зараз розміщено основну репліку вашої групи доступності.

• Вторинні репліки відображаються як "НЕ СИНХРОНІЗУЮТЬСЯ".

• Запитуючи sys.dm_exec_requests, ви помічаєте періодичне блокування блокування між сеансами користувачів і сеансами, команда яких повідомляється як "DB_STARTUP". Ви також можете помітити блокування між командами CHECKPOINT і DB_STARTUP.

• Взаємоблокування, пов'язані із сеансом, для якого відновлено одну з ваших баз даних, відображаються в журналі помилок SQL Server. Ці журнали мають вигляд наступних:

  <дата/час> spid<xx> Recovery записує контрольну точку в базу даних <dbname/dbid>. Це
  Лише інформаційне повідомлення. Користувачам не потрібно виконувати жодних дій.
  <дата/час> spid<xx> Відновлення завершено для бази даних <dbname/dbid> за <x> секунд (аналіз)
  <x> ms, redo <x> ms, undo <x> ms.) Це лише інформаційне повідомлення. Користувачам не потрібно виконувати жодних дій.
  …
  <дата/час> spid<xx> Помилка: 1205, Важливість: 13, Стан: 28.
  <дата/час> spid<xx> Транзакцію (ідентифікатор <процесу: xx>) заблоковано через блокування ресурсів іншою
  і був обраний як жертва глухого кута. Повторно виконайте транзакцію.

• Якщо для Microsoft SQL Server Service Broker увімкнуто базу даних, повідомлення в ній можуть не оброблятися. Якщо ви запустите засіб трасування профілю та захопите подію "Broker:Message Classify", буде записано таку подію:

  9791, брокера відключено в базі даних відправника

Примітка: Це не системна проблема. Можливо, ви зможете застосувати ці сукупні оновлення до конфігурації AlwaysOn без цієї проблеми. Якщо ви вже застосовували ці сукупні оновлення та не помітили цієї проблеми, це означає, що це не вплине на вашу систему і ця інформація вас не стосується.

Причина

Ця проблема виникає тому, що між системними потоками та підключеннями користувача іноді виникає умова змагання. Це запобігає логіці виправлення сукупного пакета оновлень від отримання блокувань, необхідних для завершення процесу оновлення.

Спосіб усунення проблеми

Щоб вирішити цю проблему, застосуйте наведене нижче критичне виправлення на вимогу .

3034679 РІШЕННЯ. Групи доступності AlwaysOn можуть відображатися як такі, що НЕ СИНХРОНІЗУЮТЬСЯ
Увага! Застосовувати це виправлення COD потрібно замість наведених нижче сукупних оновлень:

• SQL ServerSQL Server 2014 Cumulative Update 5
• SQL Server 2012 із пакетом оновлень 2 (сукупний пакет оновлень 4)
• SQL ServerSQL Server 2012 із пакетом оновлень 2 (SP2), сукупний пакет оновлень 3

        
Примітка Якщо ви вже застосували ці сукупні оновлення, скористайтеся наведеним нижче обхідним шляхом, щоб вирішити цю проблему.

Спосіб вирішення

Оскільки ця проблема виникає через суперечки між сеансом користувача та сеансом оновлення щодо доступних баз даних, коли бази даних відіграють основну роль, необхідно усунути це твердження, щоб бази даних могли вийти зі цього стану.

Щоб вирішити цю проблему, виконайте наведені нижче дії.

1. Спробуйте наведені нижче методи в заданому порядку.

   Спосіб 1. Ліквідація доступу до бази данихКоли на базах даних виникають симптоми, згадані в розділі "Ознаки", за необхідності виконайте один або обидва з наведених нижче кроків, щоб усунути проблему блокування.

   • Запит sys.dm_exec_requests для пошуку сеансів, у яких у базах даних доступності відбувається блокування блокування. Щоб завершити ці сеанси, використовуйте інструкцію KILL.
   • Вимкніть або зупиніть програму, яка отримує доступ до баз даних доступності.

   Якщо проблема не вирішується, перейдіть до 2.

   Спосіб 2. Перезавантаження сервера SQL Server хостаЯкщо доступ програм і користувачів усе ще вимкнуто, перезавантажте екземпляр SQL Server, на якому розміщено відповідні бази даних доступності. Ось як це зробити:

   1. Вимкнути автоматичне відновлення після відмови в групі доступності.
   2. Перезавантажте уражений екземпляр SQL ServerSQL Server, у якому розміщено основну репліку.
   3. Увімкнення автоматичного перемикання після відмови групи доступності.

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

Стан

Корпорація Microsoft підтвердила, що це одна з проблем з продуктами Microsoft, перелічених у розділі "Застосовується до".

Посилання

Додаткові відомості про сукупний пакет оновлень, на який впливає ця проблема, див. в таких статтях бази знань Microsoft:

• Сукупний пакет оновлень 5 для SQL ServerSQL Server 2014
• Сукупний пакет оновлень 4 для SQL ServerSQL Server 2012 SP2
• Сукупний пакет оновлень 3 для SQL ServerSQL Server 2012 SP2