Недавно у нас было задание SQL по вставке в базу данных. Запрос выполнялся в течение нескольких дней без необходимости, поэтому он был отключен с помощью KILL SPID. Затем процесс начал откатываться на несколько дней и просто как будто завис.
При запуске KILL SPID WITH STATUSONLY появилось сообщение о том, что «Расчетное завершение» составляет 100%, а «Расчетное время осталось» - 0 секунд.
В конце концов нам пришлось перезапустить службу SQL, которая удалила процесс.
У меня вопрос: как убить процесс SQL? Это единственный способ?
Вы все сделали правильно, но вы учли стоимость отката. Вы сказали, что ваш запрос выполнялся в течение нескольких дней, поэтому он записал данные за несколько дней в файлы журнала как незавершенную транзакцию. Убив задачу, вы инициировали откат, и это то, чего вам нужно ждать.
Если вы хотите иметь возможность уничтожить транзакцию с меньшим воздействием, подумайте о пакетной обработке транзакций и периодических фиксациях. Если вы можете вообще избежать транзакции, это будет лучше для длительных заданий.
Я видел "зависание" отката, как вы описываете, и единственный способ избавиться от него - это перезапустить службу SQL, как это сделали вы.
НО важно убедиться, что откат действительно завис, а не откат назад (как вы видели, WITH STATUSONLY не совсем надежен). Риск заключается в том, что если вы перезапустите службу SQL во время отката. все еще откатывается, то после перезапуска службы SQL база данных будет зависать в режиме «восстановления», пока не будет завершен откат.
Единственный другой способ, которым я мог сказать, - это обновить монитор активности SQL и посмотреть, увеличивается ли счетчик ЦП и / или ввода-вывода для SPID. Если это так, то откат все еще продолжается, и вам пока не следует перезапускать SQL. Дайте ему больше времени.
Еще один балл: не поддавайтесь соблазну делать сумасшедшие вещи, например, удалять файл журнала. Это «остановит» откат транзакции, но за счет целостности вашей базы данных. Единственный другой метод, который я использовал (предполагая, что откат транзакции - это только важное изменение в базе данных с момента последней резервной копии) заключается в простом восстановлении из последней резервной копии, что, как мы определили, будет быстрее и проще, чем ожидание дополнительного дня для отката. Это, конечно, сильно зависит от характера вашей активности в базе данных.