Contedo sobre Boas Prticas

Sumrio

06 Um modelo OLAP para visualizao de informaes de builds automticos

[ Mauro Pichiliani ]

Contedo sobre Boas Prticas

16 Manipulao de arquivos de dados e log no SQL Server

[ Robson Moraes ]

Contedo sobre Boas Prticas

22 Dominando os ndices columnstore

[ Weslley Moura e Emerson Silva ]

Contedo sobre Boas Prticas

28 Monitoramento automatizado o SQL Server

[ Jonatas dos Anjos ]

Contedo sobre Boas Prticas

36 Paralelismo no SQL Server

D
s

[ Luciano Moreira ]

Feedback
eu

44 Trabalhando com MemSQL

Artigo no estilo Soluo Completa

52 Trabalhando com o MySQL Cluster

[ Airton Lastori ]

Artigo no estilo Soluo Completa

61 PostgreSQL distribudo com PgPool-II

[ Luis Eduardo de Oliveira Floriano ]

edio
ta

[ Rodrigo Salvo ]

sobre e
s

Artigo do estilo Soluo Completa

D seu feedback sobre esta edio!

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, atravs do link:
www.devmedia.com.br/sqlmagazine/feedback

Assine agora e tenha acesso a

todo o contedo da DevMedia:
www.devmedia.com.br/mvp

136 Edio - 2015 - ISSN 1677918-5 - Impresso no Brasil

EXPEDIENTE
Editor
Rodrigo Oliveira Spnola ([email protected])
Subeditor
Eduardo Oliveira Spnola
Consultor Tcnico
Diogo Souza ([email protected])
Jornalista Responsvel
Kaline Dolabella - JP24185
Capa e Diagramao
Romulo Araujo
Distribuio
FC Comercial e Distribuidora S.A
Rua Teodoro da Silva, 907
Graja - RJ - 206563-900

Atendimento ao leitor
A 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.

