sql117

Estas solues so monitoradas pela tecnologia FairCom todos os dias!

v>VVUnn 2013 FairCom Corporation

tecnologia de banco de dados

A FairCom uma empresa de tecnologia de banco de dados de alta performance, que oferece aos

desenvolvedores mais liberdade no gerenciamento dos dados.

Por mais de 30 anos a FairCom tem sido a escolha de

implementaes de misso crtica em todo o mundo devido

integridade e confiabilidade de seus produtos, garantindo pouco

ou nenhum tempo de parada.

U Com baixos custos de licenciamento, requisitos de hardware mnimos e administrao simplificada, a FairCom oferece um dos banco de dados de menor custo da indstria em seu segmento.

U Milhares de ISVs e 43% das empresas da revista Fortune 100 nos EUA utilizam a ferramenta de banco de dados multiplataforma da FairCom para potencializar seus aplicativos.

U A FairCom, comprometida em oferecer o que h de melhor e mais moderno em tecnologia de banco de dados, trabalha lado a lado com os ISVs e outros desenvolvedores para inovar constantemente, sempre baseada nas necessidades de seus clientes e em um firme entendimento do futuro da tecnologia de banco de dados.

U A arquitetura nica da FairCom permite a seus clientes recuperar o controle do desenvolvimento de seu produto em seu prprio ritmo, com confiana na flexibilidade e integridade da sua ferramenta de banco de dados.

U Garanta o melhor ROI para seu produto com a integrao do gerencimento dos dados, simplificando a distribuio e suporte.

C

M

Y

CM

MY

CY

CMY

K

FairCom121212BRfullfinal.pdf 1 1/3/13 2:17 PM

Sumrio

A SQL Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista!

D seu voto sobre esta edio, artigo por artigo, atra-vs do link:

www.devmedia.com.br/sqlmagazine/feedback

D

seu Fe

edback

sob

re esta edio

D seu feedback sobre esta edio!

05 Modelagem SQL x NoSQL [ Mauro Pichiliani ]

Contedo sobre Boas Prticas


60 Avaliando recursos de paralelismo apoiado por bancos de dados[ Marcelo Josu Telles ]

16 Eventos de espera no SQL Server[ Rafael Guidastri ]


40 Bancos conectveis com o Oracle 12c [ Ricardo Ferro ]

Contedo sobre Boas Prticas, Contedo sobre Novidades

31 Por dentro do Oracle Database 12c [ Gilson Martins ]

Contedo sobre Novidades

24 Monitorando uma instncia SQL Server [ Stefano Takamatsu Gioia ]

48 Alta disponibilidade no banco de dados Oracle Parte 3 [ Ricardo Rezende ]



10 Realizando tuning com o SQL Server 2012[ Fernando Weschenfelder ]

Ano 10 - 117 Edio 2013 - ISSN 1677918-5 - Impresso no Brasil

EditorRodrigo Oliveira Spnola ([email protected])

SubeditorEduardo Oliveira Spnola

Consultora TcnicaDaniella Costa ([email protected])

Jornalista ResponsvelKaline Dolabella - JP24185

CapaRomulo Araujo

DiagramaoJanete Feitosa

DistribuioFC Comercial e Distribuidora S.A

Rua Teodoro da Silva, 907

Graja - RJ - 206563-900

Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugesto!Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine, entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria de publicar:

Rodrigo Oliveira Spnola - Editor da [email protected]

RoDRigo olivEiRa Spnola

Editor Chefe da SQL Magazine, Mobile

e Engenharia de Software Magazine.

Professor da Faculdade Ruy Barbosa,

uma instituio parte do Grupo DeVry.

Doutor e Mestre em Engenharia de

Software pela COPPE/UFRJ.

Assine agora e tenha acesso a todo o contedo da DevMedia:www.devmedia.com.br/mvp

atendimento ao leitorA DevMedia possui uma Central de Atendimento on-line, onde voc pode tirar suas dvidas sobre servios, enviar crticas e sugestes e falar com um de nossos atendentes. Atravs da nossa central tambm possvel alterar dados cadastrais, consultar o status de assinaturas e conferir a data de envio de suas revistas. Acesse www.devmedia.com.br/central, ou se preferir entre em contato conosco atravs do telefone 21 3382-5038.

[email protected] 21 3382-5038

anncios Anunciando nas publicaes e nos sites do Grupo DevMedia, voc divulga sua marca ou produto para mais de 100 mil desenvolvedores de todo o Brasil, em mais de 200 cidades. Solicite nossos Media Kits, com detalhes sobre preos e formatos de anncios.

EXpEDiEnTE

Edio 117 SQl Magazine 5

Porque este artigo til:O contedo deste artigo til para aqueles que esto comeando a

aprender tecnologias NoSQL e possuem dificuldade para se adaptar

e utilizar o conhecimento j adquirido na modelagem relacional.

A partir da discusso apresentada possvel compreender melhor

como a modelagem funciona nos bancos de dados NoSQL do ponto

de vista da modelagem de entidades, relacionamentos e atributos.

Neste contexto so discutidos exemplos de como as integridades de

entidade, de domnio e referencial afetam a modelagem tradicional

e como estes aspectos so tratados pelas tecnologias agrupadas pela

sigla NoSQL.

Resumo DevMan

Veja algumas tcnicas de modelagem utilizadas em bancos NoSQL

Modelagem SQL x NoSQL

A modelagem uma das atividades iniciais envolvidas no processo de criao de bancos de dados tradicionais que conta com diversas tcnicas consolidadas e utilizadas nas tarefas do dia a dia que envolvem programao e banco de dados. Estas tcnicas so diretamente ligadas aos bancos de dados relacionais que suportam a linguagem SQL. Contudo, novas abordagens para o armazenamento, manipulao e tratamento de dados abrem discusso sobre novas formas de modelagem de dados.

Apesar de existir muito material, recursos, exemplos e aplicaes voltadas para os bancos de dados NoSQL, pouco se fala sobre as caractersticas, aspectos e tcnicas de modelagem que podem ser utilizados com tecnolo-gias NoSQL. De fato, esta falta de discusso acaba se tornando uma barreira de aprendizado para muitas pessoas que, muitas vezes, simplesmente desistem de experimentar tecnologias NoSQL por no encontrar uma comparao com o que j existe no mundo SQL. Desta maneira, este artigo apresenta uma discusso sobre a criao de modelos para bancos NoSQL tendo como guia as tcnicas e recursos empregados na concepo e criao de bancos que suportam a linguagem SQL.

A discusso apresentada neste artigo no se prope a ser muito extensa ou se concentrar em um banco de dados relacional ou NoSQL especfico, pois o foco nas possibilidades que a modelagem proporciona quando se est trabalhando com bancos de dados reacionais ou NoSQL.

aspectos gerais de modelagemDe um ponto de vista mais geral, a modelagem repre-

senta uma abstrao da realidade. Basicamente o que estamos fazendo quando modelamos um banco de dados montar uma representao da realidade de acordo com o nosso objetivo, que no caso o armazenamento de dados. Alm da abstrao, tambm realizamos outras tarefas, tais como filtrar o que nos interessa, interpretar cenrios, enquadrar os dados em um formato que seja interessante e saber o que relevante ou no para o modelo. Estas atividades so realizadas de forma ite-rativa, ou seja, o modelo provavelmente vai passar por vrias verses antes de chegar verso final que ser

implementada em um sistema gerenciador de banco de dados relacional (SGBDR).

A modelagem relacional tradicional possui algumas caracters-ticas que a tornaram adequada para muitos tipos de ocorrncias de dados que, de certa forma, sempre envolvem um usurio final. Um dos aspectos que pouca gente nota quando se fala em modelagem tradicional que os modelos geralmente so criados pensando-se em gerao de relatrios com algum nvel de agregao de dados. Esta modelagem tambm , at certo ponto, influenciada pela prpria linguagem SQL, que possui muitos recursos para trabalhar com conjuntos de dados ao invs de dados individuais. Tambm existe certa influncia do uso de transaes nas caractersticas de modelagem, assim como a consistncia e integridade de dados.

Quem est aprendendo a modelar bancos de dados tradicionais logo nota que h uma preocupao grande em garantir que o mo-delo de dados seja rgido, ou seja, no aceite grandes variaes fora do que foi modelado. H tambm uma preocupao constante em garantir que anomalias de dados no sejam inseridas no modelo por meio da aplicao das famosas regras de normalizao ou formas normais.

Durante a fase de modelagem tradicional comum que os modelos recebam muitas modificaes para que eles estejam de acordo com as recomendaes da terceira forma normal. Isso quer dizer que o modelo deve receber modificaes tais como a criao de novas entidades, atributos e relacionamentos, para que certas anomalias no ocorram nos dados. Esta uma das principais caractersticas de modelos relacionais e que acaba


6 SQl Magazine Edio 117

guiando a modelagem para um lado mais rgido, adequando-se bem ao uso de transaes, concorrncia e integridade do esquema do banco de dados.

Contudo, recentemente os bancos de dados agrupados sob a sigla NoSQL propuseram abordagens diferentes para o ar-mazenamento, manipulao de dados e modelagem de dados. O que era considerado tradicional e desejvel no modelo relacio-nal comeou a ser desafiado pelos bancos NoSQL, pois o uso de transaes, rigidez no esquema, integridade e tambm aspectos de escalabilidade, alta disponibilidade e concorrncia de acesso nem sempre so desejveis como nos bancos SQL. Certamente esta nova forma de pensar e ver o banco de dados gera um impacto na modelagem que precisa ser conhecido para que se possa escolher, dependendo do contexto, qual o melhor tipo de modelagem a ser adotado em cada situao.

Quem est iniciando os estudos em tecnologias NoSQL no deve ter em mente que tudo o que foi aprendido deve ser deixado de lado. Muito do que foi aprendido com modelagem tradicional pode e deve ser utilizado na modelagem NoSQL. Algumas tcnicas, recomendaes e recursos so praticamente iguais, enquanto outras exigem um esforo de aprendizado. No geral, preciso sempre focar na soluo e como a modelagem pode ser utilizada para atender as necessidades do negcio independente de como a modelagem for implementada.

A modelagem tradicional empregada para atender as necessida-des de armazenamento j existe h muitos anos e diversos modelos de dados foram criados desta forma. H, inclusive, repositrios com diversos modelos de dados prontos para serem utilizados. Infelizmente, a modelagem para bancos NoSQL no conta com tantos exemplos, recursos educacionais e discusses que possam auxiliar quem est comeando a trabalhar com as tecnologias NoSQL. Contudo, a falta de recursos no deve ser um fator que impea a avaliao e o uso de modelos NoSQL no dia a dia das solues, independente de qual paradigma de armazenamento seja mais adequado.

Apesar de existirem diferentes formas de armazenar e organizar os dados nos produtos agrupados pela sigla NoSQL, a prxima seo vai discutir alguns dos principais aspectos relacionados modelagem de um banco de dados relacional ou no levando em considerao os SBGDR tradicionais e algumas abordagens NoSQL mais populares.

