SQL Magazine 13665676577592

8/18/2019 SQL Magazine 13665676577592

1/68

8/18/2019 SQL Magazine 13665676577592

2/68

8/18/2019 SQL Magazine 13665676577592

3/68

Sumário

A SQL Magazine tem que ser feita ao seu gosto. Paraisso, precisamos saber o que você, leitor, acha darevista!

Dê seu voto sobre esta edição, artigo por ar tigo, atra-vés do link:

www.devmedia.com.br/sqlmagazine/feedback

D ê

s e u

F eedb a c k

s o b r e

e s

t a e d i ç ã o

Dê seu feedback sobre esta edição!52 – Trabalhando com o MySQL Cluster[ Airton Lastori ]

Artigo no estilo Solução Completa

61 – PostgreSQL distribuído com PgPool-II[ Luis Eduardo de Oliveira Floriano ]

Artigo no estilo Solução Completa

Artigo do estilo Solução Completa

44 – Trabalhando com MemSQL[ Rodrigo Salvo ]

Conteúdo sobre Boas Práticas

36 – Paralelismo no SQL Server[ Luciano Moreira ]


28 – Monitoramento automatizado o SQL Server[ Jonatas dos Anjos ]


22 – Dominando os índices columnstore[ Weslley Moura e Emerson Silva ]


16 – Manipulação de arquivos de dados e log no SQL Server[ Robson Moraes ]


06 – Um modelo OLAP para visualização de informações de builds automáticos[ Mauro Pichiliani ]

8/18/2019 SQL Magazine 13665676577592

4/68

136ª Edição - 2015 - ISSN 1677918-5 - Impresso no Brasil

Editor

Rodrigo Oliveira Spínola ([email protected])

Subeditor

Eduardo Oliveira Spínola

Consultor Técnico

Diogo Souza ([email protected])

Jornalista Responsável

Kaline Dolabella - JP24185

Capa e DiagramaçãoRomulo Araujo

Distribuição

FC Comercial e Distribuidora S.A

Rua Teodoro da Silva,907

Grajaú - RJ - 206563-900

Fale com o Editor!

É muito importante para a equipe saber o que você está achando darevista: que tipo de artigo você gostaria de ler, que artigo você maisgostou e qual artigo você menos gostou. Fique a vontade para entrarem contato com os editores e dar a sua sugestão!Se você estiver interessado em publicar um artigo na revista ou no siteSQL Magazine, entre em contato com os editores, informando o título emini-resumo do tema que você gostaria de publicar:

Rodrigo Oliveira Spínola - Editor da Revista

[email protected]

RODRIGO OLIVEIRA SPÍNOLA

Editor Chefe da SQL Magazine, Mobilee Engenharia de Software Magazine.

Professor da Faculdade Ruy Barbosa,

uma instituição parte do Grupo DeVry.

Doutor e Mestre em Engenharia de

Software pela COPPE/UFRJ.

Assine agora e tenha acesso atodo o conteúdo da DevMedia:www.devmedia.com.br/mvp

Atendimento ao leitorA DevMedia possui uma Central de Atendimento on-line, onde vocêpode tirar suas dúvidas sobre serviços, enviar críticas e sugestões efalar com um de nossos atendentes. Através da nossa central tambémé possível alterar dados cadastrais, consultar o status de assinaturase conferir a data de envio de suas revistas. Acesse www.devmedia.com.br/central, ou se preferir entre em contato conosco através dotelefone 21 3382-5038.

Publicidade [email protected] – 21 3382-5038

Anúncios – Anunciando nas publicações e nos sites do Grupo DevMedia,você divulga sua marca ou produto para mais de 100 mil desenvolvedoresde todo o Brasil, em mais de 200 cidades. Solicite nossos Media Kits, comdetalhes sobre preços e formatos de anúncios.

EXPEDIENTE

8/18/2019 SQL Magazine 13665676577592

5/68

8/18/2019 SQL Magazine 13665676577592

6/68

Um modelo OLAP para visualização de informações de builds automáticos

6 SQL Magazine • Edição 136

Este artigo é útil por ensinar como elaborar um modelo multidi-

mensional para a visualização de informações geradas por processos

de build, geralmente compostos por várias ações e etapas. A partir

do modelo sugerido pode-se modificar as entidades, dimensões,

hierarquias, membros, atributos, medidas e relacionamentos para

adequar a estrutura de acordo com outras características associadas

à visualização das informações geradas, independente da ferramentade build utilizada. A implementação do modelo descrito no artigo

pode ser feita em qualquer ferramenta OLAP que suporte um mo-

delo multidimensional e possua uma interface para consultas que

filtrem os dados das medidas de acordo com os níveis e membros

das dimensões.

Fique por dentro

Um modelo OLAP para

visualização de informaçõesde builds automáticosVeja neste artigo um modelo multidimensionalpara visualização de informações geradas pelo

build automático de um projeto Java

Odesenvolvimento de software profissional contacom diversas etapas. Dentre as principais, po-demos destacar o processo de build, ou seja,o passo onde é necessário realizar diversas ações paraproduzir uma versão do software. Este processo podeser composto de ações automáticas ou manuais como,por exemplo, compilação, empacotamento, realização detestes, checagem de dependências e outras atividades

necessárias para completar o build.É comum que empresas preocupadas com a qualidade

de desenvolvimento e produção de software invistamem tornar o processo de build automático e adequadopara gerar todos os artefatos necessários para lançaruma nova versão do software. Isso implica em diversasverificações, chamadas de softwares externos, checagemde padrões de desenvolvimento, geração de documenta-ção e tarefas de deploy que, se realizadas manualmente,certamente consumiriam muitos recursos humanos epossuiriam alta probabilidade de falhas. Portanto, amaioria das equipes de desenvolvimento tem como uma

das prioridades iniciais de seus projetos a automação doprocesso de build.

A execução automática de processos de build geradiversos dados importantes que devem ser analisadostanto pelos membros técnicos da equipe quanto pelogerente de projeto, pois esta análise vai fornecer indi-cadores de como anda a qualidade do projeto e outrosaspectos relevantes. Contudo, ainda são poucos os sis-temas que fornecem estas informações produzidas peloprocesso de build automático em um formato analíticoque suporte tomadas de decisão e permita o acompanha-mento quantitativo e qualitativo do desenvolvimento do

software como um todo.

A partir deste cenário, este artigo apresentará como montar ummodelo multidimensional que se baseia nos dados gerados por umprocesso de build incluindo o tipo, resultado, plataformas suporta-das, usuários, commits, bugs e outras entidades. O modelo descrito

neste artigo é multidimensional e pode ser implementado em ban-cos de dados relacionais e visualizado com qualquer ferramentaque utilize a tecnologia OLAP (OnLine Analytical Processing), como objetivo de apresentar as informações agregadas em formatosadequados para análises e suporte à tomada de decisões táticas eestratégicas. O modelo conta com diversas entidades que abordamos principais aspectos relacionados às etapas, ações e verificaçõesrealizadas durante o processo de build automático.

Apesar de contemplar diversas características de um processode build de software t ípico, o modelo apresentado neste artigo érazoavelmente simples e pode ser adaptado a diferentes t ipos deprojetos que utilizam build automático de acordo com os requi-

sitos e cenários de utilização. As entidades do modelo são criadas

8/18/2019 SQL Magazine 13665676577592

7/68Edição 136 • SQL Magazine 7

para a visualização dos dados em um modelo multidimensional.Contudo, o artigo não detalha como obter as informações queforam armazenadas nestas entidades, pois tais informações sãodependentes dos formatos de dados específicos de cada projeto

e das ferramentas utilizadas para o build.

Funcionamento do build automáticoPara começar a compreender o cenário no qual vamos nos basear

para montar o modelo, é preciso primeiro estudar um pouco asações e dados gerados por um build automático a partir de umcenário que demonstre o que é tipicamente feito neste processo.Como atualmente existem diversas informações e maneirasdiferentes de apresentar tais informações, faz sentido delimitaro escopo e escolher um tipo de build e ferramentas comuns quepossam ser utilizadas como cenário para a elaboração e detalha-mento dos dados com os quais precisamos trabalhar.

O cenário no qual vamos nos basear para criar o modelo dedados utiliza uma plataforma de desenvolvimento Java que ge-ralmente emprega ferramentas como Ant, Maven ou Gradle paraautomatizar o processo de build de projetos, sejam eles projetospara aplicações desktop, para a Web ou até mesmo para o desen-volvimento mobile para a plataforma Android.

Quando um build é iniciado, ele requer algumas informaçõesimportantes, tais como o tipo de build, o local de armazenamentodos arquivos gerados e parâmetros de compilação. São estas in-formações que vão indicar quais ações precisam ser feitas. Tiposcomuns incluem “Compilação”, “Empacotamento”, “Clean” e“Completo”. Cada um deles possui diversas características e

pode conter ações que vão determinar o que efetivamente seráfeito. Por exemplo, o build “Compilação” apenas compila o códigofonte em Java para verificar se houve alguma mensagem retor-nada pelo compilador, ao passo que “Clean” limpa os diretóriosnecessários para o build e remove quaisquer arquivos geradospelo build anterior.

Builds automáticos geralmente produzem uma nova versão dosoftware, seja ela uma versão interna ou que será disponibilizadapara os usuários finais. De qualquer forma, cada build deve es-pecificar 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 informações são especialmente importantespara projetos que suportam muitas plataformas, onde toda a ge-ração de artefatos é controlada por um único processo de build.

Ao término de cada execução do build, uma nova versão dosoftware é gerada. Esta versão deve conter uma numeração(1.2.0.1, 1.3.3.2, etc.), o tipo de versão (“RTM”, “Debug”, “Beta”,“Release”) e também qual é a edição do software em relação àssuas funcionalidades e formato de utilização (“Free”, “Trial”,“Premium”, “Enterprise”, “Standard”, etc.). Assim como outrosexemplos de dados, os valores para os elementos apresentadosneste parágrafo são apenas sugestões e durante a implementaçãodo modelo o leitor pode colocar valores que façam sentido para

o seu contexto.

Os projetos de software que utilizam a plataforma de desenvolvi-mento Java geralmente são compostos por diferentes componentesexternos, como bibliotecas, frameworks ou qualquer outro tipo dedependência. Deste modo, os processos de build se encarregam