Publicidade
[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.

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 Revista
[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.

Um modelo OLAP para visualizao de informaes de builds automticos

Um modelo OLAP para

visualizao de informaes
de builds automticos
Veja neste artigo um modelo multidimensional
para visualizao de informaes geradas pelo
build automtico de um projeto Java

desenvolvimento de software profissional conta

com diversas etapas. Dentre as principais, podemos destacar o processo de build, ou seja,
o passo onde necessrio realizar diversas aes para
produzir uma verso do software. Este processo pode
ser composto de aes automticas ou manuais como,
por exemplo, compilao, empacotamento, realizao de
testes, checagem de dependncias e outras atividades
necessrias para completar o build.
comum que empresas preocupadas com a qualidade
de desenvolvimento e produo de software invistam
em tornar o processo de build automtico e adequado
para gerar todos os artefatos necessrios para lanar
uma nova verso do software. Isso implica em diversas
verificaes, chamadas de softwares externos, checagem
de padres de desenvolvimento, gerao de documentao e tarefas de deploy que, se realizadas manualmente,
certamente consumiriam muitos recursos humanos e
possuiriam alta probabilidade de falhas. Portanto, a
maioria das equipes de desenvolvimento tem como uma
das prioridades iniciais de seus projetos a automao do
processo de build.
A execuo automtica de processos de build gera
diversos dados importantes que devem ser analisados
tanto pelos membros tcnicos da equipe quanto pelo
gerente de projeto, pois esta anlise vai fornecer indicadores de como anda a qualidade do projeto e outros
aspectos relevantes. Contudo, ainda so poucos os sistemas que fornecem estas informaes produzidas pelo
processo de build automtico em um formato analtico
que suporte tomadas de deciso e permita o acompanhamento quantitativo e qualitativo do desenvolvimento do
software como um todo.

6 SQL Magazine Edio 136

Fique por dentro

Este artigo til por ensinar como elaborar um modelo multidimensional para a visualizao de informaes geradas por processos
de build, geralmente compostos por vrias aes e etapas. A partir
do modelo sugerido pode-se modificar as entidades, dimenses,
hierarquias, membros, atributos, medidas e relacionamentos para
adequar a estrutura de acordo com outras caractersticas associadas
visualizao das informaes geradas, independente da ferramenta
de build utilizada. A implementao do modelo descrito no artigo
pode ser feita em qualquer ferramenta OLAP que suporte um modelo multidimensional e possua uma interface para consultas que
filtrem os dados das medidas de acordo com os nveis e membros
das dimenses.

A partir deste cenrio, este artigo apresentar como montar um

modelo multidimensional que se baseia nos dados gerados por um
processo de build incluindo o tipo, resultado, plataformas suportadas, usurios, commits, bugs e outras entidades. O modelo descrito
neste artigo multidimensional e pode ser implementado em bancos de dados relacionais e visualizado com qualquer ferramenta
que utilize a tecnologia OLAP (OnLine Analytical Processing), com
o objetivo de apresentar as informaes agregadas em formatos
adequados para anlises e suporte tomada de decises tticas e
estratgicas. O modelo conta com diversas entidades que abordam
os principais aspectos relacionados s etapas, aes e verificaes
realizadas durante o processo de build automtico.
Apesar de contemplar diversas caractersticas de um processo
de build de software tpico, o modelo apresentado neste artigo
razoavelmente simples e pode ser adaptado a diferentes tipos de
projetos que utilizam build automtico de acordo com os requisitos e cenrios de utilizao. As entidades do modelo so criadas

para a visualizao dos dados em um modelo multidimensional.

Contudo, o artigo no detalha como obter as informaes que
foram armazenadas nestas entidades, pois tais informaes so
dependentes dos formatos de dados especficos de cada projeto
e das ferramentas utilizadas para o build.

Funcionamento do build automtico

Para comear a compreender o cenrio no qual vamos nos basear
para montar o modelo, preciso primeiro estudar um pouco as
aes e dados gerados por um build automtico a partir de um
cenrio que demonstre o que tipicamente feito neste processo.
Como atualmente existem diversas informaes e maneiras
diferentes de apresentar tais informaes, faz sentido delimitar
o escopo e escolher um tipo de build e ferramentas comuns que
possam ser utilizadas como cenrio para a elaborao e detalhamento dos dados com os quais precisamos trabalhar.
O cenrio no qual vamos nos basear para criar o modelo de
dados utiliza uma plataforma de desenvolvimento Java que geralmente emprega ferramentas como Ant, Maven ou Gradle para
automatizar o processo de build de projetos, sejam eles projetos
para aplicaes desktop, para a Web ou at mesmo para o desenvolvimento mobile para a plataforma Android.
Quando um build iniciado, ele requer algumas informaes
importantes, tais como o tipo de build, o local de armazenamento
dos arquivos gerados e parmetros de compilao. So estas informaes que vo indicar quais aes precisam ser feitas. Tipos
comuns incluem Compilao, Empacotamento, Clean e
Completo. Cada um deles possui diversas caractersticas e
pode conter aes que vo determinar o que efetivamente ser
feito. Por exemplo, o build Compilao apenas compila o cdigo
fonte em Java para verificar se houve alguma mensagem retornada pelo compilador, ao passo que Clean limpa os diretrios
necessrios para o build e remove quaisquer arquivos gerados
pelo build anterior.
Builds automticos geralmente produzem uma nova verso do
software, seja ela uma verso interna ou que ser disponibilizada
para os usurios finais. De qualquer forma, cada build deve especificar qual o resultado, ou seja, qual o sistema operacional
(Windows, Linux, MacOS, Android, etc.), a plataforma (x86, x64,
ARM) e o formato do pacote que ser produzido (JAR, EXE, WAR,
HTML, APK). Estas informaes so especialmente importantes
para projetos que suportam muitas plataformas, onde toda a gerao de artefatos controlada por um nico processo de build.
Ao trmino de cada execuo do build, uma nova verso do
software gerada. Esta verso deve conter uma numerao
(1.2.0.1, 1.3.3.2, etc.), o tipo de verso (RTM, Debug, Beta,
Release) e tambm qual a edio do software em relao s
suas funcionalidades e formato de utilizao (Free, Trial,
Premium, Enterprise, Standard, etc.). Assim como outros
exemplos de dados, os valores para os elementos apresentados
neste pargrafo so apenas sugestes e durante a implementao
do modelo o leitor pode colocar valores que faam sentido para
o seu contexto.

Os projetos de software que utilizam a plataforma de desenvolvimento Java geralmente so compostos por diferentes componentes
externos, como bibliotecas, frameworks ou qualquer outro tipo de
dependncia. Deste modo, os processos de build se encarregam
tambm de checar se as dependncias esto corretas e atualizadas para que o processo no falhe. A propsito, um build que
falha, ou seja, no consegue realizar as tarefas necessrias para
ser classificado como um sucesso, representa uma importante
informao.
A definio de falha ou sucesso de um build especificada
por uma srie de diretrizes condicionais criadas pela equipe de
desenvolvimento e varia muito para cada projeto. Por exemplo,
comum encontrar regras do tipo: se o cdigo fonte no passar
em determinado nmero X de testes, o processo de build falha. O
modelo deste artigo considera apenas o resultado do build e tambm quais testes so associados a ele, sem detalhar o tipo de teste
(testes unitrios, testes de interface, testes de integrao, etc.).
Outro aspecto importante que deve ser considerado a quantidade de cdigo fonte novo ou modificado em relao ao ltimo
build. comum que este dado seja indicado pelos commits (o
cdigo fonte novo ou modificado enviado para um sistema de
controle de verso) realizados pelos desenvolvedores desde o
ltimo build. Tambm um dado importante a identificao dos
desenvolvedores que produziram os commits.
A realizao de um build automtico normalmente associada
a algum tipo de objetivo alcanado no projeto ou a uma etapa do
processo de desenvolvimento. Por exemplo, comum a gerao
de um build quando um Sprint finalizado, pois ao final deste
ciclo curto tradicional em processos de desenvolvimento gil,
geralmente necessrio distribuir ou disponibilizar o software
para os usurios finais.
Por fim, como todo software pronto ou em desenvolvimento
possui bugs, muito importante apresentar esta informao
sempre que uma nova verso do software produzida. Fornecer
as informaes de bugs junto com o processo de build til para
ajudar a acompanhar a evoluo da qualidade do software de
forma quantitativa e qualitativa, auxiliando assim a tomada de
decises que podem impactar o projeto.
Diversas outras informaes relacionadas ao processo de build
automtico podem ser inseridas como, por exemplo, resultado de
ferramentas de checagem esttica de cdigo (PMD, CheckStyle e
FindBugs), relatrio da documentao tcnica gerada, lista de requisitos e user stories atendidas pelo build, problemas encontrados
no projeto e at diagramas e documentos gerais. Contudo, para no
tornar o modelo demasiadamente complexo, este artigo contempla
apenas as informaes relacionadas ao cenrio descrito nos pargrafos anteriores. Fica como recomendao ao leitor customizar o
modelo de acordo com os dados relacionados ao seu processo de
build automtico, de modo a facilitar a visualizao, explorao
e descoberta de fatos relevantes a partir dos dados.
Novamente, o foco do artigo apenas no modelo de dados e no
em como realizar o processo de ETL que obtm as informaes de
diferentes fontes de dados (arquivos texto, cdigo fonte, resultado

Edio 136 SQL Magazine

Um modelo OLAP para visualizao de informaes de builds automticos

da execuo de ferramentas externas, mensagens do compilador,

etc.) e as consolida em um data warehouse. Vale a pena destacar
que tal processo de ETL pode ser complexo e demandar muitos
recursos, dependendo do nvel de detalhamento, da frequncia
de atualizao e das caractersticas da informao que se deseja
obter.
Sendo assim, o prximo tpico detalha as dimenses e suas
caractersticas, as tabelas do modelo multidimensional e as medidas utilizadas para a gerao da ferramenta que permitir a
visualizao de informaes associadas com o processo de build
automtico.

Modelagem das dimenses e medidas

O modelo multidimensional utilizado no exemplo ser criado a
partir da especificao de dimenses, hierarquias, nveis, membros e tambm das medidas utilizadas para visualizar os dados
dos relatrios em um ou mais cubos de dados. A modelagem
adotada conhecida como hbrida, pois ela mistura o design
estrela (star) e floco-de-neve (snowflake). Dito isso, inicialmente
apresentaremos as dimenses e depois mostraremos como estas
dimenses esto relacionadas com a tabela fato e as medidas dos
cubos de dados.
A primeira dimenso que ser especificada a dimenso que
armazena qual o tipo de build. Este tipo geralmente est armazenado em um arquivo de configurao XML e deve ser indicado como parmetro para a execuo automtica do build. Esta
dimenso se chamar TipoBuild e seus atributos incluem um
identificador do tipo (ID_TIPO_BUILD), o nome do tipo (TIPO) e
uma descrio sem limite de texto utilizada como propriedade
dos membros da dimenso (DESCRICAO). Os dados desta dimenso so organizados em uma hierarquia simples, que agrupa os
dados de acordo com o tipo de build. A Figura 1 mostra a tabela
DM_TIPO_BUILD, que implementa a dimenso e tambm um
exemplo de dados dentro da hierarquia.

compilao falhou, mas passou em todos os testes unitrios pode

ser uma falha parcial.
A dimenso que armazenar o resultado do build se chamar
Resultado e ela organizar os seus dados da seguinte maneira:
a hierarquia conter primeiro o tipo do resultado (Sucesso ou
Falha), seguido de uma informao sobre o quo completo foi
o resultado (Completo ou Parcial). A hierarquia tambm
apresentar informaes sobre a causa apenas nos builds classificados como parciais. Por fim, haver um atributo indicando
informaes adicionais como, por exemplo, detalhes do cdigo
fonte que causou a falha do build.
A dimenso Resultado implementada na tabela DM_RESULTADO e conta com um detalhe importante em relao aos tipos de
dados. Para a coluna que armazenar o tipo de resultado (Sucesso ou Falha), utilizaremos dados caracteres do tipo de dados
VARCHAR(15). J para armazenar se o resultado completo ou
parcial, utilizaremos um tipo de dados BIT, cujo valor 0 indicar
Parcial e o valor 1 indicar Completo.
A deciso do tipo de dados utilizado na modelagem especfica
para cada projeto de acordo com a variedade dos dados e outros
fatores. Neste modelo optamos por escolher dois tipos de dados
diferentes com fins didticos e para mostrar que possvel utilizar tipos de dados caractere ou bit como membros da dimenso.
Caso o tipo bit seja escolhido, preciso montar uma expresso
que traduza o valor 0 como Parcial e o valor 1 como Completo.
A Figura 2 apresenta a tabela DM_RESULTADO junto com exemplos de navegao na dimenso com o objetivo de filtrar os dados
de acordo com os diferentes tipos de resultado do build.

Figura 2. Tabela DM_RESULTADO da dimenso Resultado e exemplos de navegao na hierarquia

Figura 1. Tabela DM_TIPO_BUILD da dimenso TipoBuild e exemplo de navegao na dimenso

Um processo de build automtico geralmente possui apenas dois
resultados de acordo com as diretrizes condicionais criadas pela
equipe de desenvolvimento: sucesso ou falha. Alm de indicar o
resultado, tambm interessante indicar se o resultado foi parcial
ou completo. Por exemplo, um build cujo processo passou nas
etapas de compilao e testes pode ser considerado um sucesso
parcial se houve algum problema na etapa de gerao de documentao. De forma semelhante, um build onde o processo de

8 SQL Magazine Edio 136

Um processo de build automtico finalizado com sucesso normalmente gera uma nova verso do software. Este versionamento
associado com o tipo da verso (Debug, Release) e com o
tipo da edio (Trial, Free e Enterprise). As informaes de
verso e edio do software so relacionadas ao tipo do build e
tambm ao resultado, porm, neste artigo uma dimenso separada
chamada Versao armazenar os dados de tipo da verso e da edio. O motivo que tanto a edio quanto a verso normalmente
so representadas pelo nmero da verso quando o processo
de build finalizado e, desta forma, as pesquisas relacionadas
ao software final podem ser feitas consultando uma dimenso
especfica.

A tabela DM_VERSAO implementa a dimenso Versao e

contm colunas para armazenar o tipo, a edio e o nmero.
importante destacar que a documentao do projeto deve
deixar claro o critrio para o incremento da verso, pois nem
todo build precisa necessariamente gerar um novo nmero
para o software. Nesta mesma documentao tambm preciso
especificar o que diferencia uma edio do software de outra
atravs da lista de funcionalidades, preo, perodo de durao
ou caractersticas, tais como a apresentao de propagandas.
Estes detalhes de documentao ficam fora do modelo de dados,
que apenas apresenta o nome da edio, o nmero e o seu tipo.
A Figura 3 mostra a tabela DM_VERSAO junto com exemplos
de navegao na hierarquia.

quando o build foi feito em relao ao ciclo (0 = Em andamento

e 1 = Logo aps o trmino), o nome do Sprint e uma coluna de
texto livre para armazenar as user stories tratadas pela equipe de
desenvolvimento. A tabela DM_SPRINT junto com exemplos de
navegao em sua hierarquia apresentada na Figura 4.

Figura 4. Tabela DM_SPRINT da dimenso Sprint e exemplo de navegao na hierarquia

Figura 3. Tabela DM_VERSAO da dimenso Versao e exemplos de navegao na hierarquia

Do ponto de vista de organizao e gerenciamento, comum
associar a gerao de um build a um marco importante do projeto
relacionado aos requisitos do software. O modelo multidimensional que estamos criando faz esta associao atravs da dimenso
Sprint, pois ela vai armazenar detalhes do ciclo em que o build
foi gerado. No nosso cenrio, o build pode ser gerado enquanto
um Sprint est em andamento ou imediatamente aps o seu trmino. Portanto, a hierarquia desta dimenso vai conter um nvel
que indicar se o build foi gerado enquanto um Sprint estava em
andamento ou logo aps ele ter sido finalizado. O prximo nvel
armazenar o nome e tambm informaes adicionais em uma
coluna de texto livre, com detalhes sobre as user stories atendidas
por este ciclo.
Como o objetivo principal do modelo disponibilizar informaes sobre o build, no sero detalhados aspectos do Sprint
e outras informaes gerenciais relacionadas ao andamento do
processo de desenvolvimento adotado. Novamente, o leitor que
desejar incluir tais informaes no modelo pode customizar
as dimenses ou mesmo criar suas prprias para atender seus
requisitos relacionados apresentao dos detalhes do processo
de desenvolvimento.
A dimenso Sprint implementada na tabela DM_SPRINT e
contm um identificador nico, a coluna do tipo BIT para indicar

A prxima dimenso do modelo armazena informaes sobre a

plataforma e empacotamento do(s) arquivo(s) binrio(s) gerado(s)
pelo processo de compilao. Estas informaes so importantes,
pois elas ajudam a identificar, entre outros aspectos, se a frequncia
de gerao de verses est sendo uniforme ou no entre as diferentes plataformas e arquiteturas nas quais o projeto deve atender.
A dimenso Plataforma deve armazenar em sua hierarquia
qual o sistema operacional alvo dos arquivos binrios (Todos,
Windows, Linux, iOS, etc.) e tambm a identificao de qual
arquitetura de processador (32 bits - x86, 64 Bits - x64, ARM,
Geral), uma vez que estas informaes so importantes para
o processo de deploy da verso do software. Depois da escolha
destas duas informaes, sistema operacional e plataforma,
preciso identificar qual o tipo de pacote gerado pelo build, que
pode incluir valores como JAR, EXE, ZIP, APK, HTML,
WAR, dentre outros. Apesar de existir associao entre tipos
de pacotes e sistemas operacionais, como o tipo APK e o S.O.
Android, importante colocar as informaes de pacote como
um nvel da hierarquia abaixo dos nveis sistema operacional e
arquitetura para facilitar a especificao de filtros nos membros
desta dimenso, implementada pela tabela DM_PLATAFORMA,
mostrada na Figura 5.
No desenvolvimento de software em Java comum o uso de
dependncias externas especificadas durante a codificao, uma
vez que necessrio utilizar as classes e outros recursos de certas dependncias para implementar os casos de uso/regras de
negcio. Assim sendo, durante o processo de build automtico
importante que estas dependncias sejam corretamente identificadas e atualizadas, pois este um dos requisitos bsicos para a
compilao do projeto.
Com base nisso, o modelo multidimensional armazena as informaes de dependncias do projeto para ajudar a realizar anlises
que identifiquem, por exemplo, se o tempo de build aumentou
quando determinada dependncia foi includa. Ou ainda, permitir
rastrear e descobrir a partir de qual momento o software comeou
ou deixou de utilizar certas dependncias.

Edio 136 SQL Magazine

Um modelo OLAP para visualizao de informaes de builds automticos

ETL faa a reduo da URL oficial do projeto com um encurtador

de endereos como o bit.ly ou o migre.me. A Figura 6 mostra a
implementao da dimenso Dependencia por meio das tabelas
DM_DEPENDENCIA e DM_DEP_BUILD, junto com exemplos de
navegao na hierarquia dos dados desta dimenso.
Com as informaes sobre dependncias do projeto j modeladas, podemos comear a pensar em como incluir as informaes
relacionadas aos commits realizados desde a execuo do ltimo
build. Os dados relacionados ao conjunto de modificaes no
cdigo fonte vo ser apresentados aos usurios do modelo atravs da dimenso Commit, que armazenar informaes sobre
os desenvolvedores que contriburam com cdigos e tambm
detalhes do que foi feito.
Aqui importante destacar que os profissionais desenvolvedores
no devem ser relacionados diretamente com o build, ou seja, primeiro preciso relacionar o build com os commits para s depois
relacion-los com os desenvolvedores. As informaes de quem
Figura 5. Tabela DM_PLATAFORMA da dimenso Plataforma e exemplos de dados na dimenso
contribuiu para o projeto desde o ltimo build incluem o papel
do desenvolvedor (designer, programador front-end, DBA,
testador), o nome e o e-mail. J para o commit necessrio algum
Portanto, a dimenso Dependencia vai armazenar detalhes
tipo de descrio, um identificador nico para relacionamento
das dependncias de cada build. O usurio final que consultar
nas tabelas do modelo, um identificador do sistema de controle
os dados desta dimenso ter a visualizao do nome da depende verso e a URL que contm informaes relevantes sobre as
dncia, qual verso est sendo utilizada no projeto e tambm uma
modificaes realizadas no cdigo fonte.
propriedade adicional com o endereo na Web da dependncia
O leitor pode incrementar o modelo e disponibilizar mais inforou do local oficial do seu repositrio.
maes sobre as mudanas se nos aprofundarmos nesta entidade.
A implementao da dimenso Dependencia requer duas
Por exemplo, pode-se associar uma data, quais arquivos fontes
tabelas para representar o relacionamento entre os builds e as
foram modificados e outros detalhes adicionais. Contudo, para
dependncias. Estas tabelas so DM_DEPENDENCIA, que vai
manter o modelo de dados simples e focado no build, no moarmazenar um identificador, o nome da dependncia, a verso e
delaremos estes detalhes, ficando a cargo do leitor implementar
a URL do site ou repositrio, e a tabela DM_DEP_BUILD, que vai
outras dimenses para lidar com o detalhamento dos dados
fazer a relao entre a tabela DM_DEPENDENCIA e a tabela fato
relacionados ao commit.
FT_BUILD, que ainda vai ser modelada logo mais neste artigo.
A tabela DM_COMMIT armazena os commits e conta com
A tabela DM_DEP_BUILD relacionada por uma chave estrangeidiversas colunas, porm, na dimenso, os usurios finais visualira colocada na coluna ID_DEPENDENCIA, que tambm a chave
zaro apenas o nome. As demais colunas podem ser visualizadas
primria com o mesmo nome na tabela DM_DEPENDENCIA.
como propriedades adicionais dos membros da dimenso. Para
A implementao da coluna VERSAO utilizou um tipo de dados
implementar a dimenso, preciso relacionar a tabela fato e a
caractere, pois diversos projetos utilizam pontos, letras e outros
tabela DM_COMMIT atravs da tabela DM_COMMIT_BUILD,
caracteres na classificao da sua verso (exemplo: 1.2_beta). J a
que contm uma chave estrangeira na coluna ID_COMMIT. Nocoluna que armazena a URL do projeto relacionado dependnvamente, a coluna ID_BUILD da tabela DM_COMMIT_BUILD
cia foi limitada a 1.000 caracteres e recomenda-se que o processo
uma chave primria para a tabela fato
FT_BUILD, que ainda no foi modelada.
Desta forma, a dimenso Commit ser
criada a partir do relacionamento entre
as tabelas DM_COMMIT, DM_COMMIT_BUILD e FT_BUILD.
Para representar os desenvolvedores
que contriburam para o build atravs
de algum commit, utilizaremos uma dimenso chamada Desenvolvedor, cujos
membros vo ser organizados em uma
hierarquia onde primeiro mostra-se o
seu papel no build e depois seu nome.
Figura 6. Tabelas DM_DEPENDENCIA e DM_DEP_BUILD junto com os elementos da dimenso Dependencia

10 SQL Magazine Edio 136

A deciso de criar uma nova dimenso

para o desenvolvedor ao invs de colocar
estes dados como um novo nvel da hierarquia Commit para facilitar o filtro
necessrio para responder perguntas do
tipo Em quais builds o profissional X
participou.
A implementao da dimenso Desenvolvedor feita pelas tabelas DM_DEVELOPER e DM_COMMIT_BUILD, pois existe
um relacionamento de chave estrangeira
entre as duas tabelas por meio da coluna
ID_DEVELOPER, presente em ambas.
A Figura 7 apresenta as tabelas DM_COMMIT, DM_COMMIT_BUILD e DM_DEVELOPER junto com seus relacionamentos
que implementam as dimenses Commit e
Desenvolvedor. Esta figura tambm apresenta exemplos de navegao nos membros
das hierarquias destas dimenses.
O acompanhamento da qualidade do
projeto de software ser feito atravs da
dimenso Bug, que mostrar quais so
os bugs no software que ainda existem
aps o build ter sido feito. importante
deixar claro que estes bugs devem ter um
controle especfico e serem gerenciados
adequadamente por ferramentas como o
Bugzilla.
A dimenso Bug implementada pela
tabela DM_BUG, que contm colunas
para identificar unicamente o bug, qual
o mdulo do sistema/aplicao na qual
o bug est relacionado e o nome do bug.
H tambm uma coluna para armazenar
um identificador geral utilizado por um
sistema de controle de bugs (Exemplo:
#BUG0394) e uma coluna de texto livre
para informaes adicionais. O relacio-

namento de DM_BUG com a tabela fato

FT_BUILD feito atravs de DM_BUGS_
BUILD, pois ela contm uma chave estrangeira na coluna ID_BUG e outra chave
estrangeira na coluna ID_BUILD para os
relacionamentos com as tabelas DB_BUG
e FT_BUILD, respectivamente.
A hierarquia da dimenso Bug apresenta o nvel que contm o mdulo do
sistema/aplicao seguido pelo nvel
com o identificador geral do bug. Neste
caso optou-se por mostrar o nome do bug
ao invs do seu identificador, pois desta
maneira mais simples para um gerente
de projeto filtrar por bugs conhecidos.
Sendo assim, o identificador do bug e as
informaes adicionais so propriedades
da dimenso. A Figura 8 mostra as tabelas
DM_BUG e DM_BUGS_BUILD junto com
exemplos de navegao na hierarquia da
dimenso Bug.

Um processo automtico de build sempre realizado em uma data especfica,

seja ela peridica (exemplo: sempre s
quartas-feiras noite) ou de acordo com
a deciso arbitrria dos membros do
projeto. De qualquer forma, o modelo
multidimensional possuir uma dimenso Data que armazenar o momento no
qual o build foi iniciado e no quando ele
foi terminado, pois teremos uma medida
que armazenar a durao do build.
A implementao da dimenso Data
feita atravs da tabela DM_DATA,
que contm diversas colunas separadas
para armazenar o ano, o ms, o dia,
o dia da semana, a hora e o minuto.
A separao dos dados por coluna um
requisito para a criao de diferentes
nveis e hierarquias da dimenso Data,
mostrada na Figura 9 junto com a tabela
DM_DATA.

Figura 7. Tabelas DM_COMMIT, DM_COMMIT_BUILD e DM_DEVELOPER das dimenses Commit e Desenvolvedor

Figura 8. Tabelas DM_BUG e DM_BUGS_BUILD da dimenso Bug

Edio 136 SQL Magazine

11

Um modelo OLAP para visualizao de informaes de builds automticos

Figura 9. Tabela DM_DATA da dimenso Data e exemplos de seleo de elementos nas

hierarquias Data, DiaSemana e Horrio
Uma possvel modificao que pode ser feita nesta dimenso
a combinao das hierarquias em apenas uma dimenso atravs da criao de nveis. Neste artigo optou-se por trabalhar da
forma mais didtica possvel e por isso foram criadas diferentes
hierarquias para a diviso de tempo.
Uma vez que todas as dimenses e suas respectivas tabelas
foram apresentadas, preciso detalhar como ser a tabela fato
e as medidas. O objetivo da tabela fato, neste caso, agregar as
informaes de cada execuo do build e combin-las com dados
relacionados ao tempo gasto e outras mtricas importantes para
quem est realizando a anlise.
No modelo descrito neste artigo a tabela fato se chama FT_BUILD
e apresentada sem os relacionamentos com as demais tabelas
de dimenso na Figura 10.

12 SQL Magazine Edio 136

Figura 10. Tabela fato FT_BUILD sem os relacionamentos com as tabelas de dimenso
Note que a tabela fato FT_BUILD contm diversas colunas e relacionamentos. A primeira coluna importante chama-se ID_BUILD
e representa um valor numrico sequencial que o identificador
nico da tabela com a propriedade de chave primria. Em seguida
temos as colunas ID_TIPO_BUILD, ID_RESULTADO, ID_VERSAO,
ID_SPRINT, ID_PLATAFORMA e ID_DATA, que so chaves estrangeiras para as chaves primrias das tabelas DM_TIPO_BUILD,
DM_RESULTADO, DM_VERSAO, DM_SPRINT, DM_PLATAFORMA e DM_DATA, respectivamente.

A dimenso Dependencias implementada atravs das tabelas DM_DEP_BUILD

e FT_BUILD, que contm a coluna ID_
BUILD. Deste modo, no h colocao da
chave estrangeira na tabela de fatos para
conectar a dimenso de dependncias. De
forma semelhante, o relacionamento que
implementa a dimenso Commit depende
de FT_BUILD e DM_COMMIT_BUILD.
Alm disso, a dimenso Bug tambm
possui relacionamento com a tabela fato,
sendo implementado de maneira equivalente, atravs de DM_BUGS_BUILD.
A tabela fato FT_BUILD apresentada
junto com os relacionamentos com as
demais tabelas de dimenso (DM_TIPO_
BUILD, DM_RESULTADO, DM_VERSAO,
DM_ SPRINT, DM_PLATAFORMA e
DM_DATA) no modelo final exposto na
Figura 11.
As outras colunas da tabela FT_BUILD
vo definir as medidas numricas que
permitiro a anlise de dados, lembrando
que as medidas sempre so em relao ao
resultado final da execuo do processo
de build automtico.
A primeira coluna que armazena medidas na tabela fato se chama TOTAL_LOC
e ela indica a quantidade de linhas de
cdigo total do projeto (somando todos
os arquivos com cdigo fonte); a coluna
TOTAL_TEMPO_SEGUNDOS indica em
segundos qual foi o tempo total para a
realizao do build; a coluna TOTAL_
QTD_BUGS contm a quantidade total
de bugs do projeto; a coluna QTD_BUGS_
CORRIGIDOS armazena o nmero de
bugs corrigidos em cada build; a coluna
TOTAL_QTD_COMITS indica o nmero
de commits desde a execuo do ltimo
build; a coluna TOTAL_QTD_PACOTES
contm o nmero total de pacotes Java do
projeto; a coluna TOTAL_QTD_ARQUIVOS armazena a quantidade de arquivos
com cdigo fonte Java no projeto; a coluna
TOTAL_QTD_TESTES armazena a quantidade total de testes (independentes do
tipo) que o processo de build realizou; a
coluna QTD_TESTE_SUCESSO armazena
o nmero de testes que foram realizados com sucesso, ou seja, que passaram
durante o processo de build; e a coluna
QTD_LOC_COBERTO_TESTES armazena

Figura 11. Tabela fato FT_BUILD e seus relacionamentos com as demais tabelas de dimenso do modelo
a quantidade de linhas de cdigo cobertas
por testes no projeto.
As medidas geradas a partir da tabela
fato deste modelo de dados so descritas
a seguir. importante destacar que estas
medidas podem ser customizadas e combinadas para montar diferentes cubos de
dados que mostrem facetas especficas
do negcio dependendo do que se desejar
visualizar. Vejamos as medidas geradas:
TotalLinhasDeCodigo (coluna TOTAL_
LOC) indicar a quantidade total de linhas
de cdigo do projeto no momento do build.
Quando se agregar esta medida de acordo
com os filtros de dimenso, a ferramenta
deve somar os valores desta medida;
TempoGasto (coluna TOTAL_TEMPO)
indicar o tempo total utilizado para fazer
o build. Esta medida pode ser convertida
para horas, minutos e segundos para facilitar sua visualizao. Quando se agregar
esta medida, a ferramenta deve somar os
valores desta medida;
MdiaTempoGasto (coluna TOTAL_
TEMPO) indica em horas, minutos e
segundos o tempo mdio necessrio para
fazer o build. Quando se agregar esta

medida de acordo com os filtros de dimenso, a ferramenta deve fazer a mdia dos
valores desta medida;
TotalBugs (coluna TOTAL_QTD_BUGS)
indicar a quantidade total de bugs no
projeto no momento do build. Quando se
agregar esta medida, a ferramenta deve
somar os valores desta medida;
BugsCorrigidos (coluna QTD_BUGS_
CORRIGIDOS) indicar a quantidade de
bugs corrigidos desde o ltimo build.
Quando se agregar esta medida, a ferramenta deve somar os valores desta
medida;
TotalCommits (coluna TOTAL_QTD_
COMITS) indicar a quantidade total
de commits realizados desde o ltimo
build. Quando se agregar esta medida, a
ferramenta deve somar os valores desta
medida;
TotalPacotesJava (coluna TOTAL_QTD_
PACOTES) indicar a quantidade total de
pacotes analisados durante o build. Quando se agregar esta medida, a ferramenta
deve somar os valores desta medida;
TotalArquivosCodigoFonte (coluna
TOTAL_ QTD_ARQUIVOS) indicar a

Edio 136 SQL Magazine

13

Um modelo OLAP para visualizao de informaes de builds automticos

quantidade total de arquivos com cdigo fonte analisados durante

o build. Quando se agregar esta medida, a ferramenta deve somar
os valores desta medida;
TotalTestes, TestesSucessoPerc e TestesFalhaPerc (colunas
TOTAL_QTD_TESTES e QTD_TESTE_SUCESSO) mostrar a
quantidade total de testes, o percentual de testes com sucesso e o
percentual de testes com falha do build, respectivamente. Quando
se agregar esta medida de acordo com os filtros de dimenso, a
ferramenta deve somar os valores desta medida;
TotalCobertura (coluna QTD_LOC_COBERTO_TESTES) indicar o percentual do cdigo fonte coberto com testes do build.
Quando se agregar esta medida, a ferramenta deve somar os
valores desta medida.
Os dados gerados durante o processo de build automtico em um
projeto de software possuem a capacidade de produzir diferentes
vises do andamento do projeto e permitem a anlise detalhada
de aspectos envolvendo tempo, commits, bugs, verses, sprints
e outras informaes. Este tipo de anlise especialmente importante para gerentes de projeto que precisam periodicamente
avaliar a qualidade do software e realizar o acompanhamento do
projeto a cada execuo do processo de build.
Baseado neste cenrio, este artigo apresentou um modelo de
dados multidimensional utilizado para facilitar as anlises de
diversos aspectos relacionados ao processo de build automtico
de um projeto de software que adota a tecnologia Java. O modelo
descrito contm dimenses para facilitar as anlises por builds,
datas, verses, ciclos de desenvolvimento, bugs, commits e dependncias de software. J as informaes quantitativas apresentadas
incluem totais de linhas de cdigo, testes, tempos, bugs e commits
realizados por desenvolvedores.

Autor
Mauro Pichiliani
[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.
Links:
Ferramenta de build Maven
https://maven.apache.org/
Ferramenta de build Gradle
http://gradle.org/
Framework para testes em Java JUnit
http://junit.org/
Ferramenta PMD para gerao de mtricas de cdigo
https://pmd.github.io/
Ferramenta CheckStyle para verificao de estilo de codificao
http://checkstyle.sourceforge.net/
Ferramenta FindBugs para identificao automtica de bugs
http://findbugs.sourceforge.net/
Ferramenta Bugzilla para controle de bugs
https://www.bugzilla.org/

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

14 SQL Magazine Edio 136

Edio 136 SQL Magazine

15

Manipulao de
arquivos de dados e log
no SQL Server
Aprenda neste artigo como dimensionar e alocar
os arquivos de dados e de log transaction

s arquivos de dados do SQL Server so compostos por dois tipos: de dados e de log transaction.
Nos arquivos de dados geralmente so armazenados objetos do banco como tabelas, procedures,
triggers e ndices, assim como registros de clientes. J
nos arquivos de log so registradas todas as alteraes
ocorridas no banco para que ele possa ser recuperado
em caso de desastres do tipo perda de disco, falha em
um dos arquivos de dados, etc. Os arquivos de dados e
de log so divididos da seguinte maneira:
Arquivos de dados primrio, com a extenso .mdf;
Arquivos de dados secundrios, com a extenso .ndf;
Arquivos de log, com a extenso .ldf.
Esses arquivos possuem suas particularidades e funes dentro do banco de dados e a perda de um desses
arquivos pode significar a perda de parte das informaes contidas no banco de dados, ou mesmo a perda de
todo o banco. No caso da perda de um dos arquivos, o
procedimento mais indicado a restaurao do banco de
dados, mas voc deve ter o cuidado de executar rotinas
de backup periodicamente.
Os arquivos .mdf so os primeiros a serem criados
quando voc executa o comando CREATE DATABASE.
O arquivo mdf sempre far parte do filegroup primary.
Dentro dele estaro armazenadas informaes sobre
tabelas, views, tabelas de sistema e metadados. Alm disso, podem ser localizados procedures, ndices, registos
e usurios. Para o armazenamento de tabelas e ndices
de usurios, no entanto, recomendamos trabalhar com
arquivos de dados secundrios.
Os arquivos .ndf armazenam dados secundrios,
opcionais no banco de dados. Eles podem ser montados

16 SQL Magazine Edio 136

Fique por dentro

Os arquivos de dados so objetos de extrema importncia em um
banco de dados, independente se estivermos falando de SQL Server,
Oracle ou MySQL. Dentro dos arquivos de dados encontram-se tabelas, ndices, procedures e registros propriamente ditos de clientes,
fornecedores e funcionrios. Por isso, os mesmos necessitam de cuidados. Sendo assim, daremos recomendaes e instruiremos como
alocar estes arquivos, como controlar o espao e configur-lo para
que seu banco ganhe performance com o gerenciamento correto
dos arquivos de dados.

tanto durante o planejamento do banco de dados ou posteriormente, aps a concluso do banco. A principal funo destes arquivos
aumentar a capacidade de armazenamento da base e manter uma
rea separada dos arquivos *.mdf, onde sero gravadas tabelas de
sistema e metadados. Como j mencionado, aconselhado utilizar
arquivos secundrios para armazenar dados dos usurios.
Caso voc no tenha o hbito de trabalhar com estes arquivos
e acha que a melhor forma armazenar os dados com arquivos
primrios, sugerimos que voc pense a respeito e trabalhe com
arquivos secundrios. Desta forma, voc pode aumentar a capacidades de armazenamento da base e ao mesmo tempo melhor
organizar os objetos e registros especficos de usurios.
O terceiro conjunto so os arquivos de Log Transaction, que
possuem a extenso .ldf. Este tipo de arquivo responsvel pela
recuperao do banco de dados em caso de falhas, sendo utilizado
em operaes de log shipping, possibilitando a recuperao da
base em caso de desastres (falha fsica de discos ou estrutura de
arquivos). Os arquivos de log armazenam todas as mudanas
realizadas no banco, permitindo a recuperao de instrues
quando estas no surtem o efeito esperado pelo programador.

 atravs dos arquivos de log que o SQL Server mantm a integridade dos dados.
Abordaremos neste artigo de que forma voc pode alocar os
arquivos de dados e log transaction, assim como saber a diferena
entre eles. Arquivos de dados tm por objetivo o armazenamento
de registros, objetos (procedures, ndices, views) e a estrutura de
tabelas, tanto de clientes quanto do sistema do SQL Server. J os
arquivos de Log Transaction tm por objetivo armazenar todas
as mudanas que so realizadas no banco (Insert, Update, Delete).
Abordaremos aqui os tipos de volume de disco mais adequados
ao tipo de arquivos que se est manipulando. Para os arquivos de
dados, recomenda-se dar preferncia a unidades onde a leitura
tenha uma tima performance, enquanto para arquivos de log,
recomenda-se o uso de unidades onde a gravao tenha melhor
performance. Apesar das diferenas, ambos os arquivos necessitam de unidades de disco com redundncia a falhas.

RAID 5: o RAID 5 combina o desempenho necessrio e a redundncia a falhas, viabilizando excelente desempenho para a
escrita e bom desempenho para a leitura. No entanto, caso uma
das unidades falhe, o desempenho leitura ficar prejudicado,
causando gargalos em instrues select, por exemplo. Mesmo
assim, convm utilizar esse tipo de RAID para armazenar tanto
arquivos de dados quanto arquivos de log;
RAID 0+1 ou 10: o RAID 0+1 ou RAID 10 junta a velocidade do
RAID 0 (striping) com a redundncia a falhas do RAID 1 (mirror).
Neste tipo de partio as leituras ganham um timo desempenho
e atualmente a melhor opo para armazenamento de arquivos
para banco de dados, independentemente de este ser o SQL Server,
o Oracle ou o MySQL. Este tipo de RAID necessita de no mnimo
quatro discos. Ademais, a Microsoft recomenda fortemente que
os arquivos do banco, principalmente os arquivos de log, sejam
alocados nesta partio.

Onde alocar arquivos de dados e de log do banco

Existem outros tipos de RAID, mas procuramos destacar os

mais usados e estudados para a implantao de banco de dados
SQL Server. Existem ainda os RAIDs de software, os quais so
gerenciados se criados por sistemas terceiros, e na verso 2012 e
2014 do Windows Server Enterprise voc pode criar RAIDs atravs
da funcionalidade File and Storage Services. Apesar destes recursos, sempre sugerido o RAID de hardware, muito mais seguro
e confivel.

Agora que voc j tem uma ideia sobre arquivos de dados e de

log transaction do SQL Server e qual a importncia dos mesmos,
vamos mostrar onde cri-los.
Os arquivos de dados e de log so alvos de instrues DML
(Insert, Update, Delete e Merge) e DDL (Create, Alter, Drop, Truncate), alm de muitas instrues envolvendo select filtrando dados
especficos. A unidade de disco onde voc ir alocar os arquivos de
dados e log faz muita diferena, mediante as operaes enviadas
ao banco de dados. Alm disso, o tipo de partio e RAID far
com que seu banco tenha mais performance ou uma performance
precria, assim como ir indicar se ele est alocado em uma rea
segura ou uma rea que no oferece redundncia a falhas. Para
entender mais a fundo sobre alocao de arquivos de dados e
de log, vamos explicar a seguir os tipos de RAID existentes e as
recomendaes de alocao:
RAID 0 (Zero): conhecido tambm por striping, o RAID 0 junta vrias unidades de disco, formando assim um nico disco, e
apresenta um timo desempenho de leitura e gravao. O grande
problema do RAID 0 que se um dos volumes falhar, a partio
toda perdida. Desta forma, embora ele seja uma tima opo de
desempenho, no oferece nenhuma redundncia a falhas;
RAID 1: conhecido tambm por mirroring (espelhamento), no
RAID 1 so usadas duas unidades de disco, que devem obrigatoriamente ter o mesmo tamanho. Caso voc use dois discos de
500GB, por exemplo, seu espao para alocar arquivos do banco
continuar sendo de 500GB e no de 1T. Lembre-se que voc
est espelhando uma unidade e duplicando-a. Em funo do
RAID 1 escrever em dois discos por ser espelhado, isso garante
a redundncia a falhas. Assim, caso um disco pare, o outro ir
assumir a responsabilidade do disco principal. Por outro lado, o
RAID 1 perde em performance, apresentando um desempenho
razovel na leitura e uma piora nos inserts e updates, pois a escrita realizada em duas unidades para manter a consistncia.
Se desempenho no for o primordial para seu banco e sim a
segurana, use o RAD 1;

Criao dos arquivos de dados e log

Agora que voc j conhece as funes dos arquivos de dados
e de log e j sabe onde armazenar os arquivos do banco, vamos
aprender como criar os bancos e definir o caminho para estes
arquivos. O primeiro exemplo que apresentamos utiliza a sintaxe
de criao do banco de dados, conforme expe a Listagem 1.
Listagem 1. Criao do banco de dados.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.

CREATE DATABASE [SQL_Teste]

ON PRIMARY
( NAME = NSQL_Teste,
FILENAME = NE:\MSSQLSERVER\DATA\SQL_Teste.mdf ,
SIZE = 5120KB ,
FILEGROWTH = 1024KB )
LOG ON
( NAME = NSQL_Teste_log,
FILENAME = NE:\MSSQLSERVER\DATA\SQL_Teste_log.ldf ,
SIZE = 1024KB ,
FILEGROWTH = 10%)
GO

Neste exemplo temos um banco de dados de nome SQL_Teste

sendo criado. Note que este banco possui um grupo de arquivos chamado PRIMARY definido na instruo ON PRIMARY.
O nome lgico do arquivo deste banco SQL_Teste, definido
no comando NAME, e seu nome fsico descrito pela sua localizao: NE:\MSSQLSERVER\DATA\SQL_Teste.mdf, definida no
comando FILENAME. O arquivo de log, por sua vez, no possui
grupo e j criado diretamente conforme o caminho indicado em

Edio 136 SQL Magazine

17

Manipulao de arquivos de dados e log no SQL Server

E:\MSSQLSERVER\DATA\SQL_Teste_log.ldf. J o comando SIZE

determina o tamanho inicial com que os arquivos sero criados
e FILEGROWTH determina de quantos em quantos KB ou porcentagem um arquivo de dados ou log ir crescer.

Adicionando arquivos ao banco

Aps a criao do banco de dados, podemos criar novos arquivos
como sugere o exemplo da Listagem 2 com o comando ALTER
DATABASE. Antes disso, no entanto, usando tambm o ALTER
DATABASE, criamos um novo grupo de arquivos, chamado
SECUNDARIO, local onde inserimos dois arquivos de dados
com a extenso ndf, por serem arquivos secundrios. Observe
o comando a seguir:

ou pela porcentagem. Neste exemplo estamos realizando as configuraes referentes ao arquivo SQL_Teste_02, como podemos
ver no ttulo da janela.
Vamos explicar agora as opes desta janela. Posteriormente mostraremos como aplicar estas opes e como voc pode
configur-las para obter benefcios na administrao do banco
de dados. Vejamos as opes:
Enable Autogrowth: ao habilitar esta opo, poderemos definir,
em MB ou porcentagem, de quanto em quanto os arquivos de
dados devem crescer quando alcanar seu limite;
In_Percent: se por acaso o arquivo possuir 500MB, ele ir crescer
10% sobre tamanho de 500MB. Desta forma, ele ir crescer mais 50MB,
supondo que o valor de In_Percent esteja configurado para 10%;

ALTER DATABASE [SQL_Teste] ADD FILEGROUP [SECUNDARIO]

Listagem 2. Criao de arquivos de Dados.

GO

Vejamos os comandos individualmente:

ALTER DATABASE: indica qual banco ir sofrer a alterao;
ADD FILE: indica que estamos inserindo um arquivo de dados
no banco descrito na instruo ALTER DATABASE;
NAME: define o nome lgico do arquivo de banco de dados;
FILENAME: define o caminho onde o arquivo de dados ser
alocado. Este o nome fsico do arquivo;
SIZE: aqui se define o tamanho inicial do arquivo, que pode
ser dado por: KB, MB e GB;
MAXSIZE: define o tamanho mximo que um arquivo de dados
ir crescer. Os valores podem ser definidos por KB, MB e GB;
FILEGROWTH: com este comando especificamos de quanto
em quanto o arquivo ir crescer assim
que atingir seu tamanho, caso o FILEGROWTH esteja ativo;
TO FILEGROUP: este comando
indica em quais grupos de arquivos os
dois arquivos de dados da Listagem 2
faro parte.
Embora seja possvel usar cdigos
para inserir arquivos de dados e controlar seu tamanho, podemos usar o
ambiente grfico do SQL Server, como
mostrado na Figura 1. Para acessar
esta tela, clique com o boto direito do
mouse em cima do banco que deseja
manipular e escolha a opo Properties. Caso seu SQL Server esteja em
portugus, Propriedades, dentro do SQL
Server Management Studio.
Na tela apresentada na Figura 2, controlamos o limite de crescimento que
um arquivo de banco de dados pode ter
e de quantos em quantos MBs o mesmo
ir crescer, sendo especificado em MB

18 SQL Magazine Edio 136

01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.

ALTER DATABASE [SQL_Teste]

ADD FILE
( NAME = NSQL_Teste_02,
FILENAME = NE:\MSSQLSERVER\DATA\SQL_Teste_02.ndf ,
SIZE = 5120KB ,
MAXSIZE = 1048576KB ,
FILEGROWTH = 102400KB )
TO FILEGROUP [SECUNDARIO]
GO
ALTER DATABASE [SQL_Teste]
ADD FILE
( NAME = NSQL_Teste_03,
FILENAME = NE:\MSSQLSERVER\DATA\SQL_Teste_03.ndf ,
SIZE = 5120KB ,
FILEGROWTH = 102400KB )
TO FILEGROUP [SECUNDARIO]
GO

Figura 1. Insero de arquivos de dados opo Files

 In_Megabytes: o arquivo ir crescer mediante o valor informado na opo In_Megabytes. Por exemplo, quando um arquivo de
500MB alcanar o espao total, o mesmo ir crescer mais 100MB,
se In_Megabytes receber o valor 100;
Maximum File Size: local onde definido o limite de crescimento de um arquivo de dados. Nesta opo podemos limitar o
crescimento do arquivo ou podemos deixar o mesmo crescer at
a capacidade mxima do disco rgido;
- Limited to (MB): limita o tamanho mximo de um arquivo
de dados. Desta forma voc evita que um arquivo de dados
ocupe todo o espao de um disco e comprometa outros bancos
que possuam arquivos de dados nesta unidade;
- Unlimited: com esta opo ativa voc est liberando o
crescimento do arquivo de dados. Assim, enquanto houver
espao na unidade de onde se encontra o arquivo, o mesmo ir
crescer. Essa prtica no recomendada para a configurao
de arquivos de dados.

a quantidade de registros seja estimada em torno de 30MB, por

exemplo. Aps criar o arquivo primrio, crie um grupo de arquivo
de dados e defina-o como padro e crie um arquivo de dados com
50MB, tendo assim uma folga no crescimento. normal, durante
a implantao do sistema, que o mesmo cresa de forma rpida,
mas quando se entra em produo com dados de usurio, este
crescimento tende a diminuir e cabe a voc observar de quanto
em quanto este banco cresce para que ento possa definir o valor
ideal para o Autogrowth.
Para que voc acompanhe o crescimento do banco de dados,
apresentaremos a seguir alguns comandos:
EXEC master.dbo.xp_fixeddrives: exibe as unidades existentes
no servidor e a quantidade de espao livre, conforme mostrado
na Figura 3;

Figura 3. Sada da execuo do comando xp_fixeddrives

Figura 2. Controle de crescimento de arquivos

sp_helpdb SQL_Teste: exibe o espao total do banco de dados

SQL_Teste e informaes individuais sobre os arquivos de dados,
conforme exibido na Figura 4;
sp_spaceused: este comando exibe o tamanho da base de dados
e o tamanho do espao no alocado nos arquivos de dados, como
mostra a Figura 5;
sp_helpfile: com a execuo dessa instruo, voc ter acesso
a informaes sobre arquivos de dados, como tamanho inicial,
tamanho total, de quanto em quanto o arquivo ir crescer,
assim como o caminho onde os mesmos esto alocados (vide
Figura 6).

Boas prticas para arquivos de dados e Log

Configurando o Autogrowth e Maxsize

Com o contedo apresentado at aqui voc j est apto a criar

seus arquivos de dados e de log e j conheceu as opes para
dimensionar os mesmos. Mas voc j sabe como dimensionar
corretamente estes arquivos de tal forma que no impactem no
desempenho de seus bancos de dados? Embora isso exija um
pouco mais de esforo, saiba que importante limitar o tamanho
de seus arquivos. Deste modo, a partir de agora, vamos verificar
questes como esta para que voc possa aplicar boas prticas e
efetivamente administrar seus SGBDs.

Neste tpico explicaremos como configurar o Autogrowth e

a melhor opo para Maxsize em suas bases de dados. O Autogrowth desabilitado por padro quando um arquivo de banco de
dados criado, mas mediante a quantidade de bancos existentes
dentro de sua instncia, aconselhvel habilitar esta opo para
controlar de quantos em quantos MBs os arquivos crescero e
limitar o crescimento mximo do banco de dados, de forma que o
crescimento de um banco no prejudique os demais que possuem
arquivos existentes em um mesmo volume de disco.
Anteriormente, na Figura 1 mostramos a tela de insero de
arquivos de dados nas propriedades de arquivos do banco. Na
tela da Figura 7 podemos controlar o crescimento e o tamanho
mximo que um arquivo pode alcanar.
Aps habilitar a opo Enable Autogrowth, outras opes so
liberadas para que voc possa trabalhar o dimensionamento
dos arquivos de dados e controlar o fluxo de crescimento dos
mesmos:

Tamanho inicial de um arquivo de dados

Quando voc est definindo o parmetro SIZE na criao de
um arquivo, tanto de dados quanto de log, voc est definindo
o tamanho o qual ele ser criado. Para definir o tamanho inicial
de um arquivo, alm de especificar de quanto em quanto este
ir crescer, vivel que junto aos desenvolvedores se tenha uma
ideia da volumetria de dados que o banco receber. Suponha que

Edio 136 SQL Magazine

19

Manipulao de arquivos de dados e log no SQL Server

File Growth: voc pode limitar o

crescimento do banco em porcentagem
ou em MB. Recomendamos controlar
o crescimento em MB pelo seguinte
motivo: suponha que voc tenha um arquivo de dados de 1TB (Terabyte), o que
muito comum nos dias de hoje, que o
mesmo esteja configurado para crescer
30% sempre que alcanar seu limite e
voc est com apenas 10GB livres em
sua unidade de disco. O arquivo chega,
ento, ao limite e cresce 30% de 1T, ou
seja, 300GB. Pronto, seu banco de dados
trava e junto com ele, todos os arquivos
de dados que se encontram nesta mesma
unidade no tero condies de crescer.
Neste cenrio voc no ir parar apenas
um banco, mas todos os bancos que possurem arquivos de dados nesta unidade.
Assim, recomendamos fortemente que
voc controle o crescimento pela opo
In_ Megabytes, definindo um tamanho
razovel, nem muito grande e nem muito
pequeno. Obtenha essa mdia atravs
dos comandos passados anteriormente
para que voc defina um tamanho razovel de crescimento. Se voc definir
um tamanho muito pequeno, o banco
ter constantes travamentos, porque
a todo o momento o banco ir dimensionar os arquivos de dados e isso gera
esforo tanto para o SQL Server quanto
para o disco rgido. Se voc definir um
taman ho muito grande, o banco de
dados ir dispor de muito tempo para
crescer o arquivo. Quando um arquivo
de dados cresce, o SQL Server preenche
os arquivos mesmo com zeros at chegar
ao tamanho especificado pelo file growth
In_Megabytes, o que gera certa degradao da performance enquanto o arquivo
est crescendo. Mediante a volumetria
de seu banco, cresa os arquivos no mximo de 500MB a 500MB. Fique de olho,
portanto, no quanto est configurado o
parmetro Maxsize, pois ele determina
o tamanho mximo de seus arquivos
de dados e log. Verifique tambm o
espao disponvel em suas unidades de
disco para no ter nenhuma surpresa
desagradvel. Ao criar um cenrio de
teste para estudos, deixe o crescimento
configurado de 100MB a 100MB para os

20 SQL Magazine Edio 136

Figura 4. Sada da execuo do comando sp_helpdb

Figura 5. Sada da execuo do comando sp_spaceused.

Figura 6. Sada de execuo do comando sp_helpfile

Figura 7. Controle de crescimento de arquivos Change Autogrowth

arquivos da base. Desta forma, voc ter
controle sobre o crescimento dos arquivos e caso seja necessrio, pode criar
outros arquivos de dados ou at mesmo
avaliar a expanso do disco, caso no
seja possvel crescer ou criar arquivos de
dados. Note, no entanto, que esse deve
ser o ltimo recurso;
Maximum File Size: nesta opo voc
controla um limite mximo de crescimento
para seu arquivo de dados habilitando a

opo Limited to MB, ou simplesmente

habilita a opo Unlimited, quando o arquivo ir crescer enquanto houver espao
no disco. Contudo, esta ltima opo
perigosa, pois caso voc tenha outros
bancos alocados junto do mesmo arquivo
sem um limite de crescimento, os demais
bancos podem ser prejudicados. Por isso,
sempre trabalhe com um limite de crescimento, controlando este limite pela opo
Limited to MB.

Arquivos de Log de Transao

Os arquivos de log de transao devem receber o mesmo esforo administrativo que os arquivos de dados e talvez at mais
em funo destes arquivos serem responsveis pela recuperao
do banco em caso de falhas. O comportamento de crescimento
dos arquivos de log depende do modelo de recuperao o qual
o banco est configurado. Existem trs modelos atualmente que
so explicados a seguir:
Full: grava nos logs de transao todas as mudanas executadas
no banco. A tendncia deste tipo de recuperao que os arquivos de log cresam bastante mediante as alteraes ocorridas no
banco;
Bulk-Logged: este modelo de recuperao registra nos arquivos
de log apenas algumas transaes, no sendo possvel, portanto,
fazer uma recuperao completa do banco com este modelo. Ele
usado no momento em que o banco ir receber uma alta carga
de dados. Para que os log transactions no cresam de forma
descontrolada, se usa esta configurao;
Simple: este modelo no oferece suporte a backups de log de
transao pelo fato de no escrever transaes nos arquivos de
log que possibilitem a recuperao do banco. Dessa forma, os
logs crescem muito pouco. Este modelo tipicamente usado em
bases de dados que servem apenas como testes de implantao
de sistemas, onde no necessria a recuperao dispensando a
ocupao de disco por crescimento dos arquivos de log.
Em um ambiente de banco de produo, a maioria dos modelos
de recuperao ser configurada como modelo Full. Neste modelo,
se registra todas as transaes e mudanas dentro do banco de
dados, possibilitando a restaurao total em caso de desastres.
Estas alteraes so registradas nos arquivos de log transaction.
Nesta situao voc pode configurar na sesso Enabled Autogrowth, opo In_Megabytes (vide Figura 7), o crescimento de 500MB
a 500MB. Com relao ao Maximum File Size, a mesma regra
para os arquivos de dados. O mesmo deve ser limitado atravs
da opo Limited to (MB). Recomendamos, tanto para arquivos

de dados quanto para arquivos de log, no deixar os arquivos

de dados crescerem vontade no disco. Por mais que exija um
esforo administrativo para monitorar os mesmos, lembre-se que
este o seu trabalho. Recomenda-se deixar 15% de espao livre
na unidade de disco para se ter condies de movimentar e criar
arquivos em outras unidades com espao disponvel.
Para alguns administradores de banco, muito fcil apenas gerenciar instncias pelo ambiente grfico. No entanto, o SQL Server
muito mais do que isso e este artigo mostrou como voc pode
planejar a criao de seu banco de dados, os lugares corretos para
cada tipo de arquivo e que voc no pode simplesmente deixar o
banco crescer sem que tenha um mnimo de esforo administrativo para acompanhar esse crescimento de forma controlada.
Embora o SQL Server possua muitas funcionalidades grficas,
procure usar os cdigos que foram descritos neste artigo. No se
limite apenas parte grfica deste SGBD. Assim voc pode ampliar e aprimorar a sua administrao atravs de cdigos e gerar
muitas outras fontes de relatrios para sua monitoria, alm das
procedures j inclusas no prprio SQL.

Autor
Robson Moraes
[email protected]
Experincia de 19 anos na rea de informtica tendo passado
por reas como analise de suporte gerente de configuraes de
sistemas administrador de conta e a quatro anos como administrador
de banco de dados focado em SQL Server mas tendo experincia com
Oracle e MySQL.

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

21

Dominando os ndices
columnstore
Melhore o desempenho de suas consultas no SQL
Server

ada vez mais as empresas vm provando que

os dados produzidos dentro e fora do ambiente
corporativo podem ser extremamente teis para
a definio de novas estratgias ou at mesmo criao de
novos produtos e servios. Neste contexto, armazenar
os dados de uma forma estruturada e recupervel so
requisitos bsicos para um ambiente analtico.
No mesmo sentido, medida que um volume maior
de informaes produzido e armazenado nos bancos
de dados das empresas, os procedimentos para garantir
um bom desempenho destes sistemas ganham ainda
mais relevncia.
Um dos recursos de banco de dados utilizado para tratar o desempenho das aplicaes so os ndices, que so
estruturas criadas para agilizar a execuo de consultas
disparadas contra determinadas tabelas.
Estabelecendo uma analogia com o mundo fsico, podese comparar os ndices de banco de dados aos ndices de
um livro. A forma mais rpida do leitor encontrar um
assunto especfico em um livro procurando o tema
de interesse em seu sumrio. Ao encontrar o assunto
de interesse, o leitor acessa a pgina desejada sem a
necessidade de passar pelas demais.
Por outro lado, em situaes em que o leitor no deseja
procurar por assuntos especficos, mas sim efetuar uma
leitura completa e sequencial das pginas, o ndice passa
a ser desnecessrio, pois no ser usado pelo leitor.
No mundo de banco de dados nos deparamos com as
mesmas preocupaes, ou seja, existem situaes em que
os ndices so teis e outras em que apenas ocupariam
espao e processamento de mquina se fossem criados.
No ser debatido aqui as melhores prticas para
implementao e manuteno de ndices de banco de
dados. O nosso foco mostrar uma nova opo para
criao de ndices incorporada no SQL Server 2012 que
permite o armazenamento das informaes dos ndices
em formato colunar.
Antes de debater sobre ndices colunares, no entanto,
sero apresentados alguns conceitos bsicos sobre as

22 SQL Magazine Edio 136

Fique por dentro

Este artigo til em situaes em que se deseja melhorar o desempenho de consultas executadas em bancos de dados SQL Server. Algumas
prticas comuns a este tipo de desafio a avaliao da infraestrutura
disponvel, qualidade do cdigo implementado e criao de ndices.
Este artigo se concentra neste ltimo ponto e aborda a teoria e prtica
dos ndices baseados em colunas (Columnstore). Este tipo de ndice
recomendado para ambientes OLAP (Online Analytical Processing)
nos quais usualmente so executados processos de carga de dados
em massa e podem melhorar o desempenho de suas consultas em
at 10 vezes.

estruturas de ndices j existentes no SQL Server (ndices clusterizados e no clusterizados). Estas opes continuam sendo importantes para o planejamento de um banco de dados que garanta
integridade e bom desempenho em suas consultas.
Os ndices colunares devem ser introduzidos nas arquiteturas
atuais de bancos de dados que utilizam o SQL Server como incremento s estruturas e padres de projeto j existentes. Portanto,
antes de comear a implementar este novo recurso, como em qualquer outro tipo de trabalho, necessria uma anlise detalhada
sobre os possveis ganhos de sua aplicao.
Vale ressaltar ainda que os ndices devem ser visualizados
como parte de uma estratgia para melhorar o desempenho das
aplicaes. Sendo assim, quando se deseja tratar o problema
otimizao de ambientes de banco de dados, deve-se levar em
considerao tambm atividades como resizing e melhoria de
processos.

ndices clusterizados e no clusterizados

Existem dois grupos de ndices no SQL Server: ndices clusterizados, tambm conhecidos como ndices agrupados, e os ndices
no clusterizados, tambm chamados de ndices no agrupados.
Ambos so usados por desenvolvedores e administradores de
banco de dados com o objetivo de melhorar os planos de execuo das consultas feitas no banco de dados e, consequentemente,
reduzir o tempo de execuo das mesmas.

Figura 1. Estrutura de um ndice no clusterizado

Como se pode notar, os ndices clusterizados no possuem referncias para as linhas da tabela original em que foram criados
pelo fato de j armazenarem as informaes da tabela em sua
estrutura (no necessrio ter uma referncia).
Vale a pena destacar tambm a forma como os dados so pesquisados. Os ndices clusterizados agrupam as informaes da
tabela (tambm de forma ordenada) em uma espcie de rvore
binria, desta forma, ao buscar uma determinada informao,
o SQL Server filtra as pginas em que a informao pesquisada
poderia estar armazenada at chegar no local exato e retornar
os dados.

Consideraes sobre o uso de ndices

Figura 2. Estrutura de um ndice Clusterizado e funcionamento de busca
Embora compartilhem objetivos em comum, ndices clusterizados e no clusterizados armazenam os dados de ndice em
estruturas diferentes. Enquanto os ndices no agrupados armazenam em sua estrutura uma referncia para as linhas da tabela
original, os ndices agrupados armazenam em sua estrutura a
prpria informao da tabela original.
Em termos de funcionamento, isto significa que os ndices no
clusterizados devem consultar a tabela original (em que o ndice
foi criado) para retornar os dados desejados em uma determinada
consulta, por outro lado, os ndices clusterizados j possuem as
informaes a serem retornadas em sua prpria estrutura.
Na Figura 1 exemplificada a estrutura de um ndice no clusterizado que foi criado sobre uma coluna chamada nome. Nota-se que
ao invs do ndice armazenar os dados originais da tabela em que foi
criado, gravada apenas uma referncia para as linhas da mesma.
Ao efetuar uma consulta na tabela pelo campo nome o mecanismo de banco de dados far uma busca no ndice, que j est
ordenado, e o nome buscado ser retornado. Cada registro do
ndice contm o endereo da sua respectiva linha na tabela. Desta
forma, ao procurar uma determinada informao na estrutura do
ndice, o SQL Server identifica a linha e a pgina de dados em que
esta informao est armazenada.
justamente neste ponto em que ndices agrupados e no agrupados se diferem: na forma de armazenar os dados no ndice e na
forma em que os mesmos so pesquisados. Na Figura 2 apresentada uma estrutura de um ndice clusterizado e um exemplo
de sua dinmica de busca.

xistem cenrios em que mais recomendada a utilizao de

E
ndices clusterizados e outros nos quais a aplicao de ndices no
clusterizados mais apropriada. Para entender em quais situaes
aplica-se melhor um ou outro, vale a pena destacar as principais
diferenas entre estes dois tipos de ndices:
Pode existir mais de um ndice no clusterizado por tabela, ao
passo que apenas um ndice clusterizado permitido;
Comandos INSERTs e UPDATEs tm melhor desempenho
quando so disparados contra tabelas que possuem ndices no
clusterizados quando comparados a disparos contra tabelas com
ndices clusterizados;
Nos ndices clusterizados, a leitura dos dados mais rpida e os
dados so ordenados fisicamente na tabela. Ao contrrio dos ndices no clusterizados, nos quais a leitura mais lenta e os dados
no so ordenados fisicamente na tabela (o ndice armazena uma
referncia lgica para o local em que o dado est armazenado).
Ambos os ndices podem ser usados para agilizar o processamento de comandos SELECTs, no entanto, de alguma forma
tambm podem prejudicar o desempenho de comandos de
INSERTs e UPDATEs.
A forma como os ndices so projetados define o real ganho de
desempenho das consultas no banco de dados. Pode at acontecer
de a criao de ndices resultar em mais perdas do que ganhos
aplicao. Consultas em que nenhum ou poucos filtros (tanto em
linhas quanto em colunas) so definidos, podem ser executadas
com mais agilidade se o mecanismo de banco de dados analisar
todas as informaes da tabela (caracterstica conhecida como
table scan).
Para ajudar no processo de manuteno dos ndices, o SQL
Server conta com uma ferramenta chamada Database Engine

Edio 136 SQL Magazine

23

Dominando os ndices columnstore

Tuning Advisor. Esta ferramenta permite

analisar ndices j existentes para entender se os mesmos esto sendo utilizados
corretamente.
O DTA tambm recomenda a criao
de novos ndices para um determinado
banco de dados, faz recomendaes
para criao de parties e efetua uma
anlise de impacto das recomendaes
efetuadas.

Fundamentos de row-store e columnstore

Figura 3. Armazenamento em linhas

Agora que j definimos alguns conceitos
bsicos sobre ndices e abordamos aqueles mais tradicionais exisVoltando ao SQL Server, pode-se trabalhar com dois tipos de
tentes no SQL Server, iniciaremos o debate sobre um novo tipo de
armazenamento de dados: rowstore e columnstore. O primeiro,
ndice incorporado no banco de dados da Microsoft.
como o prprio nome sugere, trata o armazenamento de dados
Desde sua verso 2012, o mecanismo de banco de dados do SQL
organizados por registros, ou seja, as informaes so organiServer conta com um poderoso recurso para aumentar o desemzadas nas pginas de dados linha a linha. o que acontece, por
penho de suas consultas chamado ndices columnstore. ndices
exemplo, com os tradicionais ndices clustered do SQL Server.
columnstore so baseados na tecnologia VertiPaq, responsvel
A Figura 3 esquematiza o formato de armazenamento de um
pela inteligncia de armazenamento e compresso de dados do
ndice que utiliza o conceito de rowstore.
SQL Server.
Os ndices baseados em linhas podem ter caractersticas difeOs ndices columnstore usam um formato de dados colunar para
rentes no que se refere ordenao ou agrupamento dos dados.
armazenar e recuperar as informaes, denominado columnstore,
No entanto, se o ndice baseado em linhas, obrigatoriamente
e podem melhorar em at 10 vezes o desempenho das consultas.
armazenar em suas pginas de dados informaes de linhas
Isso porque possibilita a otimizao da seleo e compresso dos
inteiras de uma tabela.
dados, como ser detalhado frente.
As pginas de dados destes ndices possuem tamanho de at
Este recurso apropriado para ambientes analticos (OLAP
8Kb e, alm de guardar as informaes da tabela, possuem
Online Analytical Processing) nos quais usualmente so executados
uma estrutura de cabealho e conexes para outras pginas.
processos de carga de dados em massa e consultas em tabelas que
O conjunto de 8 pginas (64Kb) denominado extenso. Isso
armazenam grandes histricos de informao.
significa que para armazenar as informaes do ndice de uma
Ambientes analticos so criados com o objetivo de fornecer
determinada tabela, o SQL Server pode alocar vrias pginas
flexibilidade aos processos de tomada de deciso. Usualmente
(depende do tamanho da tabela).
contidos dentro de uma arquitetura de Business Intelligence, estes
J no tipo de armazenamento colunar (columnstore), as inforambientes possibilitam que os usurios de negcio analisem as
maes so organizadas nas pginas de dados por colunas, ou
informaes em diferentes dimenses, sem a necessidade de
seja, as pginas so alocadas e preenchidas com as informaes
interveno de uma equipe de TI para criar novas vises a todo
de cada coluna da tabela em questo.
momento.
A Figura 4 apresenta a aplicao do conceito de columnstore
Isso possvel porque os metadados so organizados e disponiem um conjunto de dados.
bilizados aos usurios por meio de cubos e relatrios dinmicos.
Em uma rpida comparao entre as Figuras 3 e 4, pode-se
claro que novas demandas continuam existindo, dado a veloobservar claramente a mudana de abordagem entre o armazenacidade dos negcios atuais; no entanto, o ambiente garante mais
mento de dados baseado em linhas e o armazenamento baseado
velocidade de acessos aos dados e este fator pode ser determinante
em colunas. O principal ponto a se observar neste momento a
para a conquista de um novo negcio.
forma como as pginas de dados so preenchidas.
Do ponto de vista de armazenamento de dados, ambientes
Existem outros dois termos que aparecem na Figura 4: Seganalticos costumam usar estruturas de dados conhecidas
ment e Row Group. Nos ndices columnstore, um segment
como Data Warehouse e Data Mart. A ideia que gira em torno
armazena informaes de uma coluna que pertence a um grupo
destes conceitos teoricamente simples: armazenar os dados de
especfico de linhas, conhecido como row group. Na prtica, um
uma forma organizada, facilitando os processos de tomada de
row group pode agrupar220linhas (o que representa 1.048.576
deciso. Na prtica, existem diversos desafios que fazem com
linhas do conjunto de dados).
que projetos de Data Warehouse tenham elevados preos a altos
Portanto, existe um segment para cada combinao de coluna
riscos de fracasso.
e row group. Cada um destes segments comprimido e armaze-

24 SQL Magazine Edio 136

nado separadamente em tipos de dados LOB do mecanismo

de banco de dados do SQL Server.
Por fim, as consultas feitas em tabelas que utilizam ndices
columnstore usam o modo de processamento batch. Este
um mecanismo de processamento de consultas baseado em
vetor que se beneficia de todas as vantagens proporcionadas
pela estrutura de armazenamento em colunas.

Figura 4. Armazenamento em colunas

Consideraes sobre desempenho

O formato de armazenamento de dados em colunas oferece algumas vantagens em relao ao formato de armazenamento em linhas, entre estas vantagens destacam-se
a capacidade de comprimir os dados de uma forma mais
eficiente e o melhor desempenho na execuo de alguns
comandos SELECTs.
Comandos SELECTs que buscam informaes de apenas
algumas colunas de uma tabela podem se beneficiar com a
utilizao de ndices columnstore.
Ao criar um ndice deste tipo na tabela, o mecanismo de
banco de dados capaz de buscar as informaes necessrias nas pginas de dados especficas em que as informaes esto armazenadas (ou seja, possvel acessar apenas
as pginas de dados que armazenam as informaes das
colunas desejadas), reduzindo assim as operaes de I/O,
usualmente responsveis pelo maior tempo de processamento de uma consulta.
Como as informaes das colunas so armazenadas em uma
mesma pgina de dados, o processo de compresso dos dados
tambm otimizado. Isso possvel porque as informaes
de uma mesma coluna possuem um padro semelhante e
tipicamente so mais redundantes quando comparadas s
informaes das linhas de uma tabela (que possuem colunas
de diferentes tipos de domnios de informao).
Este fato simplifica a compresso dos dados e garante o
carregamento de mais informaes em memria. Com esta
otimizao do uso de memria, o banco de dados reduz as
operaes de acesso ao disco, e novamente temos um ganho
de desempenho pela reduo de operaes I/O.

ndice columnstore na prtica

Para demonstrar a utilizao de ndices columnstore, foi preparado um ambiente com SQL Server 2014 com a base de dados
de exemplo fornecida pela Microsoft: AdventureWorksDW. Esta
base possui o formato de um Data Warehouse que, como mencionado anteriormente, o tipo de ambiente mais recomendado
para utilizao de ndices columnstore.
Primeiramente executada uma consulta utilizando um ndice
clusterizado. Em seguida, a mesma consulta executada contra
uma base de dados com um ndice columnstore. Ao final so
apresentadas as principais diferenas de desempenho entre as
duas execues.
Foi criada uma tabela (vide Listagem 1) com base nas tabelas
FactInternetSales e DimSalesTerritory da base de dados AdventureWorksDW. O objetivo obter uma massa de dados maior para
que seja possvel demonstrar o real impacto de desempenho
fornecido pelo ndice columnstore.
Na Listagem 2 apresentado o comando de insert utilizado para efetuar a carga da massa de dados na tabela criada na
Listagem 1. Para essa carga de dados foi efetuado um join com
as tabelas FactInternetSales e DimSalesTerritory. Como mostrado
na linha 12, este comando de insert (Listagem 2) ser repetido
3.500 vezes para a construo da massa de dados.
Listagem 1. Criao de massa de dados.
CREATE TABLE [dbo].[TableInternetSales](
[ProductKey] [int] PRIMARY KEY IDENTITY,
SalesTerritoryCountry VARCHAR(200) NOT NULL,
[UnitPrice] [money] NOT NULL,
[TaxAmt] [money] NOT NULL
);
Listagem 2. Populao da tabela TableInternetSales.
01 INSERT INTO TableInternetSales
02 SELECT
03
ST.SalesTerritoryCountry,
04
UnitPrice,
05
TaxAmt
06 FROM
07 FactInternetSales FS
08 JOIN
09 DimSalesTerritory ST
10 ON
11 FS.SalesTerritoryKey = ST.SalesTerritoryKey
12 GO 3500
13
14 SET STATISTICS IO ON
15 GO
16
17 SET STATISTICS TIME ON
18 GO

As estatsticas de I/O e de tempo do SQL Server foram habilitadas para efetuar os testes de desempenho do ndice columnstore
(linhas 14 a 18 da Listagem 2).
Para efetuar o teste foi construda a consulta da Listagem 3.
Nesta consulta foram utilizadas algumas funes de agregao:
a soma de UnitPrice, a mdia de UnitPrice e a soma de TaxAmt. Por
fim, os dados foram agrupados por SalesTerritoryCountry.

Edio 136 SQL Magazine

25

Dominando os ndices columnstore

Primeiramente, a consulta da Listagem 3 foi executada com base

em um ndice clusterizado. Em seguida foi criado um ndice columnstore na tabela TableInternetSales (vide Listagem 4) com base
nas colunas SalesTerritoryCountry, UnitPrice e TaxAmt e a consulta
foi executada novamente.
Listagem 3. Query construda para o teste de performance.
SELECT
SalesTerritoryCountry,
sum(UnitPrice) SUMUnitPrice,
AVG(UnitPrice) AVGUnitPrice,
Sum(TaxAmt) TaxAmt
FROM
TableInternetSales
GROUP BY
SalesTerritoryCountry;
GO
Listagem 4. Criao do Columnstore Index.
CREATE NONCLUSTERED COLUMNSTORE INDEX INDXCLS_SALESINTERNET
ON TableInternetSales (SalesTerritoryCountry, UnitPrice, TaxAmt);

Conforme apresentado na Figura 5, possvel observar que neste

caso o desempenho da consulta melhorou consideravelmente aps
a criao do ndice columnstore. O nmero de leituras lgicas caiu
para zero. Isso acontece porque neste tipo de ndice as informaes
das colunas so armazenadas em uma mesma pgina de dados
facilitando o acesso aos dados.
Tambm possvel observar que o tempo de CPU e o tempo de
execuo foi diminudo aproximadamente em 98% e 96%, respectivamente. Vale ressaltar neste ponto que estas taxas de melhoria
podem variar de acordo com o ambiente em que a consulta est
sendo executada.

Figura 5. Comparativo das estatsticas de execuo antes e depois da criao do columnstore index

26 SQL Magazine Edio 136

Principais diferenas entre as verses SQL 2012 e 2014

A verso do SQL 2012 apresenta algumas limitaes quanto
ao uso de ndices columnstore. Entre as principais restries
esto:
1) apenas ndices no clusterizados so permitidos;
2) ao utilizar um ndice columnstore a tabela se torna somente
leitura (ndice no atualizvel).
A verso 2014 do SQL Server trouxe algumas novidades, passando a permitir o uso de ndices clusterizados atualizveis. No
entanto, h restries quanto ao uso de ndices columnstore do
tipo clustered, entre elas o fato de no ser possvel combinar outros
ndices na mesma tabela e o fato de no ser possvel definir restries do tipo unique, chave primria ou chave estrangeira.
Alm disso, todas as preocupaes de uma estratgia de
manuteno de ndices devem ser levadas em considerao no
momento de definir como as tabelas sero indexadas.
ndices columnstore podem ser usados em qualquer banco
de dados do SQL Server. Porm, ao utiliz-los em ambientes
analticos, existem grandes oportunidades para melhorar o
desempenho das consultas pela prpria caracterstica deste tipo
de ambiente (tabelas com grandes volumes de dados e histricos
de informao).
Avalie sua aplicao em projetos de Business Intelligence, nas
tradicionais estruturas de Data Warehouse ou Data Marts, por
exemplo. Neste tipo de projeto comum o consumo de informaes por processos ad-hoc ou relatrios.
Como primeiro passo, levante quais so as informaes mais
selecionadas e mais filtradas pelos processos que consomem
os dados. Estas informaes podem ser candidatas para uma
possvel indexao por colunas.

Para projetos j implementados, cabe a anlise dos prprios

ndices rowstore j existentes nas tabelas do ambiente. Eventualmente, estes prprios ndices podem ser substitudos por ndices
baseados em colunas para melhorar o desempenho das aplicaes.
O DTA pode ser usado como ferramenta de apoio para a anlise
de novos ndices ou manuteno dos ndices j existentes.
No entanto, no se esquea de estudar os ganhos reais da aplicao de ndices colunares em seu ambiente de dados. No cenrio
ideal, ndices baseados em linhas e colunas devem atuar juntos
dentro de um plano maior de gesto de dados e desempenho das
aplicaes.
Links:
SQL Server 2016 ColumnStore Technology Channel 9
https://channel9.msdn.com/Shows/Data-Exposed/SQL-Server-2016-ColumnStoreTechnology
Entendendo o Column Store Index no SQL Server 2012 TechNet
http://social.technet.microsoft.com/wiki/contents/articles/9251.entendendo-o-columnstore-index-no-sql-server-2012-pt-br.aspx
ndices columnstore MSDN
https://msdn.microsoft.com/pt-br/library/gg492088.aspx

Autor
Weslley Moura
[email protected]
Graduado em sistemas de informao pela FIAP, possui especializao em Business Intelligence pela mesma instituio e
est concluindo seu mestrado em engenharia de software pelo IPT. Atualmente ocupa seu tempo com projetos de analytics e desenvolvimento
de software nas empresas Rede, Pepsoft Sistemas e FITO.

Autor
Emerson Silva
[email protected]
Graduado em cincia da computao pelo Centro Universitrio
Adventista de So Paulo. Atualmente ocupa o seu tempo com
projetos de BI e infraestrutura em uma multinacional americana.

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

27

Monitoramento automatizado o SQL Server

Envie relatrios em HTML utilizando o SQL Agent
e o Database Mail

monitoramento automatizado do banco de dados uma tarefa importantssima para o DBA,

pois atravs dele que so obtidas informaes
sobre a disponibilidade e sade do ambiente quando o
profissional no est em seu horrio de trabalho. Obviamente, esses dados servem para alertar o administrador sobre um problema que est acontecendo ou para
preveni-lo de um problema que poder acontecer.
Alguns monitoramentos indispensveis devem ser
contemplados no projeto de manuteno do ambiente.
Vejamos:
Disponibilidade da instncia e seus bancos de dados;
Utilizao dos datafiles e transaction logs;
Consumo de recursos: CPU, disco e memria;
Rastreamento de queries mais lentas;
Situao dos ndices (o quanto esto fragmentados);
Ocorrncia de locks;
Jobs em execuo acima do esperado;
Falha em Jobs agendados;
Disco I/O;
Verificao de erros no errorlog;
Situao das rotinas de backup.

Essas so apenas algumas checagens que devem ser
realizadas periodicamente. No entanto, torna-se invivel
o DBA verificar todos esses pontos em todos os servidores que ele administra. Para isso existe o monitoramento
automatizado e, consequentemente, existem diversas
solues que podem ser adotadas.
Em empresas cujo investimento no um problema,
so implementadas ferramentas dedicadas para tal propsito. Alguns exemplos so: Microsoft System Center,
Nimsoft, Zabbix, entre outros. Porm, em empresas que
esse investimento no pode ser pago e que, inclusive, o
time de DBAs reduzido, podem-se obter excelentes
resultados de monitoramento configurando a gama de
recursos que o SQL Server j tem a oferecer nativamente,
sem custo adicional algum.

28 SQL Magazine Edio 136

Fique por dentro

Em diversas empresas, no existe uma soluo dedicada para realizar
o monitoramento do(s) servidor(es) SQL. Sendo assim, os recursos do
prprio SQL Server podem ser configurados com esse objetivo. Nesse
artigo ser abordado o envio de relatrios formatados em HTML, utilizando o SQL Agent e o Database Mail. O exemplo descrito monitora
os discos do servidor, permitindo a visualizao de espao total, livre
e o percentual livre de cada unidade.

Em diversas empresas h apenas um ou dois DBAs, o que exige

mais controle e conhecimento dos ambientes de banco de dados,
considerando que se houver algum problema, o prprio ter que
resolver rapidamente. Portanto, ao configurar verificaes mais
importantes, j damos ao DBA mais tranquilidade e poder de ao
com antecedncia. Outro ponto importante a melhoria contnua
do desempenho no banco de dados. Com um monitoramento
adequado, pode-se rastrear e melhorar queries mais lentas, verificao de locks constantes, jobs custosos, fragmentao de ndices,
crescimento dos datafiles e mais uma srie de outras anlises, o
que tornar a aplicao mais eficiente aps aes tomadas em
cima desses dados.
Esse artigo ir abordar a combinao de scripts T-SQL que gera
relatrios em HTML de uma determinada anlise do ambiente,
o SQL Agent para agendar essa anlise em perodos regulares e
o Database Mail para envio do relatrio gerado.

O Database Mail
O Database Mail uma soluo para envio de mensagens do
mecanismo de banco de dados do SQL Server. Por padro, o recurso vem desativado e possvel ativ-lo por meio do assistente
de configurao. Sua configurao simples, baseada apenas em
um perfil associado a uma conta SMTP.
H configuraes adicionais de parmetros do sistema em que
se restringe o tipo de arquivo (extenso) anexado nas mensagens
ou o seu tamanho, por exemplo.

Para usar o Database Mail, o usurio

deve ser membro da funo de banco de
dados DatabaseMailUserRole no banco de
dados msdb. As informaes de configurao do Database Mail so armazenadas
no banco de dados msdb e a procedure
sp_ send_ dbmail contida neste banco
utilizada para a formatao e envio das
mensagens. O Database Mail deve ser
primeiramente configurado, pois o nome
do perfil utilizado no script T-SQL.

O script T-SQL
Nesta alternativa de monitoramento, a
lgica da anlise realizada de forma automtica est no script T-SQL. Portanto, para
que a verificao seja consistente, necessrio ter em mente o que ser analisado e
como ser apresentada a informao.
A partir do SQL Server 2005, informaes
relacionadas sade da instncia e seus
objetos so encontradas nas DMVs e DMFs
(vises e funes de gerenciamento dinmico). Atravs das DMVs/DMFs podemos
coletar e cruzar dados importantes da
utilizao do ambiente. Com esses dados
coletados possvel determinar dentro da
lgica do script T-SQL um threshold (margem/limite) que, aps ser ultrapassado ou
se estiver abaixo do esperado, o DBA deve
dar ateno.
possvel realizar anlises diversas
que podem ser formatadas em HTML e
enviadas por e-mail, como fragmentao

Figura 1. Perfil do Database Mail

de ndices, query mais lentas ou utilizadas, waits, ocupao dos datafiles, entre
muitas outras.
No exemplo proposto nesse artigo, o
script T-SQL verifica o espao total, livre
e o percentual livre calculado para cada
unidade de disco que aloca arquivos dos
bancos de dados. Para facilitar a visualizao do que o script faz, o ideal dividi-lo
em partes. Por exemplo: a consulta das
informaes requeridas, o tratamento das
informaes dentro do HTML e o envio do
relatrio atravs da chamada da procedure
msdb.dbo.sp_send_dbmail.

O SQL Agent
O SQL Agent o servio responsvel por
executar jobs agendados. Os componentes
deste servio podem ser classificados em:
jobs, steps, schedules e alerts. Cada job
criado contm um ou mais steps e cada
step sua prpria instruo.
Cada step tambm poder ter um tipo
diferente de instruo como, por exemplo:
um script T-SQL, um script PowerShell
ou um pacote do Integration Services. Vai
depender de cada finalidade. Alm disso,
pode ser definido um usurio para executar cada step, um arquivo de log de sada
e o comportamento em caso de sucesso ou
falha na execuo.
Nos schedules temos os tipos: quando o
servio do SQL Agent for iniciado, quando
a CPU estiver ociosa, execuo recorrente

e execuo apenas uma vez em uma data

e horrio determinado. Em tarefas administrativas e de manuteno dos bancos, o
tipo mais utilizado o recorrente. No tipo
recorrente temos a frequncia que poder
ser diariamente, semanalmente e mensamente. Em cada tipo de frequncia tambm
haver as configuraes de intervalo, data
de incio e fim de execuo de cada job.
Para cada job podemos configurar mais de
um schedule. Pode ser configurado ainda
um alert que uma resposta automtica
a um evento. Um alert responde a uma
condio e notifica um operador sobre o
evento ou executa um job.
As roles SQLAgentUserRole, SQLAgentReaderRole e SQLAgentOperatorRole so
responsveis por dar permisses na utilizao do SQL Agent, cada uma com seu
conjunto de permisses. Ou seja, o usurio
precisa ser membro de uma ou mais dessas
roles para usar o servio. Se o usurio for
sysadmin, j ter acesso total e no precisar ser membro das roles mencionadas.
Por meio do SQL Agent, o script T-SQL
da anlise desejada poder ser executado
em perodos regulares e os resultados
enviados ao DBA.

Configurao do perfil e conta no

Database Mail
O perfil dever ter obrigatoriamente
um nome. Aps dar um nome ao perfil,
necessrio adicionar uma conta SMTP com
os dados de sada e autenticao. Para isso,
necessrio saber os dados do servidor
SMTP: seu nome, porta e se requer SSL
(conexo segura). Na Figura 1, o perfil foi
configurado com o nome SQLAgentDBA e
a conta SMTP j est adicionada. Veremos
suas configuraes na sequncia.
A conta SMTP tambm exige um nome.
Neste caso, DBA Monitoring, conforme
a Figura 2. A descrio opcional. Nas
configuraes de Sada (Outgoing mail
server), o e-mail (endereo de envio do monitoramento que estamos configurando), o
nome do servidor e nmero da porta so
obrigatrios. Neste exemplo foi utilizado
um endereo do Hotmail e o nome do
servidor correspondente: smtp.live.com.
Ao habilitar a opo SSL, uma porta segura
dever ser definida (neste caso 587).

Edio 136 SQL Magazine

29

Monitoramento automatizado o SQL Server

Os campos Display name e Reply e-mail

so opcionais. O campo Display name
utilizado para definir o nome que ser
mostrado nas mensagens que chegam ao
programa de mensagens. Por exemplo,
SQL Agent DBA Monitoramento. Ou podemos deixar com o mesmo endereo do
campo anterior.
O Reply e-mail, por sua vez, ser usado
para respostas s mensagens que chegaram. Por exemplo, ao responder uma
mensagem de monitoramento, esta tambm ser enviada a outro endereo que foi
definido neste campo.
Tambm teremos as configuraes de
autenticao: Windows (credencias configuradas para o servio do SQL Server),
bsica e annima. A opo autenticao
de Windows faz com que o Database Mail
utilize o usurio e senha que iniciam o
servio do SQL Server. Este usurio dever
ter um endereo de e-mail associado e suas
configuraes so definidas no controlador de domnio (Active Directory).
Na autenticao bsica so especificados
o usurio e senha associados ao servidor
definido nas configuraes de sada. E na
autenticao annima no necessrio
definir usurio e senha, mas o servidor
SMTP precisa estar configurado para no
exigir autenticao.

A construo do script T-SQL

A DMF sys.dm_os_volume_stats est
disponvel na verso SQL Server 2008 R2
SP1 ou posterior. Portanto, o script que
ser apresentado no ser compatvel em
verses anteriores. Em verses anteriores
possvel usar a procedure no documentada xp_fixeddrives, porm, a mesma s
traz o espao livre em MBs da unidade. H
tambm a possibilidade de utilizar a opo
Ole Automation Procedures (ativada pelo
sp_configure), mas no recomendvel
por questes de segurana.
No script apresentado na Listagem 1,
inicialmente feita uma consulta na
tempdb.sys.tables para verificar se a tabela
temporria chamada #Drives existe. Caso
exista, eliminada e criada com os campos
drive, freespace, totalsize e percentfree e os
seus devidos tipo de dados. Lembrando
que o banco de dados tempdb armazena as

30 SQL Magazine Edio 136

Figura 2. Configurao da conta SMTP vinculada ao perfil do Database Mail

Listagem 1. Script T-SQL Utilizao de discos Parte 1.
-- Cria a tabela temporria #Drives
SET NOCOUNT ON
GO
IF EXISTS ( SELECT name
FROM tempdb.sys.tables
WHERE name LIKE #Drives% )
DROP TABLE #Drives
GO
CREATE TABLE #Drives
(
Drive CHAR(3) PRIMARY KEY ,
FreeSpace INT NULL ,
TotalSize INT NULL ,
PercentFree AS ( CONVERT(FLOAT, FreeSpace) / TotalSize ) * 100
)
GO
-- Insere as informaes na tabela temporria consultando a DMF sys.dm_os_volume_stats
-- (apenas dos discos que esto armazenando datafiles)
INSERT #Drives
( Drive ,
FreeSpace ,
TotalSize
)
SELECT DISTINCT
dovs.volume_mount_point ,
CONVERT(INT, dovs.available_bytes / 1048576.0) ,
CONVERT(INT, dovs.total_bytes / 1048576.0)
FROM sys.master_files mf
CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) dovs
ORDER BY dovs.volume_mount_point ASC
GO
-- Variveis para envio de e-mail
DECLARE @tableHTML NVARCHAR(MAX) ,
@Subject VARCHAR(100)

tabelas temporrias e estas so eliminadas quando a conexo

fechada. No crie tabelas fsicas nesse banco, pois toda vez que a
instncia reiniciada, o tempdb recriado e todas as informaes
contidas nele so perdidas. Neste exemplo, importante relatar
a coluna PercentFree que faz o clculo percentual do espao livre
obtido das colunas FreeSpace (nmeros em MB) e TotalSize (nmeros em MB).
No segundo bloco so inseridas as informaes na tabela
temporria a partir da consulta na DMF sys.dm_os_volume_stats.
feito o clculo nas colunas available_bytes e total_bytes para
obter-se os valores em megabytes. O cross apply entre as tabelas
sys.master_files e sys.dm_os_volume_stats tem a mesma finalidade
que um inner join.
Em seguida, j na Listagem 2, o HTML montado e tratado
dentro um de SELECT com a expresso CASE que define a cor
dos campos em vermelho quando o percentual livre for menor
ou igual a 15% do espao total de cada unidade. Essa montagem
feita dentro da varivel @tableHTML que definida com o
tipo nvarchar(max). O nvarchar(max) tem o tamanho de armazenamento mximo de 2GB, ou seja, no haver problema de
truncamento dentro da varivel @tableHTML. Seu tamanho
mais que suficiente para esse objetivo.
Listagem 2. Script T-SQL Utilizao de discos Parte 1.
-- Monta o HTML para o envio do relatrio com as informaes de espao total/
livre
SET @tableHTML = N<H1>Utilizao de Discos</H1> + N<table border=1>
+ N<tr><th>Drive</th><th>Total (MB)</th><th>Livre (MB)</th><th>%
Livre</th></tr>
+ CAST(( SELECT CASE WHEN [PercentFree] <= 15 THEN #FF0000
END AS td/@BGCOLOR ,
td = Drive ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= 15 THEN #FF0000
END AS td/@BGCOLOR ,
td = TotalSize ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= 15 THEN #FF0000
END AS td/@BGCOLOR ,
td = FreeSpace ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= 15 THEN #FF0000
END AS td/@BGCOLOR ,
td = CONVERT (NUMERIC(10, 2), [PercentFree])
FROM #Drives
FOR
XML PATH(tr) ,
TYPE
) AS NVARCHAR(MAX)) + N</table>;

-- Chama a procedure sp_send_dbmail para envio do e-mail utilizando o perfil

-- SQLAgentDBA criado no Database Mail
SET @Subject = Utilizao de discos do servidor: + @@Servername
EXEC msdb.dbo.sp_send_dbmail @profile_name = SQLAgentDBA,
@recipients = [email protected],
@body = @tableHTML,
@subject = @Subject, @body_format = HTML

Finalmente, ocorre a chamada da procedure sp_send_dbmail, contida na msdb, cujos parmetros bsicos neste exemplo so: o nome
do perfil configurado no Database Mail (varivel @profile_name),
os destinatrios (varivel @recipients), o corpo (varivel @body)
que foi formatado dentro da @tableHTML, o assunto (varivel
@subject) que contm a funo @Servername para retornar o
nome do servidor no ttulo do e-mail e a definio do formato
HTML no corpo do e-mail (varivel @body_format).
A partir desse script podemos criar um procedimento armazenado (stored procedure), o que torna os parmetros mais prticos
de serem alterados. Na sequncia foi criada, dentro do banco de
sistema mster, a procedure sp_monitora_disco, em que temos
os seguintes parmetros: a varivel @to receber o e-mail do
destinatrio, a varivel @subject ser responsvel pelo assunto
da mensagem e a @PercentFree assumir o percentual livre do
disco. Note que agora teremos na montagem do HTML dentro da
varivel @tableHTML a @PercentFree e no valores fixos para
comparar com a coluna PercentFree. Veja nas Listagens 3 a 5 o
cdigo da procedure e como execut-la.
Listagem 3. Procedure sp_monitora_disco Parte 1.
USE [master]
GO
CREATE PROCEDURE [dbo].[sp_monitora_disco]
@to varchar(200),
@subject varchar(100),
@PercentFree int
AS
SET NOCOUNT ON
-- Cria a tabela temporria #Drives
IF EXISTS ( SELECT name
FROM tempdb.sys.tables
WHERE name LIKE #Drives% )
DROP TABLE #Drives
CREATE TABLE #Drives
(
Drive CHAR(3) PRIMARY KEY ,
FreeSpace INT NULL ,
TotalSize INT NULL ,
[PercentFree] AS ( CONVERT(FLOAT, FreeSpace) / TotalSize ) * 100
)
-- Insere as informaes na tabela temporria consultando a DMF
-- sys.dm_os_volume_stats (apenas dos discos que esto armazenando datafiles)
INSERT #Drives
( Drive ,
FreeSpace ,
TotalSize
)
SELECT DISTINCT
dovs.volume_mount_point ,
CONVERT(INT, dovs.available_bytes / 1048576.0) ,
CONVERT(INT, dovs.total_bytes / 1048576.0)
FROM sys.master_files mf
CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) dovs
ORDER BY dovs.volume_mount_point ASC
-- Variveis para envio de e-mail
DECLARE @tableHTML NVARCHAR(MAX)

Edio 136 SQL Magazine

31

Monitoramento automatizado o SQL Server

Listagem 4. Procedure sp_monitora_disco Parte 2.

-- Monta o HTML para o envio do relatrio com as informaes de espao total/livre
SET @tableHTML = N<H1>Utilizao de Discos</H1> + N<table border=1>
+ N<tr><th>Drive</th><th>Total (MB)</th><th>Livre (MB)
</th><th>% Livre</th></tr>
+ CAST(( SELECT CASE WHEN [PercentFree] <= @PercentFree THEN #FF0000
END AS td/@BGCOLOR ,
td = Drive ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= @PercentFree THEN #FF0000
END AS td/@BGCOLOR ,
td = TotalSize ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= @PercentFree THEN #FF0000
END AS td/@BGCOLOR ,
td = FreeSpace ,
,
right AS td/@align ,
CASE WHEN [PercentFree] <= @PercentFree THEN #FF0000
END AS td/@BGCOLOR ,
td = CONVERT (NUMERIC(10, 2), [PercentFree])
FROM #Drives
FOR
XML PATH(tr) ,
TYPE
) AS NVARCHAR(MAX)) + N</table>;
-- Chama a procedure sp_send_dbmail para envio do e-mail utilizando o perfil
-- SQLAgentDBA criado no Database Mail
SET @Subject = @Subject + @@Servername
EXEC msdb.dbo.sp_send_dbmail @profile_name = SQLAgentDBA,
@recipients = @to, @body = @tableHTML,
@subject = @Subject, @body_format = HTML
RETURN 0
GO
Listagem 5. Chamada da procedure sp_monitora_disco.
EXEC master.dbo.sp_monitora_disco
@to = [email protected];[email protected],
@subject = Utilizao de discos do servidor: ,
@PercentFree = 15

Aps criar a procedure, ela estar pronta para ser utilizada.

O usurio que a chamar precisa ter permisses administrativas
na instncia. Essas permisses so necessrias devido consulta
nas tabelas de sistema que o script faz. Dando permisses nas
roles de servidor dbcreator e processadmin ou apenas na sysadmin,
o usurio ter os direitos necessrios para executar a procedure.
importante dizer que a role sysadmin dar permisses totais
ao usurio na instncia.
Na varivel @to poder ser adicionado mais de um e-mail
destinatrio. Estes devero ser separados por ponto e vrgula (;).
Na varivel @PercentFree foi definido o valor de 15%, ou seja,
quando a unidade estiver com o percentual igual ou menor do
que 15% livre de espao, o vermelho ser definido como cor de
fundo da linha que corresponde a unidade. A qualquer momento
que houver necessidade de alterar os parmetros, s faz-lo na
chamada da procedure e no mais no corpo do script. Vamos
agora agendar a execuo do script no SQL Agent.

32 SQL Magazine Edio 136

Criando um novo job no SQL Agent

No servio do SQL Agent criado um novo job (Figura 3) cujos
componentes foram comentados anteriormente. Neste exemplo,
o job foi criado com o nome DBA - Disk Space (vide Figura 4).
Os campos categoria e descrio da aba Geral so opcionais. Mas
recomendvel fazer uma pequena descrio do que o job faz,
pois caso outro DBA analise-o j ser mais fcil entend-lo.

Figura 3. Criao de um novo job

Figura 4. Job DBA - Disk Space

Na aba steps iremos adicionar um novo passo que receber o
script. O nome do passo (step name) dever ser sugestivo ao que
ele realmente faz nas instrues. Em Jobs com mais de um step,
importantssimo essa boa prtica, pois facilita a identificao e
entendimento de todo o processo. O tipo, neste caso, o script T-SQL
e o database setado o master. Na Figura 5 podemos ver que foi
adicionado mais de um destinatrio de e-mail na varivel @to.

Figura 5. Chamada da procedure sp_monitora_disco no step do job

Figura 6. Agendamento configurado para o script executar a cada hora

Por exemplo, Dirio A cada hora. Esse
levantamento pode ser feito consultando e
cruzando os registros das tabelas msdb.dbo
.sysjobs, msdb.dbo.sysjobschedules e msdb.dbo
.sysschedules.

Histrico de execues do job

Figura 7. Detalhes do agendamento

Figura 8. Detalhes do histrico

Nas propriedades do job h a opo visualizar histrico. Ao acessar essa opo,

temos o registro de execues do job com
as datas e como foi concludo, com falha
ou sucesso. Caso d falha, possvel identificar a causa atravs do histrico (vide
Figura 8), expandindo o registro e verificando a mensagem na rea abaixo da lista
de registros. H casos em que a mensagem
contida nessa rea truncada e no possvel visualizar o restante. Deste modo,
preciso apontar um arquivo de sada na aba
Avanado dentro do step e aps executar o
job, s abrir o arquivo criado e verificar
a mensagem completa (Figura 9).

Exemplo do e-mail recebido

Finalmente, o resultado e a parte mais
interessante de tudo isso: ao receber o email, teremos as informaes desejadas de
forma organizada e clara. Teremos uma tabela com as colunas Drive, Total (MB), Livre
(MB) e % Livre. Nesta mquina, o % Livre
da unidade E est abaixo de 15% e por isso
a cor de preenchimento est em vermelho,
conforme demonstra a Figura 10.

Outras anlises

Figura 9. Arquivo de sada do step

Na aba Schedules, o agendamento dever ser configurado de
acordo com cada ambiente. No nosso caso, o job recorrente,
ser executado todos os dias, a cada hora no perodo de 00hs as
23h59min (Figuras 6 e 7). Um nome sugestivo ao agendamento
tambm importante, pois ajuda no levantamento de informaes de quais jobs executam com uma determinada frequncia.

Como dito anteriormente, as DMVs e DMFs

so recursos poderosos para checar o comportamento da instncia, databases, queries,
conexes e sistema operacional. Algumas
DMVs/DMFs importantes que podem auxiliar nessa atividade so:
Relacionadas a execues:
- sys.dm_exec_connections;
- sys.dm_exec_sessions;
- sys.dm_exec_requests;
- sys.dm_exec_cached_plans;

Edio 136 SQL Magazine

33

Monitoramento automatizado o SQL Server

- sys.dm_exec_query_plan;
- sys.dm_exec_sql_text;
- sys.dm_exec_query_stats.
Relacionadas a ndices:
- sys.dm_db_index_physical_stats;
- sys.dm_db_index_usage_stats.
Relacionadas ao sistema operacional:
- sys.dm_os_performance_counters;
- sys.dm_os_schedulers;
- sys.dm_os_nodes;
- sys.dm_os_waiting_tasks;
- sys.dm_os_wait_stats.
Relacionadas a I/O (Entrada e sada em disco):
- sys.dm_io_virtual_file_stats.

alterao de parmetros sempre mais prtica. A periodicidade

dos agendamentos depender da anlise que est sendo feito e
tambm do ambiente. Portanto, customize conforme seu servidor
de banco de dados requer. Alm disso, faa testes e comprove o
resultado das verificaes antes de colocar em produo. Tome
o cuidado tambm de gerar o script de cada job e salvar em um
local seguro e sempre fazer backup dos bancos de sistema msdb
e master. Caso haja algum desastre no ambiente, a recuperao
das rotinas ser muito mais rpida.
Para concluir, essa alternativa de monitoramento mais trabalhosa, porm com um resultado eficaz e customizado. E, claro,
o DBA ser sempre avisado se o banco de dados precisa de uma
ao imediata ou uma correo preventiva.

Autor
Jonatas dos Anjos
[email protected]
Profissional de TI h 10 anos, sendo quatro como DBA SQL
Server. Domnio e interesse em boas prticas de administrao,
monitoramento e recursos de alta disponibilidade do SQL Server. Graduado em Tecnologia de Banco de Dados pela FIAP e Microsoft Certified
Professional (MCP).
Links:

Figura 10. E-mail recebido

Database Mail
https://msdn.microsoft.com/pt-br/library/Hh245116(v=sql.110).aspx
DMF sys.dm_os_volume_stats
https://technet.microsoft.com/pt-br/library/hh223223(v=sql.105).aspx

possvel utilizar os recursos que o SQL Server oferece para

monitorar a instncia e seus bancos de dados. H diversas anlises que podem ser realizadas atravs das DMVs/DMFs, dando
ao DBA informaes importantes sobre a sade do ambiente.
O Database Mail e o SQL Agent so ferramentas poderosas e prticas que podero ser utilizadas em diversas situaes. Portanto,
vale a pena pesquisar e testar cenrios e anlises variadas que
daro cada vez mais auxlio s funes do administrador.
Sempre desenvolva o script em partes para facilitar o atendimento. Aps montar a consulta, monte o HTML conforme desejar
e chame o Database Mail. Procure utilizar procedures, pois a

34 SQL Magazine Edio 136

Procedure sp_send_dbmail
https://msdn.microsoft.com/pt-br/library/ms190307(v=sql.110).aspx
Disk Space Monitoring: How To
http://sqlmag.com/blog/disk-space-monitoring-how

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

35

Paralelismo no
SQL Server
Entendendo como o SQL Server trabalha com
planos paralelos

ivemos um perodo onde os processadores no

evoluem mais to rapidamente a cada novo ciclo
de lanamento dos fabricantes. Em contrapartida, encontramos cada vez mais processadores em uma
nica mquina. Diante disso, necessrio que os programas passem a explorar o paralelismo em seu cdigo,
com mltiplas threads em execuo, potencializando o
uso do hardware sua disposio.
O paralelismo possui um objetivo muito nobre, que
explorar a concorrncia de processamento em um
programa com o objetivo de resolver um problema
em menos tempo. Porm, importante frisar que isto
no significa que o uso de recursos ser menor, pelo
contrrio, o tempo total de processamento (uso efetivo
das CPUs) tende a ser maior, pois alm da execuo
necessrio incluir no cdigo mecanismos de sincronizao das threads.
Atualmente comum encontrarmos instncias do SQL
Server em servidores com 16, 32 ou mais ncleos (cores)
de processamento. Diante desse cenrio, desejvel que
a engine possa explorar o paralelismo em seu cdigo,
ainda mais considerando que o SQL Server licenciado
por ncleo e no por outros fatores como, por exemplo,
quantidade de memria.
E mesmo que o cdigo do SQL Server tenha diversos
trechos multi-thread, muitos deles no podem ser vistos
ou so transparentes para ns, usurios. No entanto,
existe um deles, assunto cerne deste artigo, onde podemos ver claramente a utilizao de mltiplos ncleos
de processamento: os planos de execuo que possuem
operadores paralelos.

Plano de execuo paralelo

Definimos um plano paralelo como aquele composto
por operadores que exploram o paralelismo em sua
rvore de execuo. Neste contexto, um conjunto de
operadores paralelos o que determina o que chamamos
de zona paralela. As zonas existem pelo fato do plano de

36 SQL Magazine Edio 136

Fique por dentro

Este artigo tem por objetivo apresentar aspectos do funcionamento
da engine do SQL Server no que toca a execuo de consultas utilizando operadores paralelos, isto , explorando hardwares que possuem
diversos processadores. O artigo ser til para o leitor entender os conceitos de paralelismo, analisar planos paralelos, conhecer detalhes do
otimizador de consultas, determinar as corretas configuraes de uma
instncia do SQL Server e, naturalmente, ganhar uma slida base para
aplicar em seu ambiente as melhores prticas, fazendo corretamente
o troubleshooting ou tuning de consultas paralelas.

execuo nunca ser 100% paralelo, pois sempre o ltimo operador

deve ser no paralelo (serial) para que a engine possa retornar os
registros da consulta a partir de uma nica thread, chamada de
coordenadora.
Dito isso, como primeiro exemplo deste artigo, faremos a comparao entre a execuo de duas consultas, uma serial e outra
paralela, com o intuito de apresentar como so processados os
registros em um plano com zona paralela.
O detalhamento de como interpretar um plano de execuo e
seus operadores est alm do escopo do artigo, porm importante que se tenha o conhecimento do que so e como podem
ser gerados atravs do SQL Server Management Studio. Voc
encontra um artigo sobre planos de execuo na edio 119 da
SQL Magazine.
Na Listagem 1 demonstramos uma consulta simples, que conta a
quantidade de registros na tabela dbo.bigTransactionHistory fazendo
uso da hint MAXDOP 1, que fora o SQL Server a no utilizar
paralelismo para esta consulta. O termo MAXDOP bastante
adotado por ser uma reduo de MAX Degree Of Parallelism, ou
grau mximo de paralelismo, e tambm ser empregado ao longo
deste artigo.
Como pode ser verificado na Figura 1, o plano de execuo
simples. O SQL Server opta por percorrer um ndice no cluster
por completo (index scan), retornando cada um dos registros para
ser contabilizado pelo prximo operador (stream aggregate), e por

fim devolvendo o resultado para o cliente

(o compute scalar no relevante neste
contexto).
Listagem 1. Consulta simples, sem paralelismo.
USE AdventureWorks2012
GO
SET STATISTICS TIME ON;
SELECT COUNT(*) FROM dbo.bigTransaction
History OPTION (MAXDOP 1);
GO

Esse plano de execuo tem um custo total de 150.456 e como sada gerada pelo comando SET STATISTICS TIME ON, temos:
SQL Server Execution Times CPU time
= 4130 ms, elapsed time = 4139 ms. Isto
, o SQL Server executou toda a consulta
em pouco mais de quatro segundos, utilizando praticamente o mesmo tempo de
processamento (tempo efetivo de uso dos
ciclos da CPU) para executar os operadores
definidos no plano de execuo.
Ao executar a mesma consulta removendo a hint MAXDOP 1, damos liberdade
para que o SQL Server considere o paralelismo ao determinar qual ser o plano
de execuo para esta consulta. Como resultado da consulta da Listagem 2, temos
um plano com operadores que permitem
a execuo paralela, marcados por um
crculo laranja com duas setas, como pode
ser verificado na Figura 2.
Listagem 2. Consulta simples, com paralelismo.
USE AdventureWorks2012
GO
SET STATISTICS TIME ON;
SELECT COUNT(*) FROM dbo.bigTransactionHistory;
GO

Ao analisar o plano de execuo, verificamos que o SQL Server decide utilizar

vrias threads (ou workers, na viso da
engine do SQL Server) para executar a
consulta. O nmero exato de threads
pode ser verificado apenas na janela de
propriedades de um dos operadores paralelos. Para fins didticos neste exemplo,
no entanto, considere o uso de oito threads
para esta execuo.

Figura 1. Plano de execuo simples, sem paralelismo

Figura 2. Plano de execuo simples, com paralelismo

Ao iniciar o processamento da consulta,

o index scan executado por oito threads,
onde cada uma fica responsvel por recuperar parte dos dados, seguido do stream
aggregate, que contabiliza a quantidade
de registros que cada thread leu. Isto ,
suponha que cada thread leu uma mdia
de trs milhes de registros do ndice,
o stream aggregate vai contabilizar por
thread o nmero exato de registros lidos,
fazendo com que cada thread gere em sua
sada um nico registro (o valor efetivo da
contagem).
A partir da o SQL Server introduz um
novo operador lgico, chamado gather
streams, que tem por objetivo coletar o
resultado dos diferentes fluxos de entrada
(oriundos de cada uma das threads em
execuo) e gerar um nico fluxo de sada.
Deste modo, no nosso cenrio ser produzido na sada do operador um conjunto de
oito registros, cada um com o resultado
contabilizado das threads pelo operador
anterior. Esse operador encerra a zona
paralela do plano de execuo, restando

ao SQL Server fazer a soma dos oito registros produzidos utilizando o operador
stream aggregate no paralelo (novamente
o compute scalar irrelevante). Esta diviso
de trabalho entre os operadores ilustrada
pela Figura 3, que mostra parte do fluxo
de dados manipulada pelos quatro primeiros operadores do plano de execuo
paralelo.
Esse plano de execuo tem um custo
total de 110.623, um custo menor que o
plano serial, e como sada gerada pelo comando SET STATISTICS TIME ON, temos:
SQL Server Execution Times CPU time =
8374 ms, elapsed time = 1445 ms. Isto , o
SQL Server executou toda a consulta em
menos de um segundo e meio, menos da
metade do tempo original. Porm, o tempo
de processamento foi maior, o dobro do
plano serial. Em outras palavras, gasta-se
mais recursos para executar a consulta em
menos tempo.
A partir da prxima seo vamos analisar em mais detalhes como o otimizador
de consultas do SQL Server considera a

Edio 136 SQL Magazine

37

Paralelismo no SQL Server

utilizao de planos de execuo com paralelismo e como isso

influencia o custo dos operadores em um plano, alm de discutir
melhores prticas na configurao do SQL Server.
Para executar os scripts deste artigo, necessrio fazer o
download (ver seo Links) do banco de dados de exemplo
AdventureWorks2012, disponibilizado pela Microsoft no CodePlex e utilizar o script Make Big AdventureWorks para criar
tabelas com maior volume de dados.
Vale ressaltar que diferentes computadores e instncias e verses
do SQL Server podem gerar variaes nos planos de execuo que
esto sendo apresentados neste artigo por conta das peculiaridades de cada ambiente. Para este artigo foi utilizado o SQL Server
2012 Developer Edition com o Service Pack 2.

bom o suficiente seja encontrado, o SQL Server repete a fase de

otimizao considerando a utilizao de paralelismo.
importante citarmos mais um operador, alm dos operadores
tradicionais do SQL Server, como clustered ou non-clustered index
scan, index seek, lookup, table scan, aggregate (stream and hash), sort,
entre outros. Para os planos paralelos existe um operador especfico, chamado de Exchange, e este pode assumir diferentes papis
nos planos de execuo, separados em trs operaes lgicas:
Distribute streams: recebe um nico fluxo de entrada e divide-o
em diversos fluxos de sada, de acordo com o grau de paralelismo
utilizado na consulta;
Repartition streams: recebe diversos fluxos de entrada e encaminha os registros para diversos fluxos de sada. comum
encontrarmos esse operador como uma tentativa do SQL Server de
balancear o nmero de registros entre as threads, permitindo uma
execuo mais homognea (e eficiente) do plano de execuo;
Gather streams: recebe diversos fluxos de dados oriundos de
um operador e une os fluxos em um nico fluxo de sada.
Para exemplificar o comportamento do otimizador de consultas,
vamos considerar quatro consultas diferentes sobre a mesma tabela (vide Listagem 3). E para garantir o comportamento correto
do exemplo, importante verificar se a configurao do cost
threshold for parallelism est definida como 5 antes da execuo
Listagem 3. Analisando o comportamento do otimizador em relao ao paralelismo.
USE AdventureWorks2012
GO

Figura 3. Fluxo de dados parcial no plano de execuo paralelo

Otimizador de consultas e paralelismo

O otimizador de consultas (query optimizer ou QO) , provavelmente, o componente de software mais elaborado do SQL Server
na verdade, de todo banco de dados relacional (Oracle, DB2,
MySQL, Postgre, etc.). Esta complexidade pode ser traduzida em
um custo alto para se produzir os planos de execuo, devido
ao fato de que para se otimizar uma consulta com um pequeno
nmero de tabelas, as diferentes combinaes dos elementos podem gerar um conjunto enorme de possveis planos de execuo.
Diante disso, o SQL Server divide a otimizao em fases, com
pr-requisitos e limites de custo, procurando gerar um plano que
seja bom o suficiente dado o custo do processo de otimizao.
Nesse nterim entra a configurao de instncia cost threshold for
parallelism, definida por padro com o valor 5, e que na traduo
literal significa limite de custo para paralelismo. A configurao
utilizada entre uma das fases de otimizao (o detalhamento
de cada uma est fora do escopo deste artigo), pois chega um determinado momento em que o SQL Server vai analisar a listagem
de todos os possveis planos gerados pelo QO e validar se existe
algum plano com custo menor do que o definido pela configurao citada. Caso nenhum plano atenda a condio, que um plano

38 SQL Magazine Edio 136

-- Exibe as configuraes avanadas

EXEC sys.sp_configure show advanced options, 1
RECONFIGURE
-- Verifica a configurao do SQL Server
EXEC sys.sp_configure cost threshold for parallelism
-- Analisando os custos dos planos de execuo
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 AND 1010
GROUP BY ProductID
GO
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2834
GROUP BY ProductID
GO
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
GO
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 1)
GO

dos scripts e notar que podem haver variaes no intervalo do predicado (clusula
WHERE) para reproduzir o exemplo em
diferentes mquinas.
Ao executar as duas primeiras consultas da Listagem 3 e capturar os planos
de execuo, vemos que o primeiro tem
um custo muito baixo (0,0206037), pois o
filtro somente retorna os pedidos feitos
para produtos com ID entre 1001 e 1010.
Deste modo, o SQL Server est longe de
considerar o paralelismo para esta consulta (veja a Figura 4). J o segundo plano
(veja a Figura 5) mostra que o custo da
consulta de exatamente 4,99998, isto ,
foi gerado um plano no limite de custo
para o SQL Server comear a considerar
planos paralelos.
Esse aumento significativo no custo se
deve quantidade de registros retornados
pelo operador de index seek. Na primeira
consulta o fluxo de dados entre o index
seek e o stream aggregate de 4235 registros, enquanto na segunda operao o
volume entre os operadores de 1.038.862
registros. Um aspecto interessante a ser
observado que o custo dos operadores se
mantm proporcional entre os dois planos,
pois independentemente da quantidade de
registros, cada operador ter que processar mais ou menos registros, mantendo a
proporo dentro do plano.
Ao executar a prxima consulta com
um conjunto de dados um pouco maior,
agora incluindo o ProductId de valor 2835
e fazendo com que o index scan retorne
1.039.935 registros, o SQL Server passa a
utilizar um plano de execuo paralelo.
Isso se deve ao fato de todos os possveis
planos de execuo no paralelos gerados
pelo SQL Server, at determinado momento do processo de otimizao, terem ficado
com um custo superior a 5 (configurao
do custo limite para o paralelismo), o que
fez com que o processo de otimizao
continuasse a procurar novos planos, s
que a partir de agora considerando o uso
de operadores paralelos.
No final do processo de otimizao, o
SQL Server gerou um plano paralelo com
custo de 3,7631 (vide Figura 6, editada para
facilitar a visualizao), um valor menor
do que o limite de 5, mesmo que mais

Figura 4. Otimizador de consulta e plano de baixo custo

Figura 5. Otimizador de consulta e plano no limite do custo para paralelismo

recursos de hardware sejam utilizados
durante a sua execuo (afinal, o paralelismo quer resolver um problema em menos
tempo). Isto acontece porque ao considerar
o paralelismo, o custo de processamento
de alguns operadores foi dividido entre
um nmero especfico de threads, e
mesmo adicionando novos operadores
como o gather streams e repartition streams,
o benefcio do paralelismo maior que o
custo adicional de processamento.
Para completar a srie de instrues da
Listagem 3, a ltima consulta repete o filtro
que gerou um plano paralelo, mas dessa vez
com a hint MAXDOP 1, impedindo que seja
gerado um plano paralelo. Isso faz com que

o SQL Server apresente um plano de custo

com o valor 5,00652, o menor custo entre
os planos encontrados pelo SQL Server, e
o mesmo que ele criou para a consulta 03,
antes de considerar o paralelismo.
Como voc leitor j deve ter se indagado,
para o exemplo anterior, o que aconteceria
se o limite de custo para o paralelismo
fosse maior? Para nos ajudar a responder
essa pergunta, a Listagem 4 muda a configurao da instncia, redefinindo para
6 o valor do custo para paralelismo, o que
faz com que a consulta, antes paralela, no
considere mais o paralelismo, chegando
ao mesmo plano e custo de quando utilizamos a hint MAXDOP 1.

Edio 136 SQL Magazine

39

Paralelismo no SQL Server

Figura 6. Otimizador de consulta e o plano paralelo

Listagem 4. Alterando o custo para paralelismo.
-- Exibe as configuraes avanadas
EXEC sys.sp_configure show advanced options, 1
RECONFIGURE
EXEC sys.sp_configure cost threshold for parallelism, 6
RECONFIGURE
go
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
GO
EXEC sys.sp_configure cost threshold for parallelism, 5
RECONFIGURE
go

Fica evidente que muito mais simples conseguir ver o otimizador de consultas produzindo planos paralelos quando o volume
de dados aumenta, afinal o esforo computacional para executar
a consulta ser maior. Especificamente no nosso caso, os planos
passaram a ser paralelos para as consultas que manipularam um
pouco mais de 1 milho de registros, mas no correto pensar em
um nmero de registros a partir do qual o SQL Server sempre ir
trabalhar com paralelismo, pois essa quantidade varia de acordo
com o esquema das tabelas envolvidas, complexidade da consulta,
entre outros fatores.
Em nenhum momento foi citado qual a unidade do custo dos
planos de execuo, e o motivo para isso que no existe tal unidade. Muitos anos atrs o time de produto do SQL Server compilou
um modelo de custo e nessa poca o custo se dava em segundos,
porm, com o advento de recursos computacionais mais rpidos
(CPU, memria, I/O, etc.), uma execuo que no passado levava
um minuto, hoje pode levar segundos. Esse comportamento,

40 SQL Magazine Edio 136

no entanto, no impede que o modelo seja vlido, pois uma vez

que o SQL Server tem que escolher entre N planos de execuo,
todos baseados nas mesmas mtricas, aquele de menor custo
estimado ser o escolhido pelo otimizador de consultas, que
efetivamente acredita ser a melhor opo dentro das alternativas
que ele gerou.

Grau de paralelismo e custo dos operadores

At este momento citamos somente o grau mximo de paralelismo atravs da hint MAXDOP, porm existe uma configurao
(de mesmo nome) no SQL Server que define o valor utilizado pela
instncia, o max degree of parallelism. Esse item de configurao
possui, por padro, o valor 0 (zero), o que significa para o SQL
Server que ele pode utilizar todos os processadores disponveis.
Deste ponto em diante importante especificar que a mquina
onde foram realizados os testes deste artigo um processador
de quatro ncleos com hyperthreading, deixando visvel para o
sistema operacional e o SQL Server um total de oito processadores lgicos. Essa informao relevante devido ao fato do SQL
Server sempre considerar a metade do nmero de processadores
disponveis ao estimar o custo das operaes paralelas durante
o processo de otimizao.
Para exemplificar como feita a reduo no custo total do plano
de execuo, utilizaremos as quatro consultas da Listagem 5, onde
todas possuem o mesmo predicado utilizado anteriormente, que
com a configurao padro do SQL Server, sabemos que deve
gerar um plano paralelo (custo superior a 5).
Analisando o operador de Index Seek da primeira consulta,
podemos ver um custo de CPU de valor 1,14368 e custo de I/O
em 3,23868. Quando executamos a segunda consulta com a hint
MAXDOP 2, permitimos que o index seek possa ser paralelizado
com at duas threads, fazendo com que o operador passasse a
ter o custo de CPU definido em 0,57184 e o de I/O em 3,23868.

Listagem 5. Comparando o custo do index seek com diferentes graus de paralelismo.

USE AdventureWorks2012
GO
-- Exibe as configuraes avanadas
EXEC sys.sp_configure show advanced options, 1
RECONFIGURE
-- Verifica a configurao do SQL Server
EXEC sys.sp_configure max degree of parallelism
-- Consulta 01
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 1)
GO

