Arquivo da tag: Trace

#07 – Para que serve


Boa tarde comunidade, boa tarde Brasil!!!!

Começando mais uma tarde de sábado, neste primeiro final de semana do mês de agosto, clima olímpico e muito feliz em ver que o Brasil foi capaz de fazer uma linda festa ontem na abertura dos Jogos Olímpicos Rio 2016, desejo muito sucesso para todos os participantes principalmente aos atletas brasileiros.

O post dedicado a sessão Para que serve deste mês, também esta no clima olímpico, você pode estar se perguntando o porque eu destaquei na minha abertura este clima. Quando estamos pensando em esporte muitas vezes pensamos que não existem possibilidades ou possíveis situações de um determinado time ou atleta ser superado por outro mais fraco, pode ser definido como algo “Hipotético”, sim “Hipotético” na sua definição com base em diversos dicionários: fictício, figurado, imaginário, suposto. Na área de banco de dados isso também pode ser aplicado, principalmente no SQL Server.

Mas de que maneira podemos pensar em algo hipotético, fictício ou imaginário quando estamos trabalhando com banco de dados? Pergunta que inicialmente pode ser difícil de ser respondida, complexa ou simplesmente hipotético(kkkkk).

Foi então que eu comecei a buscar mais informações em um conceito que pra mim era realmente imaginário de ser adotado, e recentemente em um dos posts publicados nos fóruns de SQL Server aqui no Brasil veio a tona o chamado Índices Hipotéticos.

Essa é uma possível resposta quando estamos trabalhando com banco de dados, fazer uso de índices hipotéticos pode nos ajudar a identificar ou similar possíveis situações de impacto na performance de uma query durante sua execução, ainda mais se estivermos trabalhando com um conjunto volumoso de dados.

Para tentar compartilhar com você um pouco sobre este mistorioso recurso que podemos adotar em nosso ambiente, o post de hoje o próximo da sessão para que serve serão dedicados justamente ao entendimento, criação e uso dos índices hipotéticos.

E como de costume aquelas perguntas já conhecidas dos posts anteriores desta sessão:

E ai, você conhece esta funcionalidade? Já utilizou? Sabe para que ela serve?

Pois bem, estas e outras possíveis perguntas serão respondidas a partir de agora em mais este post da sessão Para que Serve!


Começa agora o #07 – Para que serve – Índices Hipotéticos – Parte I.

Mais um final de semana esta chegando, hoje sexta – feira, você já esta começando a se preparar para desligar sua estação de trabalho, pegar suas coisas e voltar para casa feliz por mais um dia de trabalho duro e gratificante e por saber que fez o melhor possível para manter tudo em ordem em seu local de trabalho, eis que após alguns minutos o seu ramal de telefone toca e no display aparece 2801 – Fernanda Galvão, meu deus você pensa, respira e atende sabendo que ela é a gerente de produção da empresa e para estar ligando no final do dia não deve ser nada muito simples, mesmo assim sabendo dos seus deveres e obrigações realiza o atendimento a ligação e escuta:

Junior Galvão, boa tarde!!!

Aqui é a Fernanda, tudo bem? Estamos com um pequeno problema na emissão do relatório de produção diária, estou aqui com o analista de produção João Pedro, você pode falar com ele?

Junior responde sim, claro!!!

Neste momento, João Pedro apresenta o cenário: Junior, olá boa tarde.

Estou com dificuldades para emitir o relatório de produção diária, ao tentar filtrar os dados por clientes e categoria de clientes, o sistema aparentemente entra em loop de processamento e os dados não são apresentados em tela. 

O que será que pode estar acontecendo? Alguns segundos se passam…. Junior começa a pensar e observa que seu final de semana aparentemente foi por água, ou melhor dizendo o final de semana não vai ser tão tranquilo.

Você responde: João Pedro, boa tarde, vou verificar o que pode esta acontecendo, sei que hoje realizamos algumas mudanças na estrutura da tabela de clientes e categoria de clientes, parece-me que o time de suporte adicionou um novo índice, vou tentar verificar.

