KB4338890 – КОРЕКЦИЯ: Грешка "Non-yielding Scheduler" и SQL Server изглежда не отговаря през SQL Server 2014, 2016 и 2017

Отнася се за
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Симптоми

Да предположим, че имате инсталиран Microsoft SQL Server 2014, 2016 или 2017.  Може да изпитате един или няколко от следните проблеми:

  • Екземплярът на SQL Server изглежда не отговаря и възниква грешка "Non-yielding Scheduler". Може да се наложи да рестартирате сървъра, за да се възстановите.
  • Връщането към стабилно състояние на транзакция може да отнеме много време. В повечето случаи рестартирането на екземпляра ще позволи на базата данни да се възстанови по-бързо от връщането към стабилно състояние. Имайте предвид, че има много причини, поради които връщането към стабилно състояние може да отнеме много време, вижте раздела "Повече информация" по-долу за подробности относно наблюдението на връщания към стабилно състояние преди опит за рестартиране.
  • Може да видите голямо изчакване на спинлопове, като например SOS_OBJECT_STORE.

Решение

Този проблем е решен в следните кумулативни актуализации за SQL Server:

Сборна актуализация 9 за SQL Server 2017

Сборна актуализация 2 за SQL Server 2016 SP2

За кумулативните актуализации за SQL Server:

Всяка нова кумулативна актуализация за SQL Server съдържа всички актуални поправки и корекции на защитата, които са били включени в предишната кумулативна актуализация. Прегледайте последните кумулативни актуализации за SQL Server:

Последна сборна актуализация за SQL Server 2017

Последна сборна актуализация за SQL Server 2016

Последна сборна актуализация за SQL Server 2014

Информация за сервизен пакет за SQL Server

Тази актуализация е коригирана в следния сервизен пакет за SQL Server:

Service Pack 3 за SQL Server 2014

За сервизните пакети за SQL Server:

Сервизните пакети са кумулативни. Всеки нов сервизен пакет съдържа всички корекции, които са в предишните сервизни пакети, заедно с всички нови корекции. Нашата препоръка е да се приложи най-новият сервизен пакет и най-новата кумулативна актуализация за този сервизен пакет. Не е необходимо да инсталирате предишен сервизен пакет, преди да инсталирате най-новия сервизен пакет. Използвайте таблица 1 в следващата статия, за да намерите повече информация относно най-новия сервизен пакет и най-новата кумулативна актуализация.

Как да определите версията, изданието и нивото на актуализация на SQL Server и неговите компоненти

Повече информация

Има много причини, поради които връщането към стабилно състояние може да отнеме много време, като дългосрочна транзакция, голям брой VLF в регистрационния файл на транзакциите, бавен I/O и т.н. За да се провери, че проблемът, описан в тази статия, е основната причина за бавното връщане в предишно стабилно състояние, предлагаме да използвате следните техники за наблюдение на напредъка на операцията по връщане в предишно стабилно състояние:

  • От sys.dm_exec_requests идентифицирайте session_id, чиято команда е зададена на "KILLED/ROLLBACK", и се уверете, че сесията натрупва както IO, така и CPU време, което показва напредъка. Ако IO не се променя, това може да е индикация, че сте се натъкнали на проблема, описан в тази статия.
  • Заявка sys.dm_tran_database_transactions за идентифициране на текущото състояние на връщането към стабилно състояние с помощта на заявка като следната:

Забележка

  • SELECT getdate() as CurrentTime, database_transaction_next_undo_lsn,database_transaction_begin_lsn,t.transaction_id,database_transaction_begin_time,database_transaction_log_record_count,db_name(t.database_id)
  • ОТ sys.dm_tran_database_transactions т
  • ПРИСЪЕДИНЯВАНЕ КЪМ sys.dm_exec_requests
       НА t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Име на базата данни') и s.session_id=<Session_id извършване на операцията> за връщане към стабилно състояние

Бележка:

В горната заявка

database_transaction_next_undo_lsn е LSN на следващия запис, който трябва да се отмени. database_transaction_begin_lsn е LSN на началния запис за транзакцията в регистрационния файл на транзакциите.

database_transaction_next_undo_lsn би трябвало да намалява с всяка снимка на тази заявка. Връщането към стабилно състояние ще завърши успешно, когато database_transaction_next_undo_lsn достигне database_transaction_begin_lsn.

Целта тук е да направите няколко снимки на предишната заявка в рамките на предварително определен интервал и след това да използвате делтата на LSN, обработени в database_transaction_next_undo_lsn в рамките на този интервал, и да екстраполирате времето, което ще е необходимо, за да се прецени времето, което ще е необходимо, за да database_transaction_next_undo_lsn достигне database_transaction_begin_lsn.

Ако връщането към стабилно състояние напредва с прилична скорост между всяка снимка, предлагаме да се остави връщането да завърши само, без да се рестартира екземплярът на SQL Server.

Вижте следните статии за повече информация относно продължителното възстановяване:

Състояние

Microsoft потвърждава, че това е проблем в продуктите на Microsoft, които са изброени в раздела „Важи за“.

Справки

Научете повече относно терминологията, която Microsoft използва за описване на актуализациите на софтуера.