Eu vi um rollback "travar" como você descreve, e a única maneira de se livrar dele é reiniciar o serviço SQL, como você fez.
MAS é importante certificar-se de que o retrocesso esteja realmente travado, e não rolando de volta (como você viu, o WITH STATUSONLY não é totalmente confiável). O risco é que, se você reiniciar o serviço SQL enquanto a reversão ainda estiver rolando de volta , o banco de dados ficará preso no modo "recuperação" após a reinicialização do serviço SQL, até que a reversão seja concluída.
A única outra maneira que eu consegui dizer é usando o SQL Activity Monitor, e verificando se a contagem de CPU e / ou IO para o SPID ainda está avançando. Se estiver, a reversão ainda está em andamento e você não deve reiniciar o SQL ainda. Dê mais tempo.
Um ponto adicional : não fique tentado a fazer coisas malucas, como excluir o arquivo de log. Isso irá "parar" a reversão da transação, mas ao custo da integridade de seu banco de dados. A única outra técnica que usei (assumindo que a transação revertida é a única alteração importante do banco de dados desde o último backup) é simplesmente restaurar a partir do backup mais recente, que determinamos que seria mais rápido e mais fácil do que esperar um dia adicional para que uma reversão ocorra. Isso, é claro, depende muito da natureza da sua atividade de banco de dados.