Ознаки
Припустимо, що у вас інстальовано Microsoft SQL Server 2014, 2016 або 2017. У вас може виникнути одна або кілька з наведених нижче проблем.
-
Екземпляр SQL Server не відповідає і з'являється повідомлення про помилку "Непоступаючись планувальник". Можливо, доведеться перезапустити сервер, щоб відновити його.
-
Відкочування транзакції може тривати багато часу. У більшості випадків перезапустити екземпляр дасть змогу відновити базу даних значно швидше, ніж відкочування. Зверніть увагу, що за допомогою відкочування може знадобитися багато часу, у розділі "Додаткові відомості" нижче наведено докладні відомості про відстеження відколів перед спробою перезавантаження.
-
Ви можете побачити високе очікування на спінлоки, наприклад SOS_OBJECT_STORE.
Спосіб вирішення
Ця проблема усунена в таких сукупних оновлень для SQL Server:
Кожне нове Сукупне оновлення для SQL Server містить усі поточні виправлення та всі виправлення системи безпеки, які були включені до попереднього сукупного оновлення. Ознайомтеся з найновішими сукупними оновленнями для сервера SQL Server:
Найновіше Сукупне оновлення для SQL Server 2017
Відомості про пакет оновлень для сервера SQL Server
Це оновлення вирішено в такому пакеті оновлень для SQL Server:
Пакети оновлень є сукупними. Кожен новий пакет оновлень містить усі виправлення, які містяться в попередніх пакетах оновлень, а також будь-які нові виправлення. Наша рекомендація – це використання найновішого пакета оновлень і найновішого сукупного оновлення для цього пакета оновлень. Не потрібно інсталювати попередній пакет оновлень, перш ніж інсталювати найновіший пакет оновлень. У цій статті описано, як знайти докладні відомості про найновіший пакет оновлень і найновіше накопичувальне оновлення, використовуючи таблицю 1.
Визначення рівня версії, випуску та оновлення для сервера SQL Server і її компонентів
Додаткові відомості
Існує багато причин, через які відкочування може тривати довгий час, наприклад тривалої транзакції, велику кількість VFS у файлі журналу транзакцій, повільний I/O тощо. Щоб переконатися в тому, що проблема, описана в цій статті, – це основна причина повільного відкочування, радимо використовувати наведені нижче методи для відстеження виконання операції відкочування.
-
У sys.dm_exec_requestsвизначте session_id, за допомогою якого команда має значення "вбитий/відкат", і переконайтеся, що сеанс накопичують час і час, що вказує на перебіг виконання. Якщо IO не змінюється, це може бути свідченням того, що ви зустрічаючи цю проблему, описаної в цій статті.
-
Sys.dm_tran_database_transactions запиту, щоб визначити поточний стан відкочування, використовуючи запит, наприклад нижче:
Виберіть елемент getdate () як Currentime, 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 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.
У цій статті наведено кілька знімків попереднього запиту в межах певного інтервалу, а потім за допомогою дельти, що обробляються в 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, перелічених у розділі "застосовується до".
Посилання
Відомості про термінологію, яку корпорація Майкрософт використовує для опису оновлень програмного забезпечення.