consultas trabalham com a hiptese de que existem quatro processadores disponveis.

Este um ponto importante para destacarmos, pois, uma vez
gerado um plano de execuo paralelo, a engine de execuo
que vai decidir efetivamente quantas threads sero utilizadas,
de acordo com a situao do servidor, o limite de threads no SQL
Server, o consumo de recursos, entre outros fatores. Isso pode
fazer com que um plano em determinada execuo receba oito
threads e apenas duas threads em um momento de estresse do
servidor, gerando tempos de execuo bem distintos.

-- Consulta 02
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 2)
GO
-- Consulta 03
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 4)
GO
-- Consulta 04
SELECT ProductID, COUNT(TransactionID), SUM(Quantity), SUM(ActualCost)
FROM dbo.bigTransactionHistory
WHERE ProductID BETWEEN 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 8)
GO

Em outras palavras, paralelizando a operao de index seek em

duas threads, o custo de CPU caiu pela metade, enquanto o custo
de I/O se manteve, o que razovel, pois o SQL Server precisa
ler o mesmo nmero de pginas e registros para processar o
resultado da consulta.
Os custos do operador de seek na consulta trs seguem a mesma
linha de raciocnio: o custo de I/O se mantm, enquanto o custo de
CPU cai para 0,28592, aproximadamente 25% e 50% dos valores das
consultas 01 e 02, respectivamente. Juntamente com a reduo do
custo deste operador, o custo total do plano de execuo tambm
acompanha a queda.
A quarta consulta, quando executada, pode ser uma surpresa
para muitos, pois todos os custos do plano so idnticos aos da
terceira consulta, conforme detalhado na Figura 7, que exibe o
custo do operador em todas as quatro consultas. Isso se deve ao
fato do SQL Server considerar a metade do nmero de processadores disponveis para a otimizao, que no caso deste artigo
se restringe a oito. Portanto, para fins de otimizao, todas as

