Проблема
Предположим, что у вас установлена microsoft SQL Server 2014, 2016 или 2017. У вас может возникнуть одна или несколько из следующих проблем:
- Экземпляр SQL Server не отвечает и возникает ошибка "Планировщик не возвращается". Для восстановления может потребоваться перезапустить сервер.
- Откат транзакции может занять много времени. В большинстве случаев перезапуск экземпляра позволяет восстановить базу данных гораздо быстрее, чем откат. Обратите внимание, что есть множество причин, по которым откат может занять много времени. Дополнительные сведения см. ниже, чтобы получить подробные сведения о мониторинге откатов перед попыткой перезапуска.
- В таких спин-блокировках, как SOS_OBJECT_STORE, может наблюдаться большое ожидание.
Решение
Эта проблема устранена в следующих накопительных обновлениях для SQL Server:
Накопительный пакет обновления 9 для SQL Server 2017 г.
Накопительный пакет обновления 2 для SQL Server 2016 с пакетом обновления 2 (SP2)
Сведения о накопительных обновлениях для SQL Server:
Каждое новое накопительное обновление для SQL Server содержит все исправления и все исправления для системы безопасности, которые были включены в предыдущее накопительное обновление. Ознакомьтесь с последними накопительными обновлениями для SQL Server:
Последнее накопительное обновление для SQL Server 2017 г.
Последнее накопительное обновление для SQL Server 2016 г.
Последнее накопительное обновление для SQL Server 2014 г.
Сведения о пакете обновления для SQL Server
Это обновление исправлено в следующем пакете обновления для SQL Server:
Пакет обновления 3 (SP3) для SQL Server 2014
Сведения о пакетах обновления для SQL Server:
Пакеты обновления являются накопительными. Каждый новый пакет обновления содержит все исправления, которые были в предыдущих пакетах обновления, а также все новые исправления. Мы рекомендуем применить последний пакет обновления и последнее накопительное обновление для этого пакета обновления. Вам не нужно устанавливать предыдущий пакет обновления перед установкой последнего пакета обновления. Дополнительные сведения о последнем пакете обновления и последнем накопительном обновлении см. в таблице 1 в следующей статье.
Определение версии, выпуска и уровня обновления SQL Server и его компонентов
Существует множество причин, по которым откат может занять много времени, например длительная транзакция, большое количество VLF в файле журнала транзакций, медленный ввод-вывод и т. д. Чтобы убедиться, что проблема, описанная в этой статье, является первопричиной медленного отката, мы рекомендуем использовать следующие методы для отслеживания хода выполнения операции отката:
- На sys.dm_exec_requests определите session_id, команда которого имеет значение KILLED/ROLLBACK, и убедитесь, что сеанс накапливает время ввода-вывода и ЦП, указывающее на ход выполнения. Если операции ввода-вывода не изменяются, это может свидетельствовать о том, что вы столкнулись с проблемой, описанной в этой статье.
- Запрос sys.dm_tran_database_transactions определить текущее состояние отката с помощью следующего запроса:
Примечание
- SELECT 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)
- FROM sys.dm_tran_database_transactions t
- JOIN sys.dm_exec_requests s
ON 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 должны уменьшаться с каждым snapshot этого запроса. Откат завершится успешно, когда database_transaction_next_undo_lsn достигнет database_transaction_begin_lsn.
Цель здесь заключается в том, чтобы сделать несколько моментальных снимков предыдущего запроса в течение предопределенного интервала, а затем использовать разностность LSN, обработанных в database_transaction_next_undo_lsn в течение этого интервала, и экстраполировать время, затраченное на то, чтобы оценить время , которое потребуется database_transaction_next_undo_lsn для достижения database_transaction_begin_lsn.
Если откат выполняется с достойной скоростью между каждой snapshot, мы рекомендуем разрешить откат самостоятельно без перезапуска экземпляра SQL Server.
Дополнительные сведения о длительном восстановлении см. в следующих статьях:
- Общие сведения о производительности восстановления в SQL Server
- SQL Server (2000, 2005, 2008): восстановление и откат занимает больше времени, чем ожидалось
- Как структура файла журнала может повлиять на время восстановления базы данных
- Отслеживание хода восстановления базы данных с помощью сведений из динамического административного административного представления
Состояние
Корпорация Майкрософт подтвердила, что это проблема продуктов Microsoft, перечисленных в разделе «Относится к».
Ссылки
Узнайте о терминологии, используемой корпорацией Майкрософт для описания обновлений программного обеспечения.