Diferenas de modelagem entre noSQl e SQlUm dos principais pontos que diferenciam a modelagem de

bancos de dados NoSQL da modelagem tradicional a rigidez do modelo. Nas tcnicas tradicionais de criao deste artefato necessrio fazer um levantamento de requisitos e especificar com detalhes cada uma das entidades, relacionamentos e atributos que, no momento da criao do banco de dados fsico, vo se tornar tabelas, relacionamentos (implementados por constraints) e colu-nas, respectivamente. Uma vez que este levantamento seja feito, necessrio especificar quais so os atributos das entidades que futuramente se tornaro as colunas das tabelas.

Os atributos da modelagem tradicional so rgidos, ou seja, todos eles so necessrios para cada instncia da entidade. Isso quer dizer que cada linha da tabela dever ser composta pelos valores das colunas que foram criadas. Por exemplo, se uma entidade possui 10 atributos, espera-se que cada um deles receba um valor para cada instncia da entidade. Se houver uma tentativa de inserir menos ou mais do que 10 valores para uma nova instncia (linha) desta entidade (tabela), um erro dever ser retornado indicando uma violao de integridade de entidade.

Em bancos de dados NoSQL orientados a documento esta rigidez no existe. possvel criar uma coleo (anlogo a uma entidade ou tabela), que recebe os documentos (anlogo a ins-tncias da entidade ou linhas) e que possui atributos (anlogo a colunas da tabela). Contudo, a definio de quais atributos o documento ir possuir criada de acordo com os dados, tornan-do o modelo flexvel. Isso quer dizer que possvel ter em uma coleo um documento com trs atributos e outro documento dentro da mesma coleo com 10 atributos. Esta flexibilidade caracterstica de muitos bancos de dados NoSQL e gera novas possibilidades de armazenamento.

Vejamos um exemplo onde a flexibilidade pode ser til. Em um cadastro de produtos de uma loja provvel que cada produto tenha caractersticas nicas que precisam ser analisados. Um tnis possui cor, tamanho e marca. J uma bebida possui sabor, data de validade e contedo calrico. Geralmente a modela-gem tradicional resolve esta situao criando uma tabela de produtos com um atributo de texto livre para armazenamento de uma descrio ou observao. J a modelagem NoSQL pode separar melhor estas caractersticas em atributos que no foram criados durante a modelagem. Desta forma possvel armaze-nar dados de acordo com as caractersticas dos produtos sem a necessidade de uma modelagem rgida.

At aqui vimos algo que vai contra a integridade de entidade de uma tabela, pois tal integridade diz que o formato dos dados deve ser o mesmo para cada instncia da entidade. Entretanto, muitos cenrios no exigem a integridade de entidade devido a certas caractersticas dos dados. Nestes casos recomendado trabalhar com um esquema de banco de dados que seja flexvel e permita a insero de valores para atributos que no foram previamente modelados.

A flexibilidade de esquema tambm pode ser utilizada para armazenar diferentes valores para um mesmo atributo, uma vez que nos bancos NoSQL orientados a documentos cada do-cumento dentro de uma coleo tratado de forma individual. Isso quer dizer que, por exemplo, no atributo CODIGO podemos ter um valor numrico para um documento X e um valor alfa-numrico para o atributo CODIGO em um documento Y, sendo que ambos os documentos esto dentro da mesma coleo C. Isso pode acontecer em cenrios onde cada fabricante tem um cdigo interno do seu produto.

Geralmente a modelagem tradicional resolve esta situao de in-tegridade de domnio escolhendo um tipo de dados que armazena


qualquer tipo de valor ou criando diferentes atributos dentro da mesma entidade. Nos bancos NoSQL orientados a documentos no preciso nenhum trabalho adicional, pois, como j foi dito, cada documento tratado de forma individual.

O terceiro tipo de integridade que se encontra em um modelo relacional tradicional a integridade referencial. Este tipo de integridade garante a correspondncia entre instncias de entida-des e utilizado para estabelecer os relacionamentos. Na fase de modelagem fsica so utilizadas as constraints chave estrangeira e chave primria para garantir a integridade referencial destes relacionamentos.

Uma das principais dvidas de quem est comeando a aprender bancos de dados NoSQL sobre os relacionamentos e os joins. Os iniciantes em NoSQL sentem dificuldade em compreender que no necessrio fazer joins e relacionar as entidades ou colees no mundo NoSQL, pois o tipo de tratamento para obter os dados outro.

Por exemplo, a Figura 1 mostra um modelo simples de usurios (users) e suas habilidades (skill). Neste cenrio, a modelagem re-lacional tradicional cria trs tabelas representadas pelas colunas da Figura 1: uma tabela para armazenar os usurios (users), uma tabela para as habilidades (skill) e uma tabela de ligao entre usu-rios e habilidades (user_skill), configurando um relacionamento N:M que foi implementado como dois relacionamentos 1:N.

Figura 1. Relacionamento clssico entre usurios e habilidades

De acordo com a Figura 1, um usurio representado pela cor vermelha, trs habilidades que ele possui so representadas pela cor azul clara e a indicao que este usurio possui estas habili-dades indicada pela cor amarela. Esta a maneira tradicional e clssica de representar este relacionamento.

O relacionamento entre usurios e habilidades pode ser repre-sentado de diversas maneiras no mundo NoSQL, dependendo de qual paradigma se utiliza para armazenar os dados. Contudo, fato que as tecnologias NoSQL possuem uma tendncia a repre-sentar entidades e relacionamentos de forma diferente. No caso da modelagem tradicional, o relacionamento assumiu a forma de uma entidade adicional (user_skill) e o modelo final acabou

com trs entidades. Supondo que desejamos modelar este mesmo cenrio em um banco de dados NoSQL orientado a grafos, uma possvel representao mostrada na Figura 2, onde nota-se que a modelagem do cenrio feita de acordo com ns e arestas de um grafo.

Figura 2. Representao do relacionamento entre usurios e habilidades em um grafo

Alm da representao na forma de grafo, muito comum encontrar os relacionamentos do tipo N:M ou 1:N embutidos dentro de uma mesma entidade nos bancos NoSQL orientados a documentos. Tal representao realizada por meio de um atri-buto que contm outra coleo que por sua vez contm diferentes documentos. Este tipo de abordagem embutida permite encadear dentro de uma mesma entidade diferentes tipos de relacionamen-tos sem a necessidade de se criar novas entidades no modelo. uma maneira diferente de enxergar os relacionamentos sem precisar separ-los em entidades individuais e depois relacion-las de alguma forma.

A Figura 3 exemplifica este tipo de relacionamento embutido colocando lado a lado como seria a modelagem tradicional das entidades Book, Album, Track e Jeans no formato relacional (lado esquerdo da figura) e no formato embutido (lado direito da figura) como um documento JSON, que uma forma de representao de dados utilizada por bancos de dados NoSQL orientados a documentos.

possvel notar na Figura 3 que certos atributos das entidades da direita representam outros documentos com outras caractersticas, porm eles esto dentro dos documentos da coleo. Este o caso do atributo Details da coleo Product, pois ele possui os atributos Model, Length e Width que no existem em Product.

A modelagem tradicional possui uma tendncia de se concentrar mais nas entidades do que nos relacionamentos. Entretanto, na modelagem voltada para bancos de dados NoSQL os relaciona-mentos so tradados de forma diferenciada devido possibili-dade de represent-los de diferentes formas (arestas em grafos, embutidos em documentos) e tambm flexibilidade de criao de atributos para as entidades. Isto faz com que cenrios onde seja



necessrio representar hierarquias, mltiplos relacionamentos de acordo com o tempo, rvores e grafos, sejam mais atrativos para a modelagem NoSQL do que a modelagem relacional. Devido a esta caracterstica no a toa que cada vez mais profissionais veem optando por tecnologias NoSQL para modelar dados prove-nientes de redes sociais e relacionamentos entre pessoas, objetos, situaes, eventos, preferncias e comportamentos.

Figura 3. Exemplo de relacionamento embutido no formato JSON

Outro grande motivador para o uso de tecnologias NoSQL que remete modelagem o armazenamento de objetos utilizados pela aplicao diretamente no banco de dados. Porm este armazenamento nem sempre direto, ou seja, a aplicao deve fazer uso de algum framework ou ORM (Object-Relational Mapping) para realizar a persistncia dos objetos. Aqui, tanto as tecnologias NoSQL como SQL permi-tem este tipo de armazenamento, no entanto bancos de dados de documentos possuem uma pequena vantagem por utilizar internamento formatos como JSON, que j so apropriados para a serializao e persistncia de objetos.

Os profissionais que esto acostumados a enxergar os rela-cionamentos entre entidades da maneira tradicional podem ficar um pouco confusos com relacionamentos embutidos ou a representao dos relacionamentos na forma de um grafo. Para explicar melhor, vale a pena recorrer a aquela famosa frase: Quando tudo que se tem um martelo, a tendncia imaginar todos os problemas como um prego e sair mar-telando tudo.

A modelagem tradicional trata os relacionamentos atravs da colocao de atributos em entidades diferentes. Uma vez que o relacionamento esteja criado no modelo, comum utilizar um JOIN em uma instruo que compara o valor de atributos em diferentes tabelas.


A maneira de se obter dados atravs dos relacionamentos um pouco diferente com as tecnologias NoSQL. Nestes cenrios utiliza-se algum tipo de algoritmo para percorrer o grafo ou rotina recursiva para chegar at um nvel especfico de dado dentro de vrios documentos. Este tipo de mudana de pensamento deve ser encarado no como algo mais complexo e difcil, mas sim como algo que adequado e faz muito sentido em determinados cen-rios. O mesmo vale para outras tarefas comuns no mundo SQL, como filtros (clusula WHERE), agregaes (clusulas GROUP BY e HAVING) e ordenaes (clusula ORDER BY), apenas para citar alguns exemplos.

importante destacar que tanto a modelagem tradicional como a modelagem NoSQL permitem fazer o armazenamento de pra-ticamente qualquer dado em qualquer cenrio. A diferena est nas possibilidades, quantidade de esforo de implementao, recursos e outros elementos prticos que podem tornar mais simples e rpido o desenvolvimento da soluo e do modelo de acordo com o contexto e caractersticas dos dados. Quem j possui alguma experincia com modelagem sabe que sempre vai haver mltiplas solues para os problemas dependendo do contexto, porm cada uma possui certas vantagens e desvantagens que devem ser analisadas alm das recomendaes gerais, frmulas prontas, diretrizes e comentrios do tipo via de regra.

claro que existem vrias implicaes, tanto para o banco de dados como para as aplicaes, quando se utiliza as tcnicas de NoSQL de modelagem, que vo contra as integridades de entidade, domnio e referencial. Contudo, aqui preciso estar com a mente aberta para compreender novas formas de se enxergar como os dados so modelados e vo se comportar quando eles estiverem armazenados em um banco de dados NoSQL. Em outras palavras, preciso ter mente aberta para compreender outras abordagens que vo contra o que j est estabelecido pela modelagem rela-cional tradicional.