João Pedro responde dizendo.

Ok! Junior, fico no aguardo, assim que você tiver uma posição por favor me informe.

Junior responde: Certo, perfeito, deixa comigo, vou verificar o que esta acontecendo garanto que hoje não vou conseguir dar uma resposta mais concreta!

Sabendo justamente que a equipe de suporte esta trabalhando para realizar alguns testes de performance nas tabelas de clientes e categoria de clientes, onde milhares de registros estão sendo processados diariamente, Junior chama um dos seus analistas de suporte Eduardo Galvão e pergunta:

Edu por acaso vocês realizaram alguma alteração na estrutura das tabelas de clientes ou categoria de clientes?

A resposta é simples e direta, sim Junior, estamos fazendo uso de um recurso que até então novo ou supostamente desconhecido para nossa equipe,  pelo que pesquisei é uma funcionalidade conhecida como índices que possuem somente estatíticas mas não existem fisicamente.

Junior responde: Índices somente com estatísticas, índices que não existem, que raio de recurso é esse, por acaso vocês estão se referindo a índices hipotéticos?

Eduardo responde, sim, sim, acredito que seja isso a analista de suporte de banco de dados Maria Luíza, esta fazendo um estudo sobre isso em nosso ambiente de testes e identificou que se fizermos a adoção deste recurso poderemos ter mais facilidade em reconhecer a necessidade de um novo índice ou se o mesmo realmente é útil mesmo após ter sido criado anteriormente.

Junior responde, certo Eduardo, mas este tipo de teste ou implementação deve ser planejada, não podemos simplesmente pesquisar um recurso na internet ou livros e já sair aplicando em nossos ambientes de teste, muito menos em produção, devemos sempre por em prática nosso check-list de boas práticas e principalmente ter um ambiente de contigência caso algo aconteça de errado.

Quero saber qual será a forma para identificar o que esta acontecendo e como vamos resolver este problema até segunda – feira, questiona Junior!!!”

Muito bem, este é nosso cenário, com base, nesta pequena estória que acabamos de conhecer, será criado nosso ambiente de testes para colocar em prática o conceito de índices hipotéticos, antes disso iremos comecer um pouco mais sobre este conceito.

Índices

Falando de uma maneira simples quando criamos um novo índice no SQL Server ou em qualquer outro banco de dados, estamos criando uma estrutura que basicamente servirá como caminho na busca e identificação de um ou mais dados solicitados pelos mecanismos de banco de dados durante o processamento de uma determinada query.

Ao realizar a criação deste elemento normalmente os índices físicos apresentam em sua estrutura os dados, distribuídos de maneira demográfica confome as manipulações são realizadas, além disso, apresentam densidade, granularidade e seletividade de acordo com seu conjunto de valores, com isso, temos um conjunto de informações técnicas conhecidas como estatísticas do índice o que permite servir como elemente auxiliar no obtenção mais ágil e simples dos dados solicitados.

Índices Hipotéticos

Ao se falar de índices hipotéticos, estamos se referindo a uma estrutura completamente oposta, sem qualquer tipo estrutura física, muito menos dados, um índice hipotético é conhecido como algo imaginário que não possue estrutura física, somente estrutura lógica ou seja, somente estatísticas que podem servir como recurso para tentar criar o mecanismo de banco de dados e também o plano de execução por parte do SQL Server na busca de um ou mais dados.

Como podemos criar um índice hipotético?

A partir do SQL Server 2008 R2 a Microsoft adicionou uma opção no comando Create Index conhecido como With Statistics_Only, traduzindo ao pé da letra para o português vamos encontrar ao similar à somente estatísticas. É com base nesta opção não documentada que temos a possibilidade de fazer uso de índices hipotéticos em nossos bancos de dados.