Figura 7. Custos do index seek para as quatro consultas da Listagem 5

Para simular o comportamento do SQL Server em uma mquina
com mais processadores, possvel utilizar o comando no documentado DBCC OPTIMIZER_WHATIF, que efetivamente diz para
o otimizador de consultas E se o nmero de processadores fosse
16. Neste caso, o custo de CPU do index seek vai cair mais uma
vez pela metade, chegando ao valor de 0,14296, pois existindo 16
CPUs o SQL Server pode utilizar oito como o grau de paralelismo
na otimizao (vide Listagem 6).
O mesmo resultado tambm ser obtido usando a hint MAXDOP
16, pelos motivos apresentados anteriormente, ou simplesmente
omitindo o MAXDOP 8 ao executar a consulta. importante
ressaltar que este tipo de instruo nunca deve ser utilizado em
produo, a menos que orientado pela prpria Microsoft.
Existe uma relao de precedncia para a configurao do max
degree of parallelism na otimizao das consultas. Sempre que
especificada a hint MAXDOP, esta tem precedncia sobre a configurao homnima da instncia. Caso o administrador do banco
de dados deseje que a hint no tenha precedncia, necessrio
utilizar o Resource Governor do SQL Server, configurando um
Workload Group com o grau mximo de paralelismo, associando-o com as conexes da sua aplicao.

