A consulta de exclusão grande parece ter congelado

Executamos uma consulta de exclusão em um banco de dados com 1,8 bilhões de linhas. Essa exclusão excluiria 1,2 bilhão de linhas.

Em retrospectiva, teríamos dividido essa consulta em 100m por vez, mas estamos em uma posição em que ela está sendo executada por 24 horas e o arquivo de log está em 2Tb, que parece ser o tamanho máximo permitido para um arquivo de log.

O banco de dados está no modo de recuperação SIMPLES.

Existe alguma salvando esta consulta? Ou precisamos apenas reiniciar o SQL Server e ver o que acontece? O banco de dados será inutilizável? Existe algo que possamos fazer para acabar com isso da maneira mais limpa possível?

Primeiro, verifique o log de erros do SQL para ver se ele realmente atingiu o tamanho máximo do log. Caso isso aconteça, a consulta não tem nenhuma esperança de concluir, provavelmente já está em um estado de reversão.

Mesmo que seja, eu sempre prefiro matar o spid manualmente (use sp_who2ou sp_WhoIsActivepara encontrar o spid, faça um kill 59ou o que for). Você também não pode verificar o status de reversão, a menos que faça um KILL explícito, consulte este tópico relacionado .

Como se trata de uma exclusão e não de uma atualização ou inserção, você pode ter muita sorte e descobrir que ela reverte imediatamente. Caso contrário, pode demorar tanto (ou mais) para retroceder quanto para chegar a esse ponto.

Para ver o status da reversão, use

kill 59 with statusonly

Infelizmente, descobri que isso frequentemente não mostra nada de útil, apenas um "0% concluído". Nesse caso, você precisará usar sp_who2e assistir o IO e a CPU para ver se ainda está fazendo alguma coisa.

Em relação à reinicialização, esse é um risco grave. Se o spid estiver revertendo ativamente (CPU e IO estão mudando), a reinicialização do SQL deixará o banco de dados offline apenas até que a reversão esteja completamente concluída (horas e horas). Mas , se a CPU e o IO não estiverem se movendo, é possível limpá-lo imediatamente. De qualquer maneira, é um risco.

Uma opção final, se as coisas forem especialmente ruins: se você tiver um backup imediatamente antes do início da exclusão (e não houve outras atualizações no banco de dados) , a maneira mais rápida de recuperar pode ser simplesmente descartar o banco de dados, reiniciar SQL e restauração do backup.

Se você não conseguir eliminar o banco de dados (ou se você já reiniciou a instância e o sql errorlog está prevendo um tempo de recuperação de 24 horas), encerre os serviços SQL, exclua os arquivos MDF e LDF do disco, inicie o SQL, solte o banco de dados (fantasma) e restaure a partir do backup.

Obviamente, você só tentaria se esse fosse um banco de dados de processamento de back-end com o qual os usuários não interagissem.

NÃO REINICIE O SERVIDOR SQL. Isso prolongará sua agonia apenas uma vez que a recuperação ocorrerá, o que reverterá ou refará todas as transações não concluídas, incluindo sua exclusão.

A morte da sessão que está executando a exclusão resultará em uma reversão, o que também levará muito tempo para ser concluído.

Você deseja examinar a seguinte consulta para ver o estado da operação:

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;

A percent_completecoluna e aqueles que dependem dela, como estimated_completion_time, são preenchidos apenas para as seguintes operações:

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

Portanto, você só verá essa coluna significativa se você já cancelou a instrução de exclusão e está revertendo ou se você já reiniciou o SQL Server e está em recuperação.

Se a blocking_session_idcoluna contiver um número, isso indica que outra sessão está bloqueando a operação de exclusão. Se essa sessão estiver bloqueando a operação de exclusão desde o início, você poderá cancelar a operação sem que ocorra qualquer reversão.