ERRORLOG – Parte 3: Na prática

Olá,

Esse é o último post da série ERRORLOG. Caso tenha interesse:

• Parte 1: O básico
• Parte 2: Dicas e Casos
• Parte 3: Na prática (você está aqui)

O assunto de hoje é relacionado à importância do ERRORLOG no dia a dia e a sugestão de soluções que façam proveito dele.

ERRORLOG na essência

Apesar da palavra ERROR compor o ERRORLOG, já vimos que este log do SQL Server não se limita apenas a registrar erros: registra eventos.

Dito isso, deixo aqui uma frase inteligente que catei no highscalability.com e que tem tudo a ver com o post:

• @rolandkuhn: «the event log is a database of the past, not just of the present» — @jboner at #reactconf

Em bom português: O log de eventos é um banco de dados do passado, não somente do presente. Em parábola: um log de eventos conta uma história do antes e do agora.

Alguns usam o ERRORLOG apenas para respostas pontuais (geralmente reativas), outros para verificação rotineira (pró-ativa), mas é fato de que uma hora ou outra, estes eventos se mostram de grande valor para agregar informações em nosso dia a dia, independente da abordagem que temos com estes arquivos.

Tendo dito que o ERRORLOG é um banco de dados da própria instância, concluo que:

• Se é um “banco de dados”, merece ser armazenado;
• Se é um “banco de dados”, merece ter informação extraída para agregar em análises;

Armazenamento de ERRORLOG

Acredite se quiser, mas caso você nunca tenha precisado do ERRORLOG e venha a precisar, é decepcionante digitar na unha um sp_readerrorlog e descobrir que os eventos que você queria ler já foram reciclados 🙂

Pior ainda: se numa crise brava, o ERRORLOG for sua única opção de evidência e por um motivo e outro os eventos deste se perderam…Não tem pior desculpa que: “não tem porque eu não guardei” quando alguém pergunta sobre esses eventos…

Embora o comportamento padrão do arquivo seja circular, não quer dizer que deva ficar assim. Pensar que aquelas informações podem em algum momento, trazer algum valor (ou resolver algum problema), é razão suficiente para gastar espaço em disco armazenando-os.

Faz sentido armazenar os eventos, seja realizando backup dos arquivos (via Filesystem) ou através de soluções customizadas (uma possível solução foi proposta no decorrer deste post usando T-SQL, mas podia ser via Powershell também…) de modo que se mantenha uma história do servidor e seus eventos em algum momento poderão ser úteis.

Caso não seja identificada a necessidade de armazenar essas informações, uma medida mínima para prevenir “perda de informações” (entre aspas) é de aumentar o limite de errorlogs para um número razoável, conforme citado na parte 2 da série, onde o limite máximo de arquivos (99) é uma sugestão, embora pareça exagero. A ideia aqui é perder o menor número de eventos possíveis antes que o (re)cycle leve informações embora. Como análises de eventos ocorrem em períodos próximos, pode ser que a simples solução de ter mais arquivos de log já ajude na localização de eventos mais recentes e previna alguma falta de informação caso algum evento antigo precise ser consultado.

Informação do ERRORLOG

É possível tirar alguma inteligência a partir de arquivos “brutos” de log? Tecnicamente, muitos olham o errorlog ou em casos pontuais na ocorrência de algum problema ou por possuir postura pró-ativa, mas em geral, quando se olha o errorlog, se busca uma resposta, se busca informação. Se é interessante extrair informação, principalmente de algo que vem de graça no SQL Server, dentre várias opções, não se pode ignorar os errorlogs.

Farei algumas perguntas bem despretensiosas, mas antes de ler, pense em qualquer ambiente que você tenha:

  •  Quantos KILL’s ocorrem por dia neste servidor?
  •  Quantas operações de logins com falhas, em média, ocorrem por dia? São do mesmo login?
  • Quais são os erros sérios que você descobriu quando um problema aconteceu e uma ou mais evidências estavam no ERRORLOG?

As perguntas possuem uma importância muito relativa: identificar quantidade de KILL’s em ambientes onde a prática é comum mesmo quando não deveria ser (até pelas próprias aplicações) não agrega tanto valor ter ciência desta informação, mas em uma ambiente de BI por exemplo onde o evento é mais raro, é uma informação que possui seu peso…

