#10 – Para que serve


O louco meu, pleno feriadão e você esta passando por aqui no meu blog……

Que legal, sensacional, fico honrado com a sua ilustre visita, seja bem – vindo mais uma vez ao meu blog, espero que você consiga encontrar o que esta procurando ou algo que possa lhe agradar.

Este é mais um post da sessão Para que serve, lançada no início de 2016 e que esta chegando ao post de número 10, isso mesmo estamos no décimo post dedicado a esta sessão que aos poucos esta conseguindo se tornar uma referência de conhecimento diferenciado no meu Blog.

É isso ai, após esta tradicional saudação, chegou a hora de falar sobre o #10 – Para que serve de hoje, tenho a certeza que você vai gostar….


Introdução

Como você já deve ter percebido os posts relacionados a esta sessão tem o objetivo de apresentar e em alguns casos demonstrar como exemplos de código, aplicativos, utilitários, entre outros elementos envolvidos a banco de dados ou gerenciadores de bancos de dados dentro eles o Microsoft SQL Server podem ser utilizados para se obter uma possível solução de um problema, como em outros casos orientar na sua forma de utilização.

Para o post de hoje vou destacar um script que utilizei recentemente e posso dizer que foi de grande ajuda, mas antes de apresentar este recurso vou destacar um pouco sobre alguns elementos relacionados a ele, dentre os quais destaco File Growth.

File Growth

E ai você já ouviu falar file growth, ou simplesmente crescimento de arquivo de dados ou log? Se você é um administrador de banco de dados, ou um profissional que já trabalha a algum tempo com o banco de dados, tenho a certeza que já deve ter ouvido falar sobre a importância de se saber como esta configurado o fator de crescimento de um banco de dados e seu arquivos de transações.

Trata-se de uma configuração que pode ser aplicada durante a criação de um banco de dados ou posteriormente, sua importância esta totalmente relacionada ao espaço de armazenamento de dados durante sua utilização, o que poderá impactar na capacidade física de uma unidade de disco em gerenciar o quanto estes arquivos podem consumir e alocar espaço em disco no decorrer do seu tempo de vida.

Ao definir a forma de crescimento ou até mesmo o quanto este arquivo poderá ou não crescer de forma ilimitado o Microsoft SQL Server vai trabalhar no processo de alocação, escrita e manipulação da estrutura física e lógica tanto para os arquivos de dados, como principalmente para os arquivos de log.

Justamente sendo estes os arquivos que normalmente consomem um grande espaço física das unidades de disco para catalogar todas as operações processadas em um banco de dados que devem ser registradas em sua estrutura.

Para este tipo de cenário os gerenciadores de banco de dados através de seu mecanismo de Storage Engine observam e monitoram o que esta sendo processado e armazenado dentro de cada arquivo, caso o mesmo tenho que crescer para alocar uma nova área é com base nas configurações de File Growth definidas para o respectivo arquivo que este crescimento poderá ser realizado em fatores de Kilobytes, Megabytes, Gigabytes ou até mesmo em valores de porcentagem.

#10 Para que serve – Obtendo informações sobre database filegrowth —

Agora que conhecemos um pouco que esta relacionada com este post, vamos então conhecer este script que poderá nos ajudar a obter todas as possíveis informações relacionadas ao fator de crescimento de nossos bancos de dados e suas respectivas estruturas de dados e log.

— Bloco de Código —

filegrowth

Muito bem, observe que este código é bastante simples, estamos basicamente fazendo uso das catalogs views existentes no Microsoft SQL Server desdes suas primeiras versões o que nos permite dizer que este bloco de código pode ser aplicado facilmente a partir da versão 2005 em qualquer nível de edição, além disso, o mesmo já foi testado e aprovado nas últimos duas edições 2014 e 2016.

Após executarmos o bloco de código apresentando anteriormente, o Management Studio deverá retornar um conjunto de colunas e valores similares ao apresentado na Figura 1 apresentada abaixo:

filegrowth1Figura 1 – Relação de bancos de dados e informações sobre o filegrowth.

Podemos notar a existência das colunas AutoGrowthStatus, GrowthValue e GrowthIncrement, são justamentes estas as colunas que nos permitem encontrar as informações relacionadas aos fatores de crescimento configurados para cada banco de dados armazenado em nosso servidor ou instância de bancos de dados Microsoft SQL Server.

Falando um pouco sobre estas três colunas é possível observar:

AutoGrowthStatus: Esta coluna apresenta o status da propriedade Auto Growth, sendo esta definida para informar e o arquivo deverá ou não crescer de forma automática.

GrowthValue: Apresenta que pode ser informado a partir de 0 (zero) que indica ao Microsoft SQL Server que o determinado banco de dados não deverá crescer. Os demais valores podem representar uma indicação de crescimento em tamanho fixo ou até mesmo em porcentagem.

GrowthIncrement: Mostra a forma de incremento do fator de crescimento do banco de dados, sendo orientado e calculado através do número de páginas de dados, se o valor apresentado for igual á 0 (zero) significa que este banco de dados não terá seu crescimento realizado, qualquer outro valor acima de 0 (zero) significa que este banco de dados será impactado em algum momento pelo valor definido nas configurações do crescimento do banco de dados. Vale ressaltar que este valor esta relacionado ao tamanho de 8Kb (Kilobytes) para cada página de dados.

Após esta análise posso dizer que fica mais fácil descobrir qual banco de dados poderá apresentar problemas de crescimento acima no normal ou simplesmente aquele banco de dados que necessita crescer além do estimado.

Referências

https://technet.microsoft.com/pt-br/library/ms181338(v=sql.110).aspx

https://msdn.microsoft.com/en-us/library/ms178534.aspx

https://msdn.microsoft.com/en-us/library/bb522469.aspx

Links

Caso você ainda não tenha acessado os posts anteriores desta sessão, fique tranquilo é fácil e rápido, basta selecionar uns dos links apresentados a seguir:

https://pedrogalvaojunior.wordpress.com/2016/08/06/07-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2016/08/06/07-para-que-serve/

Conclusão

Administrar um banco de dados não é uma tarefa das mais complicadas do mundo, mas quando se referimos em administratar um servidor de banco de dados ou conjunto de servidores de bancos de dados o cenário com certeza muda bastante.

Foi pensando neste tipo de situação que compartilhei com vocês hoje este script no #10 – Para que serve, que apresenta como podemos de maneira fácil, rápida, segura e muito prática encontrar informações relacionadas ao file growth, ou simplesmente fator de crescimento.

Considerada uma das configurações mais importantes de um qualquer banco de dados alocado em uma instância ou servidor Microsoft SQL Server.

Agradecimentos

Mais uma vez obrigado por sua visita, agradeço sua atenção, fique a vontade para enviar suas críticas, sugestões, observações e comentários.

Até mais.

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.