ConclusoEste artigo apresentou uma discusso sobre a modelagem de

bancos de dados relacional e bancos de dados NoSQL. As principais tcnicas de modelagem tradicionais foram apresentadas e compa-radas com o que possvel realizar com as tecnologias NoSQL.

Saber modelar um banco de dados exige muito mais do que listar entidades, criar relacionamentos e detalhar atributos. Modelar uma tarefa que envolve compreenso, representao, abstrao, organizao e outros aspectos que se distanciam das atividades prticas de implementao de um modelo de dados, seja ele um modelo relacional ou no.

As tecnologias NoSQL permitem novas maneiras de se pensar em como a modelagem pode ser realizada, especialmente quando h necessidade de flexibilizao de armazenamento e representao de relacionamentos complexos e no h uma necessidade grande de manter as integridades de domnio, entidade e relacional.

Mauro [email protected] / @pichiliani bacharel em Cincia da Computao, mestre e doutorando pelo ITA (Instituto Tecnolgico de Aeronutica) e MCP, MCDBA e MCTS. Trabalha h mais de 10 anos utilizando diversos bancos de dados SQL e NoSQL. colunista de SQL Server do web site iMasters (http://www.

imasters.com.br) e mantenedor do DatabaseCast (@databasecast), o podcast brasileiro sobre banco de dados.

autor

links:

artigo noSQl Data Modeling Techniques, de ilya Katsovhttp://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

Repositrio de modelos relacionais Database answerhttp://www.databaseanswers.org/data_models/

D seu voto em www.devmedia.com.br/sqlmagazine/feedback

Ajude-nos a manter a qualidade da revista!

voc gostou deste artigo?


Porque este artigo til:Neste artigo sero apresentados recursos fundamentais para mo-

nitoramento de banco de dados com relao a desempenho. Neste

contexto, sero exemplificadas algumas alternativas para se obter

diagnsticos de problemas de alto consumo de recursos em um ser-

vidor SQL Server, visando a realizao de tuning por parte do DBA.

O objetivo principal do tuning em um banco de dados a resoluo

de problemas relacionados a desempenho que tornam insatisfatria

a realizao de consultas e transaes SQL. Os sintomas de lentido

podem ser frequentemente relatados por usurios de sistemas ou de

banco de dados; ento cabe ao DBA a tarefa de investigar, diagnosticar

e resolver o problema atravs da criao de ndices, gerao e atualiza-

o de estatsticas ou at mesmo alterar a lgica de alguma consulta

SQL, tendo como meta a melhoria contnua da performance.

Resumo DevMan

Conhea recursos importantes para a execuo de tuning de banco de dados

Realizando tuning com o SQL Server 2012

Com a crescente demanda por tecnologia da informao dentro das organizaes, diversos aspectos so levados em considerao pela rea de TI visando a entrega de servios e sistemas para ala-vancar e sustentar os negcios, como a disponibilidade e o desempenho, itens que geralmente andam correla-cionados e que exigem altos investimentos.

Para garantir que um sistema de informao tenha uma performance adequada aos processos de negcio e no gere descontentamentos e reclamaes por parte dos usurios, um banco de dados deve garantir que todas as consultas e transaes SQL sejam retornadas o mais rpido possvel, de forma consistente e sem pontos de falha. Para isso, preciso que o administrador de banco de dados saiba como monitorar seu banco de forma prtica e eficiente, aplicando conceitos para realizao de tuning com o objetivo de garantir rpida resposta aos processos que so submetidos instncia. Alm disso, importante que o DBA conhea as caractersticas e a criticidade dos principais sistemas utilizados nas em-presas em que atua, para que a anlise seja completa e mais precisa possvel.

Neste contexto, dando nfase especificamente ao desempenho em um ambiente de produo, este artigo ir abordar conceitos e dicas para anlise de sesses no banco de dados, bem como a identificao de processos consumidores de recursos atravs de ferramentas do prprio SQL Server, como SQL Server Management Stu-dio e SQL Profiler. Alm disso, sero destacadas algumas recomendaes sobre a utilizao de alternativas para controlar o consumo de CPU e memria em um servidor SQL Server, como tambm o uso de novos objetos para administrao e monitoramento de um banco SQL.

Desempenho em um banco de dadosDiariamente, em uma equipe de desenvolvimento de

sistemas, diversas funcionalidades so desenvolvidas tendo como um dos seus objetivos a entrega cada vez

mais frequente para atender a solicitaes para correes de bugs e/ou melhorias. No entanto, aps o setor de desenvolvimento rea-lizar as liberaes das rotinas criadas ou alteradas para a equipe de testes, geralmente o que ocorre so validaes sobre a lgica e operacionalidade do sistema. Deste modo, um aspecto fundamen-tal para o usurio final acaba sendo desprezado: o desempenho.

Com relao a este importante requisito, permanecem aber-tas algumas questes sobre as dificuldades que as reas de desenvolvimento de sistemas enfrentam para manter uma es-trutura adequada para a execuo dos testes, tais como custos operacionais, de infraestrutura e de pessoal. Quanto rotina de testes, a mesma deveria ser executada tendo como base o nmero de sesses existentes no banco de dados de produo, ou ao menos, baseando-se em sua proporcionalidade. Porm, na prtica, os testes pr-produo quase nunca refletem a reali-dade do contexto organizacional, justamente por seguirem um fluxo onde poucas sesses de banco de dados so abertas para submeter o processo de execuo dos testes. Como resultado disso, os reflexos dos problemas de performance so observados


quase sempre em produo, onde diver-sos sistemas so executados de forma paralela, gerando concorrncia entre sesses ativas e sobrecarga no servidor de banco.

Partindo desta problemtica, um item de fundamental importncia para um DBA, dentre tantos outros, avaliar o desempenho do banco de dados j pensando na possibi-lidade de realizar o tuning. No SQL Server, diversas so as possibilidades de se alcanar este objetivo, seja atravs da execuo de scripts de monitorao, ferramentas grfi-cas que geram dashboards com indicadores e mtricas sobre o tempo de execuo de rotinas, ou mesmo com o resumo dos re-cursos consumidos em uma instncia SQL. Assim, cada administrador de banco far sua anlise de acordo com sua necessidade, at porque os ambientes de produo variam muito de empresa para empresa.

Aliado a estes aspectos, podem ser ob-servados alguns benefcios com relao ao monitoramento de bancos de dados SQL Server, tais como: Ao monitorar os tempos de resposta de consultas e transaes SQL, possvel de-terminar se o desempenho satisfatrio ou se h necessidade de criao de novos ndi-ces, bem como a eliminao de outros; Ao monitorar as consultas SQL que so disparadas na instncia, pode-se averiguar se as mesmas retornam os resultados desejados ou se elas podem sofrer ajustes em sua lgica, visando otimizar o tempo de resposta e garantir que somente os dados necessrios sejam retornados ao usurio, ou a outro procedimento existente no banco; Observar os planos de execuo das consultas SQL para identificao de pro-blemas com leituras completas em uma ta-bela, tambm chamadas de Full Table Scan, evitando que taxas excessivas de leituras a disco sejam recorrentes no banco.

Estes so apenas alguns dos benefcios quando falamos em tuning de banco de dados, os quais certamente podero garan-tir a satisfao dos usurios dos sistemas existentes nas organizaes, provendo a mxima otimizao deste poderoso geren-ciador de banco chamado SQL Server.

Recursos para monitorar um bancoCertamente um aspecto de extrema

importncia para um administrador de banco de dados conhecer as diferentes maneiras de se realizar tuning em uma instncia SQL Server. No entanto, para que isto seja possvel, necessrio obter conhecimento sobre as ferramentas que podem ser empregadas para identificar e diagnosticar problemas de performance em um servidor de banco de dados. Uma destas ferramentas, que existe desde a verso 2000 do SQL Server, o Activity Monitor, aprimorado na verso 2012 para dar maior visibilidade grfica para o monitoramento das sesses conectadas instncia. O Activity Monitor pode ser acionado atravs do SQL Server Manage-ment Studio, utilizando um cone existente na barra de tarefas, ou aps clicar com o boto direito sobre o servidor de banco e selecionar a opo Activity Monitor.

Uma vez acionada a ferramenta, pode-se definir o intervalo de tempo de refresh em que o SQL Server usar para trazer as informaes para os grficos, bem como o conjunto de sesses conectadas, podendo-se filtrar pelo status das transaes, como runnable, running ou suspended, para me-lhor identificao das sesses ativas. Alm destes recursos e outras possibilidades de filtragem, a ferramenta ainda apresenta

uma lista dos diferentes tipos de recursos em espera (como PAGEIOLATCH_EX, ASYNC_NETWORK_IO e CXPACKET), grficos de consumo de I/O por datafiles e principais transaes SQL executadas na instncia, podendo-se ordenar o resultado pelo consumo de CPU, leituras lgicas e fsicas em disco ou consultas com maior consumo de memria e tempo de resposta, conforme podemos observar na Figura 1.

O Activity Monitor ainda permite capturar as transaes SQL que esto sendo executadas no banco, bem como monitorar locks e eliminar sesses atravs da opo kill.

Alm desta excelente alternativa para capturar sesses em um banco de dados SQL Server, existem outras opes para auxiliar o monitoramento e diagnosticar problemas relacionados performance, como as stored procedures de sistema. Atra-vs delas possvel, por exemplo, realizar o rastreamento de sesses SQL utilizando o seguinte conjunto de procedures: sp_trace_create, sp_trace_generateevent, sp_trace_sete-vent, sp_trace_setfilter e sp_trace_setstatus. Estas so usadas para monitorar sesses SQL conectadas na instncia e identificar as transaes executadas.

Ainda analisando as procedures do SQL Server como alternativas para o monitoramento, podemos observar

Figura 1. Viso geral dos grficos existentes na ferramenta Activity Monitor



outras que so muito utilizadas para monitorar sesses de usurio. So elas: sp_who, que fornece informaes de usurios e processos ativos, mostrando inclusive a instruo executada no banco; sp_lock, que apresenta informaes sobre bloqueios, como ID do objeto da base de dados, ID do ndice, tipo de bloqueio ou recurso ao qual se aplica o bloqueio; sp_spaceused, a qual mostra uma estima-tiva da quantidade atual de espao em disco utilizada por uma tabela ou pelo banco de dados inteiro; e sp_monitor, que exibe estatsticas, uso de CPU, uso de I/O e a quantidade de tempo ocioso de uma sesso desde a ltima execuo desta stored procedure.

J com relao identificao de pro-cessos ativos no SQL Server, com o ob-jetivo de capturar eventos de sesses da base, como o incio de uma transao at sua concluso, monitoramento de erros, deadlocks e consumo de recursos fsicos no servidor de banco de dados, pode ser utilizada a ferramenta SQL Server Profi-ler. Atravs dela, os dados coletados para uma ou mais sesses da base podem ser salvos em uma tabela ou exportados para um arquivo, para ser posteriormente analisado pelo DBA no diagnstico de algum problema existente.