Quantidade de falhas de login é um número que flutua bastante, mas é interessante saber quais são os mais recorrentes e resolver na fonte o motivo do problema (Datasource com senha errada? Pela faixa de tempo é possuir concluir que seja a possível causa das requisições mal-sucedidas) até pra não sujar muito o errorlog com mensagens repetidas.

Eventos relevantes e/ou sérios: indisponibilidade, corrupções e falhas de backup, por exemplo, podem ser descobertos ou melhor investigados com o auxílio do ERRORLOG, e por isso, é interesante saber a quantidade e frequência que esses tipos de eventos (geralmente não desejados, acredito piamente, rs) acontecem, principalmente em servidores de produção.

Solução Universal para Armazenamento e Extração de Informações?

Sinceramente, não creio que exista algo assim. Cada ambiente possui uma particularidade e cada DBA também, então, pode ser que as informações do errorlog sejam lixo pra determinado ponto de vista pessoal, e luxo para outro, principalmente quando se trata de errorlogs pois não é um dos pontos de conversa mais populares e muito pouco se fala sobre (e isso foi um dos fortes motivos que me levou a escrever essa série de posts).

Mas, podemos elaborar algo que possa atender relativamente bem este propósito de  de coleta, armazenagem e extração de informação. Em determinado cenário X, identifiquei uma boa oportunidade de fazer as duas coisas ao mesmo tempo: armazenar as informações do ERRORLOG e extrair informação útil dele.

Aproveitei para formular uma solução e gostaria de apresentar aqui no blog.

Sugestão de Solução: ERRORLOG CAPTURE

Basicamente: realiza a leitura de todos os errorlog de determinada instância com o uso da xp_readerrorlog em determinado período do tempo e joga em um determinado repositório de eventos (que seria uma tabela no SQL Server, que servirá como armazenamento). A ideia aqui é coletar o que realmente for necessário e evitar informação redundante.

A segunda ideia por trás da solução é, através de uma identificação rústica de caracteres e de baixa performance (graças ao operador LIKE) e até por esse motivo trata-se de uma carga que deve ser feita em horários estratégicos, identificar padrões de mensagem e com base nesse padrão classificar determinados eventos. Ao longo do tempo, é necessário identificar eventos que não foram tratados e que não se encaixam em nenhuma categoria e organizá-los manualmente.

Um bom exemplo: Quando a mensagem de um determinado evento conter a entrada ”%LOGIN FAILED% tenho certeza de que posso enquadrar a mensagem na categoria “LOGIN”. A ideia de classificar na mão não é eficiente mas traz a liberdade de criar categorias e criterizar de acordo com a necessidade e criatividade de cada um.

A outra ideia por trás do conceito de categorizar à mão livre, é que de acordo com o ambiente, posso classificar aquela categoria como importante, pouco importante e nada importante e usar essa informação posteriormente como critério de pesquisa.

Poderia então, por exemplo:

  • Identificar a quantidade de eventos relacionados a erros graves no mês;
  • Ver quantas mudanças de estado de bases ocorreram;
  • Checar se tenho muitas entradas de logins inválidos, e através destas informações, tomar decisões de melhorias (algumas até preventivas) para o ambiente;
  • Pesquisar mensagens de uma só categoria ou pesquisar mensagens de categorias que considero críticas (erros de backup, corrupções, etc) via query;

Vantagens:

  • Conseguimos armazenar em um formato confortável (relacional, dentro do SQL Server) e que posteriormente pode ser backupeado ou expurgado conforme necessário.
  • Conseguimos retirar informações e ter mais conhecimento de nossos servidores.
  • Categorizar erros é uma ótima forma de gerenciar melhor tanta informação.

Desvantagens:

  • Depender de uma proc fechada como a xp_readerrorlog traz uma série de limitações de performances e o código possui um comportamento não-desejado SQL Server 2014 (erros são gerados pela procedure e a leitura dinâmica dos errorlogs não é realizada conforme esperado).
  • Performance não-escalável com o uso da xp_readerrorlog. Pode ser aprimorada com o uso de Powershell;

Eis o código da solução:

Você possui alguma solução em seu ambiente para armazenar e se aproveiter melhor dos errorlogs?
Críticas, sugestões? Comente 🙂

Leia também: Controlando o crescimento do ERRORLOG http://renatomsiqueira.com/controlando-o-crescimento-do-errorlog/

Controlando o crescimento do ERRORLOG

Finge que é o errorlog =p

Olá,

Recentemente comecei uma pequena série sobre ERRORLOG composta de três partes. Antes de prosseguir com o post de hoje que é um extra ao assunto, apresento os posts da série caso tenha interesse:

Sendo direto ao ponto: Ter um ERRORLOG grande não é algo comumente desejado, por vários motivos:

  • Demora ao abrir o arquivo: É frustante abrir arquivos grandes principalmente quando queremos uma resposta rápida e experimentamos lentidão.
  • Dificulta manipulação do arquivo: Para esta finalidade, queremos arquivos de fácil manipulação e o tamanho é um dos fatores cruciais pra essa condição.
  • Evita estouro em disco: Em geral não é algo a se preocupar, pois depende do ambiente. Mas imagine que você não precise manter o errorlog no C:  com pouco espaço e as bases de sistema também estão neste disco. Caso mudar o local não seja possível  (cenários e cenários…) você precisa se certificar que um arquivo de errorlog não seja o responsável pela parada de uma instância inteira comprometendo o disco e prejudicando por exemplo, o tempdb.

Dito isso, tenho a opinião de que é interessante controlar o crescimento dos logs aqui citados. Existe uma solução pouco conhecida (e citada aqui pelo Paul Randal) que automaticamente dispara um recycle quando determinado threshold é alcançado mas funciona apenas no SQL Server 2012 ou superior (build à consultar…)  realizando algumas alterações no registro.

É possível confeccionar uma solução destas no SQL Serer 2008 R2? Sim, e vai de cada cenário e necessidade… Sugiro aqui uma solução não-reativa: um script que pode (idealmente) ser agendado via SQL Server Agent e rodado diariamente, podendo fazer o recycle ou não sob determinadas condições. Destaco que a solução abaixo atende bem um cenário X mas não necessariamente Z ou Y, já que existem N formas de endereçar uma solução para o assunto.

Você implementa(ou) alguma solução parecida no seu ambiente ou outra bem diferente? Alguma opinião sobre o assunto? Sinta-se à vontade para postar.


Semana que vem fecho a série de ERRORLOG e prometo mais posts voltados para infra, mas de uma forma um pouco diferente, fugindo do convencional.

[]’s

Second Shot 2015, exames online e surpresas no agendamento

two-headed-turtle_1842062i

Olá,

Inicialmente seria um post apenas sobre o Second Shot, mas acabou se estendendo e divido em três tópicos:

  • Second Shot
  • Exames Online
  • Surpresas no Agendamento

Vamos aos tópicos…

Second Shot

Second shot está de volta (já havia postado sobre isso em 2014) e isso é uma grande notícia pra quem está planejando tirar uma ou mais certificação, seja pra cumprir alguma resolução de ano novo, etapa de desenvolvimento profissional, etc.

Trata-se de uma promoção onde a Microsoft oferece um voucher, você marca seu exame normalmente, paga normalmente, e se, por um acaso do destino você não passar, você pode refazer a prova sem custo algum (é o que também chamam de free retake)! A ideia é você não precisar do voucher, mas se as coisas não darem certo… Só quem já precisou do Second Shot sabe o quanto é importante ter essa opção disponível…

O que é importante saber:

  • Você pode tirar um voucher de 5 de janeiro de 2015 a 31 de maio de 2015;
  • Se você reprovar em um exame e tiver usado o voucher, você tem até 30 dias pra remarcar a prova sem custo;
  • O voucher cobre todos os exames MCP. No caso de SQL Server, temos o MCSA e o MCSE, que são elegíveis para a promoção;
  • Exames MTA não contam (infelizmente);

Se informe mais aqui.

Exames Online

Com a saída da Prometric e a entrada da Person Vue como parceira da Microsoft, algumas boas novidades chegaram e uma delas é a realização de exames online. A lista dos exames elegíveis para serem feitos online podem ser encontrados aqui. No momento em que esse post é escrito, apenas os exames de MCSA SQL Server estão disponíveis para serem online. Os exames de MCSE não, infelizmente.

