ERRORLOG – O básico (Parte 1 de 3)

errorlog2222

Olá,

Estava planejando tem um tempão falar  sobre os recursos que o SQL Server oferece de graça para os usuários do produto (supondo que estejam utilizando a versão Enterprise e/ou que tenham permissão suficiente, é claro) e inevitavelmente me veio a forma mais básica de logging do SQL Server: ERRORLOG. Esse post é o primeiro de uma trilogia, onde vamos comentar o básico e o que realmente precisa ser entendido sobre o funcionamento do mesmo.

O que é?

O ERRORLOG é um dos logs utilizados do SQL Server que registra ocorrências de acordo com o que está configurando para a instância. Embora o nome possa sugerir, ele não loga apenas erros, mas também mensagens informativas.

Como ler?

Existem algumas formas de se realizar a leitura de um ERRORLOG:

  • Através da procedure não-documentada xp_readerrorlog (que é uma Extended Stored Procedure, cujo código está na xpstar.dll (que por sua vez chama outras bibliotecas, como a xplog70.dll).
Exemplo de uso da xp_readerrorlog

Exemplo de uso da xp_readerrorlog

 

  • Através da procedure não-documentada sp_readerrorlog (que chama a xp_readerrorlog por debaixo dos panos):
Exemplo de uso da sp_readerrorlog

Exemplo de uso da sp_readerrorlog

  • Via interface gráfica através do Management Studio:
Acesse a instância > Management > SQL Server Logs

Acesse a instância > Management > SQL Server Logs

Interface do Management Studio para os logs

Interface do Management Studio para os logs

O Log File Viewer faz interface com vários tipos de log do SQL Server. A realização de leitura do ERRORLOG é a opção “SQL Server”.

De todos os métodos citados acima, iremos focar apenas no sp_readerrorlog (que utiliza praticamente a mesma lógica do xp_readerrorlog, com mínimas diferenças).

O que é logado?

Para saber quais mensagens estão marcadas para serem logadas, execute a query a seguir:


select * from sys.messages where is_event_logged = 1
and language_id = 1033

Algumas das mensagens que são logadas no errorlog

Algumas das mensagens que são logadas no errorlog

No próximo post, algumas dicas em relação à sys.messages estarão presentes, e uma delas inclui escolher quais mensagens serão logadas ou não.

Estrutura lógica do ERRORLOG

O ERRORLOG possui três campos:

– LogDate: Data em que o evento foi logado (WHEN);
– ProcessInfo: O que foi logado (WHAT);
– Text: Descrição do evento logado (WHERE, WHO, WHAT (detalhes))

Um exemplo de interpretação:

Tentativa de invasão. Da minha máquina local. Ou seja, sem emoção.

Tentativa de invasão. Da minha máquina local. Ou seja, sem emoção.

No dia 15.10.2014, foi identificado um evento de logon que falhou. Alguém tentou acessar o servidor com um login chamado INVASAO e a pessoa não conseguiu logar porque não existe nenhuma conta (que é um SQL login) com esse nome para ele sequer tentar uma autenticação. A requisição partiu da máquina local.

Note que assim como manda o princípio de logging, existem alguns princípios presentes: Quando foi (When), O que foi (what) e quem foi (Who).

Lógica para geração

O arquivo mais atual se chama ERRORLOG. Toda vez que ocorre um restart¹ de serviço ou a procedure sp_cycle_errorlog é executada, um novo ERRORLOG é criado, e o anterior recebe um versionamento decadente. Por exemplo, o ERRORLOG depois de um cycle agora se chama ERRORLOG.1, o ERRORLOG.1 antigo agora passou a se chamar ERRORLOG.2 e por aí vai…

Caminho dos Errorlogs e exemplo de nomes

Caminho dos Errorlogs e exemplo de nomes

Por padrão, o diretório onde se localizam os LOGS depende do local de instalação do SQL Server. Em minha máquina, o caminho é:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log

Por padrão o SQL Server pode criar até seis (6) arquivos de errorlog mais o errorlog atual, totalizando em sete (e o limite pode ser aumentado).

Concorrência

O SQL Server sempre abrirá um handle no ERRORLOG atual para escrita e portanto, editá-lo enquanto o serviço do SQL Server está sendo executado não é possível. Ou seja, você pode abrir o errorlog atual apenas para leitura (no editor de sua preferência) mas não pode editar. O restante dos ERRORLOGS com exceção do atual, podem ser abertos para leitura e edição.

Objetos relacionados

Os objetos relativos ao ERRORLOG podem ser identificados com o uso da sys.all_objects:

Uma mistura de legado com o não documentado.

Uma mistura de legado com o não documentado.

DBCC ERRORLOG: Gera um novo arquivo de ERRORLOG executando um cycle, versionando os antigos de acordo com o limite de arquivos configurado. Requer permissão de sysadmin para executar. Não é documentada.

SP_CYCLE_ERRORLOG: Executa o DBCC ERRORLOG por debaixo dos panos. Essencialmente são idênticos. Mesmas considerações acima.

XP_ENUMERRORLOGS: Retorna um resumo com algumas informações sobre arquivos. Não é documentada.

– Archive# é o número do arquivo sendo 0 o atual (ERRORLOG) sem numeração.
– Date é a data da última modificação do arquivo (e não é necessariamente a data em que o último evento foi registrado, isso é tema para próximos post, caso se interesse).
– Log File Size (Byte): Tamanho em bytes que o arquivo em questão está ocupando em disco.

Requer permissão de securityadmin para execução.

Exemplo de saída do comando xp_enumerrorlogs

Exemplo de saída do comando xp_enumerrorlogs

SP_ENUMERRORLOGS: Executa o XP_ENUMERRORLOGS. Essencialmente são a mesma coisa. Mesmas considerações acima.

XP_READERROLOG: Basicamente², realiza a leitura de logs do SQL Server através de alguns parâmetros executando uma biblioteca chamada xpstar.dll.
Um exemplo simples de uso:

exec xp_readerrorlog 0,1,N'login'

Primeiro parâmetro: Número do log que será lido. 0 é o arquivo atual.
Segundo parâmetro: 1 é a identificação dos arquivos de log. Você pode ler outros logs se desejar. Por exemplo, 2 é a identificação dos logs do agent;
Terceiro parâmetro: filtro textual. Em nosso caso, vai retornar todas as linhas do arquivo lido que contenham a palavra login. Seu funcionamento é similar ao comando LIKE ‘%TermoDesejadoAqui%’.

É importante ressaltar que, pelo fato da xp_readerrorlog ser uma procedure extendida não-documentada, não é de conhecimento público todos os parâmetros possíveis de serem utilizados pela mesma. Até o momento, por exemplo, foi identificado que a procedure pode receber até sete (7) parâmetros diferentes.

Permissão para ser executada: sysadmin e securityadmin.

SP_READERRORLOG: Executa a xp_readerrorlog. Seriam essencialmente a mesma coisa se não fosse por um importante detalhe: a sp_readerrorlog realiza uma chamada na xp_readerrorlog com a passagem de parâmetros limitada.
Pela versão da sp, apenas quatro parâmetros são possíveis de serem passados (sendo essa a principal diferença entre ambas). Abaixo o código de chamada das procedures (comprovando a explicação dos parâmetros):

Agora dá pra ver fácilmente como funciona a chamada de uma, e a chamada de outra :)