Para monitorar as transaes e sesses de um banco de dados SQL Server exis-tem ainda alternativas como o System Monitor, que contribui para rastrear o uso de recursos do servidor, tal como o nmero de solicitaes de pginas do gerenciador de buffers em uso, permitin-do analisar o desempenho e a atividade do servidor por meio de objetos ou contadores definidos pelo usurio para monitorar eventos. O System Monitor deve ser acionado a partir do Windows Server. Com ele, contadores de desem-penho para uma ou mais instncias do SQL Server podem ser criados de forma muito simples.

De maneira sucinta e para rpida con-sulta, um banco de dados SQL Server contempla ainda a existncia de funes internas que exibem estatsticas que mostram a atividade do SQL Server desde o momento em que o servidor foi

iniciado. Essas estatsticas so arma-zenadas em contadores pr-definidos do SQL Server. Como exemplos dessas funes, podem-se citar: @@CPU_BUSY, que contm indicaes sobre o tempo de execuo do SQL Server pela CPU; @@CONNECTIONS, que exibe o nme-ro de conexes ou tentativas de conexo do SQL Server; e @@PACKET_ERRORS, que mostra o nmero de pacotes de rede existentes nas conexes do SQL Server.

Por fim, o SQL Server ainda possibilita examinar as estatsticas de desempenho e a consistncia lgica e fsica de um ban-co de dados, usando instrues DBCC (Database Console Command), bem como realizar, atravs do recurso Display the Estimated Execution Plan, uma anlise sobre o desempenho das instrues SQL executadas na base que se deseja ajustar. O otimizador de banco de dados, que utiliza as estatsticas do SQL Server, d recomendaes sobre adio, remoo ou modificao de ndices.

Tendo como base estas alternativas para anlise de performance de um banco, possvel monitorar uma base de dados SQL Server visando identificar processos e rotinas SQL que apresentam lentido na instncia. Para isto, uma base deve ser verificada com frequncia e os resultados devem servir para gerar um diagnstico com o intuito de identificar a causa de um possvel problema. Com base nestas opes indicadas pelo artigo, adminis-tradores de bancos de dados podem criar suas prprias consultas SQL para verifi-car e capturar sesses no banco.

alternativas para capturar sesses no banco

Embora o SQL Server disponibilize algu-mas procedures, instrues DBCC (BOX 1), funes e ferramentas para monitorar processos no banco de dados, conforme vimos, existem outras maneiras de descobrir sesses causadoras de problemas de perfor-mance, tais como reteno de tempo de CPU, consumo elevado de memria ou concorrn-cia de disco (I/O). Uma delas conhecida como Dynamic Management Views (DMVs), ou vises de gerenciamento dinmico, que servem para retornar informaes sobre o

estado do servidor, identificar problemas e proporcionar o ajuste do desempenho em uma instncia SQL Server. Estas views iniciam sempre com o prefixo dm em seus nomes, para diferenciar dos demais objetos de sistema. Atravs do site da Microsoft podem-se obter informaes de forma com-pleta sobre estas views, como suas caracters-ticas e principais funcionalidades.

Instrues DBCC (Database Console Command ou Comandos

de Console de Banco de Dados) servem para realizar tarefas

em uma instncia SQL Server com o objetivo de validar

a integridade do banco de dados, bem como habilitar o

rastreamento de sesses e retornar informaes diversas

sobre objetos do banco de dados.

BOX 1. Instrues DBCC

Para exemplificar o uso de tabelas de

sistema e das DMVs, duas consultas muito utilizadas para monitorar sesses ativas numa instncia SQL Server so apresen-tadas na Listagem 1.

Ambas apresentam resultados seme-lhantes, pois so filtradas somente as sesses ativas por meio da coluna sta-tus da tabela sysprocesses (existente na base Master) e da coluna status da view dm_exec_requests. A principal diferena que a segunda consulta retorna uma co-luna chamada statement_executing, que responsvel por retornar a instruo SQL executada naquele momento no banco.

Estas consultas provavelmente sero alternativas quase que imediatas para uma anlise de sesses ativas em um momento de lentido no banco de dados. Assim, uma vez identificadas as sesses que demoram muito tempo para sair do status de ativa, tais como suspended, running ou runnable, prudente captu-rar a transao SQL que est rodando e iniciar o processo de tuning, o qual ser detalhado mais adiante.

Mantendo o foco sobre a anlise das sesses existentes no banco de dados, possvel tambm verificar quais objetos esto consumindo mais recursos em uma instncia, como mostrado, por exemplo, na Listagem 2.

Neste exemplo, a consulta retorna uma lista com as 25 stored procedures executadas


Ainda com relao aos diferentes objetos de um banco de dados, existe uma alternativa interessante para se monitorar e observar quais so estes objetos dentro de uma base especfica que esto consumindo mais memria RAM, como podemos verificar na Listagem 3.

Listagem 1. Consultas para identificar sesses ativas.

-- Consulta 1 - VERIFICA PROCESSOS ATIVOSSelect Processo = spid,Computador = hostname,Usuario = loginame,[Status] = [status],BloqueadoPor = blocked,TipoComando = cmd,Aplicativo = program_namefrom master..sysprocesses where status in (runnable, suspended, running)order by blocked desc, status, spid

-- Consulta 2 - VERIFICA SESSES ATIVAS COM SQL STATEMENTSELECT r.session_id ,r.[status] ,r.wait_type ,r.scheduler_id ,SUBSTRING(qt.[text], r.statement_start_offset / 2, ( CASE WHEN r.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.[text])) * 2 ELSE r.statement_end_offset END - r.statement_start_offset ) / 2) AS [statement_executing] ,DB_NAME(qt.[dbid]) AS [DatabaseName] ,OBJECT_NAME(qt.objectid) AS [ObjectName] ,r.cpu_time ,r.total_elapsed_time ,r.reads ,r.writes ,r.logical_reads ,r.plan_handleFROM sys.dm_exec_requests AS rCROSS APPLY sys.dm_exec_sql_text(sql_handle) AS qtWHERE status IN (suspended, running, runnable)ORDER BY r.scheduler_id ,r.[status] ,r.session_id ;

Listagem 2. Consulta que retorna stored procedures com maiores taxas de leituras lgicas.

SELECT TOP ( 25 ) p.name AS [SP Name] , qs.total_logical_reads AS [TotalLogicalReads] , qs.total_logical_reads / qs.execution_count AS [AvgLogicalReads] , qs.execution_count , ISNULL(qs.execution_count / DATEDIFF(Second, qs.cached_time, GETDATE()),0) AS [Calls/Second] , qs.total_elapsed_time , qs.total_elapsed_time / qs.execution_count AS [avg_elapsed_time] , qs.cached_timeFROM sys.procedures AS p INNER JOIN sys.dm_exec_procedure_stats AS qsON p.[object_id] = qs.[object_id]WHERE qs.database_id = DB_ID()ORDER BY qs.total_logical_reads DESC ;

Listagem 3. Consulta que retorna os objetos com maior consumo de memria na base.

SELECT OBJECT_NAME(p.[object_id]) AS [ObjectName] ,

p.index_id ,

COUNT(*) / 128 AS [Buffer size(MB)] ,

COUNT(*) AS [Buffer_count]

FROM sys.allocation_units AS a

INNER JOIN sys.dm_os_buffer_descriptors

AS b ON a.allocation_unit_id = b.allocation_unit_id

INNER JOIN sys.partitions AS p ON a.container_id = p.hobt_id

WHERE b.database_id = DB_ID()

AND p.[object_id] > 100

GROUP BY p.[object_id] ,

p.index_id

ORDER BY buffer_count DESC ;

na instncia que apresentaram as taxas mais altas de leituras l-gicas, em ordem decrescente. Este indicador poder sugerir quais objetos necessitam de reviso em sua lgica, ou at mesmo ajustes para readequao de ndices nas respectivas colunas utilizadas. As procedures retornadas fazem parte das estatsticas do SQL Server, coletadas desde o ltimo reincio da instncia do banco.



Neste caso, uma informao muito importante para diagnstico o resultado do campo Buffer size(MB), que apresenta o valor em MB que o respectivo objeto est consumindo na instncia do banco de dados. Para este exemplo, foi utilizada a base de experimentos j consagrada no SQL Server, AdventureWorks2012, disponvel para download de forma gratuita. Na Figura 2 podemos verificar o resultado da consulta apresentada na Listagem 3, mesmo que devido pouca utilizao dessa base no tenhamos valores na coluna Buffer size(MB).

Figura 2. Resultado da consulta sobre buffer de objetos

Outra importante alternativa para avaliar a possibilidade de realizao de um tuning verificar o uso de ndices no banco de dados. Quando um ndice criado sobre uma coluna de uma tabela, o otimizador do SQL Server passa a adot-lo para consul-tas baseado nas estatsticas coletadas e atualizadas pelo banco. No entanto, o mesmo ndice pode pertencer a uma tabela muito utilizada para instrues DML (Data Manipulation Language), fazendo com que este ndice fique subutilizado para consultas e acabe participando de processos de insero e atualizao de dados, podendo gerar atrasos nestes processos na medida em que diversas linhas inseridas nesta coluna passam por ordenaes de dados. Na Listagem 4 verificamos um exemplo de consulta que identifica ndices que so usados com mais frequncia para escrita do que para leitura.

Neste caso, a coluna Difference, resultante da consulta da Listagem 4, ir mostrar em ordem decrescente os ndices com maiores diferenas entre leituras e escritas, para anlise da real necessidade dos mesmos. Quanto maior a diferena, menos uti-lizado para leitura o ndice est sendo na base de dados e, desta forma, poder ser reavaliado sobre sua real necessidade junto aos sistemas existentes no banco.

Dicas para a realizao de tuning de banco de dadosAo capturarmos as transaes SQL responsveis por deixar o

servidor de banco de dados lento, devemos partir para a fase de

correo e ajustes de desempenho, tambm chamada de tuning de banco de dados. Para que isto ocorra, alguns aspectos so fundamentais para auxiliar um DBA a obter xito em seu plano de ao, a saber: O uso de ferramentas para realizar tuning torna o trabalho do DBA mais eficiente, visto que as mesmas avaliam as estatsticas do banco e realizam sugestes para melhoria de rotinas SQL. Desta forma, A Microsoft recomenda a utilizao da Database Engine Tuning Advisor (DTA), pois ela pertence ao conjunto de produtos do SQL Server e trabalha de forma contgua com o SQL Profiler. Atravs da ferramenta DTA possvel verificar ndices faltantes empregando o recurso Execution Plan, tambm existente no Management Studio; Realizar constante anlise sobre os ndices e estatsticas das tabelas das bases de dados. Muitas vezes a adio de um ndice gera ganhos em torno de 99% para o plano de execuo, porm deve-se ter cuidado para no cri-los em excesso; Recomenda-se que, antes de realizar o tuning de banco de dados diretamente em ambientes de produo, as customizaes sejam feitas em bancos de testes, principalmente quando utilizadas as ferramentas SQL Profiler e DTA, bem como outros sistemas para ajustes de desempenho. Estas ferramentas podem sobrecarregar um servidor de produo dependendo dos recursos de hardware disponveis; Analisar se existem funes (functions) que possam gerar gar-galos no desempenho das consultas, como funes na clusula WHERE;

