Início / dba / Perguntas / 335310
Accepted
J. Mini
Asked: 2024-01-30 14:02:54 +0800 CST

Quando devo inspecionar o log de erros?

  • 772

Tive uma carreira variada, mas nunca encontrei informações relevantes no log de erros do SQL Server. Em que circunstâncias devo considerar inspecioná-lo?

sql-server

4 respostas

  1. Best Answer

    Tive uma carreira variada, mas nunca encontrei informações relevantes no log de erros do SQL Server.

    Estou feliz que você tenha se divertido com o SQL Server :)

    Em que circunstâncias devo considerar inspecioná-lo?

    Uma lista extremamente abreviada seria:

    • Todos os dias, porque quem sabe o que está acontecendo.
    • Quando surge qualquer tipo de problema, isso é mais do que questões de consulta superficiais.
    • Quando você quer aprender como as coisas funcionam.
    • Quando você está procurando novos recursos/funcionalidades/mudanças.

    Eu, literalmente, solucionei os piores problemas do SQL Server e sem o log de erros você está voando às cegas. Na grande maioria dos casos, é simplesmente impossível solucionar problemas sem ele.

    Isso não quer dizer que o log de erros seja tudo que você precisa. Os itens principais básicos que sempre devem ser capturados ou verificados se houver problemas ou para a integridade e bem-estar geral da instância são o log de erros, o log de eventos do Windows para sistema e aplicativo e o log de cluster, se estiver usando cluster.

    • 6

  2. Aqui estão mais três casos, além da lista de Sean:

    1. Quando a instância não inicia corretamente (como observou vonPryz).
    2. Na mesma linha, quando um banco de dados não volta a ficar online.
    3. Quando um usuário encontra falhas de login. Por motivos de segurança, apenas uma mensagem de erro genérica é mostrada ao usuário final. Os detalhes da solução de problemas que descrevem o problema real são armazenados no log de erros SQL.
    • 3

  3. Bem, droga. Parece que eu deveria verificar isso com mais frequência. Normalmente, ele é inundado com informações que me dizem que meus backups de log estão funcionando bem.

    Se você deseja uma ferramenta gratuita que restrinja o escopo dos resultados do log de erros para aqueles que não são inúteis, você pode tentar meu sp_LogHunter .

    A ideia por trás disso é retornar apenas entradas de log de erros de importância crítica, sem todas as bobagens e bobagens.

    • 2

  4. Algumas pequenas adições às boas respostas de Sean Gallardy e JD :

    1. Usei o log de erros SQL para solucionar problemas com conexões criptografadas. Nos primeiros dez ou vinte segundos após a inicialização, o SQL informará sobre o certificado que está usando. Por exemplo:

    O certificado [Cert Hash(sha1) "B91B739DBF6780EA40F45C8ED9D8F0D2AEBC1EDD"] foi carregado com sucesso para criptografia.

    Ou se estiver usando um certificado autoassinado:

    Um certificado gerado automaticamente foi carregado com êxito para criptografia.

    E se não conseguir carregar o certificado designado, ficará assim:

    A inicialização do TDSSNIClient falhou com erro 0xd, código de status 0x38. Motivo: Ocorreu um erro ao obter ou usar o certificado SSL. Verifique as configurações no Configuration Manager. Os dados são inválidos.

    1. Pode ser uma maneira prática de confirmar em qual porta o SQL está escutando. Você verá algo assim nos primeiros dez ou vinte segundos:

    O servidor está escutando em ['qualquer' 50481].

    1. Ele pode informar se o registro do SPN foi bem-sucedido ou não:

    A biblioteca da interface de rede do SQL Server registrou com êxito o nome principal do serviço (SPN) [ MSSQLSvc/myserver.domain.local:50481 ] para o serviço SQL Server.

    • 1

relate perguntas