Está aí mais uma opção interessante para se certificar (literalmente).

Surpresas no Agendamento

Tendo dito que os exames também são marcados online, mas não todos, sugiro que preste atenção redobrada caso queira marcar seus exames o quanto antes. No meu caso, pretendo tirar a 70-464 e ela não está disponível pra ser feita online (diferente das provas MCSA de Data Platform)  e aí, não me resta outra alternativa a não ser marcar em um centro de treinamento, que agora é Person Vue. Aqui em Brasília, só tenho uma opção de local…Isso não é um sério problema, mas quando fui marcar o exame, fui surpreendido.*¹


 

 

 

Calendário disponível SQN

Esse é o calendário de dias disponíveis para marcação do exame. Na data em que este post foi publicado (06.01.2015), a print acima foi tirada e uma não tão boa notícia me é mostrada, pois pretendia fazer a prova neste mês: a data mais próxima disponível ocorre em 20 de Março. Porém, quando tentei marcar para o dia 20.03, não haviam horários disponíveis! Tive que selecionar a data 27.03 no lugar.

Dizem por aí que o ano começa só depois do carnaval mas não sabia que isso se aplicava até pra marcar um exame, rs.

Com isso, além da dica habitual de jamais em sua vida marcar o exame em PT-BR, recomendo que marque a prova com antecedência, para não ser surpreendido também com períodos distantes do que você pretendia e perder a promoção do Second Shot 🙂

 


E aí, vai marcar algum exame? Alguma informação para adicionar? Dúvidas, críticas? Fique à vontade para comentar.

 

Referências

*¹ – Atualizado devido a comentários.

EDIT 20/01/2015 –  O Bruno (@bruno_silvaba) (vide os comentários) mencionou sobre o calendário da Hepta estar melhor. Ótima dica! Quando publiquei este post, a Hepta não aparecia nos relacionados. E de fato o calendário está muito melhor! Pra quem é de Brasília, tá aí uma boa notícia. Ainda assim, pesquisar a disponibilidade dos centros de aplicação de prova ainda é um conselho válido dependendo da sua região.

 

Hepta

 

Copiar resultado do SSMS no Excel sem quebra

Já copiou o resultado de determinada consulta no SSMS (SQL Server Management Studio), colou em uma planilha do Excel e se surpreendeu com a bagunça?
O que era pra ser uma solução rápida e prática acabou virando uma zona?

Eis o cenário:

Consulta exemplo

Gerando um resultset pra teste

Pense na cópia mal sucedida

Copiando o resultset no Management Studio e copiando no Excel. Olha a bagunça!

O intuito deste post é explicar o que causa o problema e como resolver.

Problema

O problema acontece quando o resultado copiado possui caracteres como quebra de linha, tab, etc. Estes caracteres são interpretados no Excel, se copiados diretamente, como comandos e acabam por desconfigurar no momento de colar.
Vamos simular o problema:

1) Criando uma massa pra testes. Existe um propósito em manter os textos no INSERT com espaço. Deixe-os desta forma caso use o código abaixo.

2) Consultando a tabela recém-criada, gerando um resultset com caracteres de controle:

Gerando um resultset problemático de novo

Mesmo caso do exemplo que abriu o post.