Agora dá pra ver fácilmente como funciona a chamada de uma, e a chamada de outra🙂

O comando abaixo utiliza seis (6) parâmetros e funciona.

xp_readerrorlog 0,1,'login', NULL,'2014-10-10 12:00:00','2014-10-17 09:00:00'

Se você trocar xp por sp, uma exceção será lançada (justamente, por passar de quatro parâmetros possíveis). Outra característica importante entre a XP e SP: a entrada textual da versão SP é VARCHAR enquanto a versão XP é texto unicode.


Conclusão

O intuito do post foi explicar um pouco mais sobre o ERRORLOG. Os dois próximos do assunto abordarão dicas e boas práticas em relação ao ERRORLOG e um projeto que coloca em prática os outros dois posts.

Caso tenha alguma sugestão, crítica, dúvida ou qualquer outro comentário, fique à vontade para comentar.

[]’s


Observações

*¹ – Para efeitos práticos, quando falamos em serviços, restart = Stop + Start. Eu sei que parece óbvio, mas é bom evitar qualquer confusão.

*² – Na verdade essa procedure é tão mística que lê até logs que não são do SQL Server, mas esse assunto não será abordado aqui até pela falta de documentação.


Referências

Monitorando os logs de erro – http://msdn.microsoft.com/pt-br/library/ms191202(v=sql.100).aspx

6 pensamentos sobre “ERRORLOG – O básico (Parte 1 de 3)

  1. Outra coisa interessante no errorlog é a limitação do tamanho do arquivo para 99 em “Maximum Number of error log files”. Por quê se o arquivo de log crescer muito, não será possível abrir o arquivo ERRORLOG, nem pela procedure (sp_readerrorlog), nem diretamente o arquivo. O windows é enjoado quando se trata de arquivos grandes. =)

    • Fala Patrocínio,

      Muito boa a observação. Esse é um dos assuntos que reservei pro segundo post de boas práticas porque vai render muito.
      Sobre abrir o arquivo por fora, você pode fazer isso tranquilamente. O que manda neste caso é o programa que você utiliza (Ex: PilotEdit) e se o tamanho não é absurdo (o que também depende da máquina), rs.
      []’s

  2. Pingback: ERRORLOG – Dicas e casos (parte 2 de 3) | Blog - Renato Siqueira

  3. Pingback: ERRORLOG – Dicas e casos (parte 2 de 3) | Renato Siqueira

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s