Edio 136 SQL Magazine

41

Paralelismo no SQL Server

Listagem 6. Simulando uma mquina com mais processadores.

DBCC OPTIMIZER_WHATIF(CPUs, 16) WITH NO_INFOMSGS;
select ProductID, count(TransactionID), sum(Quantity), sum(ActualCost)
from dbo.bigTransactionHistory
WHERE ProductID between 1001 and 2835
GROUP BY ProductID
OPTION (MAXDOP 8);
DBCC OPTIMIZER_WHATIF(ResetAll) WITH NO_INFOMSGS;

Configurando o paralelismo em sua instncia

O SQL Server reconhecidamente um produto que, mesmo com
a instalao padro, processa bem as requisies destinadas aos
bancos de dados, o que no significa que as configuraes out of
the box so as melhores.
Para a configurao do grau mximo de paralelismo, a Microsoft
tem um artigo (ver seo Links) na base de conhecimento intitulado Recomendaes e diretrizes para a opo de configurao
de grau mximo de paralelismo do SQL Server e contm a
seguinte recomendao:
Um n NUMA e menos de oito processadores lgicos: manter
MAXDOP abaixo do nmero de processadores lgicos (ex.: 4);
Um n NUMA e mais de oito processadores lgicos: manter o
MAXDOP em 8;
Diversos ns NUMA e menos de oito processadores lgicos por
n: manter MAXDOP abaixo do nmero de processadores lgicos
por n NUMA (ex.: 4);
Diversos ns NUMA e mais de 8 processadores lgicos por n:
manter o MAXDOP em 8.
Estas sugestes visam manter um bom balano entre consumos
de recursos e desempenho das consultas, evitando a utilizao
excessiva de threads durante a execuo de poucas consultas paralelas, e impedindo que uma mesma consulta possa ter threads
executando em diferentes ns NUMA, o que certamente faria com
que existissem muitos acessos memria estrangeira, aumentando o tempo de execuo da consulta.
As atuais arquiteturas de computadores trabalham com o que
chamamos de Non Uniform Memory Access (NUMA), que consiste
em dividir os processadores em grupos menores (ns) com sua
memria local e canais de I/O, para evitar colises e gargalos no
barramento, o que aconteceria se muitos processadores dividissem
um nico barramento. Como existe a possibilidade de processadores acessarem contedo de uma memria estrangeira, isto ,
um dado que est em outro n, o tempo de acesso memria no
uniforme, da o nome da arquitetura.
O SQL Server passou a ser considerado NUMA aware a partir da
verso 2005. Portanto, o SQLOS tem conhecimento da distribuio
dos processadores nos ns NUMA e tenta privilegiar o escalonamento de threads com contextos semelhantes no mesmo n, com
o intuito de minimizar a quantidade de acesso estrangeiro.
Mesmo sendo uma boa recomendao, evidente que o admi-

42 SQL Magazine Edio 136

nistrador do SQL Server pode alterar essa configurao quando

o argumento for slido. Por exemplo: em ambientes com bancos
de dados puramente analticos (OLAP) em servidores de 128
processadores, justificvel um MAXDOP maior, pois em geral
se deseja que as requisies possam se beneficiar de um grau
maior de paralelismo e processar milhes ou bilhes de registros
em um tempo menor.
Essa anlise do trade-off e realizao de testes de desempenho
so vitais para o bom comportamento da instncia, pois evita
outros problemas como, por exemplo, o consumo exagerado de
threads por requisies que podem ficar bloqueadas, e acabam
levando a um rpido consumo das threads disponveis no SQL
Server, causando a exausto do pool de threads da engine.
Outra sugesto comum de configurao que encontramos em
artigos ou fruns configurar o MAXDOP para 1 em ambientes
transacionais (OLTP), utilizando como justificativa que ambientes
transacionais possuem caractersticas de requisies pontuais e com
pequeno volume de dados, ento o paralelismo desnecessrio.
O argumento consistente, mas particularmente o autor desse
artigo discorda da abordagem, pois a engine do SQL Server somente considera planos paralelos quando os custos dos planos
gerados pelas primeiras fases de otimizao ultrapassam a configurao do limite para paralelismo. Portanto, se somente houvesse operaes leves acontecendo, a prpria engine entenderia
como desnecessria a utilizao de paralelismo. Soma-se a isso o
fato de que relatrios operacionais, muito comuns em ambientes
transacionais, levariam um tempo maior para serem executados
por no poderem se beneficiar do paralelismo, a menos que fosse
explicitamente definida a hint para cada consulta.
Discusso essa que nos leva prxima configurao: cost
threshold for parallelism. Essa uma configurao pouco comentada e que merece ateno. Deste modo, faa o seguinte exerccio:
capture diversas consultas em seu ambiente e comece a analisar
o custo do plano com a hint MAXDOP 1. O que voc ver que
comumente, mesmo consultas que so executadas em poucos
segundos, utilizam paralelismo. Em outras palavras, em geral o
valor 5 considerado uma configurao baixa para os recursos de
hardware atuais e o SQL Server acaba por criar planos paralelos
em situaes onde estes no seriam necessrios.
Assim, em vez de ser radical e definir o MAXDOP 1 para seu
ambiente OLTP, uma abordagem mais interessante seria trabalhar
com um maior limite do custo para paralelismo, o que permitiria
engine optar por utilizar o paralelismo para as consultas mais
caras, mantendo planos seriais para as consultas com caractersticas transacionais. No existe um valor recomendado para esta
configurao (ou em documento oficial da Microsoft), mas muitos
consultores de renome internacional citam valores entre 20 e 50.
A mesma estratgia pode ser adotada quando se est fazendo um trabalho de melhoria de desempenho em um ambiente
com alto consumo de processamento e muitos planos paralelos.
Aumentar o custo de paralelismo vai evidenciar os planos mais
caros e usualmente causa uma diminuio do consumo de CPU,
facilitando o trabalho de anlise.

Contudo, importante ressaltar que o cost threshold for parallelism

no pode ser sobreposto por hints, devendo a alterao do valor
ser testada e aplicada com cautela. Aliado a isso, o fato de uma
mudana na configurao poder alterar muitos planos de uma s
vez, em geral faz com que os administradores de ambientes bem
estveis no faam essa mudana, mesmo podendo ser benfica,
pois pode trazer um efeito colateral ruim, por exemplo, ao fazer
com que uma consulta vital para o sistema deixe de utilizar o plano
paralelo e gaste um segundo a mais em cada execuo, segundo
este que pode impactar significativamente toda a aplicao.
Detalhamos nesse artigo um pouco do funcionamento da engine do SQL Server no que tange o paralelismo de consultas. Esse
embasamento necessrio para que voc, DBA ou desenvolvedor,
d o primeiro passo para entender a racionalidade do otimizador
de consultas e as alternativas de execuo paralelas que o SQL
Server oferece.
Historicamente, a adoo (ou no) de consultas e operaes paralelas no SQL Server fonte de discrdia entre administradores de
banco de dados, em geral oriunda de eventuais experincias ruins
com o paralelismo, causadas por planos malcomportados, configuraes inapropriadas ou at eventos no to comuns. Mesmo
sendo natural basear nossos conceitos em experincias vividas, o
problema passa a ser quando o medo ou receio difundido como
no adote o paralelismo, ele ruim, sem uma explicao lgica
e coerente. Lembre-se que o objetivo do paralelismo nobre:
solucionar um problema em menos tempo.
A partir deste momento voc est apto a revisar as configuraes
das suas instncias e se aprofundar na anlise de planos paralelos,
buscando sempre a melhor configurao e desempenho para o
seu ambiente SQL Server.

Autor
Luciano Moreira [Luti]
[email protected]
http://luticm.blogspot.com
Arquiteto de Dados na Sr. Nimbus. Especialista e MVP em
SQL Server, vem buscando nos ltimos anos desbravar o vasto universo
dos dados, explorando diferentes solues arquiteturais e engines de
bancos de dados. Divide seu tempo como profissional entre consultorias, treinamentos
e participao na comunidade tcnica, ajudando empresas a projetar solues, capacitar
equipes e resolver problemas que envolvem bancos de dados.
Saiba mais sobre ele: http://www.srnimbus.com.br/luciano-moreira/.
Links:
[1] The Free Lunch Is Over - A Fundamental Turn Toward Concurrency in
Software
http://www.gotw.ca/publications/concurrency-ddj.htm
[2] Microsoft Sample Databases
http://msftdbprodsamples.codeplex.com/
[3] Make Big AdventureWorks
http://sqlblog.com/blogs/adam_machanic/archive/2011/10/17/thinking-big-adventure.aspx
[4] Recomendaes e diretrizes para a opo de configurao de grau mximo
de paralelismo do SQL Server
https://support.microsoft.com/pt-br/kb/2806535
[5] A new platform layer in SQL Server 2005 to exploit new hardware capabilities
and their trends
http://blogs.msdn.com/b/slavao/archive/2005/07/20/441058.aspx
[6] Understanding Non-uniform Memory Access
https://technet.microsoft.com/en-us/library/ms178144(v=sql.105).aspx

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

43

Trabalhando com o
MemSQL
Conhea esta opo de banco de dados em
memria de alta performance

esquisas realizadas recentemente estimam que

grande parte dos dados que sero gerados nos
prximos anos vir de reas que produzem fluxos
de informaes constantes em nvel de centenas a milhes
de vezes por segundo, conhecidos como "Fast Data": dados
de logs, leitura de sensores, interaes, jogos etc.
Em muitas dessas reas as informaes devem ser
processadas e analisadas em um curto perodo de tempo. reas como a da Internet das coisas, sistemas de
telecomunicaes, sistemas financeiros, de antifraude,
de anlise de riscos, de interao de jogos, sistemas de
recomendaes etc., necessitam conseguir lidar com
informaes em tempo real para poder tomar decises
de forma eficaz e at mesmo poder predizer certos
comportamentos.
Ferramentas analticas e de data warehouse existentes
so projetadas para executar consultas predefinidas em
grandes bancos de dados, e que geralmente levam de
minutos at horas para serem processadas. No entanto,
a anlise de dados em tempo real deve ser tratada de
forma diferente. nesse cenrio que entram os bancos
de dados em memria. Conhecido como in-memory database (IMDB), esse tipo de banco de dados tem crescido
muito ultimamente em resposta s novas necessidades
de negcios, sistemas e operaes.

Banco de dados in-memory

Um sistema de banco de dados in-memory um gerenciador de banco de dados que, em contraste com os
bancos de dados tradicionais, no guarda os dados em
disco, mas na memria principal de uma mquina ou
conjunto de mquinas. Esse tipo de banco de dados
mais rpido que os tradicionais, que so otimizados para
escrita em disco, visto que seus algoritmos de otimizao
so mais simples e executam menos instrues de CPU.
Acessando os dados diretamente na memria eliminase o tempo de busca gasto pelo disco procurando os
dados, fornecendo assim um desempenho maior.

44 SQL Magazine Edio 136

Fique por dentro

Este artigo faz uma breve introduo sobre bancos de dados em
memria, mostrando conceitos, vantagens e desvantagens da sua
utilizao. O artigo tambm apresenta o MemSQL, um banco de
dados em memria de alta performance, demonstrando suas principais caractersticas e sua forma de utilizao. Esse tema til em
casos onde se deseja armazenar e processar informaes, e o tempo
de resposta um fator crtico. Situaes em que se planeja construir
aplicaes que necessitam detectar mudanas de comportamento,
realizar anlises histricas e sugerir mudanas, ajudando na tomada
de decises em tempo real.

Quando todos os dados so guardados em memria, no existe

mais a necessidade de se guardar cache dos dados, podendo
tambm ser comprimidos e descomprimidos mais facilmente,
gerando menos espao do que a mesma quantidade de dados
armazenada em disco.
Apesar do uso de discos tradicionais ainda ser o padro das empresas desse setor, o desenvolvimento de novas tecnologias de memria
e o constante declnio de preos de memrias do tipo RAM vem
facilitando bastante a adoo desse tipo de sistema de dados.
Muitos se perguntam nesse momento: por que no criar ento
um disco virtual de memria RAM e mover o banco de dados
tradicional para esse volume, ou ainda, desabilitar configuraes
de bancos tradicionais para trabalharem nesses moldes? O problema que os bancos de dados tradicionais, pelo fato de serem
projetados para lidar com discos rgidos, desempenham diversas
tarefas que, executadas diretamente em memria RAM, resultariam em um desempenho pior e em mais uso de processador do
que sistemas preparados e otimizados para lidar somente com
esse tipo de memria.
Diversas empresas, dentre elas podemos citar IBM, Microsoft e
Oracle, j trabalham em solues de bancos de dados in-memory
e buscam disputar o mercado com outras empresas, mais novas e
menos conhecidas, que tambm oferecem interessantes solues
para lidar com Fast Data.

