Великий запит на видалення, здається, застиг

Ми виконували запит на видалення в базі даних з 1,8 млрд. Рядків. Це видалення видалило б 1,2 млрд. Рядків.

Заздалегідь ми розбили би цей запит на 100 м за один раз, але ми знаходимося в стані, коли він працює протягом 24 годин, а файл журналу - 2Tb, що, як видається, є максимально допустимим розміром для файлу журналу.

База даних знаходиться в простому режимі відновлення.

Чи зберігається цей запит? Або нам потрібно просто перезапустити SQL Server і подивитися, що відбувається? Чи буде база даних непридатною? Чи є щось, що ми можемо зробити, щоб знищити це якомога чисто?

Перш за все, перевірте журнал помилок SQL, щоб побачити, чи дійсно він відповідає максимальному розміру для журналу. Якщо так, то запит не сподівається на завершення, він, ймовірно, вже знаходиться в стані відката.

Навіть якщо він є, я завжди вважаю за краще вбивати павука вручну (використовувати sp_who2або sp_WhoIsActiveзнайти павука, а потім робити те kill 59чи інше). Ви також не можете перевірити стан відкату, якщо ви не зробите явний KILL, дивіться цю пов’язану тему .

Оскільки це видалення, а не оновлення чи вставка, можливо, вам пощастить і виявите, що воно негайно скачується назад. Якщо ні, то може зайняти стільки часу (або довше), як і раніше, щоб дійти до цієї точки.

Щоб побачити стан відкату, використовуйте

kill 59 with statusonly

На жаль, я виявив, що це часто не показує нічого корисного, лише "0% завершено". У такому випадку вам доведеться використовувати sp_who2та переглядати IO та процесор, щоб побачити, чи все ще щось робить.

Що стосується перезавантаження, це є серйозним ризиком. Якщо павук активно відкочується (зміниться процесор і IO), то перезапуск SQL буде повністю відключати базу даних в автономному режимі до повного завершення відкату (години та години). Але якщо CPU та IO не рухаються, то насправді це може бути зрозуміло відразу. У будь-якому випадку це ризик.

Один останній варіант, якщо справи особливо страшні: якщо у вас є резервна копія безпосередньо перед початком видалення (а інших оновлень не було) , то найшвидшим способом відновлення може бути просто скинути БД, перезапустити SQL та відновлення з резервного копіювання.

Якщо ви не можете скинути БД (або якщо ви вже перезапустили екземпляр, а файл помилок sql передбачає 24-годинний час відновлення), тоді вимкніть служби SQL, видаліть з диска файли MDF та LDF, запустіть SQL, скиньте базу даних (ghost) та відновлення з резервного копіювання.

Очевидно, ви б спробували лише це, якби це резервна база даних, з якою користувачі не взаємоділи.

НЕ РЕСТАРТАЙТЕ SQL Server. Це лише продовжить вашу агонію, оскільки відбудеться відновлення, яке призведе до відкоту або повторного завершення транзакцій, не завершених, включаючи видалення.

Вбивство сеансу, що виконує видалення, призведе до відкоту, який також займе багато часу.

Ви хочете переглянути наступний запит, щоб побачити стан операції:

SELECT des.session_id 
    , des.host_name
    , des.login_name
    , der.command
    , der.estimated_completion_time
    , der.blocking_session_id
    , der.last_wait_type
    , der.percent_complete
    , der.start_time
    , der.status
    , der.wait_resource
    , der.wait_type
    , der.wait_time
FROM sys.dm_exec_sessions des
    INNER JOIN sys.dm_exec_requests der ON des.session_id = der.session_id
WHERE des.session_id <> @@SPID
    AND des.is_user_process = 1
ORDER BY des.session_id;

percent_completeКолонка, і ті , які покладаються на нього, наприклад estimated_completion_time, заповнюються тільки для наступних операцій:

ALTER INDEX REORGANIZE
AUTO_SHRINK option with ALTER DATABASE
BACKUP DATABASE
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKTABLE
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
RECOVERY
RESTORE DATABASE
ROLLBACK
TDE ENCRYPTION

Таким чином, ви побачите, що цей стовпець має значення лише у тому випадку, якщо ви вже скасували операцію видалення, і вона відкочується назад, або якщо ви вже перезапустили SQL Server і він перебуває у відновленні.

Якщо blocking_session_idстовпець містить число, що вказує на те, що інший сеанс блокує операцію видалення. Якщо цей сеанс блокує операцію видалення з моменту її запуску, можливо, ви зможете скасувати операцію, не потребуючи відкату.