O uso desta opção é muito simples, basta ao final da linha de comando que referencia a criação de um novo índice adicionar a instrução With Statistics_Only = 0, onde o mecanismo de banco de dados vai entender que esta novo índice deverá ser criado possuindo somente uma estrutura lógica controlada e direcionada através dos dados estatísticos coletados durante as manipulações de dados ou execução de querys que fazem uso do mesmo. Quando criamos um novo índice e não informamos esta opção por padrão o mecanismo de banco de dados repassa internamente para processador de querys que este índice deve ser criado da maneira padrão ou seja, um índice que conterá estrutura física e lógica, e o valor correspondente a instrução With Statistics_Only será igual á -1, ou seja:

  • With Statistics_Only = 0 — Indica que o índice deve ser criado de maneira hipotética, índice forma somente por estrutura lógica, conhecida como estatíticas; e
  • With Statistics_Only = -1 — Indica que o índice deve ser criada da maneira clássica, índice formado por estrutura física e lógica.

Uma forma simples é fácil para saber se um ou mais índices apresentam esta diferença pode ser encontrada na visão de sistema sys.indexes através da coluna is_hypothetical, onde a mesma deverá apresentar os valores: 0(zero) ou 1(hum), sendo estes valores que identificam e diferenciam a ocorrência da existência de um ou mais índices clássicos e hipotéticos.

Mas não tudo sem flores como diria meu irmão, a criação de um índice hipotético é fácil, tranquila, sem muitos segredos. Agora, imagine se você deseja orientar otimizador de consultados existentes no SQL Server no uso deste tipo de índice durante o processamento de uma query, ou então se você deseja omitir o seu uso, situação que pode parecer muito comum de ser realizada ou automática, mas não é bem assim.

Temos a necessidade de dirigir isso mesmo, mostrar o caminho que deve ser seguido pelo Database Engine em conjunto com o Query Optimizer e posteriormente o Execution Plan, como deve ser feito o uso de um índice hipotético. Isso parece ser algo bastante complicado, não é bem assim, como sempre existe uma solução que a Microsoft muitas vezes também não reconhece como recurso documentado ou simplesmente não documento, e ai mais uma vez “Mister M de SQL Server” surge para nos ajudar e apresentar ao mundo como uma possível solução pode ser adotada maneira mais suave, mostrando como podemos  resolver este problema e sair desta sinuca de bico.

Pra variar surge para muitos um novo  DBCC – Database Command Console não documentado conhecido como DBCC AutoPilot e uma nova diretiva Set AutoPilot, onde:

  • Set AutoPilot – Orienta o query optimizer a considerar ou não o uso do índice hipotético no momento da criação do plano de execução da query; e
  • DBCC AutoPilot – Orienta o query optimizer fazer uso do índice hipotético de acordo com o conjunto de parâmetros a ser utilizado e posteriormente repassado para o plano de execução.

Preste atenção o nome dele não tem nada haver com piloto de Fórmula 1 (kkkk), vou repetir o seu nome DBCC AutoPilot e ele vai justamente nos ajudar e saber mais sobre os dados que estão relacionados com um determinado índice hipotético.

DBCC AUTOPILOT

Este comando DBCC é mais um dos diversos comandos de console de banco de dados que a Microsoft não reconhece como comando documentado ou suportado nativamente, através do conjunto de instruções “parâmetros” que compõem sua sintaxe o query optimizer vai se comportar de uma determinado maneira ou de outra.

Abaixo apresento a relação de parãmetros que formam o DBCC AutoPilot:

Parâmetro

Descrição
typeid Existem alguns valores, os mais utilizados basicamente são:
Type ID = 5: Iniciar a sessão ou comandos anteriores limpos;
Type ID = 0: Fazer uso de índices não clusterizados; e
Type ID = 6: Usar apenas índices clusterizados.
dbid Id do banco de dados habilitado para executar o comando.
maxQueryCost Supostamente definir um possível custo em relação ao processamento da query. “Sinceramente não entendi bem como usar (kkkk)”
tabid Id da Tabela a ser utilizada.
indid Id do índice a ser utilizado.
pages Ao executar o DBCC AutoPilot simular o comportamento e uso de páginas de dados.
flag Parâmetro desconhecido, não encontrei informações sobre ele….
rowcounts Parâmetro utilizado para definir o número de linhas de execução e processamento para alguns comandos.