Caractersticas
Atualmente existem diversas solues nesse padro de banco de
dados. Muitas utilizam formas hbridas, outras somente memrias
RAM. Algumas trabalham com NoSQL, outras com dados relacionais. Quando falamos em banco de dados em memria surge
sempre a questo da durabilidade dos dados, uma das caractersticas do modelo ACID. Visto que o tipo de memria utilizado
voltil, como manter esses dados de forma permanente sem que
os mesmos sejam perdidos durante uma falha de sistema?
Atualmente muitos destes bancos de dados possuem solues
para esse tipo de problema como, por exemplo, estados de replicaes dos dados atravs de cluster e commits temporrios dos
dados em disco, fazendo com que funcionem totalmente em conformidade com as caractersticas do modelo ACID, que representa
as quatro propriedades (atomicidade, consistncia, isolamento e
durabilidade) necessrias para que uma transao ocorra:
Atomicidade: uma transao deve ser uma unidade atmica de
trabalho, ou todas as suas modificaes de dados so executadas
ou nenhuma delas executada;
Consistncia: quando concluda, uma transao deve deixar todos
os dados em um estado consistente. Em um banco de dados relacional, todas as regras devem ser aplicadas s modificaes da transao
para manter toda a integridade dos dados. Todas as estruturas de
dados internas tais como ndices em rvore B ou listas duplamente
encadeadas, devem estar corretas ao trmino da transao;
Isolamento: modificaes feitas por transaes simultneas
devem ser isoladas das modificaes feitas por qualquer outra
transao simultnea. Uma transao reconhece os dados no
estado em que estavam antes de outra transao simultnea
t-los modificado ou reconhece os dados depois que a segunda
transao tiver sido concluda, mas no reconhece um estado
intermedirio;
Durabilidade: depois que uma transao tiver sido concluda,
seus efeitos ficam permanentemente no sistema. As modificaes
persistem at mesmo no caso de uma queda do sistema.
Como j foi dito anteriormente, existem diversas solues de
bancos de dados em memria no mercado, muitas delas possuem
verses gratuitas. Aqui citamos algumas da nova gerao:
OrigoDB: desenvolvido em especial para aplicaes .NET, um
banco relacional compatvel com o modelo ACID. Possui tambm
uma interface REST, possibilitando ser utilizado por outras tecnologias alm do .NET;
VoltDB: banco relacional, escalvel, compatvel com o modelo
ACID, e que implementa o padro H-Store de gerenciamento de
dados. H-Store uma implementao em memria de uma nova
categoria de sistemas de gerenciamento de dados em paralelo,
otimizado para aplicaes transacionais (OLTP), conhecido como
NewSQL, funcionando de forma distribuda. Possui fcil integrao com o Hadoop;
MemSQL: banco relacional, compatvel com o modelo ACID,
escalvel e que possui fcil integrao com o Apache Spark e
Hadoop;

GemFire XD: banco relacional, distribudo, no padro NewSQL

e que possui integrao com sistema HDFS. NewSQL uma nova
categoria de gerenciadores de bancos de dados que fornecem os
mesmos benefcios escalveis e performticos dos bancos NoSQL, mas para sistemas transacionais (OLTP), mantendo todas
as garantias do modelo ACID dos bancos tradicionais.
Dentre os apresentados, iremos nos aprofundar um pouco mais
em relao ao MemSQL, apresentando suas principais caractersticas, requisitos e instalao, alm de utiliz-lo como exemplo
para o nosso estudo de caso.

O MemSQL
O MemSQL um banco de dados em memria de alta performance que combina a capacidade escalvel dos sistemas distribudos
com as facilidades do SQL. Ele ficou conhecido por ser um banco
em memria transacional e altamente escalvel utilizado em
empresas como Comcast, Zynga e ShutterStock. A ltima verso
do banco, alm de outras melhorias e funcionalidades, possui
integrao com frameworks de processamento de Big Data como
o Apache Spark, HDFS, e o Amazon S3, sendo possvel realizar
anlises de dados em tempo-real.
Apache Spark uma engine para processamento de dados em
larga escala que se integra ao Hadoop. Atravs dele possvel
criar aplicaes em Java, Scala ou Python para processamento e
manipulao de dados.
Atravs do conector do MemSQL com o Spark, pode-se obter
uma alta vazo (do ingls, throughput) e executar visualizaes
em tempo real de dados armazenados no HDFS ou Amazon
S3. Integrando ambas as tecnologias, usurios podem carregar
dados entre o MemSQL e clusters Spark processando resultados
de anlises via SQL.
Alm da verso Enterprise com suporte, o MemSQL possui uma
verso "community" que permite sua utilizao de forma gratuita
sem limitaes. um banco relativamente fcil de configurar, manter e escalar, seja em uma mquina convencional ou na nuvem.
A nova verso inclui tambm recursos de inteligncia geospacial
em tempo real, possibilitando criar aplicativos com capacidade de
geolocalizao e realizar anlises instantneas das informaes
disponibilizadas.

Funcionamento do MemSQL
O MemSQL possui uma arquitetura de duas camadas. Essa
arquitetura pode ser distribuda por diversos ns que possuem
as mesmas funcionalidades e o que os diferencia o papel que
cada n configurado para executar.
Existe o conceito de ns agregadores (do ingls, aggregators nodes),
isto , ns responsveis por intermediar a comunicao entre aplicao e banco, fornecendo um nico ponto de acesso e agregando
o resultado das consultas. Os aggregators se comunicam com os ns
folha (do ingls, leaf nodes), responsveis por armazenar e processar os dados em si. A comunicao entre agregadores e ns folha
se d atravs de queries SQL, assim como mostra a Figura 1.

Edio 136 SQL Magazine

45

Trabalhando com o MemSQL

Estado

Descrio

Unknown

Nesse estado, um n folha no faz parte do cluster. Esse o estado antes de executar o comando ADD LEAF para inserir o n no cluster. Um n nesse
estado no aparecer quando o comando SHOW LEAVES for executado. O comando REMOVE LEAF coloca um n nesse estado.

Online

Estado default de um n no cluster. Nesse estado o n est ativo no sistema e est fornecendo dados ou em estado de leitura.

Offline

Um n se encontra nesse estado quando o Master Aggregator no consegue visualiz-lo. O Master Aggregator checa por cada um dos ns atravs
do comando SELECT. Mesmo depois de um n ir para o estado offline, o Master Agregador continua monitorando-o.

Detached

Um n offline entra nesse estado quando passa a responder novamente aos pings do agregador. Um n nesse estado pode voltar a ficar online se
executado o comando ATTACH LEAF. Esse comando tentar validar os dados contidos pelo n.

Tabela 1. Estados do n folha (leaf node)

Cada folha representa um dos estados apresentados na Tabela 1.
A Figura 2 mostra como funcionam as transies de estados entre
os ns folha do MemSQL. Um n no MemSQL constitudo de
mltiplas parties. Cada partio representa uma database no
servidor. Por exemplo, se temos uma database chamada system e
executarmos o comando SHOW DATABASES neste n, no resultado veremos algo como system_7 (significa que essa a partio 7
da database system). As parties possuem dois estados conforme
apresentado na Tabela 2.

Figura 1. Arquitetura do MemSQL

Dentro de um cluster MemSQL, um aggregator um n que funciona
como uma espcie de roteador de query. Esse tipo de n armazena
somente metadados e age como um gateway dentro do sistema distribudo. Um cluster pode ter um ou mais agregadores, dependendo
do volume de dados do mesmo. Um agregador responsvel por:
obter resultados dos ns folha;
agregar os resultados;
retornar os resultados para o cliente.
Existe tambm o conceito de Master Aggregator, que seria um
agregador especializado em monitorar o cluster e detectar falhas.
Os agregadores possuem os seguintes comandos:
- SHOW AGGREGATORS
- AGGREGATOR SET AS MASTER
As configuraes de aggregators so feitas atravs de um arquivo
de configurao "memsql.cnf". Para adicionar um novo aggregator ao cluster do MemSQL, basta adicionar a seguinte linha de
comando no arquivo de configurao:

master-aggregator = <master aggregator ip address>.

J os ns folha so pontos de armazenamento e processamento

de informaes. Eles armazenam pores dos dados dentro do
cluster. Por questes de desempenho, o MemSQL automaticamente distribui os dados dos ns folha em parties. Cada folha
consiste de um servidor com diversas parties sendo que cada
partio seria um "banco de dados" dentro do servidor.

46 SQL Magazine Edio 136

Figura 2. Transio de estados entre os ns folha do MemSQL

Estado

Descrio

Online

Estado das parties Master.

Replicating

Estado das parties Slave que esto sendo replicadas a partir da

partio Master.

Tabela 2. Estados da partio

Se executarmos o comando SHOW DATABASES EXTENDED,
ser possvel ver as parties e em quais estados elas esto. Ao
executarmos o comando em uma instalao nova do MemSQL,
vemos as informaes constantes na Figura 3.

Requisitos e instalao
O MemSQL roda nos sistemas operacionais Linux de 64-bits, ou seja, o MemSQL
no ir funcionar nos sistemas de 32-bits.
Recomenda-se utilizar pelo menos 8GB
de RAM para rod-lo, no entanto ele funcionar em mquinas com menos RAM,
apesar de no ser recomendado, pois a
capacidade de armazenamento do MemSQL limitada pela quantidade de memria RAM que a mquina possui. Dessa
forma, quanto mais RAM disponvel, maior
a quantidade de memria disponvel para
armazenamento. Outro ponto importante
em relao quantidade de processadores
que a mquina possui. O MemSQL requer
um mnimo de 4 ncleos (do ingls, cores)
para funcionar, conforme Figura 4.
A instalao bem simples, basta descompactar o tar.gz e rodar o install.sh. Toda
a configurao do cluster feita atravs
da interface do MemSQL conhecida como
MemSQL Ops:

Figura 3. Execuo do comando SHOW DATABASES EXTENDED

Figura 4. Requisito mnimo de ncleos para instalar o MemSQL

tar -xzf memsql-ops-4.0.34.tar.gz

cd memsql-ops-4.0.34
sudo ./install.sh

Uma vez que o MemSQL est instalado

na primeira mquina, a interface web do
MemSQL Ops pode ser acessada pelo endereo: http://<host>:9000. Basta acessar
a URL para configurar outras opes e
outros ns do cluster. Podemos ver na Figura 5 o MemSQL Ops rodando com um
cluster de dois ns configurados. Temos
um Master Aggregator rodando na porta
3306 e um Leaf na porta 3307.
O MemSQL utiliza o mesmo protocolo
de comunicao do MySQL, sendo assim,
quem j est acostumado com o MySQL
poder utilizar a mesma forma de comunicao, podendo conectar em seu banco
com o mesmo conector sem necessidade de
instalao de clients adicionais. Devido ao
fato do MemSQL utilizar SQL para anlise, torna-se muito simples a integrao
para quem j est acostumado com essa
linguagem.

Estudo de caso
Para demonstrar algumas das funcionalidades desse banco, vamos criar um mo-

Figura 5. Tela inicial do MemSQL Ops

delo de dados de um sistema de pedidos
bsico, conforme a Figura 6.
O sistema possui uma tabela de itens (sales_item) e as vendas dos itens so processadas na tabela de pedidos (sales_order_item e
sales_order). Temos tambm a localizao do
pedido (locality) e os centros de distribuio
(distribution_centre) que so os locais fsicos
onde as mercadorias ficam armazenadas.
O intuito dos centros de distribuio aqui
mostrar algumas das funcionalidades
geoespaciais presentes no MemSQL.
O MemSQL pode ser utilizado com
qualquer client do MySQL. Nesse caso,

utilizaremos um client default que vem

com a instalao do MySQL para linha
de comando. Para efetuar a conexo
utilizamos:
mysql.exe -u root -h <host-do-memsql>

Uma vez conectado, podemos iniciar a

criao das tabelas do nosso sistema de
pedidos. Criaremos primeiramente o database associada ao nosso sistema:
mysql> create database system;

Edio 136 SQL Magazine

47

Trabalhando com o MemSQL

Depois de criar o database, vamos agora criar as tabelas

do sistema. A DDL da tabela sales-order pode ser vista na
Listagem 1.
Notamos que, para referenciar a chave estrangeira locality_id
referente tabela locality, utilizamos o comando "FOREIGN
SHARD KEY".
Os dados no MemSQL so fragmentados pelo n atravs de
parties. Cada partio representa uma database no formato
database_N (onde N representa o nmero da partio) e que
carrega uma parte dos dados de cada tabela daquela partio.
Por padro, o MemSQL ir criar uma partio por ncleo de
CPU dentro dos ns para ter um mximo de paralelismo possvel. Esse valor configurvel pelo cluster atravs do parmetro
de configurao default-partitions-per-leaf, ou tambm como
um parmetro opcional do comando CREATE DATABASE.
Cada tabela dentro de uma partio possui exatamente um
"shard key", ou "shard index", o que seria um ndice de tabela
normal contendo qualquer nmero de colunas. O MemSQL
utiliza essa informao para determinar a qual partio determinada coluna est relacionada.
O banco tambm suporta uma variante de shard key, chamada
foreign shard key, que referencia explicitamente uma shard
key de outra tabela (quando criamos uma primary key sem especificar a shard key, a prpria primary key a shard key). At
a verso 3.2 do MemSQL, esse tipo de referncia (Foreign Shard
Key) era necessrio para realizar joins distribudos. A partir da
verso 4 essa referncia direta no mais necessria.
No MemSQL, at a verso corrente, no existe o conceito de
foreign key como uma chave de integridade referencial. Assim,
o comando utilizado serve apenas para criar um index sobre
o campo locality_id.

Figura 6. Modelo de dados sistema de pedidos

48 SQL Magazine Edio 136

Listagem 1. Criao da tabela sales_order

CREATE TABLE sales_order
(id int unsigned not null auto_increment,
protocol varchar(255) not null,
email varchar(255),
phone_number varchar(30),
sales_manager_name varchar(255) not null,
locality_id int unsigned not null,
created_at datetime,
updated_at datetime,
created_by varchar(100),
updated_by varchar(100),
status smallint,
finished_at datetime,
finished_by varchar(100),
customer_id int unsigned not null,
FOREIGN SHARD KEY (locality_id) REFERENCES locality (id),
PRIMARY KEY (id,locality_id) );

Dados geoespaciais
Outro fato interessante de mencionarmos a criao da tabela
distribution_centre (Listagem 2), visto que nela vamos utilizar
informaes geoespaciais. A coluna "location" possui o tipo
GEOGRAPHYPOINT.
O MemSQL, na verso 4, possui suporte para diferentes funes
geoespaciais. Ele suporta trs tipos de dados: pontos (points),
caminhos (paths) e polgonos (polygons), conforme demonstrado
na Figura 7. O tipo POINT, por exemplo, simplesmente uma
coordenada de latitude/longitude. O MemSQL implementa um
subconjunto do WKT. O WKT (Well-known text) uma linguagem
para representao de objetos geogrficos, referncias espaciais e
transformaes entre objetos e referncias espaciais.
A tabela locality (Listagem 3) tambm possui um campo para
coordenadas geomtricas. O intuito aqui poder calcular, dada
uma determinada localidade de entrega
de um pedido, qual o centro de distribuio mais prximo que pode atender
quela localidade.
Depois de criadas todas as tabelas (a
Listagem 4 mostra a DDL das demais tabelas), podemos inserir os dados armazenados, por exemplo, em um arquivo csv,
utilizando o comando da Listagem 5.
Na tabela distribution_centre iremos
inserir trs centros de distribuio, assim como mostra a Listagem 6.
No nosso caso s precisamos saber
quais as coordenadas de cada centro
de distribuio, por isso utilizamos o
tipo point (GEOGRAPHYPOINT), que
consiste de um par latitude/longitude.
Note que no existe vrgula separando
as coordenadas.
Qua ndo uma tabela criada no
MemSQL, para acelerar a compilao
das queries, o MemSQL pr-compila

Listagem 2. Criao da tabela centre_distribution

CREATE TABLE distribution_centre
(id int unsigned not null primary key,
name varchar(255) not null,
location GEOGRAPHYPOINT not null,
created_at datetime,
created_by varchar(100),
shard key (location) );

o cdigo utilizado para acessar e atualizar os ndices da tabela.

Isso ocorre somente uma vez para cada tabela criada. Feito isso,
o cdigo compilado colocado em cache para uso futuro.

Listagem 3. Criao da tabela locality

CREATE TABLE locality
(id int unsigned primary key,
name varchar(255), code varchar(100),
location GEOGRAPHYPOINT not null,
created_at datetime,
created_by varchar(100),
index (location));
Listagem 4. Criao das demais tabela
CREATE TABLE sales_item
(id int unsigned not null primary key,
item_price_value double not null,
quantity int default 1,
item_name varchar(255),
created_at datetime,
updated_at datetime,
created_by varchar(100),
updated_by varchar(100),
status smallint);
CREATE TABLE sales_order_item
(id_order int unsigned not null,
id_item int unsigned not null,
quantity int unsigned not null default 1,
SHARD KEY (id_item,id_order),
PRIMARY KEY (id_item,id_order));
CREATE TABLE locality
(id int unsigned primary key,
name varchar(255), code varchar(100),
location GEOGRAPHYPOINT not null,
created_at datetime,
created_by varchar(100),
index (location));
CREATE TABLE customer
(id int unsigned primary key,
name varchar(100),
birth datetime,
created_at datetime,
updated_at datetime,
created_by varchar(100),
updated_by varchar(100),
status smallint);
Listagem 5. Insero de dados armazenados num arquivo csv
LOAD DATA INFILE arquivo_com_dados.csv INTO TABLE nome_da_tabela
FIELDS TERMINATED BY ,
LINES TERMINATED BY \n

Figura 7. Tipos de dados geoespaciais

Listagem 6. Insero de centros de distribuio
insert into distribution_centre (id,name,location,created_at,created_by)
values (1, Centro P1, POINT(-12.1722904 -51.5108855), now(), admin);
insert into distribution_centre (id,name,location,created_at,created_by)
values (2, Centro P2, POINT(-19.9230507 -43.9368626), now(), admin);
insert into distribution_centre (id,name,location,created_at,created_by)
values (3, Centro P3, POINT(-8.7249743 -39.1199079), now(), admin);

Distribuio dos Inserts e Selects

Quando executamos um insert no MemSQL, o agregador calcula
o hash dos valores contidos na(s) coluna(s) que fazem parte da
shard key e realiza uma operao para gerar um nmero especfico
de partio. O banco direciona ento o INSERT para a partio
apropriada (que bate com o nmero gerado pela operao que
calcula o hash) no n da mquina.
A nica garantia que se tem sobre o local fsico de insero dos
dados a de que duas colunas com o mesmo valor para o shard
key estaro na mesma partio (dado o processo de clculo para
se determinar qual partio o dado ir ocupar). Na Figura 8
temos um exemplo de como essa estrutura entre agregadores e
ns funciona para a insero dos dados. Nesse exemplo, um dos
agregadores (agregador 1) calcula o hash dos valores da coluna e
insere os dados no n 3.

Figura 8. Mecanismo de insert

No caso da execuo de um select, o mesmo executado em
paralelo em cada uma das parties referentes database. Conforme pode ser visto na Figura 9, o agregador responsvel por
executar a query em todas as parties que compem as tabelas
envolvidas na execuo. As parties podem ser visualizadas com
o comando SHOW PARTITIONS (Figura 10).

Edio 136 SQL Magazine

49

Trabalhando com o MemSQL

Figura 9. Mecanismo de select

Quando uma query executada pela primeira vez, pode-se notar claramente uma
demora na execuo. Isso acontece porque
o MemSQL transforma as queries SQL em
cdigo C++ e o compila (SGBDs tradicionais
interpretam as queries SQL). A compilao
da query feita somente uma vez (o que gera
um pouco de demora na primeira execuo)
para cada padro de query. Uma vez que a
query est compilada, qualquer outra executada que for similar o suficiente, reutilizar
o mesmo plano de execuo. Por exemplo, se
tivermos uma query no formato select * from
customer where name=Fulano and status = 1,
o MemSQL no ir recompilar a query para
consultas parecidas. Ele substituir os parmetros para poder fazer binds de outros
valores sempre que o mesmo tipo de query
for chamado.
O MemSQL usa a compilao de queries
para otimizar a execuo da mesma. Sem
o overhead de interpretar a query dinamicamente, as queries podem ser executadas
de forma bem mais rpida, competindo
de igual para igual com outras solues
otimizadas como, por exemplo, solues
NoSQL.

Calculando distncias

Figura 10. Status das parties e database system

Figura 11. Centros de distribuio e localidade do pedido a ser entregue

50 SQL Magazine Edio 136

Criamos a tabela distribution_centre

como uma forma de demonstrar como
o clculo de dados geoespaciais pode
ser utilizado no MemSQL. Supondo um
determinado pedido a ser entregue em
Curitiba PR, precisamos saber qual centro
de distribuio, dentre os cadastrados, fica
mais prximo da localizao de entrega do
pedido (Figura 11).
Para esse feito, podemos executar a
f u no GEOGR A P H Y_ DISTA NC E
responsvel por calcular a distncia entre duas coordenadas. Executando essa
funo entre a localidade dos centros de
distribuio e do local de entrega, obtemos
que o Centro de distribuio P2 o mais
prximo, conforme Figura 12.
Outra funo interessante tambm
a GEOGRAPHY_INTERSECTS, que
serve para descobrir, dado uma ou mais
coordenadas, quais outras localidades a
interceptam.
No nosso exemplo, utilizamos informaes bem bsicas, somente para demons-

trao da funo de clculo da distncia,

calculando-a diretamente entre o centro de
distribuio e a localidade desejada. Em um
sistema real, seria necessrio, por exemplo,
ter coordenadas intermedirias para se
determinar uma rota real entre as cidades
origem e destino.

Apache Spark e MemSQL

O Apache Spark uma soluo muito
Figura 12. Resultado da execuo de clculo de distncia
interessante em cenrios de manipulao
e processamento de dados em larga escala.
Possui diversas vantagens em relao a outros frameworks de
O MemSQL um banco de dados em memria que apresenta
big data, permitindo lidar com uma grande variedade de dados
diversas funcionalidades e facilidades para lidar com dados em
atravs de diversas fontes distintas. Em muitos casos, esses dados,
grande escala de forma distribuda. Pelo fato de se tratar de um
depois de analisados, processados e reformatados, devem ser
banco de dados relacional, fica transparente de ser utilizado por
armazenados em algum lugar.
usurios que j possuem experincia com SQL, em especial com
A verso mais nova do MemSQL fornece um conector para o
o MySQL, visto que utiliza o mesmo conector.
Spark, facilitando o carregamento de dados entre ambos, transO MemSQL tambm traz facilidades para se conectar com o
formando e enriquecendo os dados em tempo real.
Apache Spark para casos onde se tem necessidade de uma maniUma das melhores caractersticas do Spark so as facilidades
pulao mais apurada dos dados, ou da realizao de processada interface de programao. Alm de permitir que usurios do
mentos complexos das informaes antes de armazen-las. A sua
MemSQL desenvolvam processos computacionais interativos,
utilizao mais adequada para situaes onde temos um fluxo
ele possibilita o acesso a vrias bibliotecas que executam em sua
de dados constante e que devem ser processados e analisados
engine. O conector do MemSQL com o Spark otimizado, permiem tempo real.
tindo minimizar a transferncia de dados e tirar vantagens dos
mecanismos de otimizao e indexao do MemSQL.
Autor
O conector uma ferramenta open source disponvel na pgina
Rodrigo Salvo
do MemSQL no GitHub. O conector cria um mapeamento entre as
[email protected]
parties do MemSQL e as parties RDD do Spark (ver BOX 1).
Formado em Cincias da Computao pela Universidade
Ele tambm tira vantagem da arquitetura distribuda de ambos
Federal de Uberlndia, possui mais de 10 anos de experincia
os sistemas, permitindo realizar o carregamento de dados em
em desenvolvimento de software. Especialista na rea de Telecom e
paralelo. Junto ao conector vem uma biblioteca (MemSQLRDD).
servios para internet.
Esta permite ao usurio criar um RDD do resultado de uma query
SQL executada no MemSQL. A classe MemSQLRDD possui um
Links:
mtodo chamado saveToMemSQL, que facilita imputar dados
no MemSQL depois de processados pelo Spark.
Big Data
Os bancos de dados em memria vm adquirindo uma imporhttp://www.technologytransfer.eu/article/98/2012/1/What_Is_Big_Data_and_Why_
tncia cada vez maior no mercado, dado um aumento constante
Do_We_Need_It_.html
de cenrios onde a velocidade no processamento e anlise de
H-Store
informaes se torna essencial para os negcios.
http://hstore.cs.brown.edu/
BOX 1. RDD
O Apache Spark possui o conceito de conjunto de dados distribudos (do ingls, Resilient Distributed
Dataset - RDD), que uma coleo de elementos tolerantes a falhas que podem ser manipulados
em paralelo. Existem duas formas de se criar uma coleo RDD: paralelizando uma coleo existente,
ou referenciando um conjunto de dados armazenados externamente, seja atravs de um sistema de
arquivos compartilhados, atravs de HDFS, HBase etc.
RDDs suportam dois tipos de operaes: transformaes (transformations), que criam um novo
conjunto de dados a partir de um j existente, e aes (actions), que retornam um valor depois de
computar informaes sobre o conjunto de dados.

MemSQL
http://www.memsql.com
Apache Spark
http://spark.apache.org/

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

51

Trabalhando com o
MySQL Cluster
Saiba como configurar o MySQL Cluster e conhea
o storage engine NDB

MySQL Database, apesar de open source, foi um

projeto criado e desenvolvido por uma empresa
privada sueca chamada MySQL AB. A sua primeira verso estvel foi lanada em janeiro de 2001. O
modelo de negcio era baseado em cdigo aberto, sem
cobrana pelo licenciamento de uso, mas com a opo de
adquirir servios de suporte e consultoria de seus criadores. A arquitetura do produto era baseada em plug-ins
e isto possibilitou a criao de um ecossistema ao seu
redor, com outras empresas e contribuidores externos
criando facilmente novas funcionalidades.
Um caso destas empresas do ecossistema MySQL foi
a Alzato, uma spin-off da Ericsson. Seu time de engenheiros criou alguns componentes adicionais ao MySQL
que o transformavam em um verdadeiro banco de dados
distribudo, com todas as caractersticas que atendiam
aos mais exigentes requisitos dos sistemas de infraestrutura de telefonia, conhecidos como Carrier-Grade.
O projeto, chamado de NDB (Network Database), era to
interessante que a MySQL AB adquiriu a Alzato em
setembro de 2003. Com isso, o time de engenheiros da
Alzato passou a fazer parte do time da MySQL AB, que
melhorou o NDB e o rebatizou como MySQL Cluster.
Em 2008, a MySQL AB foi adquirida pela Sun Microsystems, que em 2010 foi adquirida pela Oracle. Hoje,
o MySQL Cluster um produto que compe o portflio
MySQL da Oracle e continua em pleno desenvolvimento
sob licenciamento GPL, ou seja, pode ser usado, modificado e redistribudo gratuitamente mantendo-se o
cdigo-fonte aberto. A Oracle tambm prov opcionalmente suporte tcnico e ferramentas comerciais para
gerenciamento do MySQL Cluster.
O MySQL Cluster uma soluo que atende muito
bem alguns requisitos como disponibilidade de 99,999%,
workloads transacionais (OLTP), replicao geogrfica
ativo-ativo, tempos de respostas consistentes da ordem
de milsimos de segundo, escalabilidade praticamente
linear (inclusive de escritas) e capacidade de atender

52 SQL Magazine Edio 136

Fique por dentro

O MySQL Cluster um banco de dados transacional baseado no
MySQL Server que combina a flexibilidade de um banco de dados
relacional ACID, interfaces SQL e NoSQL, alta disponibilidade e alto
desempenho em operaes de leitura e escrita. Neste artigo apresentamos alguns conceitos fundamentais do MySQL Cluster para
que voc possa entender seu funcionamento, compar-lo com outras
solues (inclusive o prprio MySQL Server) e, quem sabe, utiliz-lo
com sucesso em seu prximo projeto. Em tempos onde vemos uma
avalanche de novos bancos de dados, tais como o NoSQL, entender
os conceitos que so base para o funcionamento e limitaes de um
banco de dados distribudo vai ajud-lo a fazer melhores escolhas. O
MySQL Cluster um banco de dados distribudo que pode ser a soluo
ideal para seu novo projeto, com alta disponibilidade e escalabilidade
horizontal, exigindo hardwares relativamente modestos. E o melhor,
totalmente open source e com suporte (opcional) da Oracle.