Averiguar os parmetros de instncia do banco de dados, atravs da procedure sp_configure ou da tabela sys.configurations, e propor alteraes de acordo com o ambiente e seus recursos fsicos disponveis; Verificar a lgica das rotinas SQL e propor melhorias dentro das boas prticas da Microsoft.

Listagem 4. Consulta que aponta os ndices com maior taxa de escrita do que de leitura.

SELECT OBJECT_NAME(s.[object_id]) AS [Table Name] , i.name AS [Index Name] , i.index_id , user_updates AS [Total Writes] , user_seeks + user_scans + user_lookups AS [Total Reads] , user_updates - ( user_seeks + user_scans + user_lookups ) AS [Difference]FROM sys.dm_db_index_usage_stats AS s WITH ( NOLOCK ) INNER JOIN sys.indexes AS i WITH ( NOLOCK ) ON s.[object_id] = i.[object_id] AND i.index_id = s.index_idWHERE OBJECTPROPERTY(s.[object_id], IsUserTable) = 1 AND s.database_id = DB_ID() AND user_updates > ( user_seeks + user_scans + user_lookups ) AND i.index_id > 1ORDER BY [Difference] DESC , [Total Writes] DESC , [Total Reads] ASC ;


ConclusoComo foi possvel observar no decorrer do artigo, o SQL Server

2012 oferece poderosas ferramentas para monitoramento de banco de dados, tendo como objetivo principal a realizao de tuning uma vez identificados os problemas de desempenho. De fato, cabe ao administrador de banco de dados um estudo prtico para analisar e identificar possveis gargalos de desempenho; seja esse estudo feito por ferramentas como Activity Monitor ou System Monitor, atravs da execuo de Dynamic Management Views (DMVs), ou pelas ferramentas SQL Profiler e DTA, ou ainda um combinado entre algumas delas.

Por fim, cabe ressaltar que a realizao de tuning requer, muitas vezes, pacincia e dedicao, pois cada ambiente de banco de da-dos possui caractersticas prprias e devido a isso um problema de performance no se resolve a partir de uma simples receita de bolo. Alm disso, necessrio que haja um bom entendimento prvio sobre o negcio e muito dilogo com as equipes de desen-volvimento dos sistemas envolvidos, possibilitando assim facilitar a realizao de tuning da maneira mais assertiva possvel.

Fernando [email protected] no ramo de Tecnologia da Informao h mais de 9 anos. bacharel em Administrao de Empresas com nfase em Anlise de Sistemas e ps-graduado em Gesto Estratgica de TI, na PUC-RS. Possui certificaes de banco de dados e gesto de TI. Trabalhou tambm com

bancos de dados Oracle e Ingres, alm de ter realizado diversos cursos na rea. Atua como DBA SQL Server em empresa prestadora de servios em consultoria de banco de dados, em Porto Alegre (Advanced IT). Participou da criao e execuo de grandes projetos de alta disponibilidade, ambientes de alta criticidade e complexidade, na rea de banco de dados e sistemas de informaes.

autor

links:

SQl Server 2012 Tuning e ferramentas de monitoramento.http://technet.microsoft.com/pt-br/library/ms189081.aspx

Dynamic Management views (DMvs).http://technet.microsoft.com/pt-br/library/ms188754.aspx

Download de base de dados exemplo para SQl Server.http://msftdbprodsamples.codeplex.com/releases/view/93587

Diferentes Wait Types no SQl Server 2012http://msdn.microsoft.com/en-us/library/ms179984.aspx

instrues DBCC SQl Server 2012http://technet.microsoft.com/pt-br/library/ms188796.aspx





Porque este artigo til:Com a anlise de informaes sobre eventos de espera, possvel

identificar gargalos de performance do seu servidor e direcionar

os esforos na otimizao de consultas. Tambm possvel traar

perfis de utilizao do seu ambiente e identificar qual o melhor

aproveitamento das janelas dirias para execuo de rotinas batch

sem prejudicar o ambiente produtivo. Para entender como isto pode

ser feito, este artigo trata da anlise dos eventos de espera do seu

servidor SQL Server e de como podemos utilizar essas informaes

em anlises de desempenho e performance, direcionando nossos

esforos para a otimizao de consultas ou at mesmo o upgrade

de nossos servidores.

Resumo DevMan

Analisando eventos de espera com foco em performance do servidor SQL Server

Eventos de espera no SQL Server

O desempenho das aplicaes tema recor-rente em qualquer empresa, independente de seu porte, do tipo de ambiente e do perfil dos softwares que so executados.

Para medir o desempenho da aplicao, temos uma srie de ferramentas que nos auxiliam a identificar problemas, minimizar gargalos e consequentemente melhorar continuamente o comportamento de nossos sistemas. Podemos citar como exemplo os contadores do performance monitor (perfmon), os traces do prprio SQL Server que nos direcionam para as consultas mais lentas ou que consomem mais recursos e tam-bm os Eventos de Espera (Wait Events) do nosso servidor de banco de dados. E sobre esse ltimo item que falaremos nesse artigo. O que so os eventos de espera? Como coletar essas informaes? O que elas nos dizem? Quais eventos devem ser tratados com mais ateno e quais podem ser descartados na minha anlise? Responderemos essas perguntas ao decorrer do artigo.

o que so os eventos de espera?Sempre que o banco de dados aguarda por algum

recurso para que um determinado processamento seja concludo, essa informao registrada. A espera pode ser por CPU, por disco, por escrita, no importa. Qualquer espera para que uma ao seja concluda armazenada. Esses so os chamados eventos de espera. Analisando essas informaes podemos determinar se temos uma grande espera por lock, por exemplo, se temos problemas com paralelismo de consultas ou com escrita ou leitura de disco. Isso nos ajuda no direcionamento dos trabalhos de performance.

onde ficam essas informaes e como acess-las?Os eventos de espera so registrados de forma

crescente no servidor e s so zerados aps uma

reinicializao do sistema. Dessa forma, uma foto dos eventos de espera do banco de dados de agora sempre maior que uma de minutos atrs.

Para obter essas informaes existem duas maneiras: Atravs do comando DBCC:

DBCC sqlperf (waitstats)

Por meio da view DM_OS_WAIT_STATS:

select * from sys.dm_os_wait_stats

Embora ligeiramente diferentes, os comandos acima retornam as mesmas informaes. Devemos, no entanto, manter nosso foco nas seguintes: Wait Type: Nome do evento de espera; Wait Time: Tempo acumulado de espera do evento.

Com essas informaes temos os eventos e o tempo de espera acumulado desde a ltima inicializao do servio de banco de dados.


Todos os eventos so importantes? difcil elencar eventos que sempre aparecero em suas anlises.

Pensando em priorizar nossa ateno, mais simples eliminarmos eventos que no tm relao com o tempo de resposta de nossa aplicao. Eventos do tipo Sleep e tambm Waitfor podem ser desconsiderados imediatamente por no influenciarem o tempo de resposta de nossas aplicaes. Alm desses, geralmente os eventos de sistema, como checkpoints do banco ou a limpeza da fila de processos so eventos que podem ser desconsiderados da anlise. Na Tabela 1 temos uma relao desses Wait Events.

Outros eventos que podem ser desconsiderados so eventos que ocorrem frequentemente, mas no tm relao com desem-penho, como eventos de backup e inicializao e desligamento do servidor.

Como colet-los?Executando um dos comandos que listamos anteriormente,

possvel ter uma ideia de como os eventos esto acumulados no exato momento da execuo. Mas isso no o bastante para que tenhamos uma viso clara do que acontece no que se refere espe-ra nos nossos bancos de dados. Para uma anlise mais detalhada, recomenda-se uma coleta contnua dessas informaes para que possamos ter uma viso linear, tal qual um monitor de desem-penho. A maneira mais simples para se fazer isso utilizando o SQL Server Agent e criando um JOB para que as informaes sejam coletadas.

Criando o JOBPara criar o job, vamos acessar nosso servidor e ir at o SQL

Server Agent, que fica na barra lateral esquerda. Expandindo essa seleo, possvel ver a pasta Jobs. Com um clique com o boto direito, a opo New Job estar disponvel. Basta clicar nessa opo, conforme indica a Figura 1.

Feito isto, uma nova tela para a criao do job ser disponibiliza-da (veja a Figura 2). Dentre as opes que temos do lado esquerdo, trabalharemos com trs delas:

Eventos de espera do tipo Idle, que podem ser desconsiderados em uma anlise de desempenho

SLEEP BROKER_TO_FLUSH DBMIRROR_EVENTS_QUEUE RESOURCE_QUEUE

WAITFOR SQLTRACE_INCREMENTAL_FLUSH_SLEEP ONDEMAND_TASK_QUEUE SLEEP_BPOOL_FLUSH

KSOURCE_WAKEUP BROKER_EVENTHANDLER REQUEST_FOR_DEADLOCK_SEARCH SLEEP_SYSTEMTASK

SLEEP_BPOOL_FLUSH BROKER_TRANSMITTER LOGMGR_QUEUE SLEEP_TASK

BROKER_TASK_STOP CHECKPOINT_QUEUE SLEEP_TASK SQLTRACE_BUFFER_FLUSH

XE_TIMER_EVENT CLR_SEMAPHORE CLR_MANUAL_EVENT WAITFOR

XE_DISPATCHER_WAIT DBMIRROR_EVENTS_QUEUE BROKER_RECEIVE_WAITFORPREEMPTIVE_OS_AUTHENTICATIO-NOPS

FT_IFTS_SCHEDULER_IDLE_WAIT DBMIRROR_WORKER_QUEUE PREEMPTIVE_OS_GETPROCADDRESS LOGMGR_QUEUE

SQLTRACE_BUFFER_FLUSH DBMIRRORING_CMD BAD_PAGE_PROCESS LAZYWRITER_SLEEP

CLR_AUTO_EVENT KSOURCE_WAKEUP OLEDB CHECKPOINT_QUEUE

BROKER_EVENTHANDLER BROKER_TRANSMITTER ONDEMAND_TASK_QUEUE REQUEST_FOR_DEADLOCK_SEARCH

Tabela 1. Relao de Wait Events

Figura 1. Criando o job

Figura 2. Wizard para criao de novo job

General: onde daremos as informaes gerais do job que esta-mos criando; Steps: onde configuraremos os passos que nosso job executar; Schedules: que onde agendaremos a execuo do job.



A primeira opo, General, onde daremos o nome ao nosso job, e onde podemos cadastrar uma breve descrio das atividades que esto relacionadas a ele (Figura 3). Na tela que disponibilizada para que informemos as configuraes, deveremos informar os seguintes campos: Name: Nome do job; Owner: Qual usurio o dono do job. Recomenda-se que seja um administrador; Description: Breve descrio dos passos relacionados ao job.