também de checar se as dependências estão corretas e atualiza-das para que o processo não “falhe”. A propósito, um build que“falha”, ou seja, não consegue realizar as tarefas necessárias paraser classif icado como um “sucesso”, representa uma importanteinformação.

A definição de “falha” ou “sucesso” de um build é especificadapor uma série de diretrizes condicionais criadas pela equipe dedesenvolvimento e varia muito para cada projeto. Por exemplo,é comum encontrar regras do tipo: “se o código fonte não passarem determinado número X de testes, o processo de build falha”. Omodelo deste artigo considera apenas o resultado do build e tam-

bém quais testes são associados a ele, sem detalhar o tipo de teste

(testes unitários, testes de interface, testes de integração, etc.).Outro aspecto importante que deve ser considerado é a quanti-dade de código fonte novo ou modificado em relação ao último

build. É comum que este dado seja indicado pelos commits (ocódigo fonte novo ou modificado enviado para um sistema decontrole de versão) realizados pelos desenvolvedores desde oúltimo build. Também é um dado importante a identificação dosdesenvolvedores que produziram os commits.

A realização de um build automático normalmente é associadaa algum tipo de objetivo alcançado no projeto ou a uma etapa doprocesso de desenvolvimento. Por exemplo, é comum a geraçãode um build quando um Sprint é finalizado, pois ao final deste

ciclo curto tradicional em processos de desenvolvimento ágil,geralmente é necessário distribuir ou disponibilizar o softwarepara os usuários finais.

Por fim, como todo software pronto ou em desenvolvimentopossui bugs, é muito importante apresentar esta informaçãosempre que uma nova versão do software é produzida. Forneceras informações de bugs junto com o processo de build é útil paraajudar a acompanhar a evolução da qualidade do software deforma quantitativa e qualitativa, auxiliando assim a tomada dedecisões que podem impactar o projeto.

Diversas outras informações relacionadas ao processo de buildautomático podem ser inseridas como, por exemplo, resultado de

ferramentas de checagem estática de código (PMD, CheckStyle eFindBugs), relatório da documentação técnica gerada, lista de re-quisitos e user stories atendidas pelo build, problemas encontradosno projeto e até diagramas e documentos gerais. Contudo, para nãotornar o modelo demasiadamente complexo, este artigo contemplaapenas as informações relacionadas ao cenário descrito nos pará-grafos anteriores. Fica como recomendação ao leitor customizar omodelo de acordo com os dados relacionados ao seu processo de

build automático, de modo a facilitar a visualização, exploraçãoe descoberta de fatos relevantes a partir dos dados.

Novamente, o foco do artigo é apenas no modelo de dados e nãoem como realizar o processo de ETL que obtém as informações de

diferentes fontes de dados (arquivos texto, código fonte, resultado

8/18/2019 SQL Magazine 13665676577592

8/68



da execução de ferramentas externas, mensagens do compilador,etc.) e as consolida em um data warehouse. Vale a pena destacarque tal processo de ETL pode ser complexo e demandar muitosrecursos, dependendo do nível de detalhamento, da frequência

de atualização e das características da informação que se desejaobter.Sendo assim, o próximo tópico detalha as dimensões e suas

características, as tabelas do modelo multidimensional e as me-didas utilizadas para a geração da ferramenta que permitirá avisualização de informações associadas com o processo de buildautomático.

Modelagem das dimensões e medidasO modelo multidimensional utilizado no exemplo será criado a

partir da especificação de dimensões, hierarquias, níveis, membros e também das medidas util izadas para visualizar os dados

dos relatórios em um ou mais cubos de dados. A modelagemadotada é conhecida como híbrida, pois ela mistura o designestrela (star) e floco-de-neve (snowflake). Dito isso, inicialmenteapresentaremos as dimensões e depois mostraremos como estasdimensões estão relacionadas com a tabela fato e as medidas doscubos de dados.

A primeira dimensão que será especificada é a dimensão quearmazena qual é o tipo de build. Este tipo geralmente está arma-zenado em um arquivo de configuração XML e deve ser indica-do como parâmetro para a execução automática do build. Estadimensão se chamará TipoBuild e seus atributos incluem umidentificador do tipo (ID_TIPO_BUILD), o nome do tipo (TIPO) e

uma descrição sem limite de texto utilizada como propriedadedos membros da dimensão (DESCRICAO). Os dados desta dimen-são são organizados em uma hierarquia simples, que agrupa osdados de acordo com o tipo de build. A Figura 1 mostra a tabelaDM_TIPO_BUILD, que implementa a dimensão e também umexemplo de dados dentro da hierarquia.

Figura 1. Tabela DM_TIPO_BUILD da dimensão TipoBuild e exemplo de navegação na dimensão

Um processo de build automático geralmente possui apenas doisresultados de acordo com as diretrizes condicionais criadas pelaequipe de desenvolvimento: sucesso ou falha. Além de indicar oresultado, também é interessante indicar se o resultado foi parcialou completo. Por exemplo, um build cujo processo passou nasetapas de compilação e testes pode ser considerado um sucessoparcial se houve algum problema na etapa de geração de docu-

mentação. De forma semelhante, um build onde o processo de

compilação falhou, mas passou em todos os testes unitários podeser uma falha parcial.

A dimensão 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 informação sobre o quão completo foio resultado (“Completo” ou “Parcial”). A hierarquia tambémapresentará informações sobre a causa apenas nos builds clas-sificados como parciais. Por fim, haverá um atributo indicandoinformações adicionais como, por exemplo, detalhes do códigofonte que causou a falha do build.

A dimensão Resultado é implementada na tabela DM_RESUL-TADO e conta com um detalhe importante em relação aos tipos dedados. Para a coluna que armazenará o tipo de resultado (“Suces-so” ou “Falha”), utilizaremos dados caracteres do tipo de dadosVARCHAR(15). Já para armazenar se o resultado é completo ou

parcial, util izaremos um tipo de dados BIT, cujo valor 0 indicará“Parcial” e o valor 1 indicará “Completo”.A decisão do tipo de dados utilizado na modelagem é específica

para cada projeto de acordo com a variedade dos dados e outrosfatores. Neste modelo optamos por escolher dois tipos de dadosdiferentes com fins didáticos e para mostrar que é possível utili-zar tipos de dados caractere ou bit como membros da dimensão.Caso o tipo bit seja escolhido, é preciso montar uma expressãoque traduza o valor 0 como “Parcial” e o valor 1 como “Completo”.A Figura 2 apresenta a tabela DM_RESULTADO junto com exem-plos de navegação na dimensão com o objetivo de filtrar os dadosde acordo com os diferentes tipos de resultado do build.

Figura 2. Tabela DM_RESULTADO da dimensão Resultado e exemplos de navegação na hierarquia

Um processo de build automático finalizado com sucesso nor-

malmente gera uma nova versão do software. Este versionamentoé associado com o tipo da versão (“Debug”, “Release”) e com otipo da edição (“Trial”, “Free” e “Enterprise”). As informações deversão e edição do software são relacionadas ao tipo do build etambém ao resultado, porém, neste artigo uma dimensão separadachamada Versao armazenará os dados de tipo da versão e da edi-ção. O motivo é que tanto a edição quanto a versão normalmentesão representadas pelo número da versão quando o processode build é finalizado e, desta forma, as pesquisas relacionadasao software final podem ser feitas consultando uma dimensão

específica.

8/18/2019 SQL Magazine 13665676577592


A tabela DM_VERSAO implementa a dimensão Versao econtém colunas para armazenar o tipo, a edição e o número.É importante destacar que a documentação do projeto devedeixar claro o critério para o incremento da versão, pois nem

todo build precisa necessariamente gerar um novo númeropara o software. Nesta mesma documentação também é precisoespecificar o que diferencia uma edição do software de outraatravés da lista de funcionalidades, preço, período de duraçãoou características, tais como a apresentação de propagandas.Estes detalhes de documentação ficam fora do modelo de dados,que apenas apresenta o nome da edição, o número e o seu t ipo.A Figura 3 mostra a tabela DM_VERSAO junto com exemplosde navegação na hierarquia.

Figura 3. Tabela DM_VERSAO da dimensão Versao e exemplos de navegação na hierarquia

Do ponto de vista de organização e gerenciamento, é comumassociar a geração de um build a um marco importante do projetorelacionado aos requisitos do software. O modelo multidimensio-nal que estamos criando faz esta associação através da dimensãoSprint , pois ela vai armazenar detalhes do ciclo em que o buildfoi gerado. No nosso cenário, o build pode ser gerado enquantoum Sprint está em andamento ou imediatamente após o seu tér-mino. Portanto, a hierarquia desta dimensão vai conter um nívelque indicará se o build foi gerado enquanto um Sprint estava emandamento ou logo após ele ter sido finalizado. O próximo nível

armazenará o nome e também informações adicionais em umacoluna de texto livre, com detalhes sobre as user stories atendidaspor este ciclo.

Como o objetivo principal do modelo é disponibilizar infor-mações sobre o build, não serão detalhados aspectos do Sprinte outras informações gerenciais relacionadas ao andamento doprocesso de desenvolvimento adotado. Novamente, o leitor quedesejar incluir tais informações no modelo pode customizaras dimensões ou mesmo criar suas próprias para atender seusrequisitos relacionados à apresentação dos detalhes do processode desenvolvimento.

A dimensão Sprint é implementada na tabela DM_SPRINT e

contém um identificador único, a coluna do tipo BIT para indicar

quando o build foi feito em relação ao ciclo (0 = Em andamentoe 1 = Logo após o término), o nome do Sprint e uma coluna detexto livre para armazenar as user stories tratadas pela equipe dedesenvolvimento. A tabela DM_SPRINT junto com exemplos de

navegação em sua hierarquia é apresentada na Figura 4.

Figura 4. Tabela DM_SPRINT da dimensão Sprint e exemplo de navegação na hierarquia

A próxima dimensão do modelo armazena informações sobre aplataforma e empacotamento do(s) arquivo(s) binário(s) gerado(s)pelo processo de compilação. Estas informações são importantes,pois elas ajudam a identificar, entre outros aspectos, se a frequênciade geração de versões está sendo uniforme ou não entre as diferen-tes plataformas e arquiteturas nas quais o projeto deve atender.

A dimensão Plataforma deve armazenar em sua hierarquiaqual é o sistema operacional alvo dos arquivos binários (“Todos”,“Windows”, “Linux”, “iOS”, etc.) e também a identificação de qualarquitetura de processador (“32 bits - x86”, “64 Bits - x64”, “ARM”,“Geral”), uma vez que estas informações são importantes para

o processo de deploy da versão do software. Depois da escolhadestas duas informações, sistema operacional e plataforma, épreciso identificar qual é o tipo de pacote gerado pelo build, quepode incluir valores como “JAR”, “EXE”, “ZIP”, “APK”, “HTML”,“WAR”, dentre outros. Apesar de existir associação entre tiposde pacotes e sistemas operacionais, como o tipo “APK” e o S.O.“Android”, é importante colocar as informações de pacote comoum nível da hierarquia abaixo dos níveis sistema operacional earquitetura para facilitar a especificação de filtros nos membrosdesta dimensão, implementada pela tabela DM_PLATAFORMA,mostrada na Figura 5.

No desenvolvimento de software em Java é comum o uso de

dependências externas especificadas durante a codificação, umavez que é necessário utilizar as classes e outros recursos de cer-tas dependências para implementar os casos de uso/regras denegócio. Assim sendo, durante o processo de build automático éimportante que estas dependências sejam corretamente identifi-cadas e atualizadas, pois este é um dos requisitos básicos para acompilação do projeto.

Com base nisso, o modelo multidimensional armazena as infor-mações de dependências do projeto para ajudar a realizar análisesque identifiquem, por exemplo, se o tempo de build aumentouquando determinada dependência foi incluída. Ou ainda, permitirrastrear e descobrir a partir de qual momento o software começou

ou deixou de utilizar certas dependências.

8/18/2019 SQL Magazine 13665676577592

10/68



Portanto, a dimensão Dependencia vai armazenar detalhesdas dependências de cada build. O usuário final que consultaros dados desta dimensão terá a visualização do nome da depen-dência, qual versão está sendo utilizada no projeto e também umapropriedade adicional com o endereço na Web da dependênciaou do local oficial do seu repositório.

A implementação da dimensão Dependencia requer duastabelas para representar o relacionamento entre os builds e asdependências. Estas tabelas são DM_DEPENDENCIA, que vai

armazenar um identificador, o nome da dependência, a versão ea URL do site ou repositório, e a tabela DM_DEP_BUILD, que vaifazer a relação entre a tabela DM_DEPENDENCIA e a tabela fatoFT_BUILD, que ainda vai ser modelada logo mais neste artigo.A tabela DM_DEP_BUILD é relacionada por uma chave estrangei-ra colocada na coluna ID_DEPENDENCIA, que também é a chaveprimária com o mesmo nome na tabela DM_DEPENDENCIA.

A implementação da coluna VERSAO utilizou um tipo de dadoscaractere, pois diversos projetos utilizam pontos, letras e outroscaracteres na classificação da sua versão (exemplo: 1.2_beta). Já acoluna que armazena a URL do projeto relacionado à dependên-cia foi limitada a 1.000 caracteres e recomenda-se que o processo

ETL faça a redução da URL oficial do projeto com um encurtadorde endereços como o bit.ly ou o migre.me. A Figura 6 mostra aimplementação da dimensão Dependencia por meio das tabelasDM_DEPENDENCIA e DM_DEP_BUILD, junto com exemplos de

navegação na hierarquia dos dados desta dimensão.Com as informações sobre dependências do projeto já modela-das, podemos começar a pensar em como incluir as informaçõesrelacionadas aos commits realizados desde a execução do último

build. Os dados relacionados ao conjunto de modificações nocódigo fonte vão ser apresentados aos usuários do modelo atra-vés da dimensão Commit, que armazenará informações sobreos desenvolvedores que contribuíram com códigos e tambémdetalhes do que foi feito.

Aqui é importante destacar que os profissionais desenvolvedoresnão devem ser relacionados diretamente com o build, ou seja, pri-meiro é preciso relacionar o build com os commits para só depois

relacioná-los com os desenvolvedores. As informações de quemcontribuiu para o projeto desde o último build incluem o papeldo desenvolvedor (“designer”, “programador front-end”, “DBA”,“testador”), o nome e o e-mail. Já para o commit é necessário algumtipo de descrição, um identificador único para relacionamentonas tabelas do modelo, um identificador do sistema de controlede versão e a URL que contém informações relevantes sobre asmodificações realizadas no código fonte.

O leitor pode incrementar o modelo e disponibilizar mais infor-mações sobre as mudanças se nos aprofundarmos nesta entidade.Por exemplo, pode-se associar uma data, quais arquivos fontesforam modificados e outros detalhes adicionais. Contudo, para

manter o modelo de dados simples e focado no build, não mo-delaremos estes detalhes, ficando a cargo do leitor implementaroutras dimensões para lidar com o detalhamento dos dadosrelacionados ao commit.

A tabela DM_COMMIT armazena os commits e conta comdiversas colunas, porém, na dimensão, os usuários finais visuali-zarão apenas o nome. As demais colunas podem ser visualizadascomo propriedades adicionais dos membros da dimensão. Paraimplementar a dimensão, é preciso relacionar a tabela fato e atabela DM_COMMIT através da tabela DM_COMMIT_BUILD,que contém uma chave estrangeira na coluna ID_COMMIT. No-vamente, a coluna ID_BUILD da tabela DM_COMMIT_BUILD é

uma chave primária para a tabela fatoFT_BUILD, que ainda não foi modelada.Desta forma, a dimensão Commit serácriada a partir do relacionamento entreas tabelas DM_COMMIT, DM_COM-MIT_BUILD e FT_BUILD.

Para representar os desenvolvedoresque contribuíram para o build atravésde algum commit, utilizaremos uma di-mensão chamada Desenvolvedor, cujosmembros vão ser organizados em umahierarquia onde primeiro mostra-se o

seu papel no build e depois seu nome.

Figura 5. Tabela DM_PLATAFORMA da dimensão Plataforma e exemplos de dados na dimensão

Figura 6. Tabelas DM_DEPENDENCIA e DM_DEP_BUILD junto com os elementos da dimensão Dependencia

8/18/2019 SQL Magazine 13665676577592


A decisão de criar uma nova dimensãopara o desenvolvedor ao invés de colocarestes dados como um novo nível da hie-rarquia Commit é para facilitar o filtro

necessário para responder perguntas dotipo “Em quais builds o profissional Xparticipou”.

A implementação da dimensão Desenvol-vedor é feita pelas tabelas DM_DEVELO-PER e DM_COMMIT_BUILD, pois existeum relacionamento de chave estrangeiraentre as duas tabelas por meio da colunaID_DEVELOPER, presente em ambas.

AFigura 7 apresenta as tabelas DM_COM-MIT, DM_COMMIT_BUILD e DM_DEVE-LOPER junto com seus relacionamentos

que implementam as dimensões Commit eDesenvolvedor. Esta figura também apre-senta exemplos de navegação nos membrosdas hierarquias destas dimensões.

O acompanhamento da qualidade doprojeto de software será feito através dadimensão Bug , que mostrará quais sãoos bugs no software que ainda existemapós o build ter sido feito. É importantedeixar claro que estes bugs devem ter umcontrole específico e serem gerenciadosadequadamente por ferramentas como o

Bugzilla.A dimensão Bug é implementada pela

tabela DM_BUG, que contém colunaspara identificar unicamente o bug, qualé o módulo do sistema/aplicação na qualo bug está relacionado e o nome do bug.Há também uma coluna para armazenarum identificador geral utilizado por umsistema de controle de bugs (Exemplo:#BUG0394) e uma coluna de texto livrepara informações adicionais. O relacio- Figura 7. Tabelas DM_COMMIT, DM_COMMIT_BUILD e DM_DEVELOPER das dimensões Commit e Desenvolvedor

namento de DM_BUG com a tabela fatoFT_BUILD é feito através de DM_BUGS_BUILD, pois ela contém uma chave es-trangeira na coluna ID_BUG e outra chave

estrangeira na coluna ID_BUILD para osrelacionamentos com as tabelas DB_BUGe FT_BUILD, respectivamente.

A hierarquia da dimensão Bug apre-senta o nível que contém o módulo dosistema/aplicação seguido pelo nívelcom o identificador geral do bug. Nestecaso optou-se por mostrar o nome do bugao invés do seu identificador, pois destamaneira é mais simples para um gerentede projeto filtrar por bugs conhecidos.Sendo assim, o identificador do bug e as

informações adicionais são propriedadesda dimensão. A Figura 8 mostra as tabelasDM_BUG e DM_BUGS_BUILD junto comexemplos de navegação na hierarquia dadimensão Bug.

Um processo automático de build sem-pre é realizado em uma data específica,seja ela periódica (exemplo: sempre àsquartas-feiras à noite) ou de acordo com

a decisão arbitrária dos membros doprojeto. De qualquer forma, o modelomultidimensional possuirá uma dimen-são Data que armazenará o momento noqual o build foi iniciado e não quando elefoi terminado, pois teremos uma medidaque armazenará a duração do build.

A implementação da dimensão Data é feita através da tabela DM_DATA,que contém diversas colunas separadaspara armazenar o ano, o mês, o dia,o dia da semana, a hora e o minuto.

A separação dos dados por coluna é umrequisito para a criação de diferentesníveis e hierarquias da dimensão Data ,mostrada na Figura 9 junto com a tabelaDM_DATA.

Figura 8. Tabelas DM_BUG e DM_BUGS_BUILD da dimensão Bug

8/18/2019 SQL Magazine 13665676577592

12/68



Uma possível modificação que pode ser feita nesta dimensãoé a combinação das hierarquias em apenas uma dimensão atra-

vés da criação de níveis. Neste artigo optou-se por trabalhar daforma mais didática possível e por isso foram criadas diferenteshierarquias para a divisão de tempo.

Uma vez que todas as dimensões e suas respectivas tabelasforam apresentadas, é preciso detalhar como será a tabela fatoe as medidas. O objetivo da tabela fato, neste caso, é agregar asinformações de cada execução do build e combiná-las com dadosrelacionados ao tempo gasto e outras métricas importantes paraquem está realizando a análise.

No modelo descrito neste artigo a tabela fato se chama FT_BUILDe é apresentada sem os relacionamentos com as demais tabelasde dimensão na Figura 10.

Figura 9. Tabela DM_DATA da dimensão Data e exemplos de seleção de elementos nashierarquias Data, DiaSemana e Horário

Figura 10. Tabela fato FT_BUILD sem os relacionamentos com as tabelas de dimensão

Note que a tabela fato FT_BUILD contém diversas colunas e rela-cionamentos. A primeira coluna importante chama-se ID_BUILDe representa um valor numérico sequencial que é o identificadorúnico da tabela com a propriedade de chave primária. Em seguidatemos as colunas ID_TIPO_BUILD, ID_RESULTADO, ID_VERSAO,ID_SPRINT, ID_PLATAFORMA e ID_DATA, que são chaves es-trangeiras para as chaves primárias das tabelas DM_TIPO_BUILD,DM_RESULTADO, DM_VERSAO, DM_SPRINT, DM_PLATAFOR-MA e DM_DATA, respectivamente.

8/18/2019 SQL Magazine 13665676577592


A dimensão Dependencias é implemen-tada através das tabelas DM_DEP_BUILDe FT_BUILD, que contém a coluna ID_BUILD. Deste modo, não há colocação da

chave estrangeira na tabela de fatos paraconectar a dimensão de dependências. Deforma semelhante, o relacionamento queimplementa a dimensão Commit dependede FT_BUILD e DM_COMMIT_BUILD.Além disso, a dimensão Bug tambémpossui relacionamento com a tabela fato,sendo implementado de maneira equiva-lente, através de DM_BUGS_BUILD.

A tabela fato FT_BUILD é apresentada junto com os relacionamentos com asdemais tabelas de dimensão (DM_TIPO_

BUILD, DM_RESULTADO, DM_VERSAO,DM_SPRINT, DM_PLATAFORMA eDM_DATA) no modelo final exposto naFigura 11.

As outras colunas da tabela FT_BUILDvão definir as medidas numéricas quepermitirão a análise de dados, lembrandoque as medidas sempre são em relação aoresultado final da execução do processode build automático.

A primeira coluna que armazena medi-das na tabela fato se chama TOTAL_LOC

e ela indica a quantidade de linhas decódigo total do projeto (somando todosos arquivos com código fonte); a colunaTOTAL_TEMPO_SEGUNDOS indica emsegundos qual foi o tempo total para arealização do build; a coluna TOTAL_QTD_BUGS contém a quantidade totalde bugs do projeto; a coluna QTD_BUGS_CORRIGIDOS armazena o número de

bugs corrigidos em cada build; a colunaTOTAL_QTD_COMITS indica o númerode commits desde a execução do último

build; a coluna TOTAL_QTD_PACOTEScontém o número total de pacotes Java doprojeto; a coluna TOTAL_QTD_ARQUI-VOS armazena a quantidade de arquivoscom código fonte Java no projeto; a colunaTOTAL_QTD_TESTES armazena a quan-tidade total de testes (independentes dotipo) que o processo de build realizou; acoluna QTD_TESTE_SUCESSO armazenao número de testes que foram realiza-dos com sucesso, ou seja, que passaramdurante 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 dimensão do modelo

a quantidade de linhas de código cobertaspor testes no projeto.

As medidas geradas a partir da tabelafato deste modelo de dados são descritasa seguir. É importante destacar que estasmedidas podem ser customizadas e com-

binadas para montar diferentes cubos dedados que mostrem facetas específicasdo negócio dependendo do que se desejarvisualizar. Vejamos as medidas geradas:• TotalLinhasDeCodigo (coluna TOTAL_LOC) indicará a quantidade total de linhasde código do projeto no momento do build.Quando se agregar esta medida de acordo

com os filtros de dimensão, a ferramentadeve somar os valores desta medida;• TempoGasto (coluna TOTAL_TEMPO)indicará o tempo total utilizado para fazero build. Esta medida pode ser convertidapara horas, minutos e segundos para faci-litar sua visualização. Quando se agregaresta medida, a ferramenta deve somar osvalores desta medida;• MédiaTempoGasto (coluna TOTAL_TEMPO) indica em horas, minutos esegundos o tempo médio necessário para

fazer o build. Quando se agregar esta

medida de acordo com os filtros de dimen-são, a ferramenta deve fazer a média dos

valores desta medida;• TotalBugs (coluna TOTAL_QTD_BUGS)indicará a quantidade total de bugs noprojeto no momento do build. Quando seagregar esta medida, a ferramenta devesomar os valores desta medida;• BugsCorrigidos (coluna QTD_BUGS_CORRIGIDOS) indicará a quantidade de

bugs corrigidos desde o últ imo build.Quando se agregar esta medida, a fer-ramenta deve somar os valores destamedida;

• TotalCommits (coluna TOTAL_QTD_COMITS) indicará a quantidade totalde commits realizados desde o último

build. Quando se agregar esta medida, aferramenta deve somar os valores destamedida;• TotalPacotesJava (coluna TOTAL_QTD_PACOTES) indicará a quantidade total depacotes analisados durante o build. Quan-do se agregar esta medida, a ferramentadeve somar os valores desta medida;• TotalArquivosCodigoFonte (coluna

TOTAL_QTD_ARQUIVOS) indicará a

8/18/2019 SQL Magazine 13665676577592

14/68



quantidade total de arquivos com código fonte analisados duranteo build. Quando se agregar esta medida, a ferramenta deve somaros valores desta medida;• TotalTestes, TestesSucessoPerc e TestesFalhaPerc (colunas

TOTAL_QTD_TESTES e QTD_TESTE_SUCESSO) mostrará aquantidade total de testes, o percentual de testes com sucesso e opercentual de testes com falha do build, respectivamente. Quandose agregar esta medida de acordo com os filtros de dimensão, aferramenta deve somar os valores desta medida;• TotalCobertura (coluna QTD_LOC_COBERTO_TESTES) indi-cará o percentual do código fonte coberto com testes do build.Quando se agregar esta medida, a ferramenta deve somar osvalores desta medida.

Os dados gerados durante o processo de build automático em umprojeto de software possuem a capacidade de produzir diferentes

visões do andamento do projeto e permitem a análise detalhadade aspectos envolvendo tempo, commits, bugs, versões, sprintse outras informações. Este tipo de análise é especialmente im-portante para gerentes de projeto que precisam periodicamenteavaliar a qualidade do software e realizar o acompanhamento doprojeto a cada execução do processo de build.

Baseado neste cenário, este artigo apresentou um modelo dedados multidimensional utilizado para facilitar as análises dediversos aspectos relacionados ao processo de build automáticode um projeto de software que adota a tecnologia Java. O modelodescrito contém dimensões para facilitar as análises por builds,datas, versões, ciclos de desenvolvimento, bugs, commits e depen-

dências de software. Já as informações quantitativas apresentadasincluem totais de linhas de código, testes, tempos, bugs e commitsrealizados por desenvolvedores.

Mauro [email protected] / @pichiliani

É bacharel em Ciência da Computação, mestre e doutorando

pelo ITA (Instituto Tecnológico de Aeronáutica) e MCP, MCDBAe MCTS. Trabalha há mais de 10 anos utilizando diversos bancos de dadosSQL e NoSQL. É colunista de SQL Server do web site iMasters (http://www.

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

Autor

Links:

Ferramenta de build Mavenhttps://maven.apache.org/

Ferramenta de build Gradlehttp://gradle.org/

Framework para testes em Java JUnithttp://junit.org/

Ferramenta PMD para geração de métricas de códigohttps://pmd.github.io/

Ferramenta CheckStyle para verificação de estilo de codificaçãohttp://checkstyle.sourceforge.net/

Ferramenta FindBugs para identificação automática de bugshttp://findbugs.sourceforge.net/

Ferramenta Bugzilla para controle de bugshttps://www.bugzilla.org/

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

Ajude-nos a manter a qualidade da revista!

Você gostou deste artigo?

8/18/2019 SQL Magazine 13665676577592


8/18/2019 SQL Magazine 13665676577592

16/6816 SQL Magazine • Edição 136

Os arquivos de dados são objetos de extrema importância em um

banco de dados, independente se estivermos falando de SQL Server,

Oracle ou MySQL. Dentro dos arquivos de dados encontram-se tabe-

las, índices, procedures e registros propriamente ditos de clientes,

fornecedores e funcionários. Por isso, os mesmos necessitam de cui-

dados. Sendo assim, daremos recomendações e instruiremos como

alocar estes arquivos, como controlar o espaço e configurá-lo paraque seu banco ganhe performance com o gerenciamento correto

dos arquivos de dados.

Fique por dentro

Manipulação de

arquivos de dados e logno SQL ServerAprenda neste artigo como dimensionar e alocar

os arquivos de dados e de log transaction

Os arquivos de dados do SQL Server são compos-tos por dois tipos: de dados e de log transaction.Nos arquivos de dados geralmente são arma-zenados objetos do banco como tabelas, procedures,triggers e índices, assim como registros de clientes. János arquivos de log são registradas todas as alteraçõesocorridas no banco para que ele possa ser recuperadoem caso de desastres do tipo perda de disco, falha em

um dos arquivos de dados, etc. Os arquivos de dados ede log são divididos da seguinte maneira:• Arquivos de dados primário, com a extensão .mdf;

• Arquivos de dados secundários, com a extensão .ndf;

• Arquivos de log, com a extensão .ldf.

Esses arquivos possuem suas particularidades e fun-ções dentro do banco de dados e a perda de um dessesarquivos pode significar a perda de parte das informa-ções contidas no banco de dados, ou mesmo a perda detodo o banco. No caso da perda de um dos arquivos, oprocedimento mais indicado é a restauração do banco de

dados, mas você deve ter o cuidado de executar rotinasde backup periodicamente.

Os arquivos .mdf são os primeiros a serem criadosquando você executa o comando CREATE DATABASE.O arquivo mdf sempre fará parte do filegroup primary.Dentro dele estarão armazenadas informações sobretabelas, views, tabelas de sistema e metadados. Além dis-so, podem ser localizados procedures, índices, registose usuários. Para o armazenamento de tabelas e índicesde usuários, no entanto, recomendamos trabalhar comarquivos de dados secundários.

Os arquivos .ndf armazenam dados secundários,

opcionais no banco de dados. Eles podem ser montados

tanto durante o planejamento do banco de dados ou posteriormen-te, após a conclusão do banco. A principal função destes arquivos éaumentar a capacidade de armazenamento da base e manter umaárea separada dos arquivos *.mdf, onde serão gravadas tabelas desistema e metadados. Como já mencionado, é aconselhado utilizararquivos secundários para armazenar dados dos usuários.

Caso você não tenha o hábito de trabalhar com estes arquivos

e acha que a melhor forma é armazenar os dados com arquivosprimários, sugerimos que você pense a respeito e trabalhe comarquivos secundários. Desta forma, você pode aumentar a capa-cidades de armazenamento da base e ao mesmo tempo melhororganizar os objetos e registros específicos de usuários.

O terceiro conjunto são os arquivos de Log Transaction, quepossuem a extensão .ldf. Este tipo de arquivo é responsável pelarecuperação do banco de dados em caso de falhas, sendo utilizadoem operações de log shipping, possibilitando a recuperação da

base em caso de desastres (falha física de discos ou estrutura dearquivos). Os arquivos de log armazenam todas as mudançasrealizadas no banco, permitindo a recuperação de instruções

quando estas não surtem o efeito esperado pelo programador.

8/18/2019 SQL Magazine 13665676577592


É através dos arquivos de log que o SQL Server mantém a inte-gridade dos dados.

Abordaremos neste artigo de que forma você pode alocar osarquivos de dados e log transaction, assim como saber a diferença

entre eles. Arquivos de dados têm por objetivo o armazenamentode registros, objetos (procedures, índices, views) e a estrutura detabelas, tanto de clientes quanto do sistema do SQL Server. Já osarquivos de Log Transaction têm por objetivo armazenar todasas mudanças que são realizadas no banco (Insert, Update, Delete).Abordaremos aqui os tipos de volume de disco mais adequadosao tipo de arquivos que se está manipulando. Para os arquivos dedados, recomenda-se dar preferência a unidades onde a leituratenha uma ótima performance, enquanto para arquivos de log,recomenda-se o uso de unidades onde a gravação tenha melhorperformance. Apesar das diferenças, ambos os arquivos necessi-tam de unidades de disco com redundância a falhas.

Onde alocar arquivos de dados e de log do bancoAgora que você já tem uma ideia sobre arquivos de dados e de

log transaction do SQL Server e qual a importância dos mesmos,vamos mostrar onde criá-los.

Os arquivos de dados e de log são alvos de instruções DML(Insert, Update, Delete e Merge) e DDL (Create, Alter, Drop, Trun-cate), além de muitas instruções envolvendo select filtrando dadosespecíficos. A unidade de disco onde você irá alocar os arquivos dedados e log faz muita diferença, mediante as operações enviadasao banco de dados. Além disso, o tipo de partição e RAID farácom que seu banco tenha mais performance ou uma performance

precária, assim como irá indicar se ele está alocado em uma áreasegura ou uma área que não oferece redundância a falhas. Paraentender mais a fundo sobre alocação de arquivos de dados ede log, vamos explicar a seguir os tipos de RAID existentes e asrecomendações de alocação:• RAID 0 (Zero): conhecido também por striping, o RAID 0 jun-ta várias unidades de disco, formando assim um único disco, eapresenta um ótimo desempenho de leitura e gravação. O grandeproblema do RAID 0 é que se um dos volumes falhar, a partiçãotoda é perdida. Desta forma, embora ele seja uma ótima opção dedesempenho, não oferece nenhuma redundância a falhas;• RAID 1: conhecido também por mirroring (espelhamento), no

RAID 1 são usadas duas unidades de disco, que devem obriga-toriamente ter o mesmo tamanho. Caso você use dois discos de500GB, por exemplo, seu espaço para alocar arquivos do bancocontinuará sendo de 500GB e não de 1T. Lembre-se que vocêestá espelhando uma unidade e duplicando-a. Em função doRAID 1 escrever em dois discos por ser espelhado, isso garantea redundância a falhas. Assim, caso um disco pare, o outro iráassumir a responsabilidade do disco principal. Por outro lado, oRAID 1 perde em performance, apresentando um desempenhorazoável na leitura e uma piora nos inserts e updates, pois a es-crita é realizada em duas unidades para manter a consistência.Se desempenho não for o primordial para seu banco e sim a

segurança, use o RAD 1;

• RAID 5: o RAID 5 combina o desempenho necessário e a re-dundância a falhas, viabilizando excelente desempenho para aescrita e bom desempenho para a leitura. No entanto, caso umadas unidades falhe, o desempenho à leitura ficará prejudicado,

causando gargalos em instruções select, por exemplo. Mesmoassim, convém utilizar esse tipo de RAID para armazenar tantoarquivos de dados quanto arquivos de log;• RAID 0+1 ou 10: o RAID 0+1 ou RAID 10 junta a velocidade doRAID 0 (striping) com a redundância a falhas do RAID 1 (mirror).Neste tipo de partição as leituras ganham um ótimo desempenhoe é atualmente a melhor opção para armazenamento de arquivospara banco de dados, independentemente de este ser o SQL Server,o Oracle ou o MySQL. Este tipo de RAID necessita de no mínimoquatro discos. Ademais, a Microsoft recomenda fortemente queos arquivos do banco, principalmente os arquivos de log, sejamalocados nesta partição.

Existem outros tipos de RAID, mas procuramos destacar osmais usados e estudados para a implantação de banco de dadosSQL Server. Existem ainda os RAIDs de software, os quais sãogerenciados se criados por sistemas terceiros, e na versão 2012 e2014 do Windows Server Enterprise você pode criar RAIDs atravésda funcionalidade File and Storage Services. Apesar destes recur-sos, é sempre sugerido o RAID de hardware, muito mais seguroe confiável.

Criação dos arquivos de dados e logAgora que você já conhece as funções dos arquivos de dados

e de log e já sabe onde armazenar os arquivos do banco, vamosaprender como criar os bancos e definir o caminho para estesarquivos. O primeiro exemplo que apresentamos utiliza a sintaxede criação do banco de dados, conforme expõe a Listagem 1.

Neste exemplo temos um banco de dados de nome SQL_Teste sendo criado. Note que este banco possui um grupo de arqui-vos chamado PRIMARY definido na instrução ON PRIMARY .O nome lógico do arquivo deste banco é “SQL_Teste”, definidono comando NAME, e seu nome físico é descrito pela sua loca-lização: N’E:\MSSQLSERVER\DATA\SQL_Teste.mdf’ , definida nocomando FILENAME. O arquivo de log, por sua vez, não possui

grupo e já é criado diretamente conforme o caminho indicado em

Listagem 1. Criação do banco de dados.

01. CREATE DATABASE [SQL_Teste]

02. ON PRIMARY

03. ( NAME = N’SQL_Teste’,

04. FILENAME = N’E:\MSSQLSERVER\DATA\SQL_Teste.mdf’ ,

05. SIZE = 5120KB ,

06. FILEGROWTH = 1024KB )

07. LOG ON

08. ( NAME = N’SQL_Teste_log’, 09. FILENAME = N’E:\MSSQLSERVER\DATA\SQL_Teste_log.ldf’ ,

10. SIZE = 1024KB ,

11. FILEGROWTH = 10%)

12. GO

8/18/2019 SQL Magazine 13665676577592

18/68

Manipulação de arquivos de dados e log no SQL Server


‘E:\MSSQLSERVER\DATA\SQL_Teste_log.ldf’ . Já o comando SIZEdetermina o tamanho inicial com que os arquivos serão criadose FILEGROWTH determina de quantos em quantos KB ou por-centagem um arquivo de dados ou log irá crescer.

Adicionando arquivos ao bancoApós a criação do banco de dados, podemos criar novos arquivos

como sugere o exemplo da Listagem 2 com o comando ALTERDATABASE. Antes disso, no entanto, usando também o ALTERDATABASE, criamos um novo grupo de arquivos, chamado“SECUNDARIO”, local onde inserimos dois arquivos de dadoscom a extensão “ndf”, por serem arquivos secundários. Observeo comando a seguir:

ALTER DATABASE [SQL_Teste] ADD FILEGROUP [SECUNDARIO]

GO

Vejamos os comandos individualmente:• ALTER DATABASE: indica qual banco irá sofrer a alteração;• ADD FILE: indica que estamos inserindo um arquivo de dadosno banco descrito na instrução ALTER DATABASE;• NAME: define o nome lógico do arquivo de banco de dados;• FILENAME: define o caminho onde o arquivo de dados seráalocado. Este é o nome físico do arquivo;• SIZE: aqui se define o tamanho inicial do arquivo, que podeser dado por: KB, MB e GB;• MAXSIZE: define o tamanho máximo que um arquivo de dadosirá crescer. Os valores podem ser definidos por KB, MB e GB;

• FILEGROWTH: com este comando especificamos de quantoem quanto o arquivo irá crescer assimque atingir seu tamanho, caso o FILE-GROWTH esteja ativo;• TO FILEGROUP: este comandoindica em quais grupos de arquivos osdois arquivos de dados da Listagem 2 farão parte.

Embora seja possível usar códigos

para inserir arquivos de dados e con-trolar seu tamanho, podemos usar o

ambiente gráfico do SQL Server, comomostrado na Figura 1. Para acessaresta tela, clique com o botão direito domouse em cima do banco que desejamanipular e escolha a opção Proper-ties. Caso seu SQL Server esteja emportuguês, Propriedades , dentro do SQLServer Management Studio.

Na tela apresentada na Figura 2 , con-trolamos o limite de crescimento queum arquivo de banco de dados pode tere de quantos em quantos MBs o mesmo

irá crescer, sendo especificado em MB

ou pela porcentagem. Neste exemplo estamos realizando as con-figurações referentes ao arquivo SQL_Teste_02 , como podemosver no título da janela.

Vamos explicar agora as opções desta janela. Posteriormen-

te mostraremos como aplicar estas opções e como você podeconfigurá-las para obter benefícios na administração do bancode dados. Vejamos as opções:• Enable Autogrowth: ao habilitar esta opção, poderemos definir,em MB ou porcentagem, de quanto em quanto os arquivos dedados devem crescer quando alcançar seu limite;• In_Percent: se por acaso o arquivo possuir 500MB, ele irá crescer10% sobre tamanho de 500MB. Desta forma, ele irá crescer mais 50MB,supondo que o valor de In_Percent esteja configurado para 10%;

Figura 1. Inserção de arquivos de dados – opção Files

Listagem 2. Criação de arquivos de Dados.

01. ALTER DATABASE [SQL_Teste]02. ADD FILE

03. ( NAME = N’SQL_Teste_02’,

04. FILENAME = N’E:\MSSQLSERVER\DATA\SQL_Teste_02.ndf’ ,

05. SIZE = 5120KB ,

06. MAXSIZE = 1048576KB ,


08. TO FILEGROUP [SECUNDARIO]

09. GO

10. ALTER DATABASE [SQL_Teste]

11. ADD FILE

12. ( NAME = N’SQL_Teste_03’,

13. FILENAME = N’E:\MSSQLSERVER\DATA\SQL_Teste_03.ndf’ ,

14. SIZE = 5120KB ,


16. TO FILEGROUP [SECUNDARIO]

17. GO

8/18/2019 SQL Magazine 13665676577592


• In_Megabytes: o arquivo irá crescer mediante o valor informa-do na opção In_Megabytes. Por exemplo, quando um arquivo de500MB alcançar o espaço total, o mesmo irá crescer mais 100MB,se In_Megabytes receber o valor 100;

• Maximum File Size: local onde é definido o limite de cresci-mento de um arquivo de dados. Nesta opção podemos limitar ocrescimento do arquivo ou podemos deixar o mesmo crescer atéa capacidade máxima do disco rígido;

- Limited to (MB): limita o tamanho máximo de um arquivode dados. Desta forma você evita que um arquivo de dadosocupe todo o espaço de um disco e comprometa outros bancosque possuam arquivos de dados nesta unidade;- Unlimited: com esta opção ativa você está liberando ocrescimento do arquivo de dados. Assim, enquanto houverespaço na unidade de onde se encontra o arquivo, o mesmo irácrescer. Essa prática não é recomendada para a configuração

de arquivos de dados.

Figura 2. Controle de crescimento de arquivos

Boas práticas para arquivos de dados e LogCom o conteúdo apresentado até aqui você já está apto a criar

seus arquivos de dados e de log e já conheceu as opções paradimensionar os mesmos. Mas você já sabe como dimensionarcorretamente estes arquivos de tal forma que não impactem no

desempenho de seus bancos de dados? Embora isso exija umpouco mais de esforço, saiba que é importante limitar o tamanhode seus arquivos. Deste modo, a partir de agora, vamos verificarquestões como esta para que você possa aplicar boas práticas eefetivamente administrar seus SGBDs.

Tamanho inicial de um arquivo de dados

Quando você está definindo o parâmetro SIZE na criação deum arquivo, tanto de dados quanto de log, você está definindoo tamanho o qual ele será criado. Para definir o tamanho inicialde um arquivo, além de especificar de quanto em quanto esteirá crescer, é viável que junto aos desenvolvedores se tenha uma

ideia da volumetria de dados que o banco receberá. Suponha que

a quantidade de registros seja estimada em torno de 30MB, porexemplo. Após criar o arquivo primário, crie um grupo de arquivode dados e defina-o como padrão e crie um arquivo de dados com50MB, tendo assim uma folga no crescimento. É normal, durante

a implantação do sistema, que o mesmo cresça de forma rápida,mas quando se entra em produção com dados de usuário, estecrescimento tende a diminuir e cabe a você observar de quantoem quanto este banco cresce para que então possa definir o valorideal 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 existentesno servidor e a quantidade de espaço livre, conforme mostradona Figura 3;

Figura 3. Saída da execução do comando xp_fixeddrives

• sp_helpdb SQL_Teste: exibe o espaço total do banco de dadosSQL_Teste e informações individuais sobre os arquivos de dados,conforme exibido na Figura 4;• sp_spaceused: este comando exibe o tamanho da base de dadose o tamanho do espaço não alocado nos arquivos de dados, como

mostra a Figura 5;• sp_helpfile: com a execução dessa instrução, você terá acessoa informações sobre arquivos de dados, como tamanho inicial,tamanho total, de quanto em quanto o arquivo irá crescer,assim como o caminho onde os mesmos estão alocados (vide Figura 6).

Configurando o Autogrowth e Maxsize

Neste tópico explicaremos como configurar o Autogrowth ea melhor opção para Maxsize em suas bases de dados. O Auto-growth é desabilitado por padrão quando um arquivo de banco dedados é criado, mas mediante a quantidade de bancos existentes

dentro de sua instância, é aconselhável habilitar esta opção paracontrolar de quantos em quantos MBs os arquivos crescerão elimitar o crescimento máximo do banco de dados, de forma que ocrescimento de um banco não prejudique os demais que possuemarquivos existentes em um mesmo volume de disco.

Anteriormente, na Figura 1 mostramos a tela de inserção dearquivos de dados nas propriedades de arquivos do banco. Natela da Figura 7 podemos controlar o crescimento e o tamanhomáximo que um arquivo pode alcançar.

Após habilitar a opção Enable Autogrowth , outras opções sãoliberadas para que você possa trabalhar o dimensionamentodos arquivos de dados e controlar o fluxo de crescimento dos

mesmos:

8/18/2019 SQL Magazine 13665676577592

20/68

Manipulação de arquivos de dados e log no SQL Server


Figura 4. Saída da execução do comando sp_helpdb

Figura 5. Saída da execução do comando sp_spaceused.

Figura 6. Saída de execução do comando sp_helpfile

Figura 7. Controle de crescimento de arquivos Change Autogrowth

• File Growth: você pode limitar ocrescimento do banco em porcentagemou em MB. Recomendamos controlaro crescimento em MB pelo seguinte

motivo: suponha que você tenha um ar-quivo de dados de 1TB (Terabyte), o queé muito comum nos dias de hoje, que omesmo esteja configurado para crescer30% sempre que alcançar seu limite evocê está com apenas 10GB livres emsua unidade de disco. O arquivo chega,então, ao limite e cresce 30% de 1T, ouseja, 300GB. Pronto, seu banco de dadostrava e junto com ele, todos os arquivosde dados que se encontram nesta mesmaunidade não terão condições de crescer.

Neste cenário você não irá parar apenasum banco, mas todos os bancos que pos-suírem arquivos de dados nesta unidade.Assim, recomendamos fortemente quevocê controle o crescimento pela opçãoIn_Megabytes , def in indo um tamanhorazoável, nem muito grande e nem muitopequeno. Obtenha essa média atravésdos comandos passados anteriormentepara que você defina um tamanho ra-zoável de crescimento. Se você definirum tamanho muito pequeno, o banco

terá constantes travamentos, porquea todo o momento o banco irá dimen-sionar os arquivos de dados e isso geraesforço tanto para o SQL Server quantopara o disco rígido. Se você definir umtamanho muito grande, o banco dedados irá dispor de muito tempo paracrescer o arquivo. Quando um arquivode dados cresce, o SQL Server preencheos arquivos mesmo com zeros até chegarao tamanho especificado pelo file growthIn_Megabytes , o que gera certa degrada-

ção da performance enquanto o arquivoestá crescendo. Mediante a volumetriade seu banco, cresça os arquivos no má-ximo de 500MB a 500MB. Fique de olho,portanto, no quanto está configurado oparâmetro Maxsize, pois ele determinao tamanho máximo de seus arquivosde dados e log. Verifique também oespaço disponível em suas unidades dedisco para não ter nenhuma surpresadesagradável. Ao criar um cenário deteste para estudos, deixe o crescimento

configurado de 100MB a 100MB para os

arquivos da base. Desta forma, você terácontrole sobre o crescimento dos arqui-vos e caso seja necessário, pode criaroutros arquivos de dados ou até mesmoavaliar a expansão do disco, caso nãoseja possível crescer ou criar arquivos dedados. Note, no entanto, que esse deveser o último recurso;• Maximum File Size: nesta opção vocêcontrola um limite máximo de crescimento

para seu arquivo de dados habilitando a

opção Limited to MB , ou simplesmentehabilita a opção Unlimited , quando o ar-quivo irá crescer enquanto houver espaçono disco. Contudo, esta última opção éperigosa, pois caso você tenha outros

bancos alocados junto do mesmo arquivosem um limite de crescimento, os demais

bancos podem ser prejudicados. Por isso,sempre trabalhe com um limite de cresci-mento, controlando este limite pela opção

Limited to MB.

8/18/2019 SQL Magazine 13665676577592


Arquivos de Log de TransaçãoOs arquivos de log de transação devem receber o mesmo es-

forço administrativo que os arquivos de dados e talvez até maisem função destes arquivos serem responsáveis pela recuperação

do banco em caso de falhas. O comportamento de crescimentodos arquivos de log depende do modelo de recuperação o qualo banco está configurado. Existem três modelos atualmente quesão explicados a seguir:• Full: grava nos logs de transação todas as mudanças executadasno banco. A tendência deste tipo de recuperação é que os arqui-vos de log cresçam bastante mediante as alterações ocorridas no

banco;• Bulk-Logged: este modelo de recuperação registra nos arquivosde log apenas algumas transações, não sendo possível, portanto,fazer uma recuperação 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 não cresçam de formadescontrolada, se usa esta configuração;• Simple: este modelo não oferece suporte a backups de log detransação pelo fato de não escrever transações nos arquivos delog que possibilitem a recuperação do banco. Dessa forma, oslogs crescem muito pouco. Este modelo é tipicamente usado em

bases de dados que servem apenas como testes de implantaçãode sistemas, onde não é necessária a recuperação dispensando aocupação de disco por crescimento dos arquivos de log.

Em um ambiente de banco de produção, a maioria dos modelosde recuperação será configurada como modelo Full. Neste modelo,

se registra todas as transações e mudanças dentro do banco dedados, possibilitando a restauração total em caso de desastres.Estas alterações são registradas nos arquivos de log transaction.Nesta situação você pode configurar na sessão Enabled Autogro-wth , opção In_Megabytes (vide Figura 7), o crescimento de 500MBa 500MB. Com relação ao Maximum File Size , é a mesma regrapara os arquivos de dados. O mesmo deve ser limitado atravésda opção Limited to (MB). Recomendamos, tanto para arquivos

de dados quanto para arquivos de log, não deixar os arquivosde dados crescerem à vontade no disco. Por mais que exija umesforço administrativo para monitorar os mesmos, lembre-se queeste é o seu trabalho. Recomenda-se deixar 15% de espaço livre

na unidade de disco para se ter condições de movimentar e criararquivos em outras unidades com espaço disponível.Para alguns administradores de banco, é muito fácil apenas ge-

renciar instâncias pelo ambiente gráfico. No entanto, o SQL Serveré muito mais do que isso e este artigo mostrou como você podeplanejar a criação de seu banco de dados, os lugares corretos paracada tipo de arquivo e que você não pode simplesmente deixar o

banco crescer sem que tenha um mínimo de esforço administra-tivo para acompanhar esse crescimento de forma controlada.

Embora o SQL Server possua muitas funcionalidades gráficas,procure usar os códigos que foram descritos neste artigo. Não selimite apenas à parte gráfica deste SGBD. Assim você pode am-

pliar e aprimorar a sua administração através de códigos e gerarmuitas outras fontes de relatórios para sua monitoria, além dasprocedures já inclusas no próprio SQL.

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

Ajude-nos a manter a qualidade da revista!

Você gostou deste artigo?

Robson [email protected]

Experiência de 19 anos na área de informática tendo passadopor áreas como analise de suporte gerente de configurações d esistemas administrador de conta e a quatro anos como administradorde banco de dados focado em SQL Server mas tendo experiência com

Oracle e MySQL.

Autor

8/18/2019 SQL Magazine 13665676577592

22/6822 SQL Magazine • Edição 136

Este artigo é útil em situações em que se deseja melhorar o desempe-nho de consultas executadas em bancos de dados SQL Server. Algumas

práticas comuns a este tipo de desafio é a avaliação da infraestrutura

disponível, qualidade do código implementado e criação de índices.

Este artigo se concentra neste último ponto e aborda a teoria e prática

dos índices baseados em colunas (Columnstore). Este tipo de índice

é recomendado para ambientes OLAP (Online Analytical Processing)

nos quais usualmente são executados processos de carga de dados

em massa e podem melhorar o desempenho de suas consultas em

até 10 vezes.

Fique por dentro

Dominando os índices

columnstoreMelhore o desempenho de suas consultas no SQLServer

Cada vez mais as empresas vêm provando queos dados produzidos dentro e fora do ambiente

corporativo podem ser extremamente úteis paraa definição de novas estratégias ou até mesmo criação denovos produtos e serviços. Neste contexto, armazenaros dados de uma forma estruturada e recuperável sãorequisitos básicos para um ambiente analítico.

No mesmo sentido, à medida que um volume maiorde informações é produzido e armazenado nos bancosde dados das empresas, os procedimentos para garantirum bom desempenho destes sistemas ganham aindamais relevância.

Um dos recursos de banco de dados util izado para tra-tar o desempenho das aplicações são os índices, que são

estruturas criadas para agilizar a execução de consultasdisparadas contra determinadas tabelas.

Estabelecendo uma analogia com o mundo físico, pode-se comparar os índices de banco de dados aos índices deum livro. A forma mais rápida do leitor encontrar umassunto específico em um livro é procurando o temade interesse em seu sumário. Ao encontrar o assuntode interesse, o leitor acessa a página desejada sem anecessidade de passar pelas demais.

Por outro lado, em situações em que o leitor não desejaprocurar por assuntos específicos, mas sim efetuar umaleitura completa e sequencial das páginas, o índice passa

a ser desnecessário, pois não será usado pelo leitor.No mundo de banco de dados nos deparamos com as

mesmas preocupações, ou seja, existem situações em queos índices são úteis e outras em que apenas ocupariamespaço e processamento de máquina se fossem criados.

Não será debatido aqui as melhores práticas paraimplementação e manutenção de índices de banco dedados. O nosso foco é mostrar uma nova opção paracriação de índices incorporada no SQL Server 2012 quepermite o armazenamento das informações dos índicesem formato colunar.

Antes de debater sobre índices colunares, no entanto,

serão apresentados alguns conceitos básicos sobre as

estruturas de índices já existentes no SQL Server (índices cluste-rizados e não clusterizados). Estas opções continuam sendo im-portantes para o planejamento de um banco de dados que garantaintegridade e bom desempenho em suas consultas.

Os índices colunares devem ser introduzidos nas arquiteturasatuais de bancos de dados que utilizam o SQL Server como incre-mento às estruturas e padrões de projeto já existentes. Portanto,antes de começar a implementar este novo recurso, como em qual-quer outro tipo de trabalho, é necessária uma análise detalhadasobre os possíveis ganhos de sua aplicação.

Vale ressaltar ainda que os índices devem ser visualizadoscomo parte de uma estratégia para melhorar o desempenho das

aplicações. Sendo assim, quando se deseja tratar o problemaotimização de ambientes de banco de dados, deve-se levar emconsideração também atividades como resizing e melhoria deprocessos.

Índices clusterizados e não clusterizadosExistem dois grupos de índices no SQL Server: índices clusteri-

zados, também conhecidos como índices agrupados, e os índicesnão clusterizados, também chamados de índices não agrupados.Ambos são usados por desenvolvedores e administradores de

banco de dados com o objetivo de melhorar os planos de execu-ção das consultas feitas no banco de dados e, consequentemente,

reduzir o tempo de execução das mesmas.

8/18/2019 SQL Magazine 13665676577592


Embora compartilhem objetivos em comum, índices clusteri-zados e não clusterizados armazenam os dados de índice em

estruturas diferentes. Enquanto os índices não agrupados arma-zenam em sua estrutura uma referência para as linhas da tabelaoriginal, os índices agrupados armazenam em sua estrutura aprópria informação da tabela original.

Em termos de funcionamento, isto significa que os índices nãoclusterizados devem consultar a tabela original (em que o índicefoi criado) para retornar os dados desejados em uma determinadaconsulta, por outro lado, os índices clusterizados já possuem asinformações a serem retornadas em sua própria estrutura.

NaFigura 1 é exemplificada a estrutura de um índice não clusteri-zado que foi criado sobre uma coluna chamada “nome”. Nota-se queao invés do índice armazenar os dados originais da tabela em que foi

criado, é gravada apenas uma referência para as linhas da mesma.Ao efetuar uma consulta na tabela pelo campo “nome” o meca-

nismo de banco de dados fará uma busca no índice, que já estáordenado, e o nome buscado será retornado. Cada registro doíndice contém o endereço da sua respectiva linha na tabela. Destaforma, ao procurar uma determinada informação na estrutura doíndice, o SQL Server identifica a l inha e a página de dados em queesta informação está armazenada.

É justamente neste ponto em que índices agrupados e não agru-pados se diferem: na forma de armazenar os dados no índice e naforma em que os mesmos são pesquisados. Na Figura 2 é apre-sentada uma estrutura de um índice clusterizado e um exemplo

de sua dinâmica de busca.

Figura 1. Estrutura de um índice não clusterizado

Figura 2. Estrutura de um índice Clusterizado e funcionamento de busca

Como se pode notar, os índices clusterizados não possuem re-ferências para as linhas da tabela original em que foram criadospelo fato de já armazenarem as informações da tabela em suaestrutura (não é necessário ter uma referência).

Vale a pena destacar também a forma como os dados são pes-quisados. Os índices clusterizados agrupam as informações databela (também de forma ordenada) em uma espécie de árvore

binária, desta forma, ao buscar uma determinada informação,o SQL Server filtra as páginas em que a informação pesquisadapoderia estar armazenada até chegar no local exato e retornaros dados.

Considerações sobre o uso de índices Existem cenários em que é mais recomendada a utilização deíndices clusterizados e outros nos quais a aplicação de índices nãoclusterizados é mais apropriada. Para entender em quais situaçõesaplica-se melhor um ou outro, vale a pena destacar as principaisdiferenças entre estes dois tipos de índices:• Pode existir mais de um índice não clusterizado por tabela, ao

passo que apenas um índice clusterizado é permitido;• Comandos INSERTs e UPDATEs têm melhor desempenho

quando são disparados contra tabelas que possuem índices nãoclusterizados quando comparados a disparos contra tabelas comíndices clusterizados;• Nos índices clusterizados, a leitura dos dados é mais rápida e os

dados são ordenados fisicamente na tabela. Ao contrário dos índi-ces não clusterizados, nos quais a leitura é mais lenta e os dadosnão são ordenados fisicamente na tabela (o índice armazena umareferência lógica para o local em que o dado está armazenado).

Ambos os índices podem ser usados para agilizar o proces-

samento de comandos SELECTs, no entanto, de alguma formatambém podem prejudicar o desempenho de comandos deINSERTs e UPDATEs.

A forma como os índices são projetados define o real ganho dedesempenho das consultas no banco de dados. Pode até acontecerde a criação de índices resultar em mais perdas do que ganhos àaplicação. Consultas em que nenhum ou poucos filtros (tanto emlinhas quanto em colunas) são definidos, podem ser executadascom mais agilidade se o mecanismo de banco de dados analisartodas as informações da tabela (característica conhecida comotable scan).

Para ajudar no processo de manutenção dos índices, o SQL

Server conta com uma ferramenta chamada Database Engine

8/18/2019 SQL Magazine 13665676577592

24/68

Dominando os índices columnstore


Tuning Advisor. Esta ferramenta permiteanalisar índices já existentes para enten-der se os mesmos estão sendo utilizadoscorretamente.

O DTA também recomenda a criaçãode novos índices para um determinado banco de dados, faz recomendaçõespara criação de partições e efetua umaanálise de impacto das recomendaçõesefetuadas.

Fundamentos de row-store e column-store

Agora que já definimos alguns conceitos básicos sobre índices e abordamos aqueles mais tradicionais exis-tentes no SQL Server, iniciaremos o debate sobre um novo tipo de

índice incorporado no banco de dados da Microsoft.Desde sua versão 2012, o mecanismo de banco de dados do SQLServer conta com um poderoso recurso para aumentar o desem-penho de suas consultas chamado índices columnstore. Índicescolumnstore são baseados na tecnologia VertiPaq, responsávelpela inteligência de armazenamento e compressão de dados doSQL Server.

Os índices columnstore usam um formato de dados colunar paraarmazenar e recuperar as informações, denominado columnstore,e podem melhorar em até 10 vezes o desempenho das consultas.Isso porque possibilita a otimização da seleção e compressão dosdados, como será detalhado à frente.

Este recurso é apropriado para ambientes analíticos (OLAP –Online Analytical Processing) nos quais usualmente são executadosprocessos de carga de dados em massa e consultas em tabelas quearmazenam grandes históricos de informação.

Ambientes analíticos são criados com o objetivo de fornecerflexibilidade aos processos de tomada de decisão. Usualmentecontidos dentro de uma arquitetura de Business Intelligence , estesambientes possibilitam que os usuários de negócio analisem asinformações em diferentes dimensões, sem a necessidade deintervenção de uma equipe de TI para criar novas visões a todomomento.

Isso é possível porque os metadados são organizados e disponi-

bilizados aos usuários por meio de cubos e relatórios dinâmicos.É claro que novas demandas continuam existindo, dado a velo-cidade dos negócios atuais; no entanto, o ambiente garante maisvelocidade de acessos aos dados e este fator pode ser determinantepara a conquista de um novo negócio.

Do ponto de vista de armazenamento de dados, ambientesanalíticos costumam usar estruturas de dados conhecidascomo Data Warehouse e Data Mart. A ideia que gira em tornodestes conceitos é teoricamente simples: armazenar os dados deuma forma organizada, facilitando os processos de tomada dedecisão. Na prática, existem diversos desafios que fazem comque projetos de Data Warehouse tenham elevados preços a altos

riscos de fracasso.

Figura 3. Armazenamento em linhas

Voltando ao SQL Server, pode-se trabalhar com dois tipos dearmazenamento de dados: rowstore e columnstore. O primeiro,

como o próprio nome sugere, trata o armazenamento de dadosorganizados por registros, ou seja, as informações são organi-zadas nas páginas de dados linha a linha. É o que acontece, porexemplo, com os tradicionais índices clustered do SQL Server.A Figura 3 esquematiza o formato de armazenamento de umíndice que utiliza o conceito de rowstore.

Os índices baseados em linhas podem ter características dife-rentes no que se refere à ordenação ou agrupamento dos dados.No entanto, se o índice é baseado em linhas, obrigatoriamentearmazenará em suas páginas de dados informações de linhasinteiras de uma tabela.

As páginas de dados destes índices possuem tamanho de até

8Kb e, além de guardar as informações da tabela, possuemuma estrutura de cabeçalho e conexões para outras páginas.O conjunto de 8 páginas (64Kb) é denominado extensão. Issosignifica que para armazenar as informações do índice de umadeterminada tabela, o SQL Server pode alocar várias páginas(depende do tamanho da tabela). Já no tipo de armazenamento colunar (columnstore), as infor-

mações são organizadas nas páginas de dados por colunas, ouseja, as páginas são alocadas e preenchidas com as informaçõesde cada coluna da tabela em questão.

A Figura 4 apresenta a aplicação do conceito de columnstoreem um conjunto de dados.

Em uma rápida comparação entre as Figuras 3 e 4 , pode-seobservar claramente a mudança de abordagem entre o armazena-mento de dados baseado em linhas e o armazenamento baseadoem colunas. O principal ponto a se observar neste momento é aforma como as páginas de dados são preenchidas.

Existem outros dois termos que aparecem na Figura 4: “Seg-ment” e “Row Group”. Nos índices columnstore, um segmentarmazena informações de uma coluna que pertence a um grupoespecífico de linhas, conhecido como row group. Na prática, umrow group pode agrupar 220 linhas (o que representa 1.048.576linhas do conjunto de dados).

Portanto, existe um segment para cada combinação de coluna

e row group. Cada um destes segments é comprimido e armaze-

8/18/2019 SQL Magazine 13665676577592


Índice columnstore na práticaPara demonstrar a utilização de índices columnstore, foi pre-

parado um ambiente com SQL Server 2014 com a base de dadosde exemplo fornecida pela Microsoft: AdventureWorksDW. Esta

base possui o formato de um Data Warehouse que, como men-cionado anteriormente, é o tipo de ambiente mais recomendadopara utilização de índices columnstore.

Primeiramente é executada uma consulta utilizando um índiceclusterizado. Em seguida, a mesma consulta é executada contrauma base de dados com um índice columnstore. Ao final sãoapresentadas as principais diferenças de desempenho entre asduas execuções.

Foi criada uma tabela (vide Listagem 1) com base nas tabelasFactInternetSales e DimSalesTerritory da base de dados Adventu-reWorksDW. O objetivo é obter uma massa de dados maior paraque seja possível demonstrar o real impacto de desempenho

fornecido pelo índice columnstore.Na Listagem 2 é apresentado o comando de INSERT utiliza-do para efetuar a carga da massa de dados na tabela criada naListagem 1. Para essa carga de dados foi efetuado um JOIN comas tabelas FactInternetSales e DimSalesTerritory. Como é mostradona linha 12, este comando de INSERT (Listagem 2) será repetido3.500 vezes para a construção da massa de dados.

As estatísticas de I/O e de tempo do SQL Server foram habilita-das para efetuar os testes de desempenho do índice columnstore(linhas 14 a 18 da Listagem 2).

Para efetuar o teste foi construída a consulta da Listagem 3.Nesta consulta foram utilizadas algumas funções de agregação:a soma de UnitPrice , a média de UnitPrice e a soma de TaxAmt. Por

fim, os dados foram agrupados por SalesTerritoryCountry.

nado separadamente em tipos de dados LOB do mecanismode banco de dados do SQL Server.

Por fim, as consultas feitas em tabelas que utilizam índicescolumnstore usam o modo de processamento “batch”. Este é

um mecanismo de processamento de consultas baseado emvetor que se beneficia de todas as vantagens proporcionadaspela estrutura de armazenamento em colunas.

Figura 4. Armazenamento em colunas

Considerações sobre desempenhoO formato de armazenamento de dados em colunas ofe-

rece algumas vantagens em relação ao formato de arma-zenamento em linhas, entre estas vantagens destacam-sea capacidade de comprimir os dados de uma forma mais

eficiente e o melhor desempenho na execução de algunscomandos SELECTs.

Comandos SELECTs que buscam informações de apenasalgumas colunas de uma tabela podem se beneficiar com autilização de índices columnstore.

Ao criar um índice deste tipo na tabela, o mecanismo de banco de dados é capaz de buscar as informações necessá-rias nas páginas de dados específicas em que as informa-ções estão armazenadas (ou seja, é possível acessar apenasas páginas de dados que armazenam as informações dascolunas desejadas), reduzindo assim as operações de I/O,usualmente responsáveis pelo maior tempo de processa-

mento de uma consulta.Como as informações das colunas são armazenadas em uma

mesma página de dados, o processo de compressão dos dadostambém é otimizado. Isso é possível porque as informaçõesde uma mesma coluna possuem um padrão semelhante etipicamente são mais redundantes quando comparadas àsinformações das linhas de uma tabela (que possuem colunasde diferentes tipos de domínios de informação).

Este fato simplifica a compressão dos dados e garante ocarregamento de mais informações em memória. Com estaotimização do uso de memória, o banco de dados reduz asoperações de acesso ao disco, e novamente temos um ganho

de desempenho pela redução de operações I/O.

Listagem 1. Criação 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. População da tabela TableInternetSales.

01 INSERT INTO TableInternetSales02 SELECT03 ST.SalesTerritoryCountry,04 UnitPrice,05 TaxAmt06 FROM07 FactInternetSales FS08 JOIN09 DimSalesTerritor y ST10 ON11 FS.SalesTerritoryKey = ST.SalesTerritoryKey12 GO 35001314 SET STATISTICS IO ON15 GO1617 SET STATISTICS TIME ON18 GO

8/18/2019 SQL Magazine 13665676577592

26/68

Dominando os índices columnstore


Primeiramente, a consulta da Listagem 3 foi executada com baseem um índice clusterizado. Em seguida foi criado um índice co-lumnstore na tabela TableInternetSales (vide Listagem 4) com basenas colunas SalesTerritoryCountry , UnitPrice e TaxAmt e a consulta

foi executada novamente.

Conforme apresentado na Figura 5, é possível observar que nestecaso o desempenho da consulta melhorou consideravelmente apósa criação do índice columnstore. O número de leituras lógicas caiupara zero. Isso acontece porque neste tipo de índice as informaçõesdas colunas são armazenadas em uma mesma página de dadosfacilitando o acesso aos dados.

Também é possível observar que o tempo de CPU e o tempo deexecução foi diminuído aproximadamente em 98% e 96%, respec-

tivamente. Vale ressaltar neste ponto que estas taxas de melhoriapodem variar de acordo com o ambiente em que a consulta estásendo executada.

Listagem 3. Query construída para o teste de performance.

SELECT

SalesTerritoryCountry,

sum(UnitPrice) SUMUnitPrice,

AVG(UnitPrice) AVGUnitPrice,

Sum(TaxAmt) TaxAmt

FROM

TableInternetSales

GROUP BY

SalesTerritoryCountry;

GO

Listagem 4. Criação do Columnstore Index.

CREATE NONCLUSTERED COLUMNSTORE INDEX INDXCLS_SALESINTERNET

ON TableInternetSales (SalesTerritoryCountry, UnitPrice, TaxAmt);

Figura 5. Comparativo das estatísticas de execução antes e depois da criação do columnstore index

Principais diferenças entre as versões SQL 2012 e 2014A versão do SQL 2012 apresenta algumas limitações quanto

ao uso de índices columnstore. Entre as principais restriçõesestão:

1) apenas índices não clusterizados são permitidos;2) ao utilizar um índice columnstore a tabela se torna somenteleitura (índice não atualizável).

A versão 2014 do SQL Server trouxe algumas novidades, pas-sando a permitir o uso de índices clusterizados atualizáveis. Noentanto, há restrições quanto ao uso de índices columnstore dotipo clustered , entre elas o fato de não ser possível combinar outrosíndices na mesma tabela e o fato de não ser possível definir restri-ções do tipo unique, chave primária ou chave estrangeira.

Além disso, todas as preocupações de uma estratégia demanutenção de índices devem ser levadas em consideração no

momento de definir como as tabelas serão indexadas.Índices columnstore podem ser usados em qualquer bancode dados do SQL Server. Porém, ao utilizá-los em ambientesanalíticos, existem grandes oportunidades para melhorar odesempenho das consultas pela própria característica deste tipode ambiente (tabelas com grandes volumes de dados e históricosde informação).

Avalie sua aplicação em projetos de Business Intelligence , nastradicionais estruturas de Data Warehouse ou Data Marts, porexemplo. Neste tipo de projeto é comum o consumo de infor-mações por processos ad-hoc ou relatórios.

Como primeiro passo, levante quais são as informações mais

selecionadas e mais filtradas pelo

Documents

SQL Magazine 13665676577592