Como eles acham que há um problema de memória - o SQL Server usa toda a memória disponível, até a configuração máxima de memória (e até mais). Pessoas desconhecidas entram no Gerenciador de Tarefas, consulte o SQL Server usando muita memória e pensem: "Deve haver um vazamento de memória - vou parar e reiniciar o SQL Server e ver o que acontece." Com certeza, isso libera muita memória (porque o SQL Server não aloca tudo imediatamente por padrão), então eles pensam que corrigiram o bug. A próxima coisa que você sabe é que eles estão reiniciando o SQL Server semanalmente.
Porque eles acham que há um problema de CPU - as consultas usarão uma tonelada de recursos da CPU, especialmente no caso de problemas de detecção de parâmetros. Pessoas desconhecidas tentam se conectar ao SQL Server sem conhecer o DAC (Dedicated Admin Connection), não conseguem se conectar e ficam sem opções. Eles recomeçam porque os executivos estão atrás deles, querendo uma solução rápida.
Porque eles ouviram que isso corrige corrupção - quando as pessoas se deparam com um problema de corrupção, geralmente estão dispostas a tentar qualquer coisa para corrigi-lo.
Como eles querem que uma reversão termine - eles matam uma consulta, e ela permanece na reversão por um tempo porque eles não sabiam que a reversão de uma consulta é de thread único. Após minutos (ou horas) de espera, eles reiniciam o SQL Server, pensando que a reversão não será necessária quando o backup for iniciado novamente. Infelizmente, eles estão errados, e o SQL Server continua com a reversão na inicialização.