Figura 3. Informaes gerais sobre o job

Aps essas configuraes, passaremos aos passos (Steps) que nosso job executar. Steps so os passos que nosso job execu-tar. Por exemplo, se temos duas procedures que precisam ser executadas mandatoriamente uma aps a outra, adicionamos dois steps, e escrevemos o comando exec de cada procedure em um step separado. Dessa maneira, garantimos que a execuo do segundo procedimento s ser executado aps o termino do primeiro. Assim tambm conseguimos analisar o tempo de exe-cuo de cada objeto separadamente.

No menu lateral esquerdo, selecionando a opo Steps, uma tela com novas opes ser mostrada. Nessa nova tela, devemos selecionar a opo New... no canto inferior esquerdo (Figura 4). Essa opo criar um novo step.

A tela onde o novo step ser criado abrir com duas opes no menu lateral esquerdo: General: que onde vamos inserir o comando a ser executado; Advanced: que onde configuraremos o retorno do nosso job.

Na opo General da tela de configurao dos steps, necessrio que configuremos os seguintes parmetros (Figura 5): Step name: Nome do passo; Type: Tipo de comando a ser executado. No nosso caso, uma instruo Transact- SQL; Database: Em que banco de dados o comando ser executado. Como eventos de espera referem-se ao servidor como um todo, no importa em qual base o comando ser executado; Command: Comando que ser executado.

Para esse job, utilizaremos o comando DBCC SQLPERF. Essa instruo tira uma fotografia dos eventos de espera no momento da sua execuo. Veja a Listagem 1.

Figura 4. Criando um novo step

Listagem 1. Cdigo do job.

set nocount on

declare @run_date datetime

create table #temp ( timestamp datetime, wait_type sysname, requests bigint, wait_time bigint, signal_wait_time bigint)

set @run_date = getdate()

insert into #temp(wait_type, requests, wait_time, signal_wait_time)exec(dbcc sqlperf (waitstats))

update #temp set timestamp = @run_date

select * from #temp

drop table #temp

Observando esse cdigo, podemos perceber que criada uma tabela temporria onde so inseridos os dados resultantes do comando dbcc sqlperf (waitstats).

Como o comando dbcc no retorna a data em que ele foi exe-cutado, para que possamos trabalhar com uma linha do tempo,


adicionamos o horrio em que capturamos a informao. Esse tempo obtido atravs do trecho set @run_date = getdate() que se encontra logo aps a criao da tabela temporria. Aps a tabela estar pronta, um select dado para obtermos o record set.

Figura 5. Configurando o step

Figura 6. Configurando o arquivo de log

Para que o record set seja gravado em um arquivo de log, utili-zamos as opes contidas na pgina Advanced (Figura 6). nessa etapa que direcionamos o resultado das execues contidas no step. possvel salvar os logs de execuo em arquivos e at mesmo em tabelas.

Nessa tela, configuraremos apenas a opo Output file, com o arquivo de log. importante ressaltar que o arquivo j precisa existir, mesmo que vazio. Alm disso, o checkbox Append output to existing file deve ser marcado. Isso garante que a cada execuo, o resultado ser adicionado ao final do arquivo, caso contrrio ser mantido apenas a ltima execuo do step.

Com os steps configurados, preciso criar um gatilho que for-ar a execuo do job. Para isso precisamos definir o intervalo e o perodo que desejamos que a execuo dessas instrues seja realizada. O que garante a execuo do job seu schedule, e para configurar essas informaes passaremos para a opo Schedules, no menu lateral esquerdo, que ao ser acessado apresenta uma nova tela, semelhante da Figura 7. Nessa nova tela, no canto inferior direito, devemos selecionar a opo New....

Figura 7. Criando um novo schedule

Quando criamos um novo schedule, uma nova janela com vrias opes exibida (Figura 8). Nessa nova janela, configuraremos as opes: Name: Nome do schedule; Enabled: A seleo desse checkbox garante a execuo do job; Daily Frequency: Frequncia de execuo. No caso do exemplo, executaremos os comandos do nosso step a cada 10 minutos; Duration: Pode-se optar por um perodo pr-determinado de execuo. No caso do exemplo, utilizamos a opo no end date, que significa que nosso job nunca parar de executar automaticamente.



Ao final da tela, em um campo no editvel (o campo Summary), temos uma descrio por extenso de nosso agendamento para verificao e para que possamos aferir que nossas configuraes geraram realmente o schedule que desejamos.

Com essas opes configuradas, nosso job est pronto para ser executado, e para isto, basta clicar com o boto direito sobre ele e selecionar a opo Star Job at step... (Figura 9). Aps isso, o arquivo j pode ser visto carregado no diretrio especificado, conforme demonstra a Figura 10.

Figura 8. Configurando o agendamento

Figura 9. Sumrio de execuo

Figura 10. Arquivo gerado

Agora que temos os dados, precisamos transformar essas in-formaes quase ilegveis em informaes que possam ajudar na tomada de deciso.

analisando as informaesUma vez que temos os dados em mos, necessrio trat-los para

que possamos realizar as anlises e transformar todos esses dados em informaes analticas. Para interpretar essas informaes existem duas abordagens que precisam ser feitas de uma forma ou de outra. So elas, a anlise acumulada e a linear.

Anlise acumuladaComo comentamos anteriormente, os eventos de espera tm

valores acumulados. Isto significa que o ltimo snapshot do nosso job ter os valores maiores que o primeiro, e essa diferena ser o volume de espera que tivemos no perodo em que nossa coleta foi realizada. Ento, para identificar quais eventos de espera foram os mais expressivos durante nosso perodo de coleta, a anlise relativamente simples. Basta isolar em nosso arquivo de log a primeira execuo e tambm a ltima, e encontrar a diferena entre elas. Dessa maneira, se mantivermos o nosso job ativo por uma semana, subtraindo a primeira foto da ltima, teremos os nmeros de espera dessa semana de coleta.

Aplicando o Princpio de Pareto (veja o BOX 1), onde definimos os eventos responsveis por 80% do nosso tempo total de espera, no nosso exemplo obtivemos o grfico da Figura 11.

A Lei de Pareto (tambm conhecido como princpio 80-20), afirma que para muitos fenmenos, 80%

das consequncias advm de 20% das causas.

Por exemplo, uma livraria no pode ter todos os ttulos do mercado, portanto ela aplica a regra de

Pareto e foca em 20% dos ttulos que geram 80% da receita.

Trazendo isso para o universo do artigo, devemos focar nos eventos que representam 80% ou mais

da nossa espera acumulada.

BOX 1. Principio de Pareto

Essa anlise j nos d uma noo de onde nosso ambiente est perdendo tempo, mas no nos diz, por exemplo, quantos segun-dos de espera tm em cada evento. Para isso, precisamos de uma anlise mais detalhada, como veremos a seguir.

Anlise linearUma anlise mais complexa,

mas consequentemente mais completa que a acumulada, aquela em que traamos uma linha do tempo dos nossos snapshots. Essa abordagem consiste em subtrair o primeiro snapshot do seguinte, sucessi-vamente. Assim, se tivermos, por exemplo, 100 fotos no total


da coleta tero 100 pontos em nossa anlise, com a variao de um para o outro e no do ltimo para o primeiro. Dessa maneira possvel identificar perodos do dia em que temos picos de espera por determinado evento e relacionar com as consultas executadas naquele momento.

Aps realizar o tratamento do nosso arquivo, manualmente ou atravs de ferramentas ou procedures, teremos as informaes dispostas como mostra a Tabela 2.

Figura 11. Eventos de espera acumulados

Evento Momento 1 Momento 2 Momento n

Cxpacket 10 ms 30 ms 40 ms

Writelog 15 ms 55 ms 150 ms

Tabela 2. Eventos de espera tratados

O nmero encontrado entre um snapshot e outro corresponde ao nmero em milissegundos de espera por aquele recurso, naquele intervalo. Usando o nosso exemplo de intervalos de 10 minutos, o nmero encontrado ali corresponde a quanto tempo o servidor perdeu naqueles 10 minutos. Como veremos a seguir, os nmeros podem ser muito grandes.

O grfico exposto na Figura 12 mostra o comportamento do nosso servidor em um perodo til, considerando apenas os eventos que selecionamos no Pareto.

Nele podemos verificar que temos picos de at 3.800 segun-dos, ou seja, 63 minutos dentro de um intervalo de 10 minutos de coleta. Isso acontece por que o SQL soma aos Wait events a espera de todas as transaes que estiverem rodando no servidor. Por exemplo, se temos 10 queries executando e cada uma delas tem uma espera de seis segundos por CXPACKET (veremos a descrio desse e de outros eventos posteriormente), o SQL acumular para esse evento 60 segundos. Se estivermos realizando coletas com intervalos de 5 segundos, do momento 0 segundo para o momento 5 segundos, teremos uma espera

Figura 12. Eventos de espera na linha do tempo

acumulada de 60 segundos. Isso gera esperas exorbitantes, como podemos ver no grfico da Figura 13.

Figura 13. Espera de 500 minutos

Agora que identificamos nossos principais eventos, aqueles que mais agridem nosso servidor, falaremos um pouco mais sobre eles, sobre o que representam e para onde nos direcionam, e principal-mente sobre o que podemos fazer para tentar minimiz-los.

principais eventos de esperaAo longo da anlise nos deparamos com os eventos de espera.

Dissemos o tempo todo que eles direcionam nossa anlise e nos do pistas do que ocorre com nosso servidor e com nossas consultas. Ento o que eventos como CXPACKET e WRITELOG esto querendo nos dizer? Vamos direcionar nossa anlise para os eventos que encontramos em nossas anlises.

WRITELOGEsse evento nos aponta o tempo que as transaes do SQL

esperam por escrita no arquivo LDF. comum encontrarmos um nmero elevado desse evento em servidores que possuem o arquivo de dados (MDF) no mesmo disco do arquivo de log (LDF). Isso gera uma concorrncia por disco e tambm por trfego de



rede que pode ser minimizado com a movimentao do arquivo LDF para um disco fsico diferente do arquivo MDF.

Se os arquivos j estiverem em discos diferentes e essa es-pera continuar muito alta, pode-se tentar alterar o modo de recuperao do banco de dados para minimizar a escrita de logs de transao. Se essa for a opo, deve-se tomar cuidado com a frequncia de backups, j que o modo de recuperao simple, por exemplo, que minimiza a escrita por log, tambm impossibilita o backup de transaction log. Ficar sem o backup de transao perigoso e quem toma essa deciso deve estar ciente dos riscos.

CXPACKTCXPACKT o evento que registra o tempo que o servidor tem de

esperar por consultas que tm o processamento paralelizado.Quando o SQL calcula o plano de execuo de uma determinada

consulta, ele pode optar por dividir o processamento dessa ins-truo nos processadores que ele tem disponveis. Quando divi-dida, algumas partes terminam de executar antes das outras, po-rm enquanto todas no processarem, o record set no exibido. O tempo de espera entre a primeira e a ltima parte registrado como CXPACKT.