Bom vou deixar você agora com um gostinho de quero mais, como destacado anteriormente este é a primeira parte deste Para que serve…. Na segunda parte vamos criar nossos índices hipotéticos e fazer uso da diretiva SET AutoPilot, posteriormente na terceira parte vamos utilizar a não documentada DBCC AutoPilot.


É isso ai galera, chegamos ao final de mais post da sessão Para que serve!

Espero que você tenha gostado, que as informações compartilhadas aqui possam lhe ajudar a se tornar cada vez um profissional de banco de dados reconhecido e valorizado, um dos papéis na área de tecnologia mais importantes para qualquer empresa.

Reconher o verdadeiro papel de um DBA dentro de sua estrutura, é reconhecer o verdadeiro valor de seus dados e como eles podem se tornar uma infomação valiosa para sua tomada de decisão.

Caso deseje acessar os posts anteriores desta sessão, utilize os links listados abaixo:

Anúncios

Dica do Mês – Default Trace To Audit Events – Backup and Restore


Hello everybody!!!

Tudo bem? Final de mês chegando e o que isso significa para você?

Se fosse aquele apresentador do programa do fim de noite do domingo poderia dizer, NADA, mas no meu blog todo final de mês é sempre muito importante e aguardado, é a hora de mais um post dedicado a sessão dica do mês ser publicado, alias se você ainda não conheço ou acessou os dois primeiros posts desta nova sessão não perca seu tempo, utilize um dos links abaixo e conheça mais sobre esta na área do meu blog dedicada especialmente em apresentar como um recurso ou script pode se tornar uma dica extremamente útil:

Vamos em frente, no post de hoje vou destacar um velho e conhecido assunto existente no Microsoft SQL Server e bastante difundido a partir da versão 2005, denominado Default Trace File (Arquivo de rastreamento/monitoramento padrão) em conjunto com os Audit Events (Eventos de Auditoria) introduzidos a partir da versão 2008, ambos os recursos combinados se tornando uma fantástica ferramenta para consulta e monitoramento das atividades, tarefas e processos em execução no Microsoft SQL Server.

Como de costume, vou apresentar um pouco sobre estes recursos de forma breve e resumida, tentando ilustrar sua importância:

  • Default Trace File: Surguiu da necessidade que os profissionais de banco de dados em suas atividades monitoramento tinham em colocar dados sobre o que estava sendo executado em seu servidor ou instância SQL Server de uma maneira mais “aberta”, ou seja, diferente do que acontecia na versão 2000 onde o monitoramento era realizado de uma forma conhecida como “caixa preta”, sem possibilitar algum tipoo de interação.A partir da versão 2005 este recurso foi aprimorado, se tornando uma grande ferramenta na coleta de dados sobre o comportamento do SQL Server. Com esta evolução muitas respostas para problemas de performance, deadlock e troubleshotting começaram a ser respondidas e entendidas de forma mais rápida, fácil e dinâmica. Em diversos momentos o Default Trace File, foi considerado uma ferramenta valiosa e moderna para os profissionais de Banco de DAdos – DBA.

    Oferece uma riqueza de informações, enquanto minimamente, impactando o sistema. O Default Trace File é um recurso amplamente divulgado do SQL Server 2005, mas com o passar do tempo ganhou fama e evolução nas demais versões do produto, por oferece aos administradores a capacidade de obter informações detalhadas sobre:

    • Auditoria de eventos;
    • Eventos de banco de dados;
    • Eventos de erros;
    • Eventos de texto completo;
    • Criação do objeto;
    • Exclusão de objeto; e eventos de alteração do objeto.

 

  • Audit Events: Introduzido a partir da versão 2008, o Audit Events tornou-se uma verdadeira solução de auditoria dentro do Microsoft SQL Server, considerada por muitos um complemento aos recursos e funcionalidades desempenhadas pelo Default Trace File. Composto por um longo conjunto de eventos que a cada nova versão do SQL Server é incrementado com outros os eventos de auditoria possibilitam coletar e catalogar de maneira mais detalhada e repleta de dados todo comportamento de um servidor, banco de dados e objetos existentes em um servidor ou instância SQL Server.Outro fator importante quando falamos dos eventos de auditoria esta relacionado com os pilares de segurança do SQL Server, possibilitando todo controle e monitoramento de acesso a objetos e dados direcionados ao SQL Server, possibilitando detectar possíveis tentativas de acesso não autorizado ou acessões maliciosas por partes de usuários com acesso legítimo.

