Симптоми
Да предположим, че имате инсталиран Microsoft SQL Server 2014, 2016 или 2017. Можете да се сблъскате с един или повече от следните проблеми:
-
Екземплярът на SQL Server изглежда неотговарящ и възниква грешка "негенериращ Планировчик". Може да се наложи да рестартирате сървъра, за да го възстановите.
-
Възстановяването на една транзакция може да отнеме много време. В повечето случаи рестартирането на екземпляра ще позволява на базата данни да се възстанови много по-бързо от възстановяването. Имайте предвид, че има много причини, поради които може да отнеме доста време, за да се изпълни, вижте раздела "повече информация" по-долу за подробни данни за следенето на възстановяването преди опит за рестартиране.
-
Можете да видите висока очаква на spinlocks, като например SOS_OBJECT_STORE.
Решение
Този проблем е коригиран в следните сборни актуализации за SQL Server:
Всяка нова сборна актуализация за SQL Server съдържа всички поправки и всички корекции на защитата, които са били включени в предишната сборна актуализация. Вижте последните сборни актуализации за SQL Server:
Най-новата сборна актуализация за SQL Server 2017
Информация за сервизния пакет за SQL Server
Тази актуализация е коригирана в следния сервизен пакет за SQL Server:
Сервизните пакети са кумулативни. Всеки нов сервизен пакет съдържа всички корекции, които са в предишните сервизни пакети, както и всички нови корекции. Нашата препоръка е да приложите последния сервизен пакет и най-новата сборна актуализация за този сервизен пакет. Не е необходимо да инсталирате предишен сервизен пакет, преди да инсталирате най-новия сервизен пакет. Използвайте таблица 1 в следващата статия, за да намерите повече информация за последния сервизен пакет и най-новата сборна актуализация.
Как се определя нивото на версиите, изданието и актуализирането на SQL Server и неговите компоненти
Повече информация
Има много причини, поради които възстановяването може да отнеме много време, като например продължителна транзакция, голям брой VLFs в регистрационния файл на транзакциите, Slow I/O и т. н. За да се уверите, че проблемът, описан в тази статия, е основната причина за забавяне на възстановяването, ние предлагаме следните техники да се използват за наблюдение на хода на операцията по възстановяване:
-
От sys.dm_exec_requestsОпределете session_id, чиято команда е зададена като "УБИТ/анулиран", и се уверете, че Сеансът събира време IO и CPU, което показва напредъка. Ако IO не се променя, то може да е индикация, че се натъквате на проблема, описан в тази статия.
-
Заявка sys.dm_tran_database_transactions , за да идентифицирате текущото състояние на възстановяването чрез заявка по следния начин:
Изберете getdate () като 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 t
Присъединяване към sys.dm_exec_requests s НА t.transaction_id = s.transaction_id
КЪДЕТО 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.
Целта е да направите няколко снимки на предишната заявка в определен интервал и след това да използвате делтата на LSNs, обработено в database_transaction_next_undo_lsn в рамките на този интервал, и да екстраполирате времето, което е необходимо, за да оцените времето, което ще отнеме database_transaction_next_undo_lsn за достигане до database_transaction_begin_lsn.
Ако намалението на състоянието напредва с прилична ставка между всяка снимка, ви предлагаме да се разреши да завърши самостоятелно, без да се рестартира екземплярът на SQL Server.
Вижте следните статии за повече информация за продължителното възстановяване:
-
Запознаване с производителността на възстановяване в SQL Server
-
SQL Server (2000, 2005, 2008): възстановяване/анулиране на връщане по-дълго време от очакваното
-
Как структурата на лог файла може да засегне времето за възстановяване на база данни
-
Проследяване на напредъка в възстановяване на база данни чрез информация от DMV
Състоянието
Microsoft потвърди, че това е проблем в продуктите на Microsoft, които са посочени в секцията "важи за".
Препратки
Научете повече за терминологията, която Microsoft използва, за да опише софтуерни актуализации.
