Процесс/SPID блокируется сам по себе, как очистить/убить без перезагрузки сервера Sql

Question

У нас есть процесс, который работал в течение 4 часов. Поскольку он работал так долго, это вызывало другие проблемы в базе данных, поэтому было решено убить процесс.

Теперь процесс находится в состоянии ожидания. В нем также указано, что он блокируется сам по себе после запроса sp_who2.

В мониторе активности, здесь информация waitresource:

objectlock lockPartition=0 objid=xxx subresource=FULL dbid=2 id=lockyyyy mode=X associatedObjectid=xxx

Вы заметите, что ObjId и associatedObjectId имеют одинаковое значение.

Выполнение запроса в таблице sys.objects не отображает результаты для этого идентификатора объекта.

Является ли Sql Server ожиданием блокировки объекта, который больше не существует? Как я могу избавиться от этого процесса без перезагрузки Sql Server? (наши администраторы баз данных не отвечают на запросы помощи).

Имейте в виду, что это тестовая среда, но она останавливает все разработки/тестирование, потому что мы не можем развернуть какие-либо изменения в нашей базе данных, поскольку одно из этих изменений влияет на один из объектов, к которым обращался процесс ,

Edit: подробнее от активности монитора: Command = 'УБИЛ/ROLLBACK' ЗАДАЧА ГОСУДАРСТВА = 'SUSPENDED'

Answer 1

Ну, это, кажется, блокировка из-за параллельной обработки данных TempDb внутри.

Вы можете попробовать kill [processid], если у вас есть все права на?

Другой способ, чтобы получить более подробную информацию о процессе с этим:

SELECT * FROM sys.sysprocesses WHERE spid = YOURSPID 

Как процесс работает в БД: 2 попробуйте следующее:

SELECT * FROM tempdb.sys.all_objects WHERE object_id = OBJECTID 

Как я видел, как вы отредактировали ваш вопрос. Если Spid находится в KILLED/ROLLBACK, вам нужно подождать, пока ваша транзакция откатится. После этого процесс будет убит и удален. Вы не можете ничего сделать, поскольку необходимо обеспечить безопасность транзакции.

Answer 2

Я испытал это временами. Когда вы удаляете большой оператор INSERT/UDPATE/DELETE, это может занять несколько часов, чтобы восстановить (если он когда-либо восстановится) из этого состояния.

run kill < spid> with statusonly.

Это даст вам процент и расчетное время ожидания процесса ROLLBACK.

Иногда он говорит 0% или 100% и 0 расчетное время. Если вы терпеливы, он может в конечном итоге восстановиться. Если вы перезапустите сервер, процесс отката будет завершен в автономном режиме, и в базе данных будет отображаться состояние IN RECOVERY и, как правило, будет быстрее, чем ждать, пока сервер не восстановится.

Помните, что пользователи не смогут использовать базу данных до тех пор, пока процесс восстановления не завершится, но если SPID в состоянии KILLED/ROLLBACK блокирует другой процесс, возможно, это вариант перезагрузки.