KB3020116-FIX: помилка "непоступаючись планувальник" і "AlwaysOn", що проходить через транзити для РОЗВ'ЯЗАННЯ стану

Ознаки

Припустимо, що у вас є група "доступність AlwaysOn", яка розгортається на сервері S1 і на сервері S2 в Microsoft SQL Server 2014. У основній репліці (S1) Виявлено проблему зі здоров'ям, а Група доступності проходить перехід до стану РОЗВ'ЯЗАННЯ та починається після відмови, якщо його настроєно для автоматичного відновлення після відмови. Група доступність може залишатися в стані ВИРІШЕННЯ. Помилка, що не приносить планувальник, може з'явитися в журналі помилок у основній репліці (S1) або додатковій репліці (S2):

• Після цього в основній репліці не виникає помилка після того, як група "доступність" від ПЕРВИННОГО до ВИРІШЕННЯ:

  <дата> <час> spid<ID> за допомогою "dbghelp. dll" Version "4.0.5" <дата> <> SPID> <0 ID> за допомогою функції "Dbghelp. dll" у версії "4.0.5" <дата> <час> Server за допомогою ' dbghelp. файл dll "Version" 4.0.5 ' <Date> <Time> Server * * * не вдалося отримати потік контексту для SPID 0> <0 Дата > < час > Server * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * <Дата ID> < час > server * <Дата Time> < час > server * початок стека дамп: <Дата > < час > Server Дата > < час > Server * <Дата > < час > Server * непоступаючись планувальник> <0 Дата > < час > Server * <Дата > < час > Server * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *, <Дата > < час > сервера стека для звалища 0x0000000000000176> <2 Дата > < час очікування на сервері для зовнішнього дампу 982676 Date <дата> <час> сервера процес 0:0:0 (0x11428) працівник 0x00000075CB92C160, як видається, не поступаючись за розкладом 0. Час створення ланцюжка: 13011925023676. Для використання процесорів із процесором: ядра 0 MS, користувач 0 MS. Процес використання 2%. Система простоює 84%. Інтервал: 76880 мс.

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

  <дата> <час> spid<ID> база даних груп доступності "agname" – це змінення ролей від "розв'язання" до "основного", тому що під час синхронізації ролей не вдалося виконати синхронізацію або групу доступності. Це Інформаційне повідомлення. No user action is required....<Date> <Time> Server      Using 'dbghelp.dll' version '4.0.5'<Date> <Time> Server      ***Unable to get thread context for spid 0<Date> <Time> Server      * *******************************************************************************<Date> <Time> Server      *<Date> <Time> Server      * BEGIN STACK DUMP:<Date> <Time> Server      *   <Date> <Time> spid> <8 ID><Date> <Time> Server      * Private server build.<Date> <Time> Server      *<Date> <Time> Server      * Non-yielding Scheduler> <2 Date> <Time> Server      *<Date> <Time> Server      * *******************************************************************************<Date> <Time> Server      Stack Signature for the dump is 0x000000000000006D> <4 Date> <Time> Server      External dump process return code 0x20000001. Процес зовнішнього дампу не повернув помилок. <дата> <час> сервер процесу 0:0:0 (0x1e94) працівник 0x000000082F270160, як видається, не приносить на планувальник 0. Час створення ланцюжка: 13059453624681. Для використання процесорів із процесором: ядра 0 MS, користувач 0 MS. Процес використання 3%. Система простоює 84%. Інтервал: 70358 MS. <Date> <Time> Server процес 0:0:0 (0X998) працівник 0x00000000B3F86160, як видається, не поступаючись за планувальник 2. Час створення ланцюжка: 13059458965740. Для використання процесорів із процесором: ядра 0 MS, користувач 0 MS. Процес використання 3%. Система простоює 83%. Інтервал: 76913 мс.Дата> <час> Server process 0:0:0 (0x1a64) працівник 0x0000000B5E220160, як видається, не поступаючись в планувальник 3. Час створення ланцюжка: 13059466511951. Для використання процесорів із процесором: ядра 0 MS, користувач 0 MS. Процес використання 3%. Система простоює 83%. Інтервал: 76944 мс.

Примітка. Ця проблема також виникає в SQL Server 2012.

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

Після інсталяції цього виправлення можна уникнути неоплачуваного стану планувальника. Ця проблема була спочатку зафіксоване в цьому сукупному оновленні сервера SQL Server.

Стан

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