Após este breve resumo sobre estes dois recursos, você pode estar se perguntando como ou quando podemos fazer uso deste tipo de funcionalidade? A resposta é bem simples, de diversas forma, dentre elas apresento algumas:

  • Captura de eventos e ocorrência de eventos;
  • Captura da lista e detalhes de eventos;
  • Informações sobre crescimento de um banco de dados;
  • Informações sobre erros e alertas disparados pelo SQL Server;
  • Informações sobre alertadas de ordenação de dados;
  • Quando um procedimento de Shrink foi realizado em um banco de dados ou arquivo de log;
  • Quando um determinado comando DBCC foi executado;
  • Quando um Backup de Banco de Dados ou Restore de Banco de Dados foi realizado; e
  • Pesquisa de informações sobre auto estatísticas ou eventos de estatísticas.

Enfim sobre muita coisa relacionada ao SQL Server é possível fazer uso de um Default Trace File em conjunto com o Audit Events, desta maneira na dica de hoje escolhi uma das maneiras mais comuns porém não menos importante para obter informações sobre os eventos relacionados a execução de Backup Database e Restore Database através do dois exemplos apresentados a seguir:

 


 

— Exemplo 1 – Obtendo informações sobre a ocorrência de Backup Database —

Declare @path NVARCHAR(260)

Select @path=path From sys.traces Where is_default = 1

 

SELECT DatabaseName, TextData,

             Duration, StartTime,

             EndTime, SPID,

             ApplicationName, LoginName

FROM sys.fn_trace_gettable(@path, DEFAULT)

WHERE EventClass IN (115)

and EventSubClass=1

ORDER BY StartTime DESC

Go

 

 

— Exemplo 2 – Obtendo informações sobre a ocorrência de Restore Database —

Declare @path NVARCHAR(260)

Select @path=path From sys.traces Where is_default = 1

 

SELECT DatabaseName, TextData,

             Duration, StartTime,

             EndTime, SPID,

             ApplicationName, LoginName

FROM sys.fn_trace_gettable(@path, DEFAULT)

WHERE EventClass IN (115)

and EventSubClass=2

ORDER BY StartTime DESC

 

Espero que você tenha observado que ambos os códigos de exemplo são bem similares, o que determina qual conjunto de informações será apresentada de acordo com o evento é a coluna EventSubClass, onde:

  • EventSubClass = 1 — Representa as informações sobre a sub-classe de eventos relacionada a ocorrência de Backup;
  • EventSubClass = 2 — Representa as informações sobre a sub-classe de eventos relacionada a ocorrência de Restore; e
  • EventSubClass = 3 — Representa as informações sobre a sub-classe de eventos relacionada a ocorrência de Backup Log.

Caso você queira saber mais sobre os eventos de auditoria relacionadas a Backup/Restore acesse:
https://msdn.microsoft.com/en-us/library/ms175015.aspx ou https://msdn.microsoft.com/en-us/library/ms175481.aspx para obter mais sobre a classe de eventos existente no SQL Server.

sys.fn_trace_gettable e sys.traces existentes nas atuais versões do SQL Server 2012 e 2014, segundo a documentação oficial da Microsoft ambas catalog views serão removidas nas futuras versões do produto.

 


 

É isso ai galera, chegamaos ao final de mais uma dica de mês. Com certeza uma dica bastante diferente que forma como o SQL Server é composto por diversos recursos aparentemente independentes e isolados mas que podem ser utilizados em conjunto formando uma grande ferramenta de trabalho.

Espero que você tenha gostado, nos encontramos no final do mês de Abril com mais uma dica do mês.

Um grande abraço, obrigado por sua visita.

Até mais.