3)  Copie o resultset (de preferência com o cabeçalho, botão direito no resultado da consulta, opção “Copy with Headers“, e cole no Excel:

Formatação quebrada

Olha a bagunça!

 Solução

Alguns usuários do SQL Server já abriram chamado na Microsoft para relatar o problema, que aparentemente não possui soluções definitivas, mas existe um workaround (aqui no Brasil usa-se o termo solução de contorno, alguns dizem gambiarra, etc).

Sabendo que o problema acontece quando o resultset possui caracteres como quebra de linha, tab, dentre outros (conhecidos como caracteres de controle), que são interpretados como comandos no Excel, podemos converter esses caracteres em espaço, podendo assim sacrificar a formatação original do campo em prol da realização da tarefa.

Na tabela ASCII, vamos identificar quais caracteres devem ser primariamente localizados:

Codes

Abaixo, segue dentro dos parênteses os códigos ASCII do que pretendemos remover:

  • CHAR(9) = Tab
  • CHAR(10) = Line Feed (LF)
  • CHAR(13) = Carriage Return (CR)

Tab é tab é dispensa explicações. Já Carriage Return e Line Feed são dois caracteres de controle que com frequência caminham de mãos dadas quando uma quebra de linha acontece. Em outras palavras, um ENTER, por exemplo, faz a quebra utilizando estes dois caracteres.

Pra facilitar o entendimento:

NaPratica

Podemos usar os códigos destes caracteres de controle dentro da função REPLACE e substituí-los por espaço, de modo que nossa cópia não fique desconfigurada. Note que você pode fazer o mesmo sem passar espaço, pode passar entre aspas vazias também.

Agora, vamos colar o resultado sem quebrar o resultset:

Gerando agora um resultset com o workaround

Gerando agora um resultset com o workaround

Copiando e colando no excel:

Agora foi!

Cópia bem sucedida.

O workaround, assim como mais informações a respeito do problema, foram postados nos dois links abaixo no connect:

https://connect.microsoft.com/SQLServer/feedback/details/788463/copy-and-paste-from-sql-2012-to-excel-breaks-rows-if-an-address-is-included

Conclusão

A solução apresentada permite a cópia sem maiores problemas sacrificando a formatação original de textos que possuem caracteres de controle. Caso seja realmente necessário manter a formatação, é possível realizar a importação de dados para o Excel de forma direta utilizando outros métodos, que não estão descritos neste post.

[]’s

Referências

  1. CHAR Function – http://msdn.microsoft.com/pt-br/library/ms187323.aspx
  2. REPLACE Function  – http://msdn.microsoft.com/pt-br/library/ms186862.aspx
  3. Carriage Return (CR)- http://pt.wikipedia.org/wiki/Carriage_return
  4. Line Feed (LF) – http://en.wikipedia.org/wiki/Newline
  5. Tabela ASCII – http://www.theasciicode.com.ar/ascii-control-characters/horizontal-tab-ascii-code-9.html

 

OFFTOPIC – Truncate 2014, feliz 2015, Controle e Blog

Cheers lógico comemorando a passagem de ano.

Cheers lógico (e tosco) comemorando a passagem de ano. Pura zueira.

 

Esse é o típico post que eu não compartilho em rede social nenhuma e faço algum balanço do que vivenciei nesse ano de 2014 e o que eu espero  pra 2015.

Acima, de tudo, devo dizer que 2014 foi um ano excelente pra mim no âmbito profissional. Tive a oportunidade de ingressar em uma empresa onde a equipe que pertenço é incrível, participei de dois eventos fora de Brasília (nunca tinha de viajado de avião, hehe),  fiz cursos que realmente queria (e precisava MUITO) fazer e conheci muita gente nova. Pude participar de inúmeras  discussões técnicas interessantes, errar e aprender o porquê de estar errando principalmente, como resolver problemas além de ter recebido toneladas de conselhos tanto pro lado profissional como pro lado pessoal. Foi um ano de oportunidades, aprendizado e sou grato a 2014 sem nem pensar duas vezes. Pense num ano proveitoso, e espero que o de vocês também tenha sido bacana também 🙂

E sabe o que eu espero pra 2015, não só pra mim mas pra todos vocês? Pra fugir do padrão, apenas uma palavra:

MODERAÇÃO.

Pensei bastante sobre isso não só durante a passagem de ano mas na última semana de Dezembro e queria compartilhar com vocês o que eu penso sobre isso.  Se eu tivesse mais controle em determinados momentos chaves, teria agido BEM diferente, evitado muitas dores de cabeça e alcançado muito mais alguns objetivos. E percebo que controle é uma resposta geral para vários cenários da vida.

  • Quem não se controla e se perde em vícios, acaba por  perder mais tempo que o necessário e atrasa o que realmente deve ser feito;
  • Quem não se controla, se planeja mal e traça planos 2015 com metas de 2012, 2013…
  • Quem não controla seus objetivos e ambição profissional acaba sendo controlado por outros e paraliza seu crescimento profissional;
  • Quem não se controla na alimentação/atividades físicas fatalmente terá problemas que se refletem até no rendimento do trabalho.
  • Quem não se controla, não tem objetivo nenhum na vida e canta “deixa a vida me levar” pode estar sendo levado pra um abismo. No sentido figurado da palavra, claro :p
  • Quem não controla a boca acaba falando asneira ou ofendendo, prejudicando a própria imagem e chateando os outros;

Controle é fundamental. Se moderar é fundamental.

Consistência e melhoria  é tudo de melhor que eu posso desejar pra alguém, então é isso: desejo a você moderação em tudo o que fizer. Por isso não desejo a vocês de forma direta dinheiro, promoções no emprego, carros, casas, etc (desejo default de começo de ano pra qualquer um). Desejo que você saiba se moderar, sabedoria para controle: quem se controla consegue se planejar, se esforça pra alcançar seus objetivos e sair do outro lado. Sempre. Dinheiro, sucesso, etc, acabam sendo consequência do seu esforço e dedicação

[]’s

 

DMO’s de Índices: Testes, resets e rebuilds.

raizes, indices. A ideia era pra ser essa.

Era pra passar a ideia de raízes.

Olá,

Antes de iniciar o post, aviso que vou usar bastante o termo DMO (forma de agrupar os termos DMV e DMF). Clique aqui  e aqui  para ler mais sobre os termos.

DMO’s em geral (DMV’s e DMF’s) são coisas legais do SQL Server, que se tornaram disponíveis para uso público a partir do SQL Server 2005 e desde então tem facilitado bastante a obtenção de certas estatísticas relacionadas ao servidor SQL Server e/ou banco de dados em questão.

Existe uma classe de DMO’s extremamente útil que retorna informações relacionadas aos  índices:

Nome

Tipo

dm_db_index_operational_stats

SQL_INLINE_TABLE_VALUED_FUNCTION (DMF)

dm_db_index_physical_stats

SQL_INLINE_TABLE_VALUED_FUNCTION (DMF)

dm_db_index_usage_stats

VIEW (DMV)

Vou chamar todos os três de DMO neste post, embora pessoalmente goste de usar o termo DMV pra tudo (por conveniência), inclusive pra referenciar DMF. Não estou considerando DMO’s de Missing indexes, pois não são o tópico do momento.

O objetivo deste post é explicar o que cada DMO retorna como resultado entrando utilizando a prática pra fixar o conteúdo, demonstrando alguns detalhes do funcionamento de cada um destes itens que não são tão aparentes assim relativos à persistência destas informações, e que podem gerar entendimentos incorretos sobre as informações que ele retorna.

A verdadeira data de criação de um banco de dados

Processed with VSCOcam with f2 preset

Olá,

Como descobrir a verdadeira data de criação de um banco de dados? A princípio, parece ser uma pergunta simples de responder e a resposta aparece de quase imediato: veja na create_date da sys.databases. Mas estamos falando da verdadeira data de criação de um banco de dados, aquela que permanece a mesma mesmo se for a base restaurada em uma instância diferente.

ERRORLOG – Dicas e casos (parte 2 de 3)

bart2

Olá,

Continuando a série de posts sobre errorlog (você pode ler a parte 1 clicando aqui), vamos revisitar conceitos mais importantes explicados no post anterior e comentar sobre dicas/boas práticas. Caso hajam testes, indico que devem ser feitos em ambiente de teste (pelo amor de tudo o que você mais ama, rs).
Os tópicos são:

1) Conceito de (Re)Cycle;
2) Aumentar quantidade de ERRORLOGS;
3) Necessidade do ERRORLOG
4) ERRORLOG + DBCC’s

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

Errorlog01

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.

Desafio #1 – Data Compression Labs

Books

Oi,

Antes de começar o próximo post do Compression Labs, tenho um pequeno e humilde desafio pra quem se interessar a responder (e eu até poderia dizer que estou fazendo isso pra ganhar  tempo fazendo de fazer um post direito, mas estaria sendo estupidamente honesto)…Vamos utilizar o script do Compression Labs #1 adaptado para montar o cenário: vamos criar desta vez duas tabelas, sendo que uma delas vai levar compressão de página.