O rollback do SQL Server ficou preso em 0% e não é possível matar o pid

Question

Recentemente, nossa empresa passou por um problema com nosso banco de dados do SQL Server, onde estávamos com carga alta e alguns scripts de monitoramento de banco de dados matavam várias conexões.

Quando isso aconteceu, algumas transações no processo falharam ao término da reversão.

Eles repetidamente disseram que a reversão estava 0% concluída ao executar kill no pid.

Após pesquisar on-line, descobrimos pessoas sugerindo a reinicialização do SQL Server. Isso não era desejável, pois este era um banco de dados de produção. Também estávamos preocupados com o fato de o restartinng poder corromper nosso banco de dados, forçando-nos a restaurar a partir de backups.

Eventualmente, reiniciámos o servidor e tudo começou bem sem as transações que estão sendo recuperadas.

Minha pergunta é:

É possível evitar que isso aconteça em primeiro lugar? Se não há alguma maneira de saber que é seguro reiniciar?

    

Answer 1

Primeiro para responder a sua pergunta final, você pode apresentar isso de novo, não, não realmente.

O que aconteceu é que, quando os processos foram eliminados, o SQL Server informa ao cliente que o processo foi eliminado. Em algumas circunstâncias, o SQL Server irá travar ao tentar dizer ao cliente que o processo foi morto. Normalmente, isso não é um problema, mas há algumas ocasiões em que isso causará esse problema.

Se você deixar os processos em execução, nada acontecerá, exceto o SPID. A reversão foi concluída de fato. A única maneira de limpar o SPID é reiniciar a instância do SQL. Há 0 chance de corrupção reiniciando sua Instância do SQL quando isso aconteceu.

    

Answer 2

Tudo o que posso dizer é para fazer as coisas básicas. Antes de mais nada, saiba a importância do script atualmente em execução no servidor. Scripts complicados que exigiriam muito consumo de memória e poderiam fazer o dataloss 'MUST' fazer o procedimento de backup antes de executar o script. Digamos que um script de mil linhas esteja agendado para execução autônoma. Os caras techy que desenvolveram o script devem ser aconselhados a incluir um backup diferencial automático em seus scripts para garantir que, se o script falhar, pelo menos um backup confiável seja garantido primeiro. p>

Se o script não tiver um procedimento de backup automatizado, bem, um técnico deve ser responsável por fazer o backup manualmente em um determinado horário agendado. A única coisa que precisa ser considerada é saber quando o script deve ser executado no servidor para que o dba também saiba quando iniciar o processo de backup manual. Uma razão pela qual o dba existe.