Para minimizar o nmero desse evento, preciso analisar as consultas que possuem os maiores nmeros de CPU Time (ms). Quanto maior o tempo de processamento, maior a possibilida-de de o SQL optar por paralelizar a execuo dessa consulta. Quando dizemos que o SQL escolhe se a consulta ser ou no paralelizada, estamos dizendo literalmente isso, que o servi-dor, baseado no plano de execuo, opta por paralelizar essa instruo em mais de um processador ou no. Essa definio feita pelo parmetro max degree of parallelism. Naturalmente ele configurado com o valor 0, e esse o sinal de que o SQL pode decidir quando paralelizar uma consulta. O evento CXPACKT pode ser zerado se esse parmetro for configurado com o valor 1. Isso indicar que o SQL s ter a sua disposio um CPU para a execuo de suas consultas.

Embora essa ao zere o tempo de espera por paralelismo, ela pode prejudicar muito os tempos de execuo. Portanto, se optar por uma configurao de valor 1, voc ter de indicar em cada query da sua aplicao qual ser o grau de paralelismo com o hint OPTION (MAXDOP N), onde N o nmero de CPUs que o servidor utilizar para paralelizar a execuo.

Embora essa opo d um maior controle sobre as consultas executadas, ela requer um conhecimento enorme da aplicao.

ASYNC_NETWORK_IOEste evento registra o tempo que o SQL Server espera para que

a aplicao trate a informao depois que ela j foi processada pelo banco de dados. Por exemplo: o SQL Server recebeu a solici-tao da aplicao, executou a instruo e devolveu o record set. O tempo de espera para que a aplicao trate a informao, indique que a transao foi realizada com sucesso e finali-ze a transao registrado como ASYNC_NETWORK_IO.

Como existem situaes em que diminuir o record set im-possvel, uma relao com o trfego de rede deve ser feita para que se verifique contenes nesse recurso. Caso as consultas no possam ser diminudas, um aumento na largura da banda de rede pode ser a soluo para minimizar nmeros altos de espera por esse recurso.

SOS_SCHEDULER_YELDA espera por SOS_SCHEDULER_YELD representa o socorro

do SQL Server para as threads que rodam no servidor. Literal-mente um SOS. O servidor de banco de dados nunca deixa uma thread esperando sem inici-la, ento imaginemos o seguinte cenrio: o banco de dados recebe e comea a executar uma con-sulta pesada e para melhorar a performance ele paraleliza essa execuo em todos os CPUs disponveis. nesse momento que se d a execuo de outra consulta. Como a primeira consulta est esperando por CXPACKT, o SQL opta por deix-la de lado um pouco e iniciar a execuo da segunda consulta. O tempo de espera pelo incio da execuo da consulta 2 e o tempo para que o SQL devolva a ateno para a consulta 1 so registrados como SOS_SCHEDULER_YELD.

Quanto mais velozes forem suas instrues, menor ser esse evento. Portanto, para que ele seja minimizado, devemos voltar nossa ateno para as consultas com maior tempo total de execuo (elapsed time). Diminuindo o tempo de execuo, diminuiremos o tempo de espera.

PAGEIOLATCH_SHEsse evento est relacionado espera pela transferncia de

dados do disco para a memria. Quando executamos uma consulta muito grande, que retorne cargas muito grandes de dados, geralmente no encontramos esses dados no cache. Des-sa maneira, o SQL Server tem de buscar esses dados em disco e s ento devolver o resultado. A espera por essa leitura fsica registrada como PAGEIOLATCH_SH. Uma maneira simples de minimizar essa espera identificar consultas que fazem varreduras totais em tabelas. Identificamos essas situaes atravs dos planos de execuo, onde aparecem os operadores table scans e index scans que fazem a leitura integral da tabela e do ndice respectivamente. Minimizando a incidncia desses operadores voc minimizar a espera por esse evento.

Alm desses eventos, uma srie de outros pode aparecer em suas anlises. Eventos do tipo LCK_M indicam que temos espera por locks em tabelas. Se for esse o caso, procurar por consultas que no perderiam a credibilidade se executadas com a hint (NOLOCK) e alter-las para fazer uso dessa opo pode minimizar tais esperas. Para conhecer a relao completa de eventos de espera, veja a seo Links ao final do artigo.

ConclusoIdentificar as consultas mais lentas e tentar atac-las uma

forma muito eficiente de melhorar o desempenho de nossas aplicaes, porm no a nica. Aliar essa anlise a outros


fatores alm de auxiliar na contextualizao do problema pode poupar esforos desnecessrios ou evitar que nos voltemos para o lado errado.

Ao longo do artigo conseguimos conhecer melhor uma ferra-menta importantssima no auxlio das anlises de desempenho do dia a dia, os eventos de espera. Aprendemos como colet-los, como transformar esses dados em informaes palpveis e, principalmente, tirar concluses com essas informaes.

Os eventos de espera abordados no artigo so apenas alguns dos inmeros que temos no nosso banco de dados, e como j citamos, no existe um grupo que seja o mais importante ou que sempre v aparecer em nossas anlises. Cabe ao adminis-trador de banco de dados identificar os que mais prejudicam sua aplicao e dessa maneira tentar atacar o problema, mini-mizando os seus efeitos. Diminuir o tempo de espera do seu servidor trar consequente ganho de desempenho, o que afinal de contas o que devemos buscar constantemente.

Rafael [email protected] no mercado de tecnolgia desde o incio de 2005. Analista de Sistemas formado pela UNILINS (Centro Universitrio de Lins), trabalha com SQL Server desde a verso 2000, tendo passado por desen-volvimento e administrao. Especializado em performance de bancos de

dados atualmante DBA da Athi|Wohnrath, empresa de Arquitetura e Engenharia de So Paulo. Atuou em projetos de migrao, administrao, performance e troubleshooting em ambientes de altssima disponibilidade, criticidade e complexidade.

autor

links:

SQl Server Wait Eventshttp://msdn.microsoft.com/en-us/library/ms179984.aspx





Porque este artigo til:Com o surgimento de novas edies do SQL Server, novas ferramen-

tas foram adicionadas ao arsenal do DBA. Com base nisso, este artigo

abordar tcnicas de monitorao que surgiram at o SQL Server

2012 e boas prticas para sua implantao. Adotar boas prticas ao

gerenciar um banco de dados culmina na monitorao proativa da

instncia. Ou seja, independente da existncia de problemas no SQL

Server, deve existir um acompanhamento de desempenho histrico

para prever ou corrigir problemas rapidamente.

Resumo DevMan

Alternativas e boas prticas ao monitorar um banco de dados SQL Server

Monitorando uma instncia SQL Server

A rotina de qualquer DBA inclui a monitorao de um banco, seja de forma proativa ou para encontrar e descobrir problemas que estejam ocorrendo no ambiente.

Com o passar dos anos, o SQL Server evoluiu neste aspecto, entregando ferramentas cada vez mais com-pletas e intuitivas para a monitorao do banco de dados. Porm, muitas vezes, o impacto que ferramentas como o SQL Server Profiler geram acaba agravando ou criando novos problemas de recursos, caso o servidor no esteja bem dimensionado ou o banco de dados seja extremamente transacional e sensvel.

importante ressaltar que o direcionamento da Microsoft diminuir cada vez mais o uso do SQL Server Profiler, com a introduo dos Extended Events na verso 2008 do SQL Server.

Portanto, sero apresentadas alternativas de monitora-o do SQL Server que geram pouco impacto no banco de dados e que, inclusive, podem ser implantadas em longo prazo para a gerao de mtricas e possibilitar a investigao posterior de eventos.

SQl TraceO SQL Trace surgiu com o jurssico SQL Server 6.5 como

uma forma de monitorar a comunicao cliente-servidor. Com o objetivo de capturar queries e stored procedures, sua limitao era visvel ao tentar monitorar eventos mais complexos, como a aquisio e liberao de locks.

SQl Server profilerCom o surgimento do SQL Server 7.0, a Microsoft

implementou uma forma grfica e poderosa de captu-rar diversos tipos de eventos gerados pelo SQL Trace. A Figura 1 exemplifica a arquitetura do SQL Trace a partir do SQL Server 7.0.

Note que o SQL Server Profiler apenas uma das diver-sas maneiras para capturar os eventos internos do banco de dados ou oriundos da comunicao cliente-servidor.

Criando um trace via SQl Server profilerPara criar um Trace no SQL Server Profiler, devemos proceder da

seguinte forma. Primeiro, inicie a ferramenta SQL Server Profiler, e clique em File > New Trace. Em seguida, informe o servidor e as credenciais de acesso. O usurio SQL Server deve ser administra-dor do banco de dados. A partir do SQL Server 2005, a permisso ALTER TRACE tornou esse privilgio mais granular.

As propriedades gerais do Trace so mostradas na Figura 2. So apresentados templates com eventos pr-selecionados para diversas situaes (Ex: Locks, Tuning). O Trace pode ser nomeado para facilitar a visualizao e localizao posterior. Pode-se configurar a sada do trace para um arquivo ou tabela. Estas configuraes de sada sero teis ao demonstrarmos as

Figura 1. Arquitetura do SQL Trace a partir do SQL Server 7.0


Um jeito fcil e rpido de gerar o script de um Trace que foi criado visualmente por meio do SQL

Server Profiler navegando em File > Export > Script Trace Definition. A ferramenta criar um

arquivo com extenso .sql. Basta editar o valor InsertFileNameHere, inserindo o caminho no qual

o Trace ser salvo.

BOX 1. Gerando o script T-SQL de um Trace com o SQL Profiler melhores prticas de um Trace. Por ltimo, podemos definir um horrio para que o trace seja interrompido. Na tela da Figura 2 selecione o template Tuning.

Conforme a Figura 3, selecione a aba Events Selection e clique em Column Filters. Apenas alguns filtros pr-selecionados no Template so exibidos. Informaremos o valor 1000 (valor em milissegundos) no item Duration / Greater than or equal.

Figura 2. Propriedades gerais do Trace

Figura 3. Configurando o Trace

Feito isso, aps clicar em OK/Run, o trace ser iniciado e coletar queries com durao igual ou superior a um segundo.

Criando um Trace via T-SQlPara criar o mesmo Trace via T-SQL, execute o script da Listagem 1

no servidor destino (ver BOX 1). Pode-se observar que esta captura deve ser gravada em uma tabela ou em um arquivo, pois no h uma ferramenta GUI como o SQL Server Profiler para exibir o resultado dos eventos capturados.

Aps executar esse script, o ltimo SELECT mostrar o ID do Trace criado. Esta varivel utilizada para fechar o arquivo e parar o Trace. No exemplo apresentado na Listagem 2 estamos encerrando um Trace com ID de valor 2.

otimizando a performance do SQl TraceEncontramos diversos estudos na Internet demonstrando

empiricamente que uma sesso mal configurada de Trace pode causar at 30% de sobrecarga em um servidor de banco de dados. Em cenrios especficos com alta quantidade de tran-saes, muitos usurios e poucos recursos disponveis, pode causar lentido e at mesmo o congelamento do sistema.