dezenas de milhares de transaes por segundo. Contudo, o MySQL Cluster no vai ser uma boa escolha para executar consultas
analticas (OLAP) e, por se tratar de um sistema distribudo, vai
adicionar maior complexidade na implantao e administrao.

Tipos de aplicaes
O MySQL Cluster nasceu para atender as necessidades de aplicaes de telecomunicaes, mas continua em constante evoluo
para lidar com cargas de trabalho mais genricas. Provavelmente,
o MySQL Cluster ser uma boa escolha se a carga de trabalho da
sua aplicao for semelhante aos casos da Tabela 1.
No geral, os requisitos comuns destas aplicaes so:
alta disponibilidade (99,999%), com failover automtico (abaixo
de 1s) e operaes de manuteno online;
distribuio geogrfica ativo-ativo;
alto volume de acessos e conexes (milhares), com escalabilidade
tanto em leituras quanto em escritas (milhes de TPS);
baixa latncia com pouca variao nos tempos de resposta
(milissegundos);

Tipos de Aplicao

Casos de Referncia

Infraestrutura de TI, Cloud e Telecom

Ericsson, Alcatel Lucent, NEC, Nokia, Telenor, Italtel, B2, Cell C, Emblacom, ip.access,
M1, Register.it, CenturyLink

Mensagens, mobile publishing, news portals

SpeechDesign, Go2, Kurier, XClima, UC Berkeley, American Education Corporation

Games sociais

Jogo do Chaves para Facebook (El Chavo) da Playful Play.

Games MMO e de rede

World of Warcraft e Diablo 3 da Blizzard e FIFA da EA Sports

Transaes financeiras e micro transaes OLTP

Paggo, Vivo, Telefonica, Totto Loto, Cashpoint

Internet das Coisas, Monitoramento de dispositivos ou aplicaes, aquisio

massiva de dados

Callis, Vivid Cortex

e-Commerce, workflow, sesses Web, gesto de documentos

Zillow, Shopatron, DocQ

Big Data: antifraude e recomendao

Paypal, Big Fish Games, Mapion

Sistemas de tempo real, misso crtica e militares

Marinha EUA (US Navy), ViaSuisse

Metadados como componente de outros projetos open source

Hadoop Hops, Hadoop KTH, OpenMQ, FreeRADIUS, FreeSWITCH, Kamailio, OpenIMS, Sailfin, WSO2

Tabela 1. Exemplos de uso do MySQL Cluster por tipo de aplicao

carga OLTP (transacional ACID), onde as principais queries e
transaes so baseadas na chave primria e/ou chaves nicas
(realiza poucos full table scans), possuem curta durao (at 10s) e
alto grau de paralelismo;
dados estruturados seguindo modelo relacional ou chave-valor,
com poucas foreign keys e poucos BLOBs ou TEXTs (linhas com
16KB);
reteno de dados com perodo limitado, com estratgias de
expurgo ou arquivamento peridico;
baixo custo total de implantao e operao (hardware commodity, licenciamento GPL).
O MySQL Cluster uma soluo que atende todos estes requisitos simultaneamente. Porm, se voc precisa lidar com um
ou apenas alguns destes requisitos isoladamente, talvez outras
opes de menor complexidade sejam a soluo ideal como, por
exemplo, o tradicional MySQL Database com InnoDB.
importante destacar tambm que cada vez mais as aplicaes
so arquiteturadas na forma de servios ou microservios, e perfeitamente possvel combinar mais de um banco de dados usando
tcnicas que alguns autores nomeiam de persistncia poliglota.
Com o MySQL, esta ideia j bastante natural, visto que desde
sua concepo, h a noo de tipos de tabela, que so mais ou
menos adequadas dependendo da situao. Portanto, o MySQL
Cluster pode atender muito bem a uma parte especfica da sua
aplicao, modelada em algumas tabelas, enquanto que outras
partes so atendidas por outros tipos de tabelas ou mesmo
outras tecnologias.

NewSQL
O MySQL Cluster um sistema gerenciador de banco de dados
relacional que oferece ao mesmo tempo desempenho, escalabilidade de leituras e escritas, e flexibilidade nos mtodos de acesso
aos dados dos sistemas NoSQL para processamento de transaes
online (OLTP), mantendo as garantias ACID de um sistema de
banco de dados tradicional. Isto o que alguns autores chamam
de NewSQL.

H vrias interfaces que as aplicaes podero usar para escrever e ler dados do MySQL Cluster. Por exemplo, o desenvolvedor
pode fazer chamadas diretas ao banco de dados usando C++, Java,
Node.js, HTTP ou Memcached protocol. Desta forma, a camada
de SQL no ser necessria, diminuindo sobrecarga e aumentando performance, alm de oferecer flexibilidade e agilidade no
desenvolvimento. Cada uma das APIs NoSQL pode ser utilizada
simultaneamente com SQL, sobre o mesmo conjunto de dados.
Estes sero mapeados automaticamente ou via configurao em
tabelas e a viso final ser a mesma, com consistncia e integridade garantidas pelo MySQL Cluster, inclusive para chaves
estrangeiras (FKs).

Conceitos fundamentais e arquitetura

O MySQL Cluster um banco de dados relacional ACID, mas no
(apenas) o MySQL Server com replicao. Para usar o Cluster,
voc ter que baixar outro pacote que contm mais componentes
que o popular MySQL Server. Este pacote est disponvel no site
do MySQL (ver a seo de Links).
O MySQL Cluster, apesar de operar no modo multi-master,
tambm no equivalente ao Oracle RAC. O Oracle RAC depende
de um storage compartilhado para persistir os dados, em uma arquitetura conhecida como shared-everything. J no MySQL Cluster,
cada n de dados tem sua prpria unidade de armazenamento, ou
seja, no compartilham nenhuma memria (voltil ou no) e por
isso uma arquitetura conhecida como shared-nothing.
Esta arquitetura (ver Figura 1) do MySQL Cluster permite
implementaes distribudas e sem ponto nico de falha (SPoF
ou Single Point of Failure), o que casa muito bem com hardwares
commodity ou ambientes de Cloud Computing, porm adiciona
algumas complexidades e restries.
H trs tipos diferentes de ns no MySQL Cluster, cada um
fornecendo servios especializados, sendo todos escalveis horizontalmente (adicionando mais ns). Um destes tipos de ns
o tradicional e popular MySQL Server (mysqld), mas h outros
componentes igualmente importantes.

Edio 136 SQL Magazine

53

Trabalhando com o MySQL Cluster

Figura 1. Arquitetura do MySQL Cluster

Os ns de dados (Data Nodes) so os principais ns do cluster,
onde os dados esto armazenados de fato e so escritos e lidos
atravs da NDB API.
Os ns de aplicativo (Application Nodes) so as interfaces entre
os programas e os ns de dados, oferecendo opes de acesso via
SQL ou APIs NoSQL. No contexto desta arquitetura, o MySQL
Server (mysqld) um tipo especializado de Application Node que
permite acesso via SQL aos dados.
Os ns de gerenciamento (Management Nodes) fornecem informaes de configurao e status ao cluster e permitem executar
rotinas de manuteno como, por exemplo, backup online ou
adicionar mais ns.
Caso o leitor j esteja familiarizado com o MySQL Database,
saber que possvel selecionar os motores de armazenamento
(storage engines) por tabela. Para os SQL Nodes, o MySQL Cluster
um storage engine adicional. Portanto, possvel combinar
tabelas NDBCluster com tabelas de outros tipos no mesmo
esquema de dados como, por exemplo, InnoDB ou MyISAM.
Tambm possvel utilizar recursos nativos da camada SQL
do MySQL Database em conjunto com tabelas NDBCluster,
tais como Stored Programs, Triggers, Eventos, UDFs, Binlog,
Replicao Assncrona, etc.

Alta disponibilidade
Como cada tipo de n possui uma responsabilidade bem definida e com dependncias minimizadas, possvel distribu-los
em mltiplas mquinas (hosts fsicos ou virtuais). Estas mquinas
podem estar fisicamente no mesmo datacenter ou em vrios (via
geo-replicao), o que permite as devidas redundncias para um
nvel de disponibilidade de 99,999%.
Para obter este nvel de alta disponibilidade, um cluster mnimo
deve ter seis ns lgicos (dois de cada tipo). Porm, alguns destes
ns podem ser co-alocados fisicamente em um mesmo host/mquina, desde que no haja ponto nico de falha. A implementao
mais comum para alta disponibilidade conta com quatro hosts:
dois ns de dados e mais dois co-alocando um n SQL e um n
de gerenciamento em cada um.
Podemos adicionar ns redundantes em todas as camadas. Os
dados sero replicados automaticamente pelo cluster entre os ns
de dados e mesmo que alguns ns de dados, de aplicativo ou de

54 SQL Magazine Edio 136

gerenciamento venham a falhar, as aplicaes clientes continuaro sua execuo.

No caso da falha de um dos ns de dados,
o cluster continuar funcionando normalmente e quando o n for restaurado, os
dados sero re-sincronizados automaticamente, sem nenhum trabalho administrativo. Esta uma funcionalidade conhecida
como self-healing (auto recuperao).
Entretanto, o fato de o MySQL Cluster
ser desenhado para alta disponibilidade
no uma garantia de entrega real destes resultados. Na verdade, um cluster
shared-nothing multi-master implementado e mantido de
maneira deficitria pode facilmente oferecer nveis mais baixos
de disponibilidade do que uma simples soluo de replicao
de dados master-slave. necessrio verificar diversos aspectos na implementao, tais como: configurao do hardware,
throughput e latncia da rede, redundncia da alimentao
de energia, etc.

Escalabilidade
tambm essa arquitetura do MySQL Cluster que possibilita
escalabilidade linear de leituras e escritas, distribuindo os dados e
as cargas entre os ns no modelo multi-master. No MySQL Cluster,
h particionamento automtico de dados (auto-sharding) entre os
data nodes. Por exemplo, em dois cenrios tpicos, quando uma
tabela com dados carregada no Cluster:
1. se o Cluster possuir apenas dois Data Nodes, a tabela ser
persistida em um n e uma cpia (rplica) automaticamente vai
para outro n. Se um n falhar, o Cluster automaticamente usa
os dados do n disponvel;
2. se o Cluster possuir quatro Data Nodes, as linhas da tabela (alm
de replicadas) so distribudas automaticamente e uniformemente
entre os ns (auto-sharding). Desta forma, metade dos dados da
tabela estar em dois ns e outra metade nos outros dois ns.
No somente os dados so distribudos nas operaes de escrita,
mas tambm so distribudas as operaes de leitura via balanceamento de carga. Adicionando mais ns, aumenta-se a capacidade e performance do Cluster, tanto para leituras quanto para
escritas. Esta capacidade de escalar linear, ou seja, adicionando
o dobro de ns em um Cluster possvel dobrar sua capacidade
de armazenamento e desempenho.
Portanto, o MySQL Cluster escala horizontalmente. Como veremos, a replicao dos dados ocorre de forma sncrona e imediata,
portanto os programas podero conectar-se a qualquer application
node e sempre enxergaro o mesmo conjunto consistente de dados.
Na prtica, isso significa que permitido colocar um balanceador
de carga entre os aplicativos e os application nodes distribuindo a
carga entre os ns.
Outra propriedade interessante desta arquitetura a elasticidade.
A adio de mais ns pode ser realizada online, sem paralisaes

no sistema. Sendo assim, se no h como prever a demanda antecipadamente, isto no um problema para o MySQL Cluster.

Consistncia, integridade e performance

Toda a replicao, distribuio, sincronizao e consistncia
dos dados feita pelo MySQL Cluster de forma transparente
para o usurio. Para manter a consistncia dos dados entre
todos os ns, a replicao ocorre de forma sncrona. O mesmo
conjunto consistente de dados sempre estar acessvel, independente de qual n seja consultado. Isso tambm se aplica
a operaes de escritas, o que significa que o cluster multimaster, permitindo um balanceador de carga via software ou
hardware entre as aplicaes e os application nodes. Lembrando
que cada data node tem sua unidade independente de armazenamento de dados, portanto temos um cluster multi-master
sem storage compartilhado.
Neste ponto, o leitor pode estar se perguntando: mas como
manter os dados replicados de maneira sncrona, em mquinas
completamente independentes e sem comprometer a performance? A arquitetura do MySQL Cluster distribuda, sem
necessidade de ter um storage compartilhado, mas tambm
in-memory. Ao inserir um dado em um n do cluster, ele ser
replicado para a memria RAM de pelo menos mais um n. O
cluster no aguarda o dado ser escrito em disco para responder um commit e se beneficia das atuais redes mais rpidas
e quantidades mais abundantes de RAM. Esta estratgia
conhecida como commit em nvel de rede com consistncia
eventual em disco.
O processo de gravar informao em RAM remota mais
rpido que escrever em disco local. Somando-se a isso, a capacidade de distribuir a carga de leituras e escritas entre ns,
a performance do MySQL Cluster alcana nveis na ordem de
milhes de transaes por segundo.
Por padro, os dados indexados ficaro residentes na memria
RAM, porm h suporte para mant-los apenas em disco. Esta
flexibilidade permite ao usurio fazer escolhas entre performance ou uso de maiores quantidades de memria RAM.
Como descrito anteriormente, o MySQL Cluster sobreviver
a falhas parciais em alguns de seus ns. Porm, importante
implantar o cluster sem SPoFs (Single Points of Failure), com
redundncias at na camada fsica como rede, alimentao,
etc. Se houver queda total e simultnea de todos data nodes de
uma s vez, o MySQL Cluster obedecer ao modelo failing fast,
onde vai sacrificar a disponibilidade para manter a consistncia
dos dados. Isto no deve ocorrer se os devidos cuidados na
implantao sem SPoF forem tomados.

Instalao para ambiente de desenvolvimento

H algumas opes para instalao do MySQL Cluster: binrios compilados, compilao do cgido-fonte ou atravs do
utilitrio MySQL Cluster Manager (MCM). A opo mais simples
para montar um ambiente de desenvolvimento e comear a
test-lo utilizando o MCM. Esta a opo que utilizaremos

para nossos exemplos neste artigo. Para as outras opes consulte o manual de referncia (ver a seo de Links).
Testaremos conectividade via SQL e as capacidades de alta
disponibilidade e escalabilidade horizontal. No nosso objetivo testar a performance, outras APIs de acesso, alm de SQL,
nem operaes de manuteno, tal como backup online.
O MCM um utilitrio opcional para facilitar o gerenciamento
do MySQL Cluster. Ele no essencial para o funcionamento do
MySQL Cluster, ento no confunda com o Management Node.
H duas edies do MySQL Cluster: Community Edition e Cluster Carrier-Grade Edition. A primeira est sob licenciamento GPL
v2, que permite o uso gratuito em produo e sem limitaes.
A segunda possui uma licena comercial. No h diferenas nas
funcionalidades do banco de dados em si. A opo comercial
existe para permitir que o MySQL Cluster seja embarcado em
outros produtos de hardware ou software e redistribudo sem
a necessidade de abrir o cdigo fonte da aplicao ou demais
componentes. O MySQL Cluster Manager um utilitrio tambm com licena comercial, mas opcional e pode ser utilizado
em ambiente de desenvolvimento para testes por 30 dias.
No MCM, h uma opo para criar um cluster mnimo para
testes composto por cinco ns lgicos como mostra a Figura 2,
sendo um Management Node (ndb_mgmd), dois Data Nodes
(ndbmtd) e dois SQL Nodes (mysqld).

Figura 2. Cluster criado com a opo bootstrap do MCM

O MCM pode ser baixado diretamente do site do MySQL (ver
seo Links). Aps o Sign In com conta Oracle (crie uma, caso
necessrio), procure por MySQL Cluster Carrier Grade Edition,
selecione sua plataforma como mostra a Figura 3 e siga para a
prxima tela. Nos testes a seguir, a plataforma Linux x86-64.
No passo seguinte, selecione o item MySQL Cluster Carrier
Grade Edition e o sub-item MySQL Cluster Manager. Ao seguir
para a prxima tela, voc ver os termos de uso do MCM. Leia e
prossiga para a tela de download onde ser possvel baixar arquivos .zip. Para os testes, utilizaremos o MySQL Cluster Manager
1.3.6+Cluster TAR for Generic Linux x86 (64bit). Este pacote inclui
os arquivos de instalao do utilitrio MCM e mais os arquivos
do MySQL Cluster. Se voc baixar o pacote com apenas o MCM,
ter que baixar o MySQL Cluster separadamente.

Edio 136 SQL Magazine

55

Trabalhando com o MySQL Cluster

Se houver algum erro na inicializao, verifique o arquivo de

mcmd.log. Um erro comum no ter memria suficiente na mquina de testes, sendo que 2 GB de RAM o requisito mnimo
para usar a opo bootstrap, mas recomendamos 3 GB para estes
testes. No site do MySQL h um frum na Developer Zone especfico sobre MySQL Cluster que pode ser de grande ajuda para
resolver problemas.

Testes bsicos

Figura 3. Download do MySQL Cluster Manager

Instalao
Para os passos a seguir, utilize um usurio diferente de root e
certifique-se que possui pelo menos 3 GB de RAM. A instalao
trivial, basta descompactar os arquivos baixados conforme a
Listagem 1. Extraia o contedo do .zip e, em seguida, extraia o .tar
j para um diretrio onde ficaro os executveis do MySQL Cluster
e MCM, normalmente um subdiretrio do home do usurio.
No necessria nenhuma configurao adicional. Opcionalmente, voc pode querer alterar alguns parmetros de configurao do MCM editando o arquivo em mcm*/etc/mcmd.ini.

Inicializando um cluster de testes

Para criar o cluster mnimo para testes da Figura 2, com um
usurio diferente de root, simplesmente execute o mcmd com
a opo --bootstrap. A Listagem 2 demonstra o uso desta opo.
Listagem 1. Instalao do MySQL Cluster Manager
$ mkdir -p ~/mysql/packages
$ unzip mcm*.zip -d ~/mysql/packages
$ tar -zxvf ~/mysql/packages/mcm*.gz -C ~/mysql/packages
$ mv ~/mysql/packages/mcm*64bit ~/mysqlcluster
$ ls mysqlcluster/
cluster mcm1.3.6
Listagem 2. Inicializao do MySQL Cluster com a opo bootstrap
$ ~/mysqlcluster/mcm1.3.6/bin/mcmd --bootstrap
MySQL Cluster Manager 1.3.6 (64bit) started
Connect to MySQL Cluster Manager by running /home/vagrant/mysqlcluster/
mcm1.3.6/bin/mcm -a vmclusterdev:1862
Configuring default cluster mycluster...
Setting default_storage_engine to ndbcluster...
Starting default cluster mycluster version 5.6.24-ndb-7.4.6-cluster-commercialadvanced...
Cluster mycluster started successfully
ndb_mgmd vmclusterdev:1186
ndbmtd
vmclusterdev
ndbmtd
vmclusterdev
mysqld
vmclusterdev:3306
mysqld
vmclusterdev:3307
ndbapi
*
Connect to the database by running /home/vagrant/mysqlcluster/cluster/bin/
mysql -h vmclusterdev -P 3306 -u root

56 SQL Magazine Edio 136

Agora com um Cluster em funcionamento, seguiremos com

alguns testes bsicos de conectividade e uso. Como temos dois
SQL Nodes respondendo nas portas 3306 e 3307, podemos utilizar
qualquer um deles para manipular os dados do cluster via SQL.
Abra outros dois terminais e verifique a conectividade em ambas
as portas. Crie tabelas e insira linhas alternando as instncias para
verificar que o cluster sempre dar a mesma viso dos dados,
independente de qual SQL Node utilizado. As Listagens 3 e 4
exemplificam este teste.
Listagem 3. Teste de conectividade no terminal 2, porta 3306
$ ~/mysqlcluster/cluster/bin/mysql -h127.0.0.1 -P 3306 -u root
mysql> SELECT @@port;
+-------------+
| @@port |
+-------------+
| 3306
|
+-------------+
1 row in set (0.00 sec)
mysql> SHOW DATABASES;
+---------------------------------+
| Database
|
+---------------------------------+
| information_schema |
| mysql
|
| ndbinfo
|
| performance_schema |
| test
|
+--------------------------------+
5 rows in set (0.01 sec)
mysql> CREATE DATABASE meubd1;
Query OK, 1 row affected (0.01 sec)

O database meubd1 foi criado usando a instncia da porta 3306,

mas sua tabela t1 foi criada e populada usando a instncia da
3307. Se fizermos um SELECT * FROM meudb1.t1; em ambas as
instncias, o resultado ser o mesmo. O MySQL Cluster sempre
dar uma viso consistente dos dados.
Observe que a tabela foi criada usando ENGINE=NDBCLUSTER.
Isto garante que ser uma tabela que usa o Storage Engine NDB.
permitido usar outros Storage Engines, como o InnoDB, porm,
as tabelas que forem criadas de tal forma residiro apenas nas
instncias que foram criadas e no sero visveis nas outras instncias do cluster, pois no estaro nos Data Nodes.

Teste de alta disponibilidade

Para testar a capacidade de oferecer alta disponibilidade do
MySQL Cluster, ser criado um script simples que insere e consulta dados alternando entre SQL Nodes (Listagem 5) em um loop
infinito. Com o script em execuo, mataremos um dos Data Nodes
e, em seguida, um dos SQL Nodes. O cluster dever continuar
funcionando e os dados acessveis.
Listagem 4. Teste de conectividade no terminal 4, porta 3307
$ ~/mysqlcluster/cluster/bin/mysql -h127.0.0.1 -P 3307 -u root
mysql> SELECT @@port;
+------------+
| @@port |
+------------+
| 3307 |
+------------+
1 row in set (0.00 sec)
mysql> SHOW DATABASES;
+------------------------------+
|
Database
|
+------------------------------+
| information_schema |
| meubd1
|
| mysql
|
| ndbinfo
|
| performance_schema |
| test
|
+------------------------------+
6 rows in set (0.00 sec)
mysql> USE meubd1;
Database changed
mysql> CREATE TABLE t1 ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
origem VARCHAR(6), data TIMESTAMP ) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.23 sec)
mysql> INSERT INTO t1 VALUE (NULL,@@port,NULL);
Query OK, 1 row affected (0.01 sec)
Listagem 5. Script para inserir e consultar dados
#!/bin/bash
declare -a ports=(3306 3307)
while true; do
for i in ${ports[@]}; do
echo *** Escrita na instancia $i ***
~/mysqlcluster/cluster/bin/mysql -h127.0.0.1 -P $i -uroot -eINSERT INTO
meubd1.t1 VALUE (NULL,@@port,NULL);
done
for i in ${ports[@]}; do
echo *** Leitura na instancia $i ***
~/mysqlcluster/cluster/bin/mysql -h127.0.0.1 -P $i -uroot -eSELECT COUNT(*)
FROM meubd1.t1 ORDER BY id;
done
sleep 3
done

Em outro terminal, altere a permisso do arquivo com chmod

+x testeha.sh e execute o script com ./testeha.sh. Com o script
em execuo, abra outro terminal e, atravs do MCM, mate um
dos processos dos Data Nodes (ndbmtd) com o comando stop
process (Listagem 6). Verifique que o script continua sua execuo normalmente.

Listagem 6. Teste de alta disponibilidade do Data Node

$ ~/mysqlcluster/mcm1.3.6/bin/mcm
mcm> show status --process mycluster;
+-----------+-----------------+------------------+------------+----------------+---------------------+
| NodeId | Process
| Host
| Status | Nodegroup | Package
|
+-----------+-----------------+------------------+------------+----------------+---------------------+
| 49
| ndb_mgmd | vmclusterdev | running |
| mypackage
|
|1
| ndbmtd
| vmclusterdev | running | 0
| mypackage
|
|2
| ndbmtd
| vmclusterdev | running | 0
| mypackage
|
| 50
| mysqld
| vmclusterdev | running |
| mypackage
|
| 51
| mysqld
| vmclusterdev | running |
| mypackage
|
| 52
| ndbapi
|*
| added |
|
|
+-----------+-----------------+------------------+------------+----------------+---------------------+
mcm> stop process 1 mycluster;
+---------------------------------------+
| Command result
|
+---------------------------------------+
| Process stopped successfully |
+---------------------------------------+

Verificaremos agora o que acontece quando matamos um SQL

Node. Ainda no MCM, verifique qual o ID dos ns com o comando get port. Escolha uma das instncias para matar e use
novamente o comando stop process (Listagem 7). Verifique o
comportamento do script em execuo.
Listagem 7. Teste de alta disponibilidade do SQL Node
mcm> get port mycluster;
+--------+-------+------------+------------+--+
| Name | Value | Process1 | NodeId1 | ... |
+--------+-------+------------+------------+--+
| port | 3306 | mysqld | 50 | ... |
| port | 3307 | mysqld | 51 | ... |
+--------+-------+------------+------------+--+
mcm> stop process 50 mycluster;
+--------------------------------------+
| Command result
|
+--------------------------------------+
| Process stopped successfully |
+--------------------------------------+

O script continua sua execuo, inserindo e lendo dados na

instncia que no foi parada (Listagem 8). Numa situao mais
prxima da realidade, existir um mecanismo de load balancing
entre aplicao e SQL Node que pode ou no ser inteligente e detectar falhas de conectividade. Contudo, como vimos, mesmo que
no detecte, a aplicao dever continuar acessando sem problema
os dados atravs do n SQL ativo.
Se desejar, restaure os ns que foram parados com o comando
start process XX mycluster. Pare a execuo do script de testes
com Ctrl+C.
Observe que para termos uma alta disponibilidade total, o
Management Node tambm deve ter redundncia. Na verdade,
essa uma exigncia para evitar um ponto nico de falha em
ambientes produtivos.

Edio 136 SQL Magazine

57

Trabalhando com o MySQL Cluster

Listagem 8. Teste de alta disponibilidade verificado

*** Escrita na instancia 3306 ***
ERROR 2003 (HY000): Cant connect to MySQL server on 127.0.0.1 (111)
*** Escrita na instancia 3307 ***
*** Leitura na instancia 3306 ***
ERROR 2003 (HY000): Cant connect to MySQL server on 127.0.0.1 (111)
*** Leitura na instancia 3307 ***
+-------------+
| COUNT(*) |
+-------------+
| 126
|
+-------------+

Teste de escalabilidade horizontal

A possibilidade de adicionar mais ns online pode ser testada facilmente com o MCM. Ao adicionar mais Data Nodes, aumentamos
ao mesmo tempo a performance e espao de armazenamento. Ao
adicionar mais SQL Nodes, eliminamos gargalos de processamento
SQL e conexes simultneas. A adio de mais dois Data Nodes
demonstrada na Listagem 9.
Listagem 9. Teste de escalabilidade horizontal
mcm> add process --processhosts=ndbmtd:3@vmclusterdev,ndbmtd:4@vmclusterdev mycluster;
+------------------------------------+
| Command result
|
+------------------------------------+
| Process added successfully |
+------------------------------------+
1 row in set (2 min 46.32 sec)
mcm> show status --process mycluster;
+----------+----------------+------------------+------------+----------------+----------------+
| NodeId | Process
| Host
| Status | Nodegroup | Package
|
+----------+----------------+------------------+------------+----------------+----------------+
| 49
| ndb_mgmd | vmclusterdev | running |
| mypackage |
|1
| ndbmtd
| vmclusterdev | running | 0
| mypackage |
|2
| ndbmtd
| vmclusterdev | running | 0
| mypackage |
|3
| ndbmtd
| vmclusterdev | added | n/a
| mypackage |
|4
| ndbmtd
| vmclusterdev | added | n/a
| mypackage |
| 50
| mysqld
| vmclusterdev | running |
| mypackage |
| 51
| mysqld
| vmclusterdev | running |
| mypackage |
| 52
| ndbapi
|*
| added |
|
|
+----------+----------------+------------------+------------+----------------+----------------+
8 rows in set (0.01 sec)
mcm> start process --added mycluster;

Este processo relativamente mais lento e envolve a reinicializao dos demais ns do cluster, porm o MCM o far automaticamente e de maneira alternada (rolling restart), sem que haja
indisponibilidade para a aplicao. Acompanhando o script em
execuo, possvel notar que alguns nodes ficaro inacessveis
(alternadamente) por um curto perodo de tempo, mas a execuo
em si no afetada.
A adio de SQL Nodes pode ser testada pelo leitor de maneira
anloga. Erros so raros usando o MCM, porm certifique-se
de que h memria RAM disponvel antes do comando start
process. A remoo de ns pode ser realizada com o comando
remove process XX mycluster;.

58 SQL Magazine Edio 136

Como sugesto para continuar seus estudos, crie um cluster

mais prximo do que seria usado em ambiente de produo
com ns em mquinas separadas. Isto lhe dar uma melhor
viso sobre a operao do cluster e permitir realizar testes
de performance mais realistas. Com o mcmd (sem parmetro
bootstrap) em execuo em todos os hosts, use os comandos
create cluster e add process no mcm client para montar seu
cluster distribudo. O manual de referncia do MySQL Cluster
Manager est disponvel online (veja seo de Links) e possui
exemplos de utilizao destes comandos.

Limitaes e cuidados
Como vimos, o MySQL Cluster um verdadeiro banco
de dados distribudo ACID com arquitetura shared-nothing.
Esta arquitetura ao mesmo tempo que nos d uma enorme
flexibilidade, implica em algumas limitaes, uma vez que
os dados estaro distribudos e fragmentados entre ns
independentes e que podem estar fisicamente separados.
Porm, com alguns cuidados especiais, pode-se minimizar
ou eliminar tais limitaes, expandindo os cenrios de uso
do MySQL Cluster.
O melhor caso para usar o MySQL Cluster uma aplicao
nova ou em construo e que assemelha-se s descritas no
incio do artigo (Tabela 1). Portanto, inicie seu projeto com
um ambiente de desenvolvimento j com o MySQL Cluster. Se
alguma limitao impactar o uso, ela ser detectada e contornada antecipadamente e mais facilmente. Um dos principais
cuidados a serem tomados neste caso o dimensionamento
correto de memria RAM, definindo quais tabelas podero ser
disk-based e por quanto tempo os dados devero residir no
cluster. Sempre possvel adicionar mais ns para aumentar
a capacidade do cluster, porm uma poltica de reteno de
dados com perodo limitado e com estratgias de expurgo ou
arquivamento peridicos, uma boa maneira de fazer uso
inteligente de recursos.
Se a aplicao j existe, muito provavelmente sero necessrias algumas adaptaes e otimizaes de performance, tanto
na aplicao, quanto no banco de dados. Dependendo do seu
modelo de dados e da carga de trabalho, esta tarefa pode ser
bastante simples ou muito complexa. A imensa maioria das
consultas existentes vo continuar funcionando pois, os dados
so particionados automaticamente e de maneira transparente pelo Cluster, porm quase certo que seja necessrio
algum ajuste para melhorar a performance. Por exemplo,
reescrever algumas consultas e rotinas para evitar Full Table
Scans usando FORCE/USE INDEX, ANALYZE, Adaptive Query
Localization. Em casos mais extremos, talvez seja necessrio
revisar o modelo de dados, principalmente reduzindo o uso
de Foreign Keys e tipos BLOB ou TEXT. Outro caso que pode
exigir uma adaptao quando a aplicao faz uso de ndices
Full Text, que no so suportados pelo MySQL Cluster. Neste
caso, uma sada seria manter alguns dados de consulta em
InnoDB, lembrando que possvel misturar storage engines.

Edio 136 SQL Magazine

59

Trabalhando com o MySQL Cluster

O pior caso, onde o MySQL Cluster no recomendado,

para aplicaes empacotadas e no homologadas para MySQL
Cluster, onde no possvel fazer adaptaes na aplicao ou
no banco de dados.
Como toda soluo de alta disponibilidade, planejamento na
implantao essencial. Planeje a infraestrutura. Ser necessrio ter um checklist para verificar diversos aspectos, tais como:
especificao do hardware, redundncias da alimentao de
energia e interfaces de rede e switches, configuraes do sistema operacional e rede, testes de throughput e latncia da rede,
configurao e testes da soluo de load balancing, etc.
Tambm importante investir em processos e pessoas, ou
seja, a equipe que vai operar o cluster deve ter conhecimento
da soluo e capacidade de acessar canais de suporte, alm de
fazer uso de ferramentas para automatizar processos comuns
e evitar falhas humanas.
Como o MySQL Cluster est em franca evoluo, algumas
destas limitaes tendem a desaparecer em verses futuras.
No momento da escrita deste artigo, a verso corrente a 7.4.
Certifique-se de utilizar a verso estvel (GA) mais recente e
verificar se alguma limitao deixou de existir.
Finalmente, duas fontes valiosas de informao para entender
melhor as limitaes e workarounds so o Manual de Referncia, que conta com uma seo especfica sobre limitaes e o
MySQL Cluster Evaluation Guide (ver seo Links).

Autor
Airton Lastori
[email protected] - www.alastori.com.br
Airton Lastori consultor MySQL da Oracle Brasil. Possui formao em Cincia da Computao pela Universidade Federal
de Itajub e especializao em Engenharia de Software baseada em SOA
pelo IBTA. H mais de 10 anos est envolvido com diversas tecnologias
Open Source relacionadas principalmente ao universo Web.
Links:
Download do MySQL Cluster Manager
http://edelivery.oracle.com
Download do MySQL Cluster
http://dev.mysql.com/downloads/cluster
Manual de Referncia do MySQL Cluster
http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster.html
Manual de Referncia do MySQL Cluster Manager
http://dev.mysql.com/doc/mysql-cluster-manager/1.3/en/index.html
Frum MySQL Cluster
http://forums.mysql.com/list.php?25
MySQL Cluster Evaluation Guide
http://www.mysql.com/why-mysql/white-papers/mysql-cluster-evaluation-guide

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

60 SQL Magazine Edio 136

PostgreSQL distribudo
com PgPool-II
Saiba como aumentar a disponibilidade de seu
SGBD PostgreSQL criando uma soluo distribuda
baseada no PgPool-II

m sistema de banco de dados distribudo

pode ser entendido como um banco de dados
virtual, composto por diversos bancos de dados reais interligados fisicamente, atravs de vrios
meios como redes de alta velocidade, redes sem fio
ou linhas telefnicas. Normalmente, o usurio deste
sistema no sabe onde os dados esto localizados
fisicamente, caracterizando um sistema altamente
transparente.
Entretanto, os computadores em um sistema de banco dados distribudos no compartilham componentes
fsicos, como memria principal ou discos de armazenamento, podendo variar em tamanho e funo,
diferentemente de um sistema paralelo. A Figura 1
representa um sistema distribudo interligado por
uma rede de comunicao.
Neste sistema, o banco de dados armazenado em
diversos computadores, que so denominados como
clusters (ns). Cada cluster possui seu prprio
hardware e no compartilham nenhum componente
fsico. Diferente de um sistema paralelo, os clusters podem variar em tamanho e funo. Uma das vantagens
em utilizar um sistema distribudo em clusters sua
alta disponibilidade, uma vez que no desativamento
de um cluster, seja por problemas tcnicos ou qualquer
outro motivo, um outro cluster pode tomar para si as
requisies vindas pelas aplicaes.
Um sistema de banco de dados distribudo pode
ainda ser classificado de duas formas: sistemas Homogneos, onde todos os clusters do sistema rodam o
mesmo SGBD, conhecendo um ao outro e facilitando
o processamento das transaes; e, Sistemas Heterogneos, onde cada cluster roda um SGBD diferente,
muitas vezes limitando e dificultando o processo
de manipulao dos dados, alm de aumentar sua
complexidade.

Fique por dentro

O objetivo deste artigo apresentar a ferramenta PgPool-II, utilizada
para a criao de sistemas de banco de dados distribudo no SGBD
PostgreSQL atravs da instalao e configurao de um ambiente
de redundncia e de alta disponibilidade. Um sistema de banco de
dados distribudo capaz de oferecer diversas vantagens onde um
grande volume de dados e processamento utilizado, aumentando
o desempenho das aplicaes e oferecendo um ambiente descentralizado e de alta disponibilidade. Em um cenrio global onde o volume
de dados vem sendo cada vez maior em tamanho e importncia,
torna-se essencial que o banco de dados consiga oferecer agilidade
e segurana para o acesso dos dados.

Figura 1. Representao de um sistema distribudo

Formas de armazenamento de dados

Existem diversas formas com que um banco de dados distribudo
pode armazenar os dados, sendo as principais:
Replicao: onde o sistema mantm rplicas idnticas dos
dados entre seus diversos clusters, assegurando que todos os
servidores tenham o mesmo contedo durante todo o tempo.
Esta replicao pode ocorrer de forma sncrona ou assncrona.

Edio 136 SQL Magazine

61

PostgreSQL distribudo com PgPool-II

No caso da primeira, o contedo replicado imediatamente aps

uma transao, enquanto que na segunda, o servidor que est
recebendo a transao pode esperar por todo seu processamento
para depois enviar a modificao aos demais servidores. De modo
geral, a replicao dos dados tambm fornece maior desempenho
nas operaes de leitura, porm, as operaes de atualizao consomem maior recurso, pois h a necessidade de atualizar todos
os clusters do sistema. Na replicao sncrona, todos os clusters
possuem o mesmo nvel de responsabilidade e o contedo das
bases de dados idntico durante todo o tempo. J na replicao
assncrona, determinados clusters tm a responsabilidade de
repassar informaes aos demais, podendo as bases de dados
diferir em algumas circunstncias, como em uma insero ou
atualizao de dado;
Fragmentao: os dados so fragmentados e divididos entre os
clusters instalados. Assim, um cluster ser requisitado dependendo da informao a ser consultada. A fragmentao ainda pode
ser dividida em horizontal, onde cada fragmento criado a partir
da seleo de linhas ou vertical, onde cada fragmento criado a
partir do agrupamento de atributos.
Existem ainda sistemas com as duas caractersticas, onde seus
dados so fragmentados e estes fragmentos so replicados em
servidores diferentes.
Para demonstrar um ambiente de banco de dados distribudo
neste artigo, foram utilizados dois pequenos servidores para representar o hardware dos clusters. Cada servidor est configurado
com o sistema operacional Linux Fedora. Uma distribuio Linux
faz-se necessria porque a ferramenta PgPool-II suportada apenas por sistemas operacionais UNIX-like como Solaris, FreeBSD
e o prprio Linux. Desse modo, fica invivel a configurao de um
cluster com outro tipo de sistema. J para a criao do ambiente
distribudo, ser utilizada a ferramenta PgPool-II.

Ferramenta PgPool-II
O PgPool-II um projeto criado com o objetivo de suprir a
carncia de funcionalidades que o SGBD PostgreSQL possui,
principalmente na funcionalidade de balanceamento de carga.
Ele um software middleware que funciona em uma camada
entre um servidor do banco de dados PostgreSQL e um cliente,
proporcionando diversas funcionalidades, entre elas:
Pooling de conexo: armazena um nmero limitado de conexes
em um repositrio interno para serem utilizadas posteriormente
sempre que uma aplicao requisitar. Sua principal funo
otimizar o acesso ao banco de dados atravs da reutilizao de
conexes sempre que uma nova conexo com as mesmas propriedades for detectada. Quando o tamanho mximo de conexes
for alcanado, as requisies so enfileiradas para aguardar a
liberao de novas;
Replicao: mantm cpias idnticas de uma base de dados em
diferentes servidores PostgreSQL, chamados clusters. Atravs destas cpias, possvel criar um sistema tolerante a falhas, ligando e
desligando clusters a qualquer momento, uma vez que seus dados

62 SQL Magazine Edio 136

encontram-se replicados e por isso no afetam o comportamento

da aplicao. Utilizar a replicao tambm permite que sejam
criados backups em tempo real.
Balanceamento de carga: gerencia todos os clientes que esto
utilizando o servidor e distribui a carga de uso entre os clusters
disponveis. Desta forma, se vrios usurios necessitarem consultar o mesmo banco de dados simultaneamente, ocorrer uma
distribuio de acessos pelos clusters disponveis, garantindo
maior desempenho nas consultas. O balanceamento de carga pode
ocorrer de duas maneiras: a primeira delas dividindo uma query
em diversas partes (Query Paralela), a outra, particionar o nmero
de queries entre os servidores disponveis, cada um responsvel
por retornar o resultado ao usurio separadamente;
Query paralela: utilizada em grandes bases de dados, a query
paralela a possibilidade de dividir uma query em diversas partes, que so executadas em diversos servidores simultaneamente
e que, aps o processamento, so unidas em uma nica resposta.
Isso permite diminuir o custo e a carga no servidor. Porm, pode
ser muito custoso dependendo da largura da banda da rede;
Failover: procedimento realizado quando ocorre um erro com
algum cluster do sistema. O Pgpool elimina todos os processos
filhos e sesses em execuo, eliminando do sistema o cluster
onde ocorreu o problema, e reinicializando automaticamente
para continuar a receber novas conexes. Alm do Failover, o
Pgpool-II ainda pode ser configurado para realizar o Failback,
onde ele remapeia todos os clusters do sistema quando um novo
adicionado.
O middleware comunica-se com o servidor PostgreSQL, chamado de BackEnd, e a aplicao, chamada de FrontEnd. A aplicao
considera o PgPool-II como sendo o servidor PostgreSQL. J o
servidor considera que o PgPool-II um de seus clientes. Pelo
fato do PgPool-II ser transparente tanto para o servidor quanto
para o cliente, um banco de dados existente pode ser usado com
o PgPool-II praticamente sem mudana no seu cdigo fonte.
Para garantir a integridade da conexo com os servidores, o
PgPool-II utiliza um procedimento chamado de Health Check.
Atravs dele realizada uma tentativa de conexo com cada servidor para saber se ele continua disponvel na rede. Caso retorne
um erro, o PgPool-II tenta realizar um failover. Este procedimento
se comporta como um usurio comum no servidor de banco de
dados, por isso, precisa das prprias permisses para acessar o
servidor. Estas permisses podem ser configuradas no arquivo
postgresql.conf, alm de um nome de usurio e uma senha para
autenticao. Tambm podemos configurar o nmero de tentativas de conexo, assim como o tempo que cada tentativa pode
levar antes de retornar erro, que pode variar dependendo de
cada ambiente.
Outra caracterstica interessante presente no PgPool-II a possibilidade de configurar seu prprio cache em memria, armazenando queries (SELECTS) diretamente na memria para uma
maior agilidade em sua reutilizao. Ainda possvel configurar
o modo de armazenamento, que alm do cache em memria, pode

usar a memria compartilhada shared memory. A memria compartilhada utilizada em ambientes onde esto presentes vrias
instncias do PgPool-II, e garante a integridade do cache atravs
de seu compartilhamento.

como no PostgreSQL (que ocorre atravs do arquivo pg_hba.conf),

necessitando de outros meios externos para limitar os acessos.
Alm disso, h algumas limitaes ao manipular valores como
timestamp e serial no modo de replicao.

Modos de operao
De acordo com a documentao oficial, o PgPool-II pode operar
em cinco modos distintos: Raw Mode, Connection Pool Mode, Replication Mode, Parallel Mode e Master/Slave Mode.
No Raw Mode, ele configurado no front-end apenas para receber
a conexo de clientes que acessarem o servidor PostgreSQL, podendo desse modo limitar a quantidade de conexes simultneas
ao servidor, oferecendo tambm um ambiente de alta disponibilidade atravs do failover.
No Connection Pool, ele continua gerenciando as conexes dos
clientes ao servidor, porm, mantendo um pool de conexes
atravs da criao de vrios processos para poderem ser reutilizadas sempre que possvel, diminuindo a carga no servidor de
dados.
No Replication, ele replica as operaes em todos os servidores
conectados a ele criando um sistema de redundncia. Dessa forma,
caso algum servidor venha a ficar indisponvel, ele removido
pelo PgPool-II e o sistema no interrompido. Esta caracterstica
tambm conhecida como degenerao.
No Parallel, o PgPool-II divide as queries e as tabelas em diferentes servidores conectados ao sistema, aliviando dessa forma
a quantidade de dados armazenados nos servidores. Como o
SGBD PostgreSQL no suporta este tipo de arquitetura de queries
paralelas, o Pgpool-II na verdade acaba utilizando o conceito de
fragmentao horizontal, que considerada um tipo de query
paralela.
J o modo Master/Slave utilizado em conjunto com outro sistema de replicao Master/Slave, como por exemplo o Slony. Nesse
modo, as operaes do banco de dados so enviadas a um servidor
principal (Master) e ele responsvel por envi-las aos demais
servidores (Slaves) quando possvel.
O PgPool-II fornece uma interface de controle chamada de pcp,
em que o administrador pode gerenciar o status do pgpool-II
alm de poder controlar processos remotamente. Todos os modos
de operao requerem que o pcp esteja configurado para serem
operados.
A arquitetura do PgPool-II formada por (ver Figura 2):
um SQL Parser, que tem a funo de validar e analisar todas as
queries vindas das aplicaes;
um SQL Rewriter, que responsvel por reescrever queries em
determinados casos, como na execuo de queries paralelas, e;
um motor de execuo, ou engine, que responsvel por enviar
informaes e manipular os demais clusters do sistema.
O Pgpool-II uma ferramenta robusta. Entretanto, algumas
limitaes ocorrem em sua utilizao como a impossibilidade
de realizar o balanceamento de carga com queries paralelas no
modo Master/Slave, impossibilidade de autenticao por host

Figura 2. Arquitetura do PgPool-II

Apesar de ter um modo de replicao funcional, ele ainda possui
algumas limitaes se comparado com outras ferramentas como
Slony-I. Isto faz com que ele deva ser operado com bastante cautela, uma vez que suas bases de dados podem ser corrompidas
ou desatualizadas por causa de alguma configurao feita de
forma incorreta.

Watchdog
possvel tambm coordenar um sistema de alta disponibilidade constitudo de vrios Pgpool-IIs atravs de um processo
chamado watchdog. Ele pode monitorar os sistemas trocando
informaes atravs de dois mtodos: Modo Hearthbeat ou
Modo Query.
No modo Hearthbeat, o watchdog monitora os demais processos
do pgpool-II enviando sinais frequentes atravs da rede garantindo que a outra ponta esteja sempre operacional. Caso algum
sinal enviado no retorne nada por algum tempo, o watchdog
interpretar isto como sendo um ponto de falha e informar a
ocorrncia.
No modo Query, o watchdog realiza o monitoramento enviando queries aos demais servios Pgpool-II, verificando assim sua
resposta. Apesar de funcional, este modo pouco utilizado e j
encontra-se depreciado.
Alm de monitorar os demais processos, o Watchdog tambm
pode monitorar os servidores de aplicao. Ele pode ser configurado pelo arquivo de configuraes pgpool.conf, informando qual
ser seu hostname, porta e chave de autenticao.

Viso geral de um ambiente distribudo

Para exemplificar um ambiente distribudo neste artigo, ser
considerada uma rede com dois servidores que sero utilizados
para hospedar o middleware Pgpool e os servidores de banco
de dados (clusters). O PgPool-II no necessita obrigatoriamente
de um servidor prprio, podendo ser hospedado junto a outro

Edio 136 SQL Magazine

63

PostgreSQL distribudo com PgPool-II

cluster, mas prefervel um servidor dedicado afim de desacoplar o ambiente e manter um maior controle sobre o sistema.
A Figura 3 mostra a disposio de um ambiente distribudo com
PostgreSQL.

O arquivo pg_hba.conf, que responsvel pela configurao de

autenticao dos clientes PostgreSQL, controla quais hosts so
permitidos, mtodos de autenticao, nomes de usurios e quais
databases podem ser acessados. Tambm necessrio configurar
o servidor para escutar endereos externos e sua porta de acesso
editando o arquivo postgresql.conf. Essa configurao deve ser
feita para todos os clusters do sistema.

Instalao e Configurao do PgPool-II

Figura 3. Sistema com banco de dados distribudo com o PostgreSQL

O download do PgPool-II pode ser realizado atravs de sua

pgina de downloads (ver seo Links). Alm disso, possvel
tambm consultar uma detalhada documentao com tudo que
preciso para dominar a ferramenta.
Para realizar a instalao do Pgpool-II, primeiro necessrio
compilar seu cdigo fonte. Ele requer o gcc (Compiler Collection)
na verso 2.9 ou superior, GNU make e a biblioteca libpq. Porm,
antes de realizar a instalao, necessrio executar seu script de
configurao, que coleta informaes do sistema e o local onde
esto instaladas as bibliotecas do PostgreSQL. O comando make
compila o cdigo fonte e o comando make install instala todos
os executveis:
$./configure --with-pgsql=/var/lib/

O middleware responsvel por receber todas as conexes

externas dos clientes e ento acessar uma das bases de dados
disponveis para realizar consultas. Os clientes conectam ao
middleware atravs da porta padro do PgPool-II 9999, que por
sua vez se conecta aos demais bancos de dados pela porta padro
do PostgreSQL 5432. Desse modo, o arquivo de configurao no
mais se conecta a um servidor PostgreSQL diretamente.
O primeiro cluster, nomeado Cubie1, responsvel por
armazenar uma das bases de dados do sistema. Cada cluster
possui uma rplica da base de dados que gerenciada pelo middleware. Desse modo, a cada nova alterao realizada, todas
as bases de dados recebem a instruo para se atualizarem.
O Cubie1 tambm responsvel por hospedar o middleware, por
esse motivo, ambos possuem o mesmo endereo na rede. O ideal
ele ficar em seu prprio hardware desvinculado de qualquer
base de dados. Porm, por motivos de praticidade, ele pode ser
instalado juntamente a um dos clusters, sendo necessrio apenas que se configure portas diferentes para o pgpool-II e para
o servidor PostgreSQL.
O segundo cluster, nomeado Cubie2, tambm responsvel
por armazenar uma das bases de dados. Ele foi configurado para
ser acessado somente atravs do middleware, rejeitando qualquer
outro endereo de conexo, como visto na Figura 4.

$make

Figura 4. Configurao dos arquivos pg_hba.conf e postgresql.conf

Figura 5. Configurao do Arquivo pgpool.conf

64 SQL Magazine Edio 136

$make install

O diretrio padro do pgpool /usr/local/. Ao trmino do

processo, necessrio configurar o pgpool-II, conforme visto
na Figura 5. Seus parmetros de configurao so salvos no
arquivo pgpool.conf. Por padro, ele vem configurado para
aceitar apenas conexes locais usando a porta 9999. Por isso,
o parmetro listen_addresses deve ser editado para receber
conexes externas.
Tambm pelo pgpool.conf, possvel configurar a porta pela
qual o pcp se conectar ao sistema que, por padro, a porta 9898.

O PCP uma interface controladora que possui diversas funes

que podem coletar informaes do pgpool-II e dos clusters, terminar processos remotamente, alm de poder atar e desatar ns.
Para utilizar a interface pcp, necessria uma autenticao com
usurio e senha diferentes dos usados para acessar o PostgreSQL.
Ela deve ser definida no arquivo pcp.conf, conforme Figura 6.
A senha deve ser criptografada em um formato hash md5, que
pode ser obtida atravs do executvel pg_md5 instalado junto
com o pgpool-II.

Aps a configurao do PCP, necessrio configurar os clusters

onde esto instalados os servidores PostgreSQL. Para este artigo,
foram utilizados dois clusters que devem ser identificados como
backend0 e backend1, sendo preciso configurar o host, porta,
peso, diretrio dos dados e comportamento de cada cluster.
O host o endereo na rede onde se encontra o cluster, a porta
por onde o servidor se comunica, o peso define a prioridade que
cada cluster ter caso haja um balanceamento de carga, o diretrio
de dados onde est localizada a pasta de dados do PostgreSQL,
e o comportamento define o que o cluster far em determinadas
situaes. A Figura 7 exibe o arquivo pgpool.conf com os clusters
configurados.
Agora basta configurar os demais parmetros do arquivo pgpool.
conf para satisfazer o sistema. Para o caso de um sistema de replicao com balanceamento de carga, o atributo replication_mode
e load_balance_mode devem ser definidos como true. Isso
permitir a distribuio automtica das queries do tipo SELECT
para cada cluster a fim de balancear a carga do sistema.
Para o balanceamento de carga ocorrer, necessrio que alguns
requisitos sejam cumpridos:
A verso do PostgreSQL deve ser a 7.4 ou superior;
O modo de operao do Pgpool-II deve ser replicao ou master/slave;
A query no deve estar em um bloco de transao;
A query no seja um SELECT INTO, SELECT FOR UPDATE
ou FOR SHARE.

Para iniciar o PgPool-II, necessrio executar o comando:

Figura 6. Configurao do autenticador pcp

$ pgpool n d > /arquivo_log.log

No comando, a opo n no
executa o processo como um daemon, deixando o terminal aberto.
A opo d habilita as mensagens
de log no arquivo indicado. Diversas outras opes podem ser
utilizadas como c para limpar o
cach e -f/-a/-F para especificar os
arquivos de configurao (pgpool.
conf, pool_hba.conf e pcp.conf
respectivamente).
Antes de iniciar o PgPool-II,
importante verificar se todos
os servidores backend esto em
operao.

Comandos PCP

Figura 7. Configurao dos Clusters no arquivo pgpool.conf

Os comandos PCP so utilizados

para gerenciar o Pgpool-II atravs
da rede. Alm do PCP, ele tambm
pode ser gerenciado por comandos

Edio 136 SQL Magazine

65

PostgreSQL distribudo com PgPool-II

Comando

Finalidade

pcp_node_count

Exibe o nmero total de clusters definidos no arquivo pgpool.conf. Todos so considerados, tanto os ativos quanto os
inativos.

pcp_node_info

Exibe a informao de determinado cluster atravs de seu ID. Ele retorna o status do cluster que pode ser:
1 para ativo, mas sem conexes;
2 para ativo e sendo utilizado no momento, e;
3 para desligado.

pcp_attach_node/pcp_detach_node

Conecta/Desconecta um cluster ao sistema. Caso o cluster esteja ativo, ele forado a desligar.

pcp_stop_pgpool

Termina o processo do PgPool-II.

pcp_proc_count

Exibe a lista de processos do PgPool-II separados por um espao em branco.

pcp_proc_info

Exibe as informaes sobre cada processo.

pcp_pool_status

Exibe os parmetros configurados no arquivo de configurao pgpool.conf.

pcp_detach_node

Retira um cluster do sistema.

pcp_attach_node

Adiciona um novo cluster no sistema.

pcp_promote_node

Configura um novo cluster para ser o Master.

Tabela 1. Lista de alguns principais comandos PCP

SQL onde o Pgpool-II faz uma interceptao procurando por
comandos especficos como pool_status, pool_nodes, entre
outros.
J no console PCP, os comandos so interpretados diretamente
do terminal. Cada comando pcp recebe um mnimo de cinco argumentos bsicos que so o Timeout, hostname, PCP Port,
PCP user e PCP password. Alguns dos principais comandos
so listados na Tabela 1.
Desse modo, utilizando o terminal PCP, possvel conectar um
novo n ao sistema passando seu ip:

A ferramenta middleware PgPool-II proporciona um confivel

ambiente para o desenvolvimento de sistemas de banco de dados
distribudo em servidores PostgreSQL, estendendo suas funcionalidades e oferecendo opes para replicao e fragmentao de
dados, controle de conexes, balanceamento de carga, alm de
uma interface prtica e simples para fins administrativos.

Autor
Luis Eduardo de Oliveira Floriano
[email protected]
Graduado em Banco de Dados e Especialista em Desenvolvimento de Sistemas Web e Mobile. Atua como Desenvolvedor
Java, possuindo experincia com banco de dados relacionais, banco de
dados distribudos, PostgreSQL, Oracle e MySQL.

$pcp_attach_node d 10 192.168.1.30 9898 postgres postgres 1

Todos os comandos PCP possuem um nmero de cinco argumentos em comum:

1. o tempo mximo em segundos que o comando pode levar para
ser executado, abortando-o caso seja ultrapassado;
2. o nome do host em que o Pgpool-II foi configurado;
3. a porta em que o Pgpool-II est escutando;
4. o usurio de autenticao que foi configurado no arquivo pcp.
conf e;
5. a senha de acesso.
Utilizar um sistema de banco de dados tornou-se indispensvel.
Porm, o acentuado crescimento do volume de dados, especialmente em grandes empresas, acaba afetando o desempenho na
consulta destes dados. Utilizar um sistema distribudo pode
auxiliar neste cenrio.

66 SQL Magazine Edio 136

Links:
Pgina de Downloads do PgPool-II
http://pgpool.net/mediawiki/index.php/Downloads
Documentao Oficial do PgPool-II
http://www.pgpool.net/docs/latest/pgpool-en.html

Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/sqlmagazine/feedback
Ajude-nos a manter a qualidade da revista!

Edio 136 SQL Magazine

67

PostgreSQL distribudo com PgPool-II

68 SQL Magazine Edio 136