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).

 

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

• 

Via interface gráfica através do Management Studio:

Acesse a instância -> Management -> SQL Server 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

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:

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…

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 FilesMicrosoft SQL ServerMSSQL10_50.MSSQLSERVERMSSQLLog

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:

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.

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):

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