A seguir, listamos recomendaes para mitigar tais riscos ao executar uma sesso de Trace ou SQL Server Profiler: Restritividade ao escolher eventos: conhea o retorno espe-rado de cada evento escolhido em seu Trace para no causar sobrecarga por dados em demasia. Por exemplo: em um caso especfico, o evento SP:StmtStarting pode gerar resultados se-melhantes ao SQL:BatchStarting, portanto no h necessidade de adicionar os dois contadores; Utilize filtros: Alm de tornar o seu Trace mais legvel, os filtros diminuiro a massa de dados a ser gerada, reduzindo o impacto da sesso; Opte por Server Side Traces: executar um Trace via T-SQL comprovadamente mais leve que a ferramenta grfica SQL Server Profiler; Opte pela gravao do Trace em arquivo: Sempre que possvel, opte pela gravao de um arquivo de extenso .trc com os dados coletados. Esta opo consome menos recursos em comparao com o display de informaes na ferramenta ou a gravao em tabela. Lembre-se de configurar tamanhos razoavelmente pequenos para o arquivo (at 200 MB), pois desta maneira ser mais fcil transportar o arquivo ou abri-lo posteriormente. Esteja atento ao drive de destino do arquivo. recomendvel escolher um drive no qual no existam datafi-les e logfiles do SQL Server, evitando a concorrncia de I/O; Lembre-se de adicionar um lembrete, job ou configurar um tempo de parada para o seu Server Side Trace. Ao criar uma sesso via script, torna-se muito mais fcil esquecer o Trace ativo e consumindo recursos do banco de dados de forma desnecessria; Caso deseje utilizar o SQL Server Profiler para um Trace rpido, inicie a ferramenta no prprio servidor: executando localmente, haver menor trfego de rede.

alternativas ao SQl TraceNos tpicos seguintes, exploraremos recursos de moni-

torao sofisticados como Extended Events e o SQL Data Collector. Porm, estas funes surgiram apenas na verso 2008 do SQL Server.

Monitorando uma instncia SQL Server


DECLARE @TraceID int, @Tamanho bigint, @Arquivo nvarchar (256), @On bit, @Duracao bigint

SELECT @Tamanho = 20SELECT @Arquivo = C:\TraceTesteSELECT @On = 1

EXEC sp_trace_create @TraceID output, 2, -- Configura o trace para criar um novo arquivo ao atingir o tamanho de 20 MB.@Arquivo, -- Caminho do arquivo sem a extenso .trc.@Tamanho, -- Tamanho mximo do arquivo em MB.NULL, -- Data/hora de parada do trace5 -- Nmero mximo de arquivos a serem criados no Trace.

-- Seleciona os eventos que sero adicionados ao trace.EXEC sp_trace_setevent @TraceID, 10, 1, @onEXEC sp_trace_setevent @TraceID, 10, 3, @onEXEC sp_trace_setevent @TraceID, 10, 11, @onEXEC sp_trace_setevent @TraceID, 10, 35, @onEXEC sp_trace_setevent @TraceID, 10, 12, @onEXEC sp_trace_setevent @TraceID, 10, 13, @onEXEC sp_trace_setevent @TraceID, 45, 1, @onEXEC sp_trace_setevent @TraceID, 45, 3, @onEXEC sp_trace_setevent @TraceID, 45, 11, @onEXEC sp_trace_setevent @TraceID, 45, 35, @onEXEC sp_trace_setevent @TraceID, 45, 12, @onEXEC sp_trace_setevent @TraceID, 45, 28, @onEXEC sp_trace_setevent @TraceID, 45, 13, @onEXEC sp_trace_setevent @TraceID, 12, 1, @onEXEC sp_trace_setevent @TraceID, 12, 3, @onEXEC sp_trace_setevent @TraceID, 12, 11, @onEXEC sp_trace_setevent @TraceID, 12, 35, @onEXEC sp_trace_setevent @TraceID, 12, 12, @onEXEC sp_trace_setevent @TraceID, 12, 13, @on

-- Configurando filtro de Duration para 1000000 (em microssegundos).SELECT @Duracao = 1000000 EXEC sp_trace_setfilter @TraceID, 13, 0, 4, @Duracao

-- Inicia o Trace.EXEC sp_trace_setstatus @TraceID, 1

-- Mostra o ID do Trace criado.SELECT @TraceID ID do Trace

DECLARE @TraceID int, @Tamanho bigint, @Arquivo nvarchar (256), @On bit, @Duracao bigint

SELECT @Tamanho = 20SELECT @Arquivo = C:\TraceTesteSELECT @On = 1

EXEC sp_trace_create @TraceID output, 2, -- Configura o trace para criar um novo arquivo ao atingir o tamanho de 20 MB.@Arquivo, -- Caminho do arquivo sem a extenso .trc.@Tamanho, -- Tamanho mximo do arquivo em MB.NULL, -- Data/hora de parada do trace5 -- Nmero mximo de arquivos a serem criados no Trace.

-- Quais eventos sero adicionados ao trace. EXEC sp_trace_setevent @TraceID, 10, 1, @onEXEC sp_trace_setevent @TraceID, 10, 3, @onEXEC sp_trace_setevent @TraceID, 10, 11, @onEXEC sp_trace_setevent @TraceID, 10, 35, @onEXEC sp_trace_setevent @TraceID, 10, 12, @onEXEC sp_trace_setevent @TraceID, 10, 13, @onEXEC sp_trace_setevent @TraceID, 45, 1, @onEXEC sp_trace_setevent @TraceID, 45, 3, @onEXEC sp_trace_setevent @TraceID, 45, 11, @onEXEC sp_trace_setevent @TraceID, 45, 35, @onEXEC sp_trace_setevent @TraceID, 45, 12, @onEXEC sp_trace_setevent @TraceID, 45, 28, @onEXEC sp_trace_setevent @TraceID, 45, 13, @onEXEC sp_trace_setevent @TraceID, 12, 1, @onEXEC sp_trace_setevent @TraceID, 12, 3, @onEXEC sp_trace_setevent @TraceID, 12, 11, @onEXEC sp_trace_setevent @TraceID, 12, 35, @onEXEC sp_trace_setevent @TraceID, 12, 12, @onEXEC sp_trace_setevent @TraceID, 12, 13, @on

-- Configurando filtro de Duration para 1000000 (em microssegundos).SELECT @Duracao = 1000000 EXEC sp_trace_setfilter @TraceID, 13, 0, 4, @Duracao

-- Inicia o Trace.EXEC sp_trace_setstatus @TraceID, 1

-- Mostra o ID do Trace criado.SELECT @TraceID ID do Trace

Listagem 1. Script para criao de um SQL Trace.

Listagem 2. Finalizando um Trace

EXEC sp_trace_setstatus 2, 0

EXEC sp_trace_setstatus 2, 2

Em verses anteriores do SQL Server, um pouco de criatividade e trabalho manual deve entrar em cena, caso o DBA almeje implantar uma monitorao que no cause praticamente nenhuma sobrecarga no servidor. Scripts compatveis com o SQL Server 2000 e 2005 que listam processos lentos e bloqueados podem ser encontrados na Internet e facilmente adaptados para alimentarem uma tabela ou arquivo texto. A seguir so apresentadas algumas sugestes:

sp_blocker_pss08: Criado pela prpria Microsoft para suprir esta lacuna, trata-se de um script que tira uma foto do banco de dados em perodos pr-determinados, salvando os resultados de queries, locks e conexes em um arquivo texto. Pode ser encon-trado no site da empresa (vide seo Links); sp_whoisactive: Este script, criado pelo DBA Adam Macha-nic, conhecido na comunidade por ser sucinto e superior ao comando nativo sp_who, alm de possuir retro compatibilidade com o SQL Server 2005. Pode ser encontrado no site que est na seo Links; Desenvolver uma rotina customizada: utilizando tabelas de sistema como a sysprocesses (SQL Server 2000) e DMVs como a sys.dm_exec_requests, o DBA pode criar um script que atenda


suas necessidades apenas com dados relevantes ao cenrio a ser monitorado.

Extended EventsOs Extended Events tornam a captura de informaes mais

performtica e customizvel (ver BOX 2). Tambm conhecidos como XEvents, apresentam uma curva de aprendizado mais com-plexa que o SQL Server Profiler, mas essencial para qualquer DBA que administre um ambiente SQL Server na verso 2008 ou superior.

O conceito chave dos Extended Events a flexibilidade: pode-se criar uma sesso englobando qualquer evento, e este evento pode ser armazenado em um ou mais destinos, como uma tabela ou log no Event Viewer.

Implementados na verso 2008 do SQL Server, os Extended Events so mais numerosos a cada

edio lanada, confirmando a tendncia da Microsoft de abandonar o SQL Server Profiler. Apesar

disso, eles ganharam uma interface grfica apenas na verso 2012, uma deficincia que pode ser

suprida na verso anterior com a instalao do complemento SQL Server 2008 Extended Events

Addin, desenvolvida em cdigo-aberto. Como uma das novidades da prxima verso, so previstos

145 novos eventos para o SQL Server 2014 (codinome Hekaton), totalizando 763 Extended Events.

BOX 2. A evoluo dos Extended Events

Os eventos so subdivididos em Packages e Channels. Desta forma, se torna mais fcil localizar o evento desejado para iniciar um rastreamento. A query da Listagem 3 retorna todos os eventos disponveis.

Com os eventos selecionados, podemos consultar as colunas disponveis atravs da DMV sys.dm_xe_object_columns.

Listagem 3. Retornando todos Extended Events disponveis.

SELECT p.name AS package, c.event, k.keyword, c.channel, c.descriptionFROM( SELECT event_package=o.package_guid, o.description, event=c.object_name, channel=v.map_value FROM sys.dm_xe_objects o LEFT JOIN sys.dm_xe_object_columns c ON o.name = c.object_name INNER JOIN sys.dm_xe_map_values v ON c.type_name = v.name AND c.column_value = cast(v.map_key AS nvarchar) WHERE object_type=event AND (c.name = channel OR c.name IS NULL)) c left join( SELECT event_package=c.object_package_guid, event=c.object_name, keyword=v.map_value FROM sys.dm_xe_object_columns c INNER JOIN sys.dm_xe_map_values v ON c.type_name = v.name AND c.column_value = v.map_key AND c.type_package_guid = v.object_package_guid INNER JOIN sys.dm_xe_objects o ON o.name = c.object_name AND o.package_guid=c.object_package_guid WHERE object_type=event AND c.name = keyword) kONk.event_package = c.event_package AND (k.event = c.event OR k.event IS NULL)INNER JOIN sys.dm_xe_packages p ON p.guid=c.event_packageWHERE (p.capabilities IS NULL OR p.capabilities & 1 = 0)ORDER BY channel, keywo

sql117

Documents

banco de dados

dados oracle

tecnologia faircom

artigo por artigo

artigo voc

dados multiplataforma

ferramenta de banco

artigo na revista