ISSN 1677918-5

9 771677 918004 00149

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

149ª Edição - 2017 - ISSN 1677918-5

EXPEDIENTE 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
Editor Atendimento ao leitor em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site
Rodrigo Oliveira Spínola (rodrigo.devmedia@gmail.com) A DevMedia possui uma Central de Atendimento on-line, onde você SQL Magazine, entre em contato com os editores, informando o título e
pode tirar suas dúvidas sobre serviços, enviar críticas e sugestões e mini-resumo do tema que você gostaria de publicar:
Subeditor
falar com um de nossos atendentes. Através da nossa central também
Eduardo Oliveira Spínola Rodrigo Oliveira Spínola - Editor da Revista
é possível alterar dados cadastrais, consultar o status de assinaturas rodrigo.devmedia@gmail.com
Consultora Técnica e conferir a data de envio de suas revistas. Acesse www.devmedia
Anny Caroline (annycarolinegnr@gmail.com) .com.br/central, ou se preferir entre em contato conosco através do
telefone 21 3382-5038.
Jornalista Responsável
RODRIGO OLIVEIRA SPÍNOLA
Kaline Dolabella - JP24185 Publicidade Editor Chefe da SQL Magazine, Mobile
publicidade@devmedia.com.br – 21 3382-5038 e Engenharia de Software Magazine.
Capa e Diagramação
Professor da Faculdade Ruy Barbosa,
Romulo Araujo
Anúncios – Anunciando nas publicações e nos sites do Grupo DevMedia, uma instituição parte do Grupo DeVry.
você divulga sua marca ou produto para mais de 100 mil desenvolvedores
Doutor e Mestre em Engenharia de
de todo o Brasil, em mais de 200 cidades. Solicite nossos Media Kits, com
detalhes sobre preços e formatos de anúncios. Software pela COPPE/UFRJ.

Conteúdo sobre Boas Práticas

04 – Planejamento e governança em Data Warehouses

[ Rodrigo Diniz ]
Sumário
Conteúdo sobre Boas Práticas

13 – Oracle Audit Vault Server

[ Darlan Bastos ]

Artigo no estilo Mentoring

22 – IOPS: determinando o throughput no Oracle

[ Renato Rosa Peres ]

Conteúdo sobre Boas Práticas

29 – Arquitetura do SQL Server Database Engine

[ Henrique Ribeiro ]

Conteúdo sobre Boas Práticas

38 – Descoberta de conhecimento utilizando o processo KDD

[ José Adair Fabricio, Jones Granatyr e Heitor Murilo Gomes ]
Planejamento e
governança em Data
Warehouses
Conhecendo melhor os conceitos de arquitetura,
qualidade e modelagem de um Data Warehouse
N Fique por dentro
os dias atuais, que muitos autores classificam
como “Era do Conhecimento”, estamos em
um momento em que a corrida frenética por
tecnologia e informação alcança proporções grandiosas
e direciona a atenção das organizações para as técnicas
de BI (Business Intelligence) e em contratações de pro-
fissionais que possam executá-las. Esses profissionais
provêm tanto da área de Tecnologia da Informação
e Comunicação (TIC) quanto de outras áreas, como
analistas de marketing, analistas comerciais, analistas
financeiro, etc.
Esses profissionais, principalmente os de TIC, normal-
mente são encarregados tanto da extração quanto na
disponibilização da informação em relatórios, painéis
ou dashboards. A informação disponibilizada será
considerada íntegra, parcialmente íntegra ou inválida
pelos administradores, dependendo de sua expertise
no negócio. Quando aceitas, as tomadas de decisão da
organização serão realizadas sobre essas informações e
todo seu resultado acarretará em lucros ou prejuízos à
empresa. Destacado a importância desse cenário, vere-
mos neste artigo conceitos e técnicas de como montar
um Data Warehouse e uma introdução a governança e
qualidade nas informações antes que virem dados analí-
ticos, adicionando conceitos de integridade e qualidade
e as principais formas de disponibilizar a informação,
tanto no armazenamento quanto no compartilhamento.
Conceitos para implantação de Governança da Quali-
dade da Informação
A implantação de BI normalmente está acompanhada
de uma grande mudança na cultura da organização e,
com isso, é importantíssimo o conhecimento e uso de
4 SQL Magazine • Edição 149
Data warehouses permitem o armazenamento e análise de grande
quantidade de informação, e têm sido um recurso muito utilizado
por organizações com o objetivo de auxiliar o processo de tomada de
decisão. Este artigo é destinado a quem queria adquirir uma forte base
conceitual sobre Data Warehouses, desde sua modelagem dimensional
aos passos necessários para a implantação de conceitos de governança
da qualidade da informação. Também serão abordados os conceitos
de uma arquitetura em um Data Warehouse, Staging Area e ETL, com
exemplos em SQL Server e SSIS.
certas práticas para manter o BI altamente disponível e com quali-
dade (governança). Devemos ter em mente para que para obtermos
maturidade dos processos, devemos adotar certos policiamentos
sob os seguintes conjunto de fatores:
1. Preocupação Organizacional: preocupação da organização
desde a segurança à qualidade dos dados, sendo estratégico ou
exigências regulatórias (leis, por exemplo);
2. Definição de Papeis: definição dos papéis sob os recursos de da-
dos. Exemplo: Financeiro, Gerência, Produtores, Mantenedores, etc.;
3. Definição das Políticas: regras, diretrizes e orientações de
alto nível que apontem os caminhos para a implementação da
governança de dados. Esses devem ser revistos periodicamente
e ser definidos pela alta direção da empresa;
4. Definição de Métricas: os custos de manter a governança de
dados normalmente tornam-se o grande empecilho para a manu-
tenção da qualidade. Para isso, é necessário definir métricas que
justifiquem tais investimentos;
5. Gerência de Riscos: quais os riscos de manter os dados sem
qualidade? É necessário ter um mapeamento sobre os riscos de
possuir determinados tipos de dados fora da zona de auditoria
da qualidade. Esses planos devem constar classificações, prio-
rizações e ações de monitoramento;
6. Segurança, Privacidade e Aderência: aspectos que controlam
o uso dos dados, associadas à gerência de riscos. A segurança
deve ser tanto física (arquivos e backups) quanto lógica (segu-
rança, acesso, etc.). A privacidade deve estar alinhada às per-
missões por papéis. Já os aspectos de aderência são baseados
as normas regulatórias (ITIL, Cobit, Sox, etc.);
7. Arquitetura de Dados: definição da arquitetura de acordo
com os ambientes coorporativos, devendo ser adequado aos
processos transacionais (vendas, operações financeiras, opera-
ções de RH, etc.) e aos processos informacionais (inteligência
de negócio, DW, Data Marts, etc.);
8. Qualidade dos Dados: adoção de processos para garantir a
qualidade dos dados;
9. Classificação dos Dados e definição dos metadados: este
ponto é fundamental no quesito maturidade da governança
de dados, consistindo em uma catalogação de todos os dados
da empresa, classificando e enriquecendo o seu conteúdo.
Pode ser definido como dicionário ou repositório de dados,
podendo ser aplicado conceitos de gestão de conhecimento,
dando autonomia aos dashboards ou painéis da área de TI
aplicando, por exemplo, novas metas de vendas aos relatórios
correlacionados às vendas;
10. Gerência do Ciclo de Vida da informação: assunto pouco
abordado na implantação do BI em uma empresa, consiste em
definir até quando a informação pode ou deve ser utilizada;
11. Auditoria: define a auditoria nos processos ETL, garantindo
assim sua qualidade (principalmente integridade) e medições
(por exemplo, volume de acesso).
Para medir o nível de maturidade da governança de dados, a
empresa de consultoria Gardner Group (empresa de consulto-
ria e análise de tendências em TI) definiu o modelo Enterprise
Information Management (EIM) com seis níveis de maturidade:
• Nível 0 - Unaware (Ausente): nesse nível as extrações das
informações estratégicas normalmente são definidas pela ne-
cessidade x prazo curto e, com isso, a qualidade fica de lado.
Normalmente a informação é utilizada apenas por uma área,
não existindo compartilhamento;
• Nível 1 - Aware (Consciente): a informação já é vista como
um ativo e, com isso, começam as estratégias de definição dos
primeiros padrões básicos de qualidade, evidenciando os riscos
da informação advinda de algumas fontes;
• Nível 2 - Reactive (Reativo): com a consciência da informação
como ativo, nesse nível ela passa a ser utilizado em áreas dife-
rentes. Nesse nível é importantíssimo deixar claro a(s) real(is)
utilidade da informação, por exemplo, se a informação foi criada
para o departamento de Marketing para extrair estratégias para
atividades “A” e “B”, pode fornecer um falso resultado quando
utilizado pelo departamento Comercial para atividades “C”;
• Nível 3 - Proactive (Proativo): a arquitetura da informação
é criada e passa a ser mantida, as definições do papeis são
elaboradas e as informações são vistas com enorme valor para
as definições estratégicas da empresa. Aqui é possível implantar
conceitos de Self BI;
• Nível 4 - Managed (Gerenciado): os recursos críticos ganham
evidencia e são definidas as políticas, padrões e procedimentos
aceitos por toda a empresa. O monitoramento das informações
passa a ser algo crítico também e normalmente é necessária a
criação de um departamento para controle delas;
• Nível 5 - Effective (Efetivo): a cadeia de suprimentos da infor-
mação é criada e a informação passa a ser vista com enorme valor
para a alta gestão. Recursos de hardware e sistemas especialistas
em extração de dados e criação de painéis, dashboards, cockpits,
report history entre outros recursos de BI são indispensáveis
para a manutenção e disponibilização da informação com valor.
Nesse nível, a informação traz reais vantagens competitivas para
a organização.
Escopo da informação
Uma das quinze dimensões da qualidade da informação é a
dimensão da abrangência/escopo da informação. Vamos imaginar
um cenário no qual somos analistas de sistemas do departamento
de tecnologia da informação de uma rede varejista de venda de
camisas esportivas e um gerente regional (cliente interno) faz o
seguinte pedido: “preciso das vendas de nossas lojas, por mês, em
que eu saiba qual é o melhor vendedor...”. Logo, podemos con-
cluir os requisitos que ele precisa: um ranking mensal por valor
de vendas dos vendedores das unidades de negócios (business
units, termo muito comum em ERPs). Ao desenvolver, utilizando
nossos conhecimentos de extração, extraímos um relatório no qual
apresentamos as colunas indicadas na Tabela 1.
Mês Unidade Vendedor Total em Vendas
Tabela 1. Relatório extraído a partir do desenvolvimento
E disponibilizamos uma planilha na qual ele pode fazer os
filtros de ano, mês e unidade de negócios. Ao apresentarmos ele
pergunta: “Posso ordenar por quantidade vendida de um de-
terminado Grupo de Itens?”. Obviamente não! Nosso relatório é
simples e direcionado aos requisitos iniciais. A partir desse ponto
começam só as lamentações por parte do cliente: “A TI nunca
entrega o que eu quero...”, “Eu imaginei que estava implícito o
que eu queria...”, como também pela parte da TI: “O cliente não
sabe pedir...”, “não estava no escopo...”, entre outras frases clichês
que servem apenas para criar um clima de perda de credibilidade
geral de ambas as partes. Extrair o que o cliente deseja não é uma
tarefa fácil, porém tentar adivinhar o que o cliente quer também
não é um bom caminho. Extração de dados sem no mínimo duas
interações normalmente não terminam em sucesso, e por não
existir uma técnica precisa para o processo de levantamento de
requisitos, um bom caminho é uma abordagem simples seguida
de um protótipo (modelo). Mais à frente veremos mais exemplos
de como obter essas informações.
Edição 149 • SQL Magazine 5
Planejamento e governança em Data Warehouses
Arquitetura de um Data Warehouse
O Data Warehouse (DW) é um repositório de dados que normal-
mente armazena uma grande quantidade de informações para
tomadas de decisões e é utilizado somente leitura, não sendo reco-
mendado que exista inserção de dados por parte de seus usuários.  - Seus dados não devem sofrer alterações não divulgadas;
Considerado por muitos como o inventor do DW, o cientista de
dados Bill Inmon o define como “uma coleção de dados orientados
por assuntos, integrados, variáveis com o tempo e não voláteis,
para dar suporte ao processo de tomada de decisão”. Para ele, trata-
-se de um processo em andamento que aglutina dados de fontes
heterogêneas (de naturezas distintas), incluindo dados históricos. 
Portanto, a primeira e marcante característica de um DW é
ser “orientado a assuntos”, sendo utilizado para analisar um
assunto particular do negócio. Exemplo: Vendas canceladas para
clientes com determinadas características, rotação de estoque por
trimestres, tributações relacionadas a determinadas atividades,
etc. Além dessa característica, podemos citar:  Dentro de um DW, é comum encontrarmos vários Data Marts,
• Centralizador de assuntos: um DW provém de integração de
dados de fontes de naturezas distintas, orientados a um assunto.
Por exemplo: uma parte da venda estar no sistema ERP, algumas
informações dos clientes estar no sistema CRM e outras estarem
em uma planilha de dados;
• Variáveis com o tempo: quando implantado, um DW pode ficar
com as informações históricas de determinadas atividades da
empresa, liberando dos sistemas transacionais essas informações.
Com isso, esses sistemas podem ganhar performance por não ter
que lidar mais com informações muito antigas, guardando apenas
os dados mais recentes;
• Não voláteis: um DW não deve alterar seus dados históricos.
Quando identificada uma necessidade, deve ser feito um comuni-
cado avisando as áreas que trabalham com essas informações. De-
pendendo da criticidade da alteração, ela pode afetar todas as
tomadas de decisões realizadas até então.  mas que, devido a conceitos diferentes da modelagem relacional
 
Ralph Kimball, um pioneiro quanto às definições de DW, desta-
cou que para se construir um DW é necessário aplicar às necessi-
dades específicas dos usuários e aos bancos de dados específicos,
um conjunto de ferramentas e técnicas de projeto. Com base nisso,
explicaremos dois importantes estágios que devem ser aplicados
entre as fontes de dados e o DW: Staging Area e ETL.
Um DW possui características e conceitos diferentes de um banco
relacional, como destacado a seguir:
• Banco relacional:
- Geralmente utilizados para suportar as atividades operacionais;
- Utiliza conceitos de modelagem relacional;
- Normalizado;
- É utilizado por uma ou mais aplicações específicas;
- Preocupação com a informação atual;
- Seus dados podem sofrer alterações a qualquer momento;
- Serviço voltado no desempenho de retorno dos detalhes.
• Data warehouse:
- Os dados são voltados ao planejamento e relatórios;
- Utiliza conceitos de modelagem multidimensional;
6 SQL Magazine • Edição 149
- Desnormalizado;
- Integrador de dados, sendo que a origem das informações pode
provir de várias fontes;
- Informações históricas e consolidadas;
- Serviço voltado no desempenho de retorno das agregações.
 
Para os exemplos a seguir, utilizaremos uma base relacional
simulando um sistema de vendas utilizado por uma distribuidora,
mantida no MS SQL Server 2014, como mostra a Figura 1.
Diagrama do banco de dados relacional
Observe que utilizamos conceitos de Pascal Case para o nome
das tabelas e suas colunas, além de pluralizar o nome das tabelas
e singularizar o nome das colunas, técnica muito eficiente para
padronização dos metadados.
que nada mais são que grupos de assuntos separados logicamen-
te, ou seja, enquanto o DW possui uma visão mais abrangente
do negócio, os Data Marts possuem uma visão mais focada por
setor. Alguns especialistas acreditam que para a formação de um
DW é necessário minerar as informações de cada área especifica
via Data Mart, porém isso não é uma regra geral. Como um DW
deve ser elaborado conforme a necessidade das áreas de negócio,
ele precisa dar condições de navegações para chegar a níveis de
granularidade extremos. Para isso, existem os conceitos de arqui-
tetura Top-down (navegação consolidada para o nível granular) e
Bottom-UP (navegação granular para o nível consolidado).
Uma das características principais do Data Warehouse é a mode-
lagem dimensional, que segundo Kimball, é a única técnica viável
para bancos de dados que devem responder consultas em um DW.
Esse assunto muitas vezes confunde os desenvolvedores de siste-
(normalmente utilizada para criação de sistemas transacionais),
está relacionado a termos como “Cubo”, “Tabelas Fato”, “Dimen-
sões”, “Medidas”, entre outros. Para que possamos adentrar em
exemplos práticos de modelagem de dados, é necessário maior
conhecimento na modelagem dimensional que veremos a seguir.
Modelagem Dimensional
A modelagem dimensional é uma técnica que permite uma
visão consolidada para um ou mais grupos de informações/ca-
racterísticas (chamadas de dimensões) que facilita a investigação,
o resumo e a organização de dados para a análise de negócios. Ela
normalmente é usada para DW relativo às ações (fatos) das ativi-
dades históricas da organização (proprietária da fonte de dados
a ser analisada). Formado por relações entre dimensões e fatos,
visa uma alta performance para execução de consultas analíticas.
O modelo dimensional oferece, clara e diretamente, os elementos
de que se precisa para buscar as informações (“fato”) via dimensões
de referências.
Uma modelagem dimensional deve ser planejada de forma
atômica, ou seja, deve suportar filtros, consultas agrupadas, cate-
Figura 1. Modelo da base de dados

gorizadas e satisfazer as regras de negócio. Os usuários Pergunta Atributo Tipo

devem poder analisar tanto a informação totalizada What (o quê?) Produto, Categoria Dimensão Produtos, Dimensão Categorias
quando chegar aos detalhes mínimos desejados. When (quando?) Data de Entrega Dimensão Tempo
Para armazenar a informação, como em um modelo
Dimensão Clientes, Dimensão Represen-
relacional, é necessária a criação de entidades (tabelas) Who (quem?) Cliente, Representante
tantes
com atributos (colunas). A base para a modelagem Dimensão Endereços, Dimensão CEPs,
Where (onde?) Local de Entrega
dimensional são as tabelas de fatos, que possuem Dimensão Cidades, Dimensão Estados
uma história de uma ação relacionada diretamente Why (por quê?) Necessidade do Cliente Não se aplica neste exemplo
com os indicadores numéricos da mesma (medidas): How (como?) Tipo de Venda Dimensão TipoVendas
• Tabela Fato: principal tabela no DW, onde são en- How Much
contradas as informações de um “fato” ocorrido, ou Preço de Custo Medida PrecoCusto
(quanto custa?)
seja, o histórico de uma ação armazenada. Uma tabela How Many (quanto?) Quantidade Medida Quantidade
fato deve possuir grãos únicos (possuindo ligação
com as tabelas de dimensão) com suas respectivas Tabela 2. Fato – Vendas (de Produto)
medidas (números calculáveis). Outra característica
importante da tabela Fato é garantir que a granularidade da É recomendado que a tabela Fato, junto às tabelas de Dimensão,
informação deve ter, exatamente, o mesmo nível de detalhe. Não possua em suas informações a resposta para o 5W3H (“What?”,
é recomendado que em uma linha pudesse se ver o tipo de um “Who?”, “When?”, “Where?”, “Why?”, “How?”, “How Much?” e
produto e na outra não; “How Many?”), como exemplificado na Tabela 2.
• Tabela Dimensão: contém as informações descritivas e quali-
ficadoras do negócio. Exemplo: Raças, Categorias, Cores, Produ- Além das tabelas Fato e Dimensão, a modelagem dimensional
tos, Cidades, Tempo, etc. Quando a ausência de informação na possui outros termos comuns, como:
tabela Fato for constatada, a mesma deve ser corrigida em suas • Medidas (measures): um valor numérico, encontrado nas Tabe-
dimensões através de uma nova categoria. Porém, essa ausência las Fato, que representam a contabilização de uma ação armaze-
pode diminuir a confiabilidade na informação. nada. Exemplo: Quantidade, Valor Unitário e Valor Total de um

Edição 149 • SQL Magazine 7

Planejamento e governança em Data Warehouses
produto em uma Nota Fiscal. Ao ser consultada, é agregada com
uma função: soma, média, mínimo, máximo, etc.;
• Dimensão (dimension): uma lista independente que categoriza
uma informação do Fato. Exemplo: uma dimensão de categoria
de um produto, uma dimensão de qual sexo o cliente pertence,
uma dimensão que caracteriza o tipo de um animal, etc. Uma
dimensão pode ser analisada tanto como coluna quanto níveis
com subtotais;
• Grão: unidade de medida de um indicador de desempenho li-
gada a tabela Fato. Exemplo: Uma Ordem de Compra foi realizada
por um Comprador (grão), para uma Unidade (grão), para um
Departamento (grão), por um fornecedor (grão), etc.;
• Atributo: campo descritivo referente a uma dimensão;
• Chave Substituta (Surrogate Key): chave única da tabela no
DW, ou seja, o identificador exclusivo único da informação (Fato
ou Dimensão) não existente em nenhuma outra fonte de dados
originaria do DW (salvo em casos de coincidência);
• Chave de Negócio (Business Key): identificador exclusivo pro-
veniente da origem da informação. Uma entidade de dimensão
normalmente possui uma ou mais BK.  Modelo Estrela (Star) em cima das tabelas relacionais de vendas
Modelos conceituais da modelagem dimensional
Hoje, a modelagem dimensional possui dois modelos conceituais
de arquitetura:
Figura 2. Tabela Fato - Vendas (de Produtos). Cenário das tabelas envolvidas
8 SQL Magazine • Edição 149
• Modelo Estrela (Star Schema): mais simples de planejar, nesse
modelo todas as dimensões relacionam-se diretamente com a
tabela Fato. Conceitualmente, suas tabelas de dimensões não
são normalizadas e possuem descrições repetidas e, com isso, as
tabelas de dimensão costumam armazenar mais informações que
no modelo Snow Flake;
• Modelo Floco de Neve (Snow Flake): mais complexo de pla-
nejar, visando normalizar as tabelas de dimensões, o modelo
Floco de Neve também é constituído por tabelas dimensionais
relacionadas a uma tabela Fato, porém possui algumas tabelas
de dimensão que só se relacionam com elas mesmas. As tabelas
de dimensões possuem tabelas de dimensão auxiliares que
normalizam as descrições das tabelas de dimensões principais
e, com isso, ajudam a reduzir também o seu tamanho de ar-
mazenamento. Nesse modelo uma dimensão muito comum é a
de Tempo que possui, pelo menos, as dimensões auxiliares de
Ano, Mês e Dia.
 
Para o exemplo de modelagem dimensional, utilizaremos o
demonstradas anteriormente. Veja esse modelo na Figura 2.
Como optamos por utilizar o modelo estrela, iremos desnorma-
lizar as tabelas de dimensões auxiliares (em azul) para dentro da
tabela de dimensão (em verde) a que ela está vinculada. Apenas
no caso do endereço precisaremos também
descentralizar para dentro da dimensão
clientes. Como a tabela fato é o assunto a
ser extraído, e o assunto definido foi venda
de produtos, utilizaremos as duas tabelas
de vendas (em vermelho) como base da
tabela fato. O resultado é apresentado na
Figura 3.
Caso a fonte de dados seja pequena ou
não possua colunas de auditoria do tipo
data criação e data modificação, recomen-
damos o Modelo Estrela (Star). Alguns
especialistas gostam de controlar as sur-
rogate keys manualmente, nesse exemplo,
até pela baixa complexidade optamos em
utilizar a função de auto incremento do
SQL Server (identity).

Staging Area
Embora não obrigatório para criação
de um DW, consiste em um banco de
Figura 3. Modelo final
armazenamento temporário dos dados
antes de enviá-los para o data warehouse.
Nesse local, as informações são extraídas
dos sistemas transacionais (ERP, SCM,
CRM, etc.), transformadas e consequen-
temente carregadas para o DW. Esse
conceito é altamente dependente do ETL
e serve principalmente para não com-
prometer o desempenho dos servidores
(principalmente disco e memória) onde
estão os sistemas transacionais. Portan-
to, é recomendado que tanto o staging
area quanto o DW estejam em discos
diferentes dos sistemas transacionais e,
se possível, em servidores diferentes.
É comum que determinados assuntos no
Staging Area tenham ciclos diferentes,
ou seja, as informações provenientes
das vendas podem precisar de mais Figura 4. Exemplo de Staging Area
tempo para ser processadas do que as
informações de manufatura, quando, por
exemplo, estão em mais de um sistema de • Pré-cálculo de dados agregados; cialistas de TIC voltados apenas para
vendas. O staging area também pode ser • Carga imediata da base de dados ope- utilização dessas técnicas, comumente
considerado o local ideal para se aplicar racionais; encontrados pelas funções de Analistas
técnicas de Data Quality (Qualidade de • Armazenamento de processamentos de ETL ou Consultores de ETL. Um bom
Dados), uma vez que conceitualmente programados executados em diferentes planejamento e execução de técnicas ETL
o DW só recebe a informação, ou seja, a momentos. é indispensável para a criação de um data
informação é apenas adicionada e não   warehouse de sucesso.
deve ser modificada. Veja um exemplo Introdução ao ETL A sigla ETL significa Extract, Transform
na Figura 4. Um termo muito comum quando se and Load, que traduzindo de uma maneira
Funções aplicadas no Staging Area: fala de criação de um data warehouse simples nos leva ao “processo de extração,
• Data Quality; é ETL. No mercado atual, temos espe- transformação e carga” dos dados.

Edição 149 • SQL Magazine 9

Planejamento e governança em Data Warehouses
No cenário atual das empresas, normalmente encontramos
mais de um sistema transacional de controle das atividades dos
departamentos, além de dezenas de arquivos de texto, planilhas
eletrônicas, PDFs, entre outros utilizados como repositório de
informações. Para utilizar todos esses dados para a criação de um
data warehouse, normalmente é utilizado um sistema especialista
de ELT, como o SQL Server Integration Services (SSIS), que será
utilizado em nossos exemplos. Outro sistema especialista em ETL
muito conhecido é o Oracle Warehouse Builder.
Para o exem plo a seguir, utilizaremos a tabela fato e as tabelas
dimensões e extrairemos os dados das tabelas relacionais, ambas
detalhadas durante o artigo. Para isso, crie views (observe que
essas views apontam para o banco de dados relacional) indicadas
na Listagem 1.
Agora, abra o Microsoft Visual Studio, clique em New Project,
escolha o Template Business Intelligence e clique sobre o Projeto de
Listagem 1. Script de criação das views
Create View vFatoVendas
as  ,        categoria.Categoria                as ProdutoCategoriaNome
Select  
venda.VendaId                        as VendaBK
,        vendaItem.VendaItemId        as VendaItemBk
,        dataVenda.DataVendaKey        as VendaDataKey
,        venda.TipoVendaId                as VendaTipoBk
,        venda.RepresentanteId        as VendaRepresentanteBk
,        venda.ClienteId                        as ClienteBk
,        vendaItem.ProdutoId                as ProdutoBk
,        vendaItem.Quantidade        as Quantidade
,        vendaItem.Preco                        as Preco
 
From Distribuidora_OLTP.dbo.Vendas venda
Join Distribuidora_OLTP.dbo.VendasItens vendaItem on venda.VendaId = vendaItem.
VendaId
Join Distribuidora_DWStar.dbo.DimDatasVendas dataVenda on venda.DataVenda =
datavenda.DataVenda  Create View VDimVendasTipo
Go
  
Create View vDimClientes
as  ,        tipoVenda.TipoVenda                as VendaTipo
Select
cliente.ClienteId                        as ClienteBK
,        cliente.Nome                                as ClienteNome
,        tipocliente.TipoCliente                as ClienteTipo
,        endereco.Logradouro                        as ClienteLogradouro
,        cep.CEP                                                as ClienteCEP
,        cidade.Cidade                                as ClienteCidade
,        estado.Estado                                as ClienteEstado
 
From Distribuidora_OLTP.dbo.Clientes cliente
Join Distribuidora_OLTP.dbo.TipoClientes tipocliente on cliente.TipoClienteId = tipo-
cliente.TipoClienteId
Join Distribuidora_OLTP.dbo.Enderecos endereco on cliente.EnderecoId = endereco.
EnderecoId
Join Distribuidora_OLTP.dbo.CEPs cep on endereco.CepId = cep.CepId
Join Distribuidora_OLTP.dbo.Cidades cidade on cep.CidadeId = cidade.CidadeId
Join Distribuidora_OLTP.dbo.Estados estado on cidade.EstadoId = estado.EstadoId 
Go
 
Create View vDimProdutos
as  From Distribuidora_OLTP.dbo.Vendas venda
Select
produto.Produtoid                as ProdutoBK
10 SQL Magazine • Edição 149
Integration Services. Defina o nome e o local para criar o projeto
e clique no botão OK. No Control Flow, adicione um componente
do tipo Tarefa Fluxo de Dados (Data Flow Task) e renomeie para
“Dimensão Clientes”. O resultado disso pode ser visto na Figura 5.
Dê um duplo clique em Dimensão Clientes e crie um componente
Origem OLE DB (Other Sources) e renomeie para Origem Clientes.
Em seguida, dê um duplo clique no Origem Clientes e clique no
botão New para adicionar um novo OLE DB connection manager e
configure conforme sua origem de dados. Agora selecione a view
vDimClientes, adicione o componente Comando OLE DB, reno-
meie para Limpar DimClientes e arraste a setinha azul do Origem
Clientes para ele e dê um duplo clique no Limpar DimClientes e
adicione a sua conexão OLE DB.
Na aba Component Properties, adicione o comando Truncate
Table DimClientes para limpar toda a tabela DimClientes após o
carregamento full das informações da vDimClientes e adicione
,        produto.NomeProduto                as ProdutoNome
 
From Distribuidora_OLTP.dbo.Produtos produto
Join Distribuidora_OLTP.dbo.Categorias categoria on produto.CategoriaId = categoria.
CategoriaId 
Go
 
Create View vDimRepresentantes
As 
Select
representante.RepresentanteId        as RepresentanteBK
,        representante.Nome                                as RepresentanteNome
 
From Distribuidora_OLTP.dbo.Representantes representante
Go
 
As 
Select 
tipoVenda.TipoVendaId        as VendaTipoBK
 
From Distribuidora_OLTP.dbo.TipoVendas tipoVenda 
Go
 
Create View vDimDatasVendas
As 
Select
Distinct 
venda.DataVenda                                        as DataVenda 
,        YEAR( venda.DataVenda )                        as AnoVenda
,        Month ( venda.DataVenda )                as MesVenda 
,        Convert(
varchar(10)
,        DateName (
month
,        venda.DataVenda
 
)
)                                                                as MesDescricaoVenda 
,        Day ( venda.DataVenda )                        as DiaVenda
 
Go

Figura 5. Criando a dimensão Clientes
Figura 6. Criando o fluxo de dados
Figura 7. Mapeamento das colunas
o componente Destino OLE DB (Other
Destinations), renomeie para Destino
DimClientes e arraste a setinha azul do
Limpar DimClientes para ele, conforme
mostra a Figura 6.
Feito isso, dê um duplo clique em Destino
DimClientes, adicione a conexão OLE DB
e selecione a tabela DimClientes e clique
em Mappings para criar o relacionamento
entre as colunas. Por utilizarmos o nome
das colunas nas views iguais aos nomes
das colunas nas tabelas de dimensões, o
mapeamento é automático (vide Figura 7).
Caso você tenha optado por utilizar outro
nome, você pode realizar o mapeamento
manualmente.
Agora aperte o F5 e observe o resultado.
Refaça as operações em todas as outras
dimensões, ligando cada uma das dimen-
sões na sequência. Após isso, adicione um
novo componente Tarefa Fluxo de Dados
(Data Flow Task) e renomeie para Fato Ven-
das, como demonstra a Figura 8.
O próximo passo é adicionar um com-
ponente Origem OLE DB (Other Sources)
e renomear para Origem Fato Vendas.
A origem das informações de Fato será a
view vFatoVendas. Após isso, adicione um
componente de Pesquisa e renomeie para
Lookup Clientes e ligue a seta da origem
Fato Vendas, dê um duplo cliente no Lookup
Clientes e clique em Connection, adicio-
Figura 8. Configurando o fluxo de controle
Edição 149 • SQL Magazine 11
Planejamento e governança em Data Warehouses
nando a tabela DimClientes. Em seguida,
clique em Columns e clique com o botão
direito no Available Input Columns e em Edit
Mappings, selecionando os campos Cliente-
BK para Input e Lookup Columns.
Figura 9. Lookup Transformation Editor
Figura 10. Conclusão do mapeamento
12 SQL Magazine • Edição 149
Agora, sobre o Available Lookup Columns,
clique sobre a caixa de seleção do Clien-
teKey e clique em Ok (vide Figura 9).
Repita para as demais dimensões, me-
nos a DimDataVenda, pois a mesma já está
sendo tratada na view vFatoVendas e ligue
todas as dimensões com um componente
de Destino OLE DB com o nome de Fato
Vendas, apontando para a tabela FatoVen-
das. Ao ligar, selecione o Output do tipo
Saída de Correspondência de Pesquisa. Caso
você queira ocultar ou mudar a descrição
das setas, selecione a seta desejada e mude
a propriedade (F4) Path Annotation para
a opção desejada, no exemplo deixamos
como Never. Dê um duplo clique sobre o
Fato Vendas e mapeie conforme a Figura 10.
Aperte o F5 e observe o resultado.
Como pudemos notar, planejar e criar
um data warehouse com qualidade e go-
vernança é algo que exige muito esforço,
estudo e uma forte arquitetura, uma vez
que a modelagem dimensional envolve
conceitos não habituais pela maioria dos
profissionais de TIC. Além dos conceitos,
vimos também exemplos básicos e simples
de como criar um DW no modelo estrela
utilizando o SQL Server e o SSIS. Obvia-
mente, para manter a escalabilidade, a in-
tegridade e a performance deve-se utilizar
muitos outros recursos que não couberam
ser abordados nesse artigo.
Autor
Rodrigo Diniz
rodrigo.bdiniz@hotmail.com
MBA em Gestão da Informa-
ção, possuo mais de 12 anos
de experiência em desenvolvimento de
Sistemas .NET em vários seguimentos
distintos. Possuo certificação MCPD em ASP.NET e MCITP
MS SQL Server. Há 3 anos venho atuando em Business
Intelligence e Auditoria/Qualidade da informação no
Sistema Poliedro de Ensino.
corOracle Audit Vault
Server
Credibilidade em TI com auditoria centralizada e
inviolável
N Fique por dentro
as camadas mais críticas dos ambientes de
infraestrutura de TI (por exemplo, bancos
de dados, firewall, sistemas operacionais e
controladores de identidade) há recursos voltados para
auditoria das operações. Essas ferramentas são indispen-
savelmente utilizadas quando as organizações mantêm
políticas de segurança interna ou por força de lei, visan-
do ter capacidade de auditar acesso e modificações de
informações sigilosas, sensíveis, de segredo de estado
ou simplesmente estratégicas no mercado. São nesses
momentos que a TI precisa responder adequadamente
à área de negócio com soluções aprimoradas de segu-
rança, demonstrando preparo e não dando nem mesmo
a impressão de possuir alguma vulnerabilidade.
De qualquer forma, a heterogeneidade das camadas
de TI coloca dúvidas sobre a autenticidade dos registros
antigos de auditorias automáticas. Por exemplo, em
bancos de dados, há risco de uma consulta ser realizada
sem deixar vestígios ao acessar informações sensíveis?
Os registros de auditoria armazenados pelo banco de
dados estão protegidos de remoção intencional? Ao
ocorrer alguma modificação na estrutura de tabelas
ou mesmo manipulação de dados em massa, como a
organização é alertada preventivamente?
O Oracle Audit Vault Server (AV Server) é capaz de
responder essas questões estratégicas para a segurança
dos ambientes de TI, pois coleta as auditorias de diversos
sistemas operacionais e bancos de dados, guardando de
uma forma segura e com papéis específicos de adminis-
tração da ferramenta, sendo viável que administradores
de bancos de dados possam gerenciar o ambiente em
nível de infraestrutura e que as responsabilidades das
informações fiquem a cargo de auditores, que podem
ser avisados sobre incidentes auditados, como quando
algum comando SQL/DDL é executado em ambiente de
produção indevidamente.
O AV Server não audita, ele não tem relação direta com
o Oracle Database Vault.
Para atender as exigências de padrões internacionais de segurança
da informação, como a norma ISO 17799, e de padrões de prevenção
de fraudes, como a legislação norte-americana Sarbanes-Oxley, os
registros de auditoria em sistemas operacionais e em bancos de dados
precisam de um armazenamento inviolável. Ao receber processos de
auditagem, as organizações que possuem ferramentas de software
para a proteção de dados de auditoria têm mais credibilidade acerca
das informações históricas. O Oracle Audit Vault Server (AV Server) é um
desses produtos disponíveis no mercado. Ele é desenvolvido pela Ora-
cle Corporation com excelente integração ao SGBD Oracle Database.
O AV Server é capaz centralizar registros de auditoria em um ambiente
seguro, gerar alertas sobre incidentes de segurança e também dispo-
nibilizar uma base para consulta e análise de relatórios. Neste artigo, o
AV Server é contextualizado e abordado em seus aspectos essenciais.
Qualquer um pode executar a instalação de um AV Server, sendo
possível ter um AV Server sem precisar instalar um Oracle Data-
base Firewall, o contrário não. Não é possível instalar o AV Server
(versões recentes) em um sistema operacional, pois ele é o próprio
sistema operacional. Essas são respostas comuns de um consultor
dessa solução para as perguntas que surgem com frequência por
administradores de bancos de dados e de sistemas operacionais.
Algumas até assustam quem adquire o produto por pressão de
áreas de segurança ou auditores externos, sem ater-se a muitos
detalhes técnicos.
O uso do AV Server é recomendado para ambientes de TI com
missão crítica nas áreas que envolvem idoneidade absoluta, como
bancos de dados da área financeira. A utilização de sistemas que
blindam as auditorias realizadas em nível de sistema operacional
e bancos de dados é fundamental para a rastreabilidade de opera-
ções críticas. Por exemplo, a leitura de dados altamente sigilosos
de uma organização precisa gerar registro com os detalhes do
observador, possuindo validade se, e somente se, for utilizado
um armazenamento seguro, a sete chaves, a prova de qualquer
Edição 149 • SQL Magazine 13
corOracle Audit Vault Server
manipulação ou mascaramento. O AV Server é essa caixa-preta a
prova de fraudes que guarda os registros de auditoria. Seus as-
pectos de acessos são muito bem resolvidos e possui credibilidade
por parte de auditores de TI em escala mundial.
O Audit Vault Server é um Software Appliance
O primeiro pré-requisito no guia oficial de instalação do AV
Server é de que qualquer pessoa ou usuário comum pode fazer a
instalação. É a partir daí que entramos no conceito de o AV Server
ser um software appliance. Não é necessário instalar pacotes de
requisitos para o AV Server. Ele é o próprio sistema operacional.
A própria camada de clusterware, de file system, de banco de dados,
de aplicação, tudo.
Quem instala, apenas insere a mídia no servidor, digita uma
passphrase, informa o IP e pronto, está tudo pronto, conforme
Figura 1. Após esses pequenos passos, o produto é instalado au-
tomaticamente. Um Oracle Linux com características específicas
é carregado como camada de sistema operacional, sem interação
alguma. Ele sai varrendo e formatando os discos disponíveis e
configurando as áreas sem questionar. Se instalar a mídia pelo
servidor errado, tudo será perdido. Não é uma formatação ami-
gável como em um desktop.
A passphrase criada pelo usuário, que interagiu com o console
após o boot da mídia, é necessária apenas no primeiro acesso
para definição das senhas do ambiente. Após isso, ela perde sua
validade. Toda a infraestrutura criada na instalação demora em
ser executada, pois além do sistema operacional, as camadas de
clusterware, ASM e banco de dados Oracle são criadas. Por fim, um
aplicativo web baseado em APEX é disponibilizado, finalizando
a instalação. A partir de então, o gerenciamento pode ser feito
totalmente remoto através de um navegador qualquer suportado.
Esse é o conceito de software appliance no AV Server, utilizando
diversos outros produtos e gerando uma estrutura única e conso-
lidada, do sistema operacional à aplicação. Uma característica im-
portante da arquitetura de software appliance é que o gerenciamento
deve ser realizado sempre baseado no ambiente consolidado, como
ajustes de suporte e aplicação de patches.
Os componentes da caixa-preta
Na aviação a caixa-preta não interfere no trabalho dos equi-
pamentos, é um produto inviolável, absolutamente resistente a
ataques e acidentes de forte impacto, e muitos não fazem ideia
de como o conteúdo está armazenado, exceto especialistas. Essas
características descrevem muito bem o AV Server, que é um servi-
Figura 1. Instalação do AV Server
14 SQL Magazine • Edição 149
dor escondido na rede com praticamente todas as portas fechadas
e uma excelente política de acesso. Tanto que pode receber esse
apelido de caixa-preta que tudo guarda e onde nada se acessa por
parte de implantadores de projetos de auditoria e DBA´s.
O AV Server possui uma estrutura de agentes que podem ser
instalados nos servidores para coleta de registros de auditoria.
Os registros são gerados basicamente por sistemas operacionais
ou por bancos de dados de forma nativa. Os agentes conhecem
alguns formatos de auditoria, como as auditorias do MySQL e do
Sybase, permitindo então que estes sistemas sejam suportados.
A configuração do que deve ser auditado depende do banco de
dados e da sua tecnologia de auditoria. No caso do MySQL é de
uma forma, no Sybase de outra, no sistema operacional Windows,
para geração de eventos de auditoria podem haver uma série de
configurações, como em serviços do sistema. Ou seja, o AV Server é
tão somente o servidor remoto que recebe os registros de auditoria
que são enviados pelo agente do servidor alvo.
No caso de um banco de dados Oracle, as configurações para ha-
bilitar a auditoria seriam a ativação do parâmetro AUDIT_TRAIL
(‘XML, EXTENDED’) e a especificação de alguma auditoria no
banco de dados, como auditar todos os comandos executados no
banco: audit all statements. O agente instalado poderá então acessar
os registros gerados pelo banco de dados em um diretório especí-
fico de auditoria para envio imediato ao AV Server. Conhecendo o
formato dos dados, o sistema vai armazenar de uma forma mais
segura que no próprio servidor de banco de dados, onde esses
registros poderiam estar vulneráveis. Esse é o conceito básico de
funcionamento do AV Server.
Além do agente, os usuários também são componentes funda-
mentais em uma arquitetura de AV Server. Os papéis de acesso
são os seguintes:
a) Root: é o root do Linux instalado no servidor;
b) Support: também é um usuário de sistema operacional liberado
para acesso SSH remoto, ou seja, é sempre necessário acessar com
ele para passar ao root. Ele é utilizado para operações sugeridas
pela equipe de suporte da Oracle;
c) Administrador: é um usuário que mantém a estrutura do Audit
Vault, realiza a administração da ferramenta, implantação de agen-
tes, configura rede, etc. Não tem acesso aos dados de auditoria.
Comumente fica a cargo de um DBA;
d) Auditor: é o usuário final da ferramenta que se beneficia dos
recursos de análise dos registros de auditoria, elabora relatórios,
programa geração de alertas em casos de incidentes e tudo mais.
Um administrador pode ser um super ad-
ministrador, que possui acesso irrestrito na
administração do ambiente. No caso de ser um
administrador comum, pode ter acesso a determi-
nado alvo de auditoria, como, somente servidores
de homologação. Um auditor também possui
o mesmo conceito de poder ser super auditor.
É importante salientar aqui, que independente
de ser super auditor ou super administrador,
auditores não interferem nas questões de
administradores e vice-versa. É um traba-
lho em conjunto, mas sem interferências.
Cada um cumpre o seu papel, então se
o super administrador desejar remover
um usuário auditor, não vai conseguir.
Os nomes dos primeiros super usuários
são definidos na primeira vez que o siste-
ma é acessado e informado a passphrase da
instalação, conforme Figura 2.
Após configurar os nomes e senhas dos
super usuários, é possível fazer login no
sistema web e explorar os recursos, lem-
brando que as opções disponíveis vão se
moldar conforme o usuário for um admi-
nistrador ou um auditor, embora a tela de
acesso seja unificada.
A Oracle também disponibiliza um
executável nativo para a administração Figura 2. Definição de usuários
do AV Server, assim como existe o EMCLI
para o Oracle Enterprise Manager, os re-
cursos disponíveis na interface gráfica
podem ser realizados por linha de co-
mando, através de um utilitário chamado
AVCLI. Uma opção muito útil é definir o
nível log de erros para os servidores que
possuem agentes registrados, conforme
Figura 3. Essa é uma opção que atual-
Figura 3. AVCLI
mente não consta na interface gráfica,
sendo feita somente pelo AVCLI. Para
determinadas situações, é importante
saber que esse utilitário existe e que se
beneficia dos paradigmas de linha de co-
mando, como a interpretação de scripts.
Ainda outro item que pode ser citado
como componente do AV Server é o Oracle
Database Firewall, que será abordado em
um artigo futuro.

Administração no Audit Vault Server

O papel de um usuário do tipo admi-
nistrador no AV Server é exclusivamente
de manter o ambiente em nível de infra-
estrutura e também de executar a confi-
guração de agentes e alvos de auditoria,
permitindo assim que tudo funcione
adequadamente para que o auditor possa
focar exclusivamente nas suas respectivas
atividades. Em linhas gerais, o adminis-
trador configura e mantém o ambiente
para o auditor. O administrador é res-
ponsável por dezenas de configurações,
sendo as principais delas:
Figura 4. Definição da rede
Configurações de rede
Como em qualquer servidor, em alguma
manutenção pode ser necessário realizar a
troca do IP, máscara de rede, gateway ou o
hostname do AV Server. É possível realizar
esses ajustes de forma bem simplificada
através da console do servidor ou pela
interface gráfica web.
É interessante saber que essa configura-
ção está disponível por interface gráfica,
conforme Figura 4, mas que envolve um
reboot imediato para efetivação da modifi-
cação. A interface web ainda não alerta de
forma clara sobre o reboot. A reinicializa-
ção total, até a disponibilização do serviço
web, pode demorar bastante dependendo
do servidor.
O acesso à interface gráfica web (camada
em APEX) pode ser restringida para um
conjunto de clientes limitados, através
da definição de um conjunto restrito de
endereços IP.

Edição 149 • SQL Magazine 15

corOracle Audit Vault Server

Da mesma forma, pode ser realizada essa configuração para os
serviços de SSH e SNMP, como mostra a Figura 5. A recomendação
é de que fique habilitada somente a interface web para clientes
específicos de administração e auditoria e que, apenas quando
necessário seja habilitado o serviço SSH para uma eventual
manutenção.
Brasil/Brasília: GMT-3), bem como validar que o servidor pode
sincronizar seu relógio com um servidor de tempo (protocolo
NTP), como mostra a Figura 7. Até três servidores NTP podem
ser especificados. Uma configuração inadequada pode distorcer
as informações de auditoria e gerar embaraços com auditores
externos, bem como outros tipos de confusão em registros de
auditoria e alertas.

Figura 5. Liberação de acessos

Mensagens por e-mail são o principal método de o AV Server

alertar os auditores sobre ocorrências em tempo real. Por exemplo,
uma movimentação financeira fora de padrão precisa ser verifica-
da no mesmo dia e o quanto antes possível, todavia, para o alerta
ser emitido, a infraestrutura de comunicação entre o AV Server e
o servidor de e-mail precisa ser estável e bem testada.
Também é papel do administrador certificar-se de que o AV
Server é capaz de enviar e-mails através de um servidor SMTP.
Esse recurso é muito útil para os auditores serem alertados sobre
incidentes de segurança. Os dados fornecidos podem ser validados Figura 7. Timezone e servidor de NTP
com um teste, disponível na própria tela de configuração, como
mostra a Figura 6. Avaliação de espaço em disco
Obter a visibilidade do espaço em disco usado é um item aprovei-
tado da linha de comando do sistema operacional para a facilitada
e simplificada interface gráfica web do AV Server.
Os discos formatados na instalação do AV Server são dis-
tribuídos em formato de pontos de montagens do sistema
operacional (Oracle Linux), bem como grupos de discos do ASM
para o banco de dados que armazena os registros de auditoria.
O administrador pode então acompanhar o espaço, conforme
Figura 8 e, se necessário, realizar manutenções baseadas no
suporte do produto.

Figura 6. Apontamento para servidor de e-mail

Resumidamente, um registro de auditoria contém o que foi

executado, quem executou e quando. Se uma dessas informações
essenciais está distorcida, a análise e a confiabilidade ficam to-
talmente comprometidas. Informações com data errada podem
gerar confusão, por isso é muito importante que o AV Server
esteja adequadamente configurado de acordo com os ambientes
dos quais recebe logs de auditoria. Como em qualquer sistema
operacional, a definição do timezone e uma correta configuração
do serviço de NTP são as configurações suficientes para manter
o relógio sempre correto.
Utilizando a interface do sistema web, o administrador do AV
Server pode configurar de forma correta o timezone (no caso do Figura 8. Espaço em disco no ASM e file system

16 SQL Magazine • Edição 149

Publicação de agentes
Finalizadas as configurações de rede e análise dos discos cria-
dos, o primeiro passo de fato para colocar esse grande software
appliance em funcionamento é cadastrar um servidor que deve
ser auditado, como mostra a Figura 9. Dessa forma, será possível
que o AV Server receba os registros de auditoria através da coleta
realizada por um agente, que é um executável em Java.
Figura 9. Cadastro de agente do AV Server
O cadastro consiste tão somente no nome completo da má-
quina e seu IP. Uma chave de ativação é imediatamente gerada
e fica disponível para visualização. Ela é o elo de confiança
com a instalação do agente, a qual é feita manualmente no
servidor alvo.
Figura 10. Instalação de agente do AV Server
No servidor que será auditado, independente do objetivo da
auditoria ser sistema operacional ou banco de dados, um agente
(AVAGENT) precisa ser instalado. Ele será o processo do sistema
operacional responsável pela coleta dos logs de auditoria e envio
para o AV Server. O instalador do agente é um pacote Java (JAR).
É importante certificar-se na documentação do produto a versão
de JRE necessária para execução do processo, conforme exemplo
da Figura 10.
O download do arquivo JAR que corresponde ao agente é rea-
lizado na própria interface do AV Server. Ele deve ser transferido
para os servidores alvos de auditoria, como os nodes de um banco
de dados em cluster Oracle RAC. O processo de instalação é bem
simples, sendo necessário somente ter uma versão suportada de
JRE instalada no servidor e informar a chave de ativação criada
no cadastro do servidor. A Figura 10 demonstra detalhes da ins-
talação do agente, incluindo variáveis de ambiente.
Gerenciamento de alvos
Um alvo (Secured Target) no AV Server corresponde ao recurso que
está sendo auditado, o qual sempre está vinculado a um servidor e
seu respectivo agente. Por exemplo, um host Windows pode conter
alvos do tipo Microsoft Active Directory, Oracle Database, MySQL
e SQL Server. O agente e o AV Server possuem uma camada de
plugin para cada tipo de alvo.
Edição 149 • SQL Magazine 17
corOracle Audit Vault Server
Essa arquitetura permite que futuras edições do Audit Vault
possam suportar cada vez mais tipos de alvos.
Com um agente instalado e em pleno funcionamento, o adminis-
trador tem o papel de configurar alvos (Secured Target), conforme
Figura 11. Um mesmo servidor pode suportar diversos bancos de
dados, podendo ser cadastrados pelo administrador. Os dados de
conexão para alvos do tipo banco de dados Oracle são fornecidos
como em qualquer aplicação que deseja conectar no ambiente,
como porta do listener e usuário. Caso o tipo de alvo fosse outro,
informações diferentes seriam solicitadas.
Figura 11. Inclusão de alvo para auditoria
Para cada alvo (ou seja, cada banco de dados), precisa ser
configurada a coleta de informações, chamada de trilha de
auditoria (Audit Trail), conforme Figura 12. Essa é a definição
de um local onde o agente pode ficar monitorando, coletando
e sincronizando as informações com o servidor. No caso do
Oracle Database, pode ser uma tabela de auditoria (AUD$)
ou também um diretório contendo arquivos em XML com os
dados de auditoria.
O tipo da trilha (Audit Trail Type) depende muito de como o alvo
realiza a auditoria. No Oracle Database é definido através do pa-
râmetro de instância AUDIT_TRAIL. Isso vai sempre depender
do tipo de alvo auditado, pois o agente não audita, ele apenas
coleta e sincroniza.
Figura 12. Trilhas de auditoria de dois alvos
Há ambientes que são massivamente auditados e uma quantida-
de elevada de registros é armazenada no AV Server. A definição
de uma política de expurgo é fundamental para a continuidade
18 SQL Magazine • Edição 149
de uma arquitetura de auditoria baseada no Oracle Audit Vault
Server, como mostra a Figura 13.
No AV Server, podem ser criadas políticas de retenção que poste-
riormente são utilizadas pelo auditor em cada alvo. O administrador
cria as políticas baseadas em um conceito de informação on-line,
que estará disponível para filtro, sendo registros no banco de da-
dos do próprio software appliance e um período de arquivamento,
ou seja, um arquivo morto, onde os registros são movimentados
do banco de dados para diretórios externos, via NFS, para outro
servidor, podendo ser restaurados por demanda. Esse conceito
permite elaborar rotinas, por exemplo, de um ano on-line com dez
anos arquivados. Diversas políticas de retenção podem conviver,
sendo aplicadas para alvos distintos. Uma política adequada de
período on-line garante maior desempenho do ambiente.
Figura 13. Política de retenção com 180 dias online, sem arquivamento
Auditoria no Audit Vault Server
O papel de um usuário do tipo auditor no AV Server é analisar os
dados coletados através de pesquisas e relatórios, podendo reali-
zar tarefas adicionais de avaliação de segurança, como a geração
de snapshot sobre privilégios em um banco de dados. O auditor
pode ser proativo com a segurança do ambiente por programar
geração automática de relatórios e o recebimento de alertas sobre
incidentes de segurança. Vamos descrever as principais funções
do auditor utilizando algumas telas de exemplo.
Aplicação de política de retenção em um alvo
As políticas de retenção definidas pelos administradores podem
ser aplicadas pelo auditor em determinados alvos, conforme
desejar. Dessa forma, o banco de dados vai manter nas tabelas
internas do AV Server menos registros, conforme definido pela
política de retenção.
Embora o desempenho da base de dados seja muito satisfatório
para os filtros que podem ser realizados, ter a política de expurgo
definida, mantendo somente os registros necessários, melhora o
desempenho em longo prazo.
Visualização de registros de auditoria
A visualização de registros de auditoria é a função mais básica
no AV Server. É possível utilizar a interface gráfica da aplicação
em layout do APEX para elaborar filtros avançados, até mesmo
agrupando registros e gerando gráficos em algumas telas.
O exemplo da Figura 14 é um filtro baseado no nome de uma
tabela do owner AVDF em um banco de dados específico.
 Ele retorna todas as operações que foram auditadas pelo banco
de dados nesse objeto e que foram também coletadas pelo agente
e enviadas ao servidor de auditoria.
Figura 14. Filtrando registros de auditoria
Definição do que deve ser auditado
O administrador precisa deixar as trilhas de auditoria em per-
feito funcionamento para que o auditor visualize o status das
auditorias de cada alvo. No caso de banco de dados, é possível
identificar as auditorias ativas, bem como gerar os comandos para
passar a auditar novos itens.
A diferença entre o que se deseja auditar versus o que está de fato
sendo auditado pode ser transformada em script com comandos
para habilitar a auditoria, ou mesmo especificado um usuário e
senha que automaticamente executem o script no banco de dados.
Após, é necessário certificar-se de que tudo que se deseja auditar
está sendo auditado no banco de dados.
Como comentado no início deste artigo, quem audita é o banco de
dados, não é o AV Server. É nessa etapa de definição de auditoria
que as telas do AV Server possuem os recursos para avaliar essa
integração de informações.
Definir uma auditoria como sendo ou não necessária (Needed/
Not Needed) pode divergir a depender de como esteja definido
atualmente o banco de dados. Por esse motivo, existem as setas
indicativas, para avaliar se há alguma divergência. Conforme
exemplo da Figura 15, nenhuma divergência foi encontrada, en-
tão tudo que está marcado como necessário no Audit Vault está
sendo auditado pelo banco de dados e não há auditorias feitas
pelo banco de dados que não estejam definidas como necessárias
no Audit Vault. O objetivo dessa interface é justamente solucionar
possíveis divergências.
Há diversos tipos de auditoria. Um exemplo comum é a auditoria
por objetos de banco de dados, exemplificado na Figura 15. Nesse
exemplo, uma tabela do owner SCOTT está sendo auditada para
operações SQL/DML de ALTER, UPDATE e INSERT.
Criação de listas e modelos de distribuição de e-mails
Podem ser criados modelos de e-mails com textos padrões,
incluindo trechos variáveis, os quais são substituídos em tempo
de geração do e-mail. Esses modelos podem servir para alertas
de incidentes ou para envio de relatórios agendados. Também
podem ser criadas listas de distribuição de e-mails, de forma a
serem facilmente atribuídas aos alertas ou relatórios agendados.
A Figura 16 apresenta um e-mail recebido, após um DELETE ser
executado em uma tabela do usuário SCOTT. O layout é baseado
em um modelo criado previamente.
Figura 15. Exemplo de definição do que deve ser auditado no banco de dados
Figura 16. Notificação por e-mail quando um alerta é aberto
Gerenciamento de alertas
Gerar alertas sobre incidentes ocorridos em nível de segurança é
um dos recursos de maior pró-atividade disponíveis no AV Server.
Ele consiste em elaborar um filtro avançado sobre os registros de
auditoria, sendo que se as regras do filtro casarem com algum
registro, um alerta é disparado para uma lista de distribuição de
e-mails, podendo ter layout baseado em um modelo previamente
definido.
É semelhante a uma configuração de regra de firewall, onde são
determinadas as condições de convergência à uma regra. Quando
um registro de auditoria for enviado por um agente e recebido
no AV Server, ele será analisado pelas regras existentes. Caso o
registro se enquadre em algum alerta, há a geração do incidente,
que pode ou não disparar uma notificação por e-mail. Mesmo não
havendo uma notificação configurada, o alerta permanece na tela
inicial do login de auditor (Dashboard) até que seja marcado como
conhecido ou resolvido (Figura 17).
Agendamento de relatórios
Deparar-se com um grande volume de registros de auditoria
exige organização e classificação de prioridade de análise. Exaus-
tivas pesquisas e definições de filtros para encontrar operações
suspeitas precisam ser reutilizadas para aperfeiçoar o trabalho de
auditores. O AV Server tem essa possibilidade através do agenda-
mento de relatórios predefinidos, os quais podem ser entregues
por e-mail aos auditores em formato PDF ou Excel.
Assim, auditores podem receber relatórios prontos na caixa de
e-mail sem precisar logar na ferramenta e efetuar cansativas bus-
cas. Basta configurar agendamentos de envio de relatórios, como
Edição 149 • SQL Magazine 19
corOracle Audit Vault Server
Figura 17. Criando uma regra para geração de alerta
Figura 18. Definindo um relatório para envio por e-mail diariamente
Figura 19. Comparando privilégios entre períodos
20 SQL Magazine • Edição 149
mostra a Figura 18. Por exemplo, podemos
enviar um relatório se houve comandos
de remoção de registros em uma tabela
específica do banco de dados na data de
ontem. Há também a opção para geração
do relatório em formato PDF e XLS.
Acompanhamento de privilégios
Com as modificações em sistemas e im-
plantação de novas aplicações, a tendência
comum é de que os privilégios em um
banco de dados sofram mudanças. Poder
comparar a situação de privilégios com o
passado é um ótimo recurso para auditores
especializados em bancos de dados Oracle.
Analisar a diferença entre o início e o final
do mês fornece uma relação completa das
modificações de privilégios, o que dá uma
visão apurada sobre as mudanças que
ameaçam o ambiente em termos de novas
vulnerabilidades (Figura 19).
O AV Server possui esse recurso, sendo
bem prático de ser utilizado. Basta gerar
um snapshot da situação atual, fornecendo
um nome para que fique armazenado. Es-
sas fotos de status podem ser comparadas
entre si, gerando um relatório detalhado
de privilégios adicionados ou removidos
em um período. Por exemplo, um snapshot
do mês de Março pode ser comparado com
um snapshot gerado em Janeiro, possibili-
tando ser verificado pelo auditor que um
usuário no Oracle Database adquiriu, nesse
meio tempo, privilégio de DBA. Esse item
pode ser trabalhado então pelo auditor
dentro da organização, no sentido de
avaliar se foi algo temporário, para teste,
sem aprovação, ou se realmente foi uma
mudança aprovada.
A maturidade do ambiente de TI com o
AV Server
Embora a implantação de ferramentas de
controle como o AV Server não seja o tipo
de projeto mais empolgante, ela demonstra
a maturidade da TI nas organizações, tor-
nando-as bem preparadas para identificar
modificações descontroladas em bancos de
dados, rastreando os responsáveis. Como
foi descrito neste artigo, uma caixa-preta
não interfere no trabalho, é inviolável, ab-
solutamente resistente a ataques, e muitos
não fazem ideia de como o conteúdo está
armazenado. Por isso, é tão comum a utilização desse termo para Autor
descrever o AV Server, que possui essas mesmas características.
Todavia, adicionalmente, há outra característica do AV Server DBA Darlan Bastos
dbadarlanbastos@gmail.com
que também pode ser usada na comparação: ele não compõe o
Consultor DBA Oracle Certified Expert. Responsável por projetos
ambiente para aumentar desempenho, reduzir custos ou trazer al-
na AdvancedIT, empresa gaúcha Oracle Platinum Partner. Atua
gum outro benefício imediato. Na realidade, nem sempre as coisas em projetos de migrações e implementa soluções de alta disponibilidade.
dão certo, e ele está ali para quando as coisas ruins acontecerem,
essa é a sua utilidade, que pode ser a solução para um incidente
grave, como bugs de aplicação, usuários mal-intencionados ou Links:
vulnerabilidades de acesso.
Toda a arquitetura e gestão de acesso diferenciado do AV Server HANNA, G. et al. Oracle® Audit Vault and Database Firewall Administrator's Guide.
entre auditor e DBA, bem como os recursos adicionais apresen- Release 12.1.2: Oracle Corporation, p. 1–278, 2015.
tados neste artigo, demonstram a maturidade do produto e os MOORE, S. et al. Oracle® Audit Vault and Database Firewall Installation Guide.
benefícios em médio prazo que o investimento nele proporciona. Release 12.1.2: Oracle Corporation, p. 1–38, 2015.
Ele é fundamental para ambientes de missão crítica em segurança,
HANNA, G. et al. Oracle® Audit Vault and Database Firewall Auditor’s Guide.
principalmente para aqueles que são baseados em Oracle Database,
Release 12.1.2: Oracle Corporation, p. 1–266, 2015.
como as áreas financeiras, comerciais, saúde e governo.

Edição 149 • SQL Magazine 21

rIOPS: determinando o
throughput no Oracle
Dimensionando o sistema de I/O
Este artigo é do tipo mentoring
saiba mais: www.devmedia.com.br/mentoring-saibamais
E
stimar um subsistema de I/O é parte essencial na
construção da infraestrutura do desenvolvimen-
to de uma aplicação. Segundo as boas práticas
de mercado, recomenda-se que antes da implantação,
desenvolvimento e liberação de uma funcionalidade
ou até mesmo de um sistema para produção, todos os
elementos da arquitetura sejam analisados para garantir
que os acordos de SLAs sejam satisfatórios.
O SLA - Service Level Agreement, ou, ANS – Acordo de
Nível de Serviço, é muito importante para os contratos
de prestação de serviços em tecnologia. Trata-se de
uma especificação dos serviços que o contratante pode
esperar do contratado baseado nos resultados. Temos
como exemplo os prazos contratuais, termos de compro-
misso, metas de nível e serviço, suporte técnico, entre
outros. Através do SLM – Service Level Management
– os SLAs são gerenciados, e para que tal atividade seja
eficaz, é necessário obter indicadores que possibilitem
a transparência entre as empresas e seus clientes. Al-
guns exemplos de indicadores são: de disponibilidade,
de custos, de incidências de falhas, tempo de resposta,
documentações, backlog, entre outros.
Nos ambientes, independente do grau de complexi-
dade, faz-se necessário o entendimento da demanda
por operações de leitura e escrita. De certo, essa nunca
é estática e sofre constantes variações. Assistir a essas
mudanças de maneira pró ativa, entendê-las e principal-
mente conhecer os picos de I/O (Input/Ouput), é garantir
um bom desempenho como um todo.
Uma ação fundamental e até desafiadora para admi-
nistradores de banco de dados é justamente mensurar
a capacidade de throughput (taxa de transferência) do
ambiente e confrontá-lo com comportamentos e reações
dos sistemas, pois a performance de muitas aplicações
22 SQL Magazine • Edição 149
Cenário
Dimensionar um sistema de I/O é uma das partes fundamentais para
a implantação de um novo sistema, para o redimensionamento da
infraestrutura e para identificar possíveis gargalos no desempenho das
aplicações. Para atingir tais conceitos, é importante também conhecer
as métricas e SLAs do ambiente. Neste artigo, veremos como o IOPS
pode nos ajudar e como podemos mensurá-lo. Através de exemplos,
conheceremos as sintaxes, configurações, pré-requisitos e analisare-
mos os resultados das ferramentas Oracle CALIBRATE_IO e Oracle Orion.
O conteúdo apresentado neste artigo auxiliará administradores de
banco de dados a mensurar o throughput de dispositivos de armaze-
namento. Esse conhecimento será útil em situações que demandam a
implantação de um novo sistema, atualização ou migração de platafor-
ma e até mesmo contribuir na análise de problemas de desempenho.
restringem-se à IOPS (Input/Output per second) dos dispositivos
de armazenamento.
No mercado existem várias ferramentas para tais tarefas, como
Iometer, Iozone, SLOB, entre outras. Apesar de serem boas, a
Oracle já disponibiliza algumas, até mais adequadas ao analisar-
mos o I/O em conjunto com o banco de dados, com a vantagem
da facilidade/mobilidade. A partir da versão 11g, temos como
opções o Oracle RAT (ver BOX 1) e uma outra novidade, a função
CALIBRATE_IO, tema principal do artigo.
Presente no package DBMS_RESOURCE_MANAGER, podemos
de maneira simples realizar uma análise confiável. Tal função
permite aos usuários analisar o desempenho dos dispositivos de
armazenamento de dados e avaliar se a possível degradação na
performance resulta do banco de dados ou storage.
Esse package auxilia administradores a controlar os recursos de
hardware, pois em ambientes com um número considerado de
usuários simultâneos, diferentes cargas e rotinas são processadas
com níveis de prioridade variados.
Através do Resource Manager, você é capaz de configurar ses-
sões de usuários em grupos baseados em seus atributos e alocar
recursos de maneira otimizada quanto a utilização de hardware
no ambiente das aplicações. Algumas possibilidades ao utilizá-la
são: limitar a utilização de CPU, limitar graus de paralelismo de
membros pertencentes a um determinado grupo, limitar a quanti-
dade de tempo de inatividade das sessões, utilização de diferentes
planos para um mesmo ambiente baseado nas cargas e picos do
ambiente, entre outras.
Neste artigo serão abordados alguns cenários e através de
exemplos utilizando a procedure CALIBRATE_IO, conhecere-
mos as configurações, as sintaxes, os métodos, os parâmetros
e finalmente os resultados produzidos com uma projeção da
escalabilidade dos discos.
BOX 1. Oracle RAT – Real Application Testing
Trata-se de uma option, que permite simular testes de carga reais do banco de dados. É composto
por dois elementos, o Database Replay e o SQL Performance Analyzer. Através da captura de cargas
de trabalho e avaliação do impacto das alterações no sistema, o Oracle RAT auxilia na minimização
de problemas de performance e instabilidades provenientes das mudanças.
Database Replay: fornece aos DBAs a capacidade de capturar e simular com precisão e de forma
realista as cargas de trabalho de produção em ambientes de teste. Com o Database Replay, você pode
testar upgrades das bases de dados, aplicação de patches, alterações de parâmetros, alterações em
schemas, conversão de single instance para Oracle RAC (alta disponibilidade), discos, rede, alterações
de hardware, entre várias outras, tudo isso com baixo custo e rápida construção dos testes.
SQL Performance Analyzer: pode prevenir e evitar problemas na execução de instruções SQL causados
por mudanças no ambiente, fornecendo uma visão do impacto dessas alterações nos planos de
execução e nas estatísticas. O SPA identifica divergências no desempenho para cada instrução SQL
gerando um relatório de impacto quanto ao desempenho nas cargas de trabalho. Para as instruções
ineficientes, ou seja, aquelas que tiveram alterações negativas em seu plano de execução, o SPA
também faz recomendações de tuning.
Porque IOPS?
Indicadores de desempenho são importantes para o monitora-
mento e funcionamento adequado da infraestrutura. Uma dessas
métricas, o IOPS, possui grande importância em TI, pois tem relação
direta com o desempenho das aplicações (ver BOX 2). Além disso,
auxilia gestores e colaboradores a avaliar o comportamento atual e a
tomar melhores decisões durante a implantação de novos sistemas.
IOPS é a sigla para Input/Output per Second, ou seja, representa as
operações de entrada e saída por segundo, aplicada sobre disposi-
tivos de armazenamento. Sua principal importância é evidenciar
a capacidade que um dispositivo possui em realizar operações de
leitura e escrita, o que favorece a avaliação do funcionamento dos
sistemas antes mesmo da implementação deles.
Essa métrica também pode ser utilizada para mensurar a quan-
tidade de discos necessários para o funcionamento saudável do
sistema com base na relação de usuários previstos. Existem hoje
ferramentas e sites que calculam o número de IOPS e discos
exigidos por um sistema, levando em conta até mesmo o uso de
soluções como RAID (ver BOX 3).
Calculando IOPS utilizando o banco de dados Oracle
Como muitos conhecem, relatórios AWR são úteis na identifi-
cação de problemas, e passar horas identificando-os e propondo
BOX 2. IOPS
Para ambientes Oracle RAC, deve-se somar os valores de IOPS e MBytes/s de todas as instâncias.
Para alcançar o IOPS e throughput desejados, não apenas os discos podem ser o fator
determinante, mas sim um conjunto. Tratando o assunto internamente, ou seja, no próprio banco
de dados, podemos atuar com otimizações de instruções SQL com o objetivo de melhorar o acesso
às leituras e configurar corretamente alguns parâmetros. Além disso, também nos deparamos
com fatores externos como: o block device manager, multipathing driver, SCSI driver, HBA, System
Bus, Switch/iSCSI, Storage Array, disks e RAID. Portanto, quando avaliarmos o desempenho de I/O,
devemos levar tudo isso em consideração.
BOX 3. RAID – Redundant Array of Independent Disks
O RAID consiste em um conjunto de dois ou mais discos com o objetivo de tornar a arquitetura
de discos mais rápida ou mais segura através de duas técnicas: a distribuição de dados (data
stripping) e o espelhamento (mirroring). Ambas as configurações podem ser utilizadas
isoladamente ou de forma conjunta.
O RAID é classificado em níveis e a implementação desses corresponde às necessidades do
ambiente. Alguns exemplos são: RAID 0 (não há redundância; dados distribuídos; muito utilizado
para performance;), RAID 1 (utilizado para redundância/espelhamento), RAID 5 (mínimo três
discos; espelhamento/paridade). RAID 10 ou RAID 1+0 (mínimo quatro discos; combinação de
redundância e performance).
soluções faz parte do dia a dia de muitos administradores de banco
de dados. Além desse relatório, podemos identificar o IOPS da
base de dados através do statspack (para aqueles que não possuem
o licenciamento do Diagnostics Pack) e instruções SQL.
Exemplificando com o relatório AWR, na sessão Instance Activity
Stats, você pode encontrar informações de IOPS conforme indicado
na Listagem 1.
Listagem 1. Trecho relatório AWR – Instance Activity Stats
01 IOPS = “physical read total I/O requests” + “physical write total I/O requests”
02 MBytes/s = “physical read total bytes” + “physical write total bytes”
03 physical read total IO requests = 124,594.000
04 physical write total IO requests = 13,313.041
05 physical read total bytes = 19,285,444.47
06 physical write total bytes = 2,904,587.09
A linha 01 representa o somatório das requisições de leitura e
escrita. A linha 02 representa o somatório em Mbytes/s resultante
das operações de leitura e escrita. Em seguida, o total das requisi-
ções de leitura e escrita é representado, respectivamente. Por fim,
tem-se o total de dados em Mbytes/s transmitidos/utilizados nas
operações de leitura e escrita, respectivamente. Com os dados,
podemos concluir que no período selecionado, obtemos:
IOPS ~ 137.907
Mbytes/s ~ 21
Essas informações podem ser utilizadas após alterações de har-
dware, alterações na aplicação e até mesmo para identificar garga-
los no ambiente, proporcionando assim informações conclusivas.
Edição 149 • SQL Magazine 23
rIOPS: determinando o throughput no Oracle
Caso não possua o licenciamento adequado para a utilização do
relatório mencionado, temos as opções do statspack e SQL. Como
já visualizamos um exemplo baseado em relatório, observe agora
a Listagem 2.
Listagem 2. Seleção V$SYSMETRIC_SUMMARY
1. SELECT
2. CASE
3. WHEN metric_name = ‘Physical Read Total Bytes Per Sec’ THEN ‘PR_BPS’
4. WHEN metric_name = ‘Physical Read Total IO Requests Per Sec’ THEN ‘PR_IOPS’
5. WHEN metric_name = ‘Physical Write Total Bytes Per Sec’ THEN ‘PW_BPS’
6. WHEN metric_name = ‘Physical Write Total IO Requests Per Sec’ THEN ‘PW_IOPS’
7. END METRIC,
8. ROUND(AVERAGE,2) as AVERAGE
9. --MAXVAL,
10. --MINVAL,
11. --STANDARD_DEVIATION
12. FROM V$SYSMETRIC_SUMMARY
13. WHERE metric_name IN
14. (
15. ‘Physical Read Total Bytes Per Sec’,
16. ‘Physical Write Total Bytes Per Sec’,
17. ‘Physical Write Total IO Requests Per Sec’,
18. ‘Physical Read Total IO Requests Per Sec’
19. )
20. ORDER BY metric_name;
Da linha 02 a 07 temos a formatação das métricas para a seleção.
Da linha 08 a 11 temos colunas da seleção. As colunas que estão
comentadas referem-se aos valores observados no intervalo de 60
minutos. Na linha 12, a view V$SYSMETRIC_SUMMARY exibe um
resumo de todos os valores das métricas de sistema dos últimos
60 minutos. Já a 13 exibe o filtro das métricas. Por fim, mostra a
ordenação através do nome das métricas.
Uma desvantagem do não licenciamento do Diagnostic Pack é
que essas informações se limitam aos últimos 60 minutos, ou seja,
não temos acesso a um histórico abrangente.
Determinando o throughput com Oracle CALIBREATE_IO e
Oracle Orion-
Após a explanação dos termos mencionados no início do artigo,
daremos sequência a sua parte principal. Nesta sessão veremos
como a função CALIBRATE_IO funciona, como é composta sua
sintaxe, quais configurações utilizar e, principalmente, como
entender seus resultados. Para os exemplos a seguir, utilizaremos
dois casos de teste: um com dois discos configurados em ASM
(Automatic Storage Management) e outro com quatro discos também
em ASM. Após realizá-los, será apresentada a ferramenta Oracle
Orion, a qual possui finalidade semelhante à função exibida nos
testes, com a vantagem de não necessitarmos de um banco de
dados Oracle instalado e configurado.
Para entendermos a procedure em questão, vamos primeiramen-
te entender como os discos são gerenciados pelo ASM. O ASM
é um gerenciador de volume e sistema de arquivos para banco
de dados Oracle que pode ser utilizado tanto em single-instance
quanto em Oracle RACs. Para armazenar os arquivos de dados
do banco (conhecidos como datafiles), o ASM utiliza um conceito
24 SQL Magazine • Edição 149
denominado disk group, o que nada mais é do que um conjunto
de discos gerenciados como uma única unidade. Os dados são
distribuídos uniformemente e sua performance é comparada com
raw devices.
O Oracle ASM também trabalha com redundâncias e possui três
níveis de configuração:
• External: não utiliza espelhamento, sendo recomendada a con-
figuração de RAIDs;
• Normal: os dados possuem uma cópia espelhada fornecendo
uma proteção contra, pelo menos, uma falha de disco;
• High: os dados possuem duas cópias espelhadas, ou seja, os extents
possuem uma disponibilidade primária e outras duas secundárias,
fornecendo uma proteção de pelo menos duas falhas de disco.
Enquanto o ASM gerencia a distribuição dos dados nos datafiles,
a procedure CALIBRATE_IO utiliza-os para acessar os discos e
produz resultados muito parecidos com a performance real da
base, pois utiliza um código próprio. Através de cargas intensivas
de leituras nos arquivos de dados, a primeira fase utilizando o
valor do parâmetro db_block_size, e uma segunda utilizando blocos
de 1Mb, é determinada a quantidade máxima de operações de
leitura e escrita por segundo e a quantidade de megabytes que
os discos podem suportar. Para Oracle RACs, a carga é gerada
simultaneamente de todas as instâncias.
Sintaxe e parâmetros
Devido à sobrecarga aplicada no ambiente, a procedure CALIBRA-
TE_IO (ler BOX 4) deve ser utilizada quando o banco de dados
estiver com pouca atividade ou nenhuma, mas principalmente
deve ser executada fora dos horários de pico, minimizando assim o
impacto de I/O na aplicação. Para executá-la e avaliar a capacidade
de I/O utilizada pelo banco de dados, utilize o exemplo conforme
a Listagem 3 e a Tabela 1.
BOX 4. Considerações CALIBRATE_IO
• Apenas realize um teste por vez em bases que utilizem o mesmo storage, caso contrário, o teste
falhará;
• Para Oracle RACs, a carga de trabalho é simultaneamente gerada de todas as instâncias. Garanta
que todas elas estejam em modo open;
• O parâmetro disks é opcional, no entanto é aconselhável configurá-lo para que o teste seja mais
rápido e mais assertivo.
Listagem 3. DBMS_RESOURCE_MANAGER.CALIBRATE_IO
01 SET SERVEROUTPUT ON
02 DECLARE
03 lat INTEGER;
04 iops INTEGER;
05 mbps INTEGER;
06 BEGIN
07 --DBMS_RESOURCE_MANAGER.CALIBRATE_IO
(<disks>, <max_latency>, max_iops, max_mbps, actual_lat);
08 DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);
09 DBMS_OUTPUT.PUT_LINE (‘max_iops = ‘ || iops);
10 DBMS_OUTPUT.PUT_LINE (‘latency = ‘ || lat);
11 DBMS_OUTPUT.PUT_LINE (‘max_mbps = ‘ || mbps);
12 end;
13 /
 Parâmetros Descrição
disks Quantidade de discos físicos.
Tolerância máxima em milissegundos para acesso aos discos. Deve ser configurado um valor com base no SLA de sua aplicação. Para
max_latency
ambientes OLTP, um valor tolerável é abaixo de 10 ms.
max_iops Quantidade máxima de IOPS suportada pelo dispositivo de armazenamento.
max_mbps Throughput máximo em Mb/s suportado pelo dispositivo de armazenamento.
actual_lat Latência atual observada durante o teste.

Tabela 1. Parâmetros CALIBRATE_IO

A linha 01 define a configuração para exibir o output gerado $ cat /proc/sys/fs/aio-max-nr

pelo package DBMS_OUTPUT. Na linha 08, ocorre a execução da $ cat /proc/sys/fs/aio-nr
procedure com os parâmetros e variáveis declaradas nas linhas
anteriores. Já nas linhas 09 a 11 os resultados são apresentados. Execução do primeiro teste
Conforme dito anteriormente, a execução do CALIBRATE_IO
Pré-requisitos é formada de duas fases. A primeira realiza cargas de leitura
São necessárias as seguintes configurações antes de executarmos de pequenos blocos e, na segunda, cargas com blocos de 1 Mb.
os testes: A Figura 2 apresenta os resultados do nosso primeiro teste (dois
• usuário com privilégios sysdba; discos configurados em ASM).
• parâmetro timed_statistics configurado para TRUE;
• I/O assíncrono (parâmetro disk_asynch_io=true) para todos
os arquivos de dados. Em ambientes que utilizam ASM para
gerenciamento dos dados, essa configuração é default. Utilize a
instrução indicada na Listagem 4 e observe o output na Figura 1.

Listagem 4. Seleção ASYNCH_IO

1. COL NAME FORMAT A50

2. SELECT NAME,ASYNCH_IO
3. FROM V$DATAFILE F,V$IOSTAT_FILE I
4. WHERE F.FILE#=I.FILE_NO AND FILETYPE_NAME=’Data File’;

Figura 2. Primeira execução CALIBRATE_IO

Dependendo do ambiente analisado, o tempo de execução pode

Figura 1. Resultado da seleção ASYNCH_IO
A linha 01 do código apresentado faz a formatação da coluna
NAME e, em seguida, efetua a consulta. Na linha 03 é definida
a origem dos dados da seleção e, por fim, o filtro é aplicado na
seleção.
Mesmo que a todos os arquivos de dados estejam configurados
como ASYNC_ON, talvez você não consiga executar o teste. Isso
pode ocorrer devido ao número de slots assíncronos disponíveis
no sistema. Se não houver, os arquivos não utilizarão essa fun-
cionalidade e o erro ORA-56708 serão exibidos.
Para identificar a quantidade máxima de slots disponíveis e a
quantidade utilizada em sistemas operacionais Linux, basta você
executar, respectivamente:
variar conforme a performance do dispositivo de armazenamento,
número de arquivos de dados e tamanho da base de dados. Como
a execução da procedure pode ser demorada, a view V$IO_CA-
LIBRATION_STATUS nos fornece informações sobre o status de
execução.
Resultados
Após a execução, além de visualizarmos os resultados pelo
output da procedure, podemos também listá-los através da view
DBA_RSRC_IO_CALIBRATE, conforme Figura 3.
Com base nessas informações, podemos entender que nesse
cenário, o tempo do teste resultou em aproximadamente seis
minutos, obtendo um throughput máximo de 48 Mbytes/s, 95
requisições de I/O por segundo e latência de nove milissegun-
dos, abaixo dos 10 configurados como parâmetro. A coluna
MAX_PMPBS representa as requisições de I/O de 1 Mb que são
suportadas por um único processo.

Edição 149 • SQL Magazine 25

rIOPS: determinando o throughput no Oracle

Execução e resultados do segundo teste
Para o segundo teste, utilizaremos o
mesmo sistema exceto quanto ao número
de discos, no qual foram adicionados mais
dois ao ASM, totalizando quatro, como
mostram as Figuras 4 e 5.
Com base nas informações obtidas,
podemos entender que nesse cenário
o tempo do teste resultou em aproxi-
Figura 3. Resultados da primeira execução
Figura 4. Segunda execução CALIBRATE_IO
Figura 5. Resultados da segunda execução
madamente seis minutos, obtendo um
throughput máximo de 46 Mbytes/s, 79
requisições de I/O por segundo e latência
de 11 milissegundos, tempo 10% acima
do tolerável.
Podemos entender que, ao duplicarmos
os discos, nenhuma melhoria foi encon-
trada. Assim, a utilização de quatro discos
para o sistema em questão não corresponde
à uma configuração adequada, já que hou-
ve uma redução de IOPS para 79.
Comparações
Observando os resultados, já compreen-
demos que uma configuração com quatro
discos não é a ideal para o sistema em
questão e que a utilização de dois discos
com latência de 10 milissegundos repre-
senta o melhor cenário.
A fim de estabelecer um padrão de
comportamento e melhor entendermos
as configurações, foram realizados outros
testes. Nesses testes, a latência foi duplica-
da para 20 e 40. Desse modo, os testes totais
apresentados no artigo contemplam casos
com dois e quatro discos e latências de 10,
20 e 40, conforme as Tabelas 2 e 3.
Analisando os dados obtidos, podemos
concluir que a média de throughput obtido
para o sistema, seja configurado com dois
ou quatro discos, foi de 48,5 Mbps/s. Agora
vejamos as relações e comportamento
entre as requisições de I/O e latências
conforme evidenciado nas Figuras 6 e 7.
Com base nos resultados obtidos, podemos
entender que o acréscimo na tolerância da
latência tem relação direta com o aumento
das requisições de I/O.
É importante lembrar que as latências
testadas foram utilizadas apenas para
evidenciar a relação de progressão das
requisições e que bases de dados que su-
portam sistemas OLTP (Online Transaction
Processing) devem manter esse tempo abai-
xo de 10 milissegundos como boa prática
e métrica de desempenho.

Testes c/ 2 discos max_iops Latency max_mbps

Oracle Orion
Se você deseja conhecer as caracterís-
Teste 1 95 9 48
ticas de seu sistema de armazenamento,
Teste 2 96 9 51 necessita realizar um benchmark para um
Teste 3 104 18 51 novo ambiente e identificar melhor seus
Teste 4 147 39 47 limites obtendo informações antes mesmo
de dimensioná-lo adequadamente, a ferra-
Tabela 2. Resultados obtidos com dois discos
menta Oracle Orion é ideal. Ela estima o
desempenho sem a necessidade de criar
Testes c/ 4 discos max_iops Latency max_mbps
um banco de dados, tendo sido desen-
Teste 1 79 11 46
volvida para simular cargas de trabalho
Teste 2 76 12 47
(requisições I/O) e também reproduzir os
Teste 3 74 26 50 mesmos efeitos do ASM.
Teste 4 102 38 48 Para cada tipo de carga de trabalho (que
Tabela 3. Resultados obtidos com quatro discos são Small Random I/O, Large Sequencial I/O,

26 SQL Magazine • Edição 149

Large Random I/O e Mixed Workloads), o Oracle Orion pode executar
testes utilizando diferentes loads para medir o throughput, IOPS e
latência, assim como a CALIBRATE_IO.
Figura 6. Análise com dois discos
Figura 7. Análise com quatro discos
Execução
Nesse exemplo utilizaremos uma configuração similar ao pro-
cesso executado no CALIBRATE_IO (small blocks e large blocks).
A ferramenta discutida nesse tópico possui inúmeras combinações
de execução com alto grau de customização. Para acesso à todas
as configurações, ver seção Links.
Embora não necessite de nenhuma base de dados para sua exe-
cução, é necessário que apenas os binários sejam instalados, pois
seu aplicativo fica no $ORACLE_HOME/bin. O primeiro passo da
configuração é criar um subdiretório para armazenamento dos
resultados e, nesse diretório, criar um arquivo com a listagem
dos discos que fazem ou farão parte do sistema e que devem ser
analisados. Cada linha do arquivo deve corresponder à um disco
conforme exemplo da Listagem 5.
A linha 01 cria o diretório teste e depois cria o arquivo teste1.
lun utilizando o editor de texto vi. Em seguida, da linha a1 a
a3 temos um exemplo de configuração do arquivo teste1.lun.
Após essas configurações, devemos executar o aplicativo orion,
conforme evidenciado nas Figuras 8 e 9. É aconselhável que o
procedimento a seguir seja executado em horários fora de pico
(para não existir concorrência), permitindo que o resultado seja
mais confiável e assertivo:
$ORACLE_HOME/bin/orion -run simple -testname teste1 -num_disks 4 –hugenotneeded
Listagem 5. Procedimentos para utilização do Oracle Orion
01 $ mkdir teste/
02 $ vi …/teste/teste1.lun
a. teste1.lun:
1. /dev/oracleasm/disks/DISK1 -- > linha 1
2. /dev/oracleasm/disks/DISK2 -- > linha 2
3. … -- > linha n
Figura 8. Execução Oracle Orion
Figura 9. Arquivos gerados pela execução.
Sobre os parâmetros utilizados nesse comando, temos:
• run simple: execução do teste em modo small random e large random
não simultâneos;
• testname: arquivo criado com o path dos discos utilizados no teste;
• num_disks: quantidade de discos utilizados;
• hugenotneeded: alocação de páginas regulares quando huge pages
não estão disponíveis.
Os arquivos visualizados na Figura 9 nos fornecem informações
mais detalhadas dos testes e, como são do tipo .csv, podemos
utilizá-los para criar gráficos e melhor entendermos as projeções.
O arquivo *summary* exibe as mesmas informações listadas no
output da execução. Sendo assim, com base na Figura 8, temos
como throughput máximo 43,74 Mbps e 184 IOPS, valores próximos
à execução da CALIBRATE_IO.
Neste artigo, investigamos o uso das ferramentas CALIBRA-
TE_IO e Oracle Orion para produzir cargas de I/O compatíveis
com situações reais de utilização e avaliar a performance dos
discos. Através de configurações simples e rápidas, conseguimos
entender os processos e mensurar as características mais impor-
tantes do sistema de armazenamento, como a latência, throughput
máximo e as requisições de leitura e escrita.
Edição 149 • SQL Magazine 27
rIOPS: determinando o throughput no Oracle

Com base nos cenários expostos, podemos compreender que o Autor

acréscimo de discos não representou ganho algum de performan-
Renato Rosa Peres
ce. Essa ideia vale para o ambiente em questão, pois os resultados
renato.r.peres@gmail.com
variam conforme as configurações de hardware e software de
Graduado em Análise de Sistemas e Tecnologia da Informação
cada ambiente. pela Fatec. Possui experiência como consultor em banco de
Embora os resultados apresentados por ambas as ferramentas dados Oracle, MySQL, Microsoft SQL Server, PostgreSQL e Weblogic Server.
tenham sido bem parecidos, a utilização do Oracle Orion pos- É certificado Oracle OCS e OCE.
sui mais vantagens por permitir execuções com maior nível de
configuração e, principalmente, por não necessitar de nenhuma
base de dados criada. Tais funcionalidades podem ser utilizadas Links:
de maneira antecipada para um setup adequado na criação de
Parâmetros Oracle Orion
um ambiente.
https://docs.oracle.com/cd/E11882_01/server.112/e41573/iodesign.htm#PFGRF95228

28 SQL Magazine • Edição 149

Arquitetura do SQL
Server Database Engine
Compreendendo e assimilando conceitos
B
anco de dados, por definição, é um conjunto de
arquivos relacionados entre si, com diferentes
registros sobre diferentes assuntos. Porém, hoje
em dia, os bancos de dados são muito mais que isso.
No momento em que estamos, num mundo cada vez
mais globalizado, ele se tornou vital para uma empresa
funcionar e prosperar. A necessidade por informações o
tempo todo se tornou habitual e quando algo ou alguém
não consegue fornecer esse tipo de serviço, ele acaba
ficando obsoleto e perdendo espaço.
Dentro do universo de banco de dados, temos inú-
meras opções de Sistemas Gerenciadores de Bancos de
Dados (SGBD) para atender diferentes casos e cenários,
dos quais alguns se destacam no mercado. Neste artigo
traremos informações e detalhes sobre o Microsoft SQL
Server, mais precisamente sobre o módulo de Database
Engine (funcionamento do banco de dados). O SQL Ser-
ver foi criado em 1988 e vem evoluindo e desenvolvendo
novas soluções para usuários finais, desenvolvedores e
administradores. Hoje é um dos líderes de mercado e
possui grande importância no cenário de banco de da-
dos, facilitado pela sua grande integração com demais
softwares Microsoft e de terceiros. Desde sua criação
em 1988, já foram desenvolvidas 16 versões sólidas, sem
contar algumas derivações com ferramentas e opções
extras. A versão mais recente é o SQL Server 2016.
Podemos entender sua arquitetura considerando duas
etapas: a primeira seria uma visão de fluxo e a segunda
de funcionamento. Dentro dessas etapas temos mais
subdivisões, e para o fluxo de processo temos:
• Mecânica de fluxo relacional;
• Mecânica de armazenamento;
• SQL Server SO.
Já para o fluxo de funcionamento temos:
• Arquitetura de log;
• Arquitetura de dados;
• Arquitetura de paginação e extensão;
• Arquitetura de índices;
• Arquitetura de memória.
Fique por dentro
O artigo traz informações sobre a arquitetura do Microsoft SQL Server
Database Engine. Ele discute, em linhas gerais, o seu funcionamento
em duas etapas: fluxo de processo e de funcionamento. Também
conheceremos uma das opções na criação de índices, a FILL FACTOR.
Este artigo é importante no desenvolvimento de aplicações que irão
utilizar a base de dados SQL Server, no entendimento de problemas
de performance e na criação de cenários de alta disponibilidade.
Auxilia também projetistas nas análises de funcionamento, buscando
maior utilização de recursos do próprio SQL Server Database Engine
a fim de trazer mais estabilidade, performance e robustez do software
desenvolvido ou em desenvolvimento.
A primeira etapa fornece uma visão geral do funcionamento do
SQL Server, estando muitas vezes focada em parametrizações para
um melhor funcionamento do software, além de definir locais de
armazenamento dos diferentes arquivos (dados, log, binários). A
segunda etapa provê detalhes mais ricos de como o SQL Server
opera em uma camada transparente para usuários finais, além
de ser importantíssimo aos desenvolvedores, administradores e
projetistas de software. Saber como os arquivos de dados, memó-
ria, índices, arquivos de log e de paginação funcionam, auxilia na
estruturação à nível de hardware, separação de discos, reservas
de espaço e memória, identificação de lentidão de sistema, entre
outras atividades.
O entendimento das duas etapas por completo culmina com
a visão geral da arquitetura do SQL Server Database Engine e
potencializa-nos a administrar e desenvolver melhor soluções
que utilizam como base esse software. Obter o conhecimento da
arquitetura de um software de apoio, como acaba sendo os sof-
twares de banco de dados, é importantíssimo para as aplicações
extraírem seu máximo potencial. Um banco de dados bem confi-
gurado acaba eliminando diversos problemas que seus aplicativos
podem estar passando.
Etapa de Fluxo de Processo
Essa etapa compreende três itens: SQL OS, mecânica de fluxo e
mecânica de armazenamento.
Edição 149 • SQL Magazine 29
Arquitetura do SQL Server Database Engine
Eles são compostos por blocos da etapa de funcionamento, que
abordaremos na próxima seção.
SQL Server OS (Sistema Operacional SQL Server)
O SQL Server OS tem como objetivo fazer a comunicação entre
o ambiente em que a Database Engine está instalada e o próprio
banco de dados, sendo responsável por interpretar comandos em
nível de sistema operacional, rede e processamento.
Uma das funções que ele desempenha é a reserva de memória
para uso exclusivo do banco de dados, controle do nível de pa-
ralelismo e sua execução, mantendo sempre o banco de dados
íntegro e trazendo o resultado esperado pelo usuário final.
Além de controle de I/O (leitura e escrita), ele também realiza
agendamentos de tarefas, controle de locks e sincronização
com demais serviços do próprio SQL Server ou que possuem
integração com o mesmo.
Mecânica de Fluxo
Mecânica de fluxo é por onde começa o processo de execução
do comando informado pelo usuário. É nesta etapa que ocorre
a comunicação com o client (software utilizado para realizar a
comunicação com o banco de dados). O banco de dados recebe a
instrução SQL do usuário no bloco CMD PARSE (analisador de
comandos).
Nesta etapa do fluxo, primeiramente há uma verificação de sin-
taxe e collation (conjunto de caracteres aceito pelo banco de dados
que é configurado no momento de instalação do software). Após
a validação ter ocorrido com sucesso, é realizado um segundo
processo, o qual desenvolve uma sequência de etapas a serem
seguidas, similares a uma árvore de execução. Apenas após essas
duas etapas do CMD PARSE é que o fluxo segue até o próximo
bloco, o otimizador (optimizer).
O otimizador observa a estrutura gerada pelo CMD PARSE e
realiza otimizações a fim de trazer o resultado da maneira mais
rápida possível, utilizando índices e estatísticas da tabela como
base. E, caso a consulta já tenha sido executada anteriormente, o
mesmo economiza tempo com estes cálculos e reutiliza o plano
gerado previamente. Com o plano de execução montado e otimi-
zado, o processo é repassado ao responsável pela sua execução
(query executor).
O responsável pela execução da consulta é quem de fato
executa as tarefas solicitadas pelo usuário. Ele executa o plano
montado pelo bloco otimizador e com os resultados em mãos,
envia-os ao usuário através da comunicação estabelecida pelo
client no início do processo. A Figura 1 demonstra claramente
essa mecânica de fluxo.
Mecânica de Armazenamento
A mecânica de armazenamento começa a aparecer no momento
em que o fluxo chega ao bloco executador (Query Executor). Nesta
etapa há uma comunicação com a etapa de método de acesso. É ele
quem controla o tipo de acesso requisitado pela instrução. Caso a
consulta seja um select (comando de leitura de dados), o qual não
30 SQL Magazine • Edição 149
realiza alterações no banco de dados, o fluxo é direcionado para
o buffer manager. Porém, se for alguma operação de insert, update,
delete, os quais realizam alterações no banco de dados (comandos
de escrita/alteração/remoção de dados), o comando é direcionado
ao gerente de transação (Transaction Manager).
Figura 1. Imagem demonstrativa da mecânica de fluxo. Fonte: Microsoft
O gerente de transação (Transaction Manager) realiza, conforme
o próprio nome diz, o controle de transações. Nessa etapa ele
trabalha juntamente do gerenciador de lock (Lock Manager), que
gerencia os locks do banco de dados, e o gerenciador de log (Log
Manager) a fim de manter as propriedades ACID (Atomicidade,
Consistência, Isolamento e Durabilidade) do banco de dados, garan-
tindo a integridade das informações. Realizada a gravação dos
comandos necessários no log de transação (Transaction Log) e,
após os processos serem finalizados, repassa-os ao arquivo de
dados (data file).
O log de transação (Transaction Log) é um arquivo de log que
possui um identificador único e incremental, chamado LSN (Log
Sequence Numbers/ Números de sequência de log). Após a transação ser
gravada e iniciada no arquivo de log, um lock é criado, evitando
que outras operações acessem esses dados que estão sendo alte-
rados. O lock permanece até que a transação seja finalizada e as
alterações sejam salvas no data file. Este é o arquivo que contém
as informações e dados do seu banco de dados.
Com a transação finalizada, armazenada nos arquivos de log e
dados, o fluxo volto ao bloco métodos de acesso, o qual repassa
os dados da transação SQL ao buffer manager. Este, por sua vez,
guarda informações como transação executada, dados alterados,
planos de execução criados, otimizações realizadas e inclusive
o resultado das ações. Isso fica salvo em memória até que não
haja mais espaço disponível, havendo então o descarte de dados
mais antigos e substituição por dados novos gerados pela última
transação.
Na Figura 2 temos uma visão geral da etapa de fluxo de processo.
Podemos notar claramente na parte superior a mecânica de fluxo
abordada e na inferior a mecânica de armazenamento.
Etapa de funcionamento
Como informado previamente, nesta etapa temos uma subdivi-
são de cinco itens, a qual provê um entendimento dos diferentes
processos seguidos internamente no SQL Server:

Figura 2. Visão geral da Etapa de Fluxo de Processo. Fonte: Microsoft
Arquitetura de Log
Por definição, log é o arquivo que armazena toda e qualquer
transação no banco de dados. O arquivo de transaction log (log
de transação) torna possível qualquer reversão de alteração, se
necessário. O arquivo de log armazena toda transação, sempre
verificando a quantidade de espaço disponível, assim mantendo
a integridade das transações caso um rollback seja necessário
devido a algum erro ou cancelamento do processo por parte do
usuário/administrador.
Assim, toma-se por regra que para cada transação, o dobro do
espaço necessário é reservado e, em caso de sucesso, o mesmo
já é liberado para outra transação. As seguintes operações são
registradas no arquivo de log:
• O início e o término de cada transação;
• Toda modificação de dados (inserção, atualização ou exclusão).
Isso inclui mudanças por procedimentos armazenados do siste-
ma ou instruções DDL (linguagem de definição de dados) para
qualquer tabela, inclusive tabelas do sistema;
• Toda extensão, locação ou desalocação de página;
• Criação ou remoção (drop/delete) de um objeto (tabela, índice,
procedure, função.).
É considerada parte ativa do log da primeira transação que não
possui um commit ou rollback definido até sua última transação
não concluída. Essa janela é chamada de ‘log ativo’. Nenhuma parte
desse log deve ser perdida afim de termos uma completa recupe-
ração do banco de dados se necessário. O arquivo de transaction
log (log de transação) é o responsável por manter a integridade dos
dados no banco de dados, auxiliando a manter as regras ACID.
Arquitetura de Dados
O SQL Server tem seu banco de dados formado por conjuntos
de arquivos, que pertencem a diferentes filegroups (grupos de
arquivos) que ficam armazenados no sistema operacional. Estes
são únicos e pertencem somente a um banco de dados:
• Primário: filegroup padrão do SQL Server, possui o arquivo
.mdf que contém informações sobre toda estrutura do banco de
dados, como nome de demais arquivos, informações sobre objetos,
localização dos demais arquivos e objetos;
• Secundários: demais arquivos criados a partir do crescimento
do banco de dados. Possuem extensão .ndf, contêm apenas in-
formações/dados do usuário, como tabelas, procedures, dados.
Podem inclusive fazer parte de um segundo filegroup que não o
primário, estratégia geralmente considerada por administradores
afim de facilitar restaurações a partir de backups;
• LOG: filegroup exclusivo para arquivos de transaction log (pos-
sui extensão .ldf), armazenam todas as informações/dados utili-
zadas pelo usuário para realizar alguma operação. São essenciais
para a recuperação do banco de dados em caso de algum problema.
Todos os nomes de arquivos e localizações do mesmo são ar-
mazenados no arquivo .mdf do banco de dados e na base master
da instância. Ao se criar o arquivo, o mesmo deve possuir nome
lógico único dentro do banco de dados, e físico único dentro do
servidor/instância.
Os arquivos podem possuir qualquer tamanho desejado pelo
cliente, pode-se ainda definir um tamanho limite e criar uma
política de crescimento. Aqui está uma grande vantagem do SQL
Server, a fim de auxiliar na manutenção do banco de dados sem
intervenção humana, especialmente quando o administrador de
banco de dados possui inúmeras instâncias para administrar.
Já os filegroups podem ser classificados em:
• Primário: padrão do SQL Server ao se criar um banco de
dados. Possui o arquivo .mdf e demais informações sobre o
banco de dados, tais como: tamanho dos arquivos, quantidade
de arquivos e localização dos arquivos que compõem o banco
de dados;
• Secundários: criados pelos administradores, sempre armaze-
nam dados/informações da aplicação e do usuário, não possuem
informações estruturais do banco de dados.
Arquitetura de paginação e extensão
Páginas
Na questão armazenamento do SQL Server, tudo se resume
a página (logicamente falando), embora essas páginas estejam
alocadas dentro dos arquivos .mdf ou .ndf. São nelas que são es-
critas e lidas as informações do banco de dados. São de tamanho
fixo, 8 kb, e possuem uma numeração única para cada uma delas,
partindo de 0 e indo até n.
Dentro dos 8 kb de cada página, é reservado um espaço de 96
bytes para o cabeçalho, que armazena informações de sistema
sobre a página, tais como o número e o tipo de página, a quan-
tidade de espaço livre e o ID de unidade de alocação do objeto
que possui a página.
Existem oito tipos diferentes de tipos de páginas, são eles:
• Dados: linhas contendo todos os dados, exceto dados text, ntext,
image, nvarchar(max), varchar(max), varbinary(max) e xml, quando o
texto na linha é definido como ON;
• Índice: entradas de índice;
Edição 149 • SQL Magazine 31
Arquitetura do SQL Server Database Engine
• Texto/Imagem: tipos de dados de objeto grande (text, ntext,
image, nvarchar(max), varchar(max), varbinary(max) e xml). Colunas
de comprimento variável quando a linha de dados excede 8 KB:
varchar, nvarchar, varbinary e sql_variant;
• Global Allocation Map, Shared Global Allocation Map: informações
sobre alocação de extensões;
• Page Free Space: informações sobre alocação de página e espaço
livre disponível em páginas;
• Index Allocation Map: informações sobre extensões usadas por
uma tabela ou índice por unidade de alocação;
• Bulk Changed Map: informações sobre extensões modificadas
pelas operações em massa desde a última instrução BACKUP
LOG por unidade de alocação;
• Differential Changed Map: informações sobre extensões modifica-
das desde a última instrução BACKUP DATABASE por unidade
de alocação.
Extensões
Extensões são coleções das páginas, no caso do SQL Server
limitado a oito páginas por extensão, assim limitando a 64 kb de
dados contínuos. A fim de manter as extensões eficientes, foram
desenvolvida duas políticas de extensões:
• Extensão mista: páginas compartilhadas por até oito objetos
diferentes (uma página por objeto), utilizado em objetos recém-
-criados e/ou de baixo uso;
• Extensão uniforme: páginas que pertencem a um único objeto,
sendo utilizado em objetos grandes e de muito uso, obtendo como
resultado mais performance.
Arquitetura de Memória
Por natureza, o SQL Server utiliza e libera memória dinami-
camente conforme necessário. Porém, existem parâmetros para
tornar tais configurações fixas, os quais são recomendados em
ambientes mais críticos.
Normalmente, se tratando de banco de dados, temos por regra
que: quanto mais memória melhor. Quanto mais informações
puderem ser armazenadas em memória, maior será a velocidade
de retorno. Entretanto, há limitações que devemos respeitar. Em
ambientes de 32 bits, o máximo de memória que o SQL Server
suporta seriam aproximadamente 4GB e em ambientes 64 bits
ficamos limitados de 7 a 8 TB de memória (dependendo da ar-
quitetura do sistema).
Uma das principais metas de design de todo o software de
banco de dados é minimizar acesso ao disco, visto que este é o
maior gargalo em nível de hardware. O SQL Server cria um pool
de buffers na memória para manter o máximo de dados nela.
Grande parte do código do SQL Server é dedicado a minimizar
o número de leituras e gravações físicas entre o disco e o pool de
buffers, tentando encontrar um equilíbrio entre os dois objetivos:
• Evitar que o pool de buffers consuma toda memória do sistema,
afetando a performance;
• Minimizar a E/S física aos arquivos, maximizando o tamanho
do pool de buffers.
32 SQL Magazine • Edição 149
Um buffer é uma página de 8 kb da memória, mesmo tamanho
de uma página de dados ou de índice como mencionado na ar-
quitetura de páginas e extensões. Portanto, o cache do buffer é
dividido em páginas de 8 kb. O gerenciador de buffer gerencia
as funções lendo páginas de dados ou de índice dos arquivos do
disco de banco de dados no cache do buffer e gravando páginas
modificadas de volta no disco. Uma página permanece no cache
do buffer até que o gerenciador de buffer precise da área para ler
mais dados. Os dados serão gravados no disco apenas se forem
modificados. Os dados podem ser modificados no cache do buffer
várias vezes antes de serem gravados no disco.
Como o gerenciador de buffer usa a maior parte da memória no
processo do SQL Server, ele coopera com o gerenciador de memó-
ria para permitir que outros componentes usem seus buffers. O
gerenciador de buffer interage principalmente com os seguintes
componentes:
• Gerenciador de recurso para controlar o uso de memória global
e, em plataformas de 32 bits, controlar o uso de espaço de endereço;
• Gerenciador de banco de dados e SQLOS (SQL Server Sistema
Operacional) para operações de E/S de arquivo de nível baixo;
• Gerenciador de log para log write-ahead.
Sendo ‘log write-ahead’ um mecanismo do SQL Server que ga-
rante que nenhuma modificação de dados seja gravada no disco
antes de o registro de log associado ser gravado no disco. Isso
mantém as propriedades ACID de uma transação.
Arquitetura de índices
Um índice é uma estrutura de pesquisa criada em uma tabela
para otimizar, classificar e melhorar o desempenho de uma con-
sulta. Índices são criados em uma coluna ou colunas particulares
e armazenam os valores de dados dessas colunas em ordem. No
SQL Server, projetar, gerenciar e manter índices eficientes são sem
sombra de dúvida a maneira mais eficaz de se consultar dados
armazenados e garantir o máximo desempenho. Os índices são
projetados para facilitar a busca da informação em um grande
volume de dados usando a menor quantidade de recursos de
leitura. O índice correto, criado para a consulta correta, pode
reduzir o tempo de execução da consulta de horas para segundos.
Um banco de dados não necessariamente precisa ter índices para
obter os dados, uma tabela pode ser varrida até que se encontrem
os dados necessários, contudo, quanto mais dados há na tabela,
maior será o tempo de recuperação desses dados.
Para que a consulta aos dados de uma tabela atinja uma perfor-
mance satisfatória, devemos primeiramente elaborar um projeto
de índices. Os índices podem ser adicionados ou retirados de
uma tabela quando necessário sem comprometer o esquema do
banco de dados, uma vez que não fazem parte do projeto lógico
da tabela. Mas cuidado, o excesso de índices pode ser pior do que
uma quantidade pequena de índices na tabela.
Imagine um livro onde você precisa encontrar um determinado
assunto, você poderá chegar ao seu objetivo passando página
por página até encontrar o assunto ou poderá consultar o índice
do livro e localizar a página correspondente ao assunto. As duas
formas te levarão ao objetivo final, porém com o uso do índice
você localiza o assunto desejado com menor esforço.
O SQL Server utiliza, por padrão, a mesma estrutura de índices
reconhecida como B-Tree (árvore binária). A mesma possui uma
página raiz, com inúmeras páginas intermediárias e uma última
página para os nós folhas. No SQL Server existe quatro tipos de
índices diferentes, que são: clusterizados, não clusterizados, XML
e espaciais.
• Índices clusterizados são ordenados conforme a chave do
cluster, fornecendo assim uma ordem de classificação para o
armazenamento da tabela. Esta ordem de classificação não é a
ordem física dos dados e sim a classificação lógica das páginas
do índice. É possível definir somente um índice clusterizado
por tabela, pois a mesma só pode ser ordenada de uma única
maneira e uma única vez. Geralmente, utiliza-se na chave
primária da tabela visto que é o índice de maior velocidade de
retorno MS SQL Server.
• Índices não clusterizados não classificam ordens e portando é
possível criar inúmeros índices nonclustered por tabela, tendo
cada um no máximo 900 bytes na chave de índice e no máximo
16 colunas. Ao percorrer um índice não clusterizado até seu nível
folha em busca do ponteiro para retornar os dados necessários,
o mesmo trata os seguintes casos:
- Existe índice clusterizado na tabela, desta forma o ponteiro
aponta para a chave do cluster;
- Não existe índice clusterizado na tabela, então o ponteiro
aponta para a linha de dados da tabela.
• Índices XML podem ser criados em colunas de tipo de dados
XML. Eles indexam todas as marcas, valores e caminhos através
das instâncias XML na coluna e se beneficiam do desempenho
das consultas. Seu aplicativo pode se beneficiar de um índice XML
nas seguintes situações:
- Consultas em colunas XML são comuns em sua carga de
trabalho. O custo da manutenção de índices XML durante a
modificação de dados deve ser considerado;
- Seus valores XML são relativamente grandes e as partes
recuperadas são relativamente pequenas. A construção de ín-
dices evita a análise de todos os dados em tempo de execução
e beneficia pesquisas de índice para processamento eficiente
de consultas;
- Índices XML se encaixam nas seguintes categorias: índice
XML primário e índice XML secundário.
O primeiro índice na coluna de tipo XML deve ser o índice
XML primário. Usando o índice de XML primário, os seguintes
tipos de índices secundários podem ser considerados: PATH,
VALUE e PROPERTY. Dependendo do tipo de consulta, esses
índices secundários podem ajudar a melhorar o desempenho
de consultas.
• Um índice espacial é um tipo de índice estendido que permite
indexar uma coluna espacial. Uma coluna espacial é aquela que
contém tipo de dados espaciais, como geometria ou geografia.
O SQL Server é capaz de trabalhar com os modelos de armaze-
namento OLTP (On-line Transaction Processing ou Processamento
de Transações em Tempo Real) e OLAP (On-line Analytical Pro-
cessing ou Processamento Analítico On-line). Os sistemas OLTP
têm como principal finalidade dar integridade, consistência e
boa performance nas operações de inclusão, exclusão e alteração
de dados. Os dados com os quais os sistemas OLTP trabalham
são normalizados e armazenados em tabelas inter-relacionadas.
Os sistemas OLAP utilizam dados sem normalização, ou dados
desnormalizados, o que permite a criação de estruturas multi-
dimensionais com o objetivo de oferecer boa performance na
obtenção de informações.
Os dados no SQL Server são armazenados em páginas de dados
de 8.192 bytes os quais podem ser usados para armazenar 8.060
bytes de dados, sendo que o cabeçalho ocupa 96 bytes. As pági-
nas de dados são mantidas em uma estrutura conhecida como
B-tree. Essa estrutura possui três níveis conhecidos como raiz,
intermediário e folha. O FILL FACTOR ou fator de preenchimento
é utilizado para ajustar o armazenamento de dados e desempenho
do índice. Quando se cria ou recria um índice, o fator de preen-
chimento é informado e determina a quantidade de espaço a ser
preenchido com dados em cada página no nível folha. Para se
criar bons índices são necessários alguns fatores como, conhecer
seus dados, conhecer sua carga de trabalho e conhecer como o
SQL Server trabalha.
A partir de agora, veremos como configurar o FILL FACTOR
do índice para obtenção de melhores resultados. Antes, porém, é
necessário primeiro entender o básico sobre como os índices são
organizados através do conceito da estrutura B-tree e seus níveis.
Ao tomar conhecimento dessas informações você estará mais apto
para criar os índices corretos para sua carga de trabalho.
B-tree
O SQL Server utiliza a estrutura B-tree para construir e manter
índices. Uma estrutura B-tree é composta por um nó raiz com
uma página de dados, uma ou mais páginas no nível intermedi-
ário (opcional) e uma ou mais páginas no nível folha (opcional).
Os dados no nível folha estão armazenados na ordem que foram
especificados na sua criação, todos os caminhos que partem do
nó-raiz até o nível folha possuem comprimentos iguais. O número
de linhas que uma página pode ter depende do tipo de dados das
colunas que foram escolhidas para esse índice. Na Figura 3 temos
a visão de uma página de dados.
Uma página de dados pode armazenar até 8.060 bytes de dados
ou 8kb. Um índice criado em uma coluna do tipo (inteiro) pode
armazenar 2.015 valores em uma única página. Os níveis raiz e in-
termediário da B-tree são compostos pela primeira entrada de cada
página do nível abaixo, juntamente com um ponteiro para a página
de onde o valor veio. Na Figura 4 temos um exemplo de B-tree.
Níveis da B-tree
A quantidade de níveis de um índice e a quantidade de páginas
que um nível pode ter é determinada por um cálculo simples:
Edição 149 • SQL Magazine 33
Arquitetura do SQL Server Database Engine
basta pegar 8.060 bytes e dividir pelo valor da chave do índice
determinado pelo seu tipo de dados.
Se for construído um índice em uma coluna “datetime”, cada
linha terá 8 bytes de armazenamento no índice. Se uma tabela
contém 504 linhas de dados, serão necessários 4032 bytes de
armazenamento. Sendo assim, todos os seus dados caberiam em
uma única página de dados e seu índice teria apenas uma página
representando então os níveis raiz e folha, então você poderia
armazenar até 1.007 linhas utilizando a mesma página.
Figura 3. Página de dados
Figura 4. Estrutura B-tree
Porém, ao armazenar a 1.008ª linha, os seus dados não mais
caberiam em uma única página e o SQL Server alocaria mais duas
páginas para o índice em um processo conhecido no SQL Server
como “Page split” ou divisão de página.
Uma das páginas alocadas assume a função de raiz e empurra
a antiga página para o nível folha e divide a metade dos dados
com a outra página alocada. O próximo passo será preencher a
nova página raiz com os dados da primeira entrada das duas
outras páginas. Com isso, seu índice agora tem uma página raiz
e duas páginas no nível folha. Nesse caso não foi necessário um
nível intermediário, pois o nível raiz pode conter todos os dados
do início das páginas no nível folha.
Para obter um dado através da busca na B-tree, o SQL Server
inicia sua busca pelo nó raiz, verificando onde o valor passado
se encontra e através do ponteiro inicia a busca no nível interme-
34 SQL Magazine • Edição 149
diário a que esse valor se refere. No nível intermediário inicia-se
novamente a busca até encontrar o valor e, novamente através
do ponteiro, inicia a busca no nível folha corresponde àquele
valor. No nível folha inicia-se novamente a busca até encontrar
o valor desejado e então os dados são localizados e retornados.
A seguir falaremos de duas estruturas de índices que podem
ser usadas.
Clustered
Nessa estrutura a tabela é ordenada fisicamente. Podemos dizer
que o índice clustered ou índice agrupado é a própria tabela, pois
através dele podemos recuperar todos os dados da tabela, com isso
o SQL Server precisa apenas de uma operação para percorrer e
encontrar os dados. Quando um índice cluster é criado, os dados
da tabela são o nível folha. No momento em que o índice cluster
é criado, os dados da tabela são copiados e ordenados pela chave
de cluster. Pode existir apenas um índice clustered por tabela,
uma vez que as linhas de dados só podem ser ordenadas de uma
maneira. Geralmente ele é criado em uma coluna designada como
PRIMARY KEY ou chave primária.
As páginas de dados desse índice se encontram no nível folha.
Ele deve sempre ser criado antes dos índices nonclustered já que
podem alterar a ordem física das linhas de dados. Isso evitará a
reconstrução dos índices nonclustered.
NonClustered
Nessa estrutura, os dados são ordenados logicamente: índices
nonclustered ou índices não agrupados possuem os dados defi-
nidos pelo índice, os dados definidos pelo comando INCLUDE
juntamente com um “ponteiro” para a linha de dados. Se a página
de dados estiver em uma tabela com índice clustered, esse “pontei-
ro” será a chave do índice cluster, caso contrário se ela estiver em
uma heap (BOX 1), será um apontador de linha. Nessa estrutura,
quando o SQL Server percorre o índice até o nível folha, mais uma
operação é necessária para localizar os dados. Podem existir até
1.000 índices nonclustered por tabela, mas vale lembrar que a cada
inclusão, alteração ou exclusão de dados, esse índice precisa ser
reconstruído, portanto use com moderação.
BOX 1. Heap (pilha)
Quando uma linha de dados de uma tabela é armazenada sem uma determinada ordem, essa
situação é conhecida como heap (pilha). Uma heap é composta de múltiplas páginas e cada página
contém múltiplas linhas de dados. Toda tabela sem um índice clustered é, portanto, uma heap.
Page Split
Uma page split ou divisão de página ocorre quando o SQL Ser-
ver identifica que uma página de dados está cheia e não há mais
lugar para alocar uma nova linha de dados, então ele cria uma
nova página de dados e divide os dados da página cheia pela
metade, deixando 50% na página atual e os outros 50% na nova
página. Essa nova página não necessariamente estará próxima
da antiga, mas o SQL Server mantém uma ligação entre elas para
saber onde encontrar esses dados, mesmo que elas não estejam
sequencialmente em ordem.
O processo de divisão de páginas em si já é muito caro para o
sistema, pois, à medida que essas divisões ocorrem, fazem com
que a varredura dos dados se torne cada vez mais cara pelo fato
dos dados não estarem mais ordenados fisicamente causando
excessivos I/Os. Outro problema na divisão de páginas de dados
está na quantidade de espaço em branco deixado nas páginas
após se dividirem. Como o nível folha é a maior estrutura de um
índice, ela está mais propensa a se fragmentar, portanto, ao criar
um índice determinando o quanto de espaço em branco deve
existir na página para novas inserções e atualizações, poderá
reduzir as divisões de páginas e manter a sua tabela intacta por
mais tempo. É possível fazer isso informando um valor correto
do fator de preenchimento para seu índice.
Fragmentação
Fragmentação é um termo geral usado para descrever os efeitos
causados nos índices pela modificação de dados. Existem dois ti-
pos de fragmentação: internas e externas. A fragmentação interna
ocorre quando há espaços vazios nas páginas dos índices, tanto
no nível folha quanto nos demais níveis e é causada por divisões
de páginas e operações de exclusão que deixam a página sem
a sua total capacidade. Indica que o índice está ocupando mais
espaço do que o necessário, causando aumento do uso de espaço
em disco, mais páginas para ler os dados e mais memória.
A fragmentação externa ocorre quando a página que compõem
o nível folha do índice cluster não está mais ordenada de forma
eficiente e é causada pelas divisões de páginas, reduzindo a efi-
ciência da busca ordenada.
FILL FACTOR
No momento que se cria ou recria um índice, você tem a possi-
bilidade de configurar uma opção conhecida como FILL FACTOR
ou fator de preenchimento. Ela indica qual a porcentagem que a
página de dados no nível folha de um índice poderá ser preen-
chida com dados e quanto ficará à disposição para expansão. Por
exemplo, se especificarmos um valor de fator de preenchimento
igual a 80, significa que 20 por cento de cada página ficará vazio,
ficando à disposição para futuras expansões. Vale ressaltar que
o espaço vazio fica espalhado entre as linhas dos dados e não ao
final da página. O valor do fator de preenchimento pode ser uma
porcentagem de 1 a 100 e o valor padrão do servidor é zero, onde
zero significa que a página de dados no nível folha será preenchida
por completo.
Façamos uma analogia, imagine uma biblioteca onde as prate-
leiras com os livros estão ordenados alfabeticamente pelo nome
do autor e estão completamente cheias. Se a biblioteca adquire
um novo exemplar cujo nome do autor comece com a letra “C”,
então a funcionária teria que retirar todos os livros da prateleira
para reorganizá-los e teria que fazer isso com todas as demais
prateleiras até que finalmente colocaria o último exemplar na
nova prateleira criada. Parece muito trabalhoso não?
Bom, e se ao invés de todo esse trabalho, ao organizar as pra-
teleiras, ela deixasse 10 por cento de espaço livre para novos
exemplares: Poderíamos simplesmente inserir o novo exemplar
na sua posição correta e reorganizar os demais no espaço livre
que foi deixado na prateleira, reduzindo assim o esforço gasto na
organização das prateleiras e é isso que o FILL FACTOR faz.
A decisão de configurar o FILL FACTOR de um índice passa pelo
entendimento de suas tabelas no banco de dados. Se sua tabela
recebe muitas inserções, atualizações e poucas consultas, o ideal é
configurar um valor de fator de preenchimento baixo, pois assim
deixará espaço para expansões futuras. Agora se a sua tabela é
utilizada mais para consulta e quase não recebe nem atualiza os
dados, o ideal é que se configure um valor de fator de preenchi-
mento igual a cem por cento. O fator de preenchimento é aplicado
no nível folha da estrutura de índice, para que se aplique ao nível
raiz e intermediário a opção PAD_INDEX deverá ser especificada.
Um fator de preenchimento bem configurado é capaz de reduzir
a ocorrência de divisões de páginas e ainda consegue disponibi-
lizar espaço nos índices para permitir expansões futuras, sendo
esse espaço nas páginas de dados de um índice clustered ou em
uma página de índice caso seja um nonclustered.
Deixar um fator de preenchimento cem por cento nem sempre
é bom. Se você preenche as páginas completamente e mais tarde
precisa inserir novos dados nessa página, eles não irão caber.
Para preservar a estrutura do índice e organizar os dados, o SQL
Server terá que realizar algumas tarefas caras para o sistema tais
como, adicionar uma nova página, mover metade do conteúdo
para a nova página, atualizar a página antiga com um ponteiro
para a nova e isso gera muito trabalho, causando excesso de I/O
e registros nos logs.
Por outro lado, deixar um fator de preenchimento diferente de
cem por cento também pode ser prejudicial, uma vez que seus
dados serão espalhados por mais páginas e o SQL Server terá que
ler mais páginas na memória. Assim você desperdiça espaço em
cache que estão apenas vazios.
Isso pode ser um grande desperdício, pois nem todas as divisões
de páginas são causadas por índices ruins. Por exemplo, um ín-
dice em um campo inteiro com valor IDENTITY com dados que
raramente são excluídos e atualizados, você pode configurar o
fator de preenchimento cem por cento, pois os dados serão sempre
inseridos no final do índice, assim sendo, as páginas adicionadas
não são consideradas divisões de páginas ruins.
Definir o fator de preenchimento diferente do padrão diminui
as linhas por páginas do índice, aumentando assim o número de
páginas que devem ser lidos. Segundo o Books Online do SQL Ser-
ver, a perda de desempenho é o dobro do fator de preenchimento
escolhido. Isso significa que se for definido o valor de cinquenta
por cento para o fator de preenchimento, o SQL Server irá levar
o dobro de leituras para obter os dados.
O fator de preenchimento não se aplica em uma heap. Essa con-
figuração somente se aplica em índices, não em todas as tabelas.
Se você tem uma tabela que não tem um índice cluster, então
não poderá informar um fator de preenchimento, nem mesmo se
Edição 149 • SQL Magazine 35
Arquitetura do SQL Server Database Engine

defini-lo no nível do servidor. O fator de preenchimento também Listagem 1. Criando um índice com fator de preenchimento informado
não se aplica quando as novas páginas são inseridas no final do CREATE NONCLUSTERED INDEX [Index Name] ON [dbo].[Table Name]
índice, por exemplo, um campo com um valor identity. Assim (
como também não se aplica em páginas LOB (Large Object) que [Column Name] ASC
)WITH ( DROP_EXISTING = ON, FILLFACTOR = 80) ON [Filegroup Name]
armazenam dados do tipo varchar (max), varbinary (max), entre GO
outros.
Mesmo com uma boa definição de FILL FACTOR, você precisa ter
uma boa rotina de manutenção do banco de dados, já que com o
tempo os espaços livres deixados nas páginas para inserções futu-
ras também serão ocupados. Assim, pode ser necessária a divisão
de páginas e a intervenção manual do DBA para reconstruir esses
índices e informar um novo valor para o fator de preenchimento
evitando assim sua fragmentação.
Você pode configurar o FILL FACTOR utilizando o SQL Server
Management Studio ou o Transact-SQL. Na Figura 5, que pode ser
acessada clicando-se com o botão direito no item Server dentro do
Object Explorer e em seguida em Properties, podemos ver a con-
figuração do fator de preenchimento com o valor padrão através
das propriedades do servidor SQL Server no SSMS.

Figura 6. Configuração de FILL FACTOR pelo design da tabela

Figura 5. Configuração padrão de FILL FACTOR por servidor

Também pelo SSMS podemos configurar o fator de preenchi-

mento através da opção “design” da tabela e escolhendo a opção
de gerenciamento de índices e chaves conforme nos mostra a
Figura 6.
Outra opção, também no SSMS, é configurarmos o fator de preen-
chimento de cada índice individualmente pelas suas propriedades
conforme nos mostra a Figura 7.
Utilizando T-SQL ou Transact-SQL, podemos configurar o fator
de preenchimento na criação e recriação do índice, conforme
podemos ver no código a seguir, que recria um índice com um
determinado fator de preenchimento informado, e na Listagem 1.
ALTER INDEX [Index Name] ON [dbo].[Table Name] REBUILD PARTITION = ALL
WITH ( FILLFACTOR = 90 )
Figura 7. Configuração individual de FILL FACTOR pela propriedade do índice
Para expor e entender as estruturas de um índice mais detalha-
damente, use a DMV dm_db_index_physical_stats. Ela é uma das
funções mais úteis para obtermos um diagnóstico da estrutura
da sua tabela.
O SQL Server Database Engine possui uma arquitetura muito
eficaz e versátil. Como apresentado no artigo, ela é composta por
duas etapas: fluxo de processo e fluxo de funcionamento. Cada
uma com suas particularidades, porém havendo uma grande
interação, a fim de atingir um melhor desempenho, integridade e
segurança. Ao aprofundar as análises nesses fluxos, conhecemos

36 SQL Magazine • Edição 149

também outros blocos com diferentes mecânicas, funcionando de
maneira integrada aos demais.
Grande parte do desempenho de um banco de dados é obtida
através da estrutura de memória, extensões e paginação as quais
estão extremamente conectadas. A página tem seu tamanho defi-
nido e se junta a outras páginas tornando-se uma extensão. Essa
pode ser mista ou uniforme, dependendo apenas se as demais pá-
ginas fazem parte de mais objetos ou compõem apenas um único.
A arquitetura de memória foi desenvolvida para poder abrigar
o máximo de informação em memória, minimizando o acesso
em disco, o qual geralmente acaba sendo o gargalo de qualquer
processo. Além disso, a arquitetura de memória possui um buffer
de instruções e comandos. Nesse caso, se alguma instrução ou
operação já tiver sido realizada previamente, essa mesma está no
buffer de memória e não há necessidade de realizar todo o fluxo
de processo novamente, aproveitando apenas o plano de execução
diretamente do buffer.
Somando-se a toda essa estrutura do fluxo de processo, na etapa
de funcionamento temos os índices que trazem muita velocida-
de no retorno das instruções e comandos informados. Com os
diferentes estilos de índice que o SQL Server Database Engine
suporta, é possível cobrir as necessidades que a grande maioria
das aplicações tem, desde dados espaciais, colunas em xml e
colunas com textos/números.
Sua estrutura de dados (filegroups) auxilia muito no gerencia-
mento dos arquivos de dados, visto que o mdf possui informações
de estrutura, localizações e tamanhos, além de poder possuir
dados de usuários. A criação de diversos filegroups é aconselhada,
mantendo o filegroup padrão (primário/primary) com informações
de sistema apenas e os demais (secundários) com dados de usuá-
rios. Lembrando que a quantidade e diversificação de filegroups
dependem da estratégia de backup escolhida pelo administrador
do banco de dados.
O SQL Server Database Engine tem manuseio facilitado devido
a sua arquitetura, trazendo com ele grande desempenho e dis-
ponibilidade. A sua integridade (lógica), assegurada pelo log de
transação, o qual armazena os valores antes e depois da transação,
assim com o próprio comando executado, permite recuperar fa-
cilmente o banco de ‘crashes’ eventuais, além de ser fundamental
para garantir as propriedades ACID em casos de rollback.
Autor
Henrique Ribeiro
henriqueribeiro91@yahoo.com.br
https://sqlissues.wordpress.com/
DBA MS SQL Server desde 2010, certificações Microsoft em
nível de Windows Server e SQL Server.
Autor
Roger Gontijo Resende
gontijo.roger@gmail.com
www.estudandosql.blogspot.com.br
Bacharel em Sistemas de Informação, possui um MBA em
Gestão de T.I pela faculdade Pitágoras (Unidade Belo Horizonte) e cer-
tificação MCP, MTA, trabalha com banco de dados SQL Server na Lifesys
Informática desde 2011.
Edição 149 • SQL Magazine 37
Descoberta de
conhecimento utilizando
o processo KDD
Um estudo de caso em uma base de dados de
pizzaria
A
s informações chegam a grandes quantidades
e mudam numa velocidade muito rápida. É
importante armazenar essas informações em
grandes bases para filtrá-las, estudá-las e transformá-las
em conhecimento afim de que possam ser úteis ao traçar
estratégias e tomar decisões. O uso de ferramentas de
extração do conhecimento possibilita tratar as informa-
ções e apresentá-las numa forma clara, precisa e de fácil
compreensão aos tomadores de decisões e gestores, au-
xiliando-os no planejamento de ações de marketing e nas
mais diversas atividades que requerem ações decisivas.
Os avanços contínuos na área da Tecnologia da Infor-
mação têm gerado grandes quantidades de informações,
que são consequentemente armazenadas em grandes
bases de dados. As diversas tecnologias existentes, como
computadores, celulares, leitores de códigos de barras,
sistemas gerenciadores de banco de dados viabilizam
a proliferação de inúmeras bases de informações, que
precisam ser trabalhadas, analisadas e transformadas
em informações úteis, que possam gerar conhecimento.
É impossível ao ser humano tratar todas essas informa-
ções sem o auxílio de ferramentas apropriadas, daí a ne-
cessidade do desenvolvimento de técnicas de mineração
de dados, que auxiliem o homem a selecionar, analisar,
interpretar e relacionar os dados para desenvolver es-
tratégias de ação em cada contexto.
O processo de KDD (Knowledge Discovery in Databa-
ses) foi formalizado em 1989 em referência a procura de
conhecimento a partir de bases de dados. Seu objetivo
principal é extrair conhecimento de grandes bases da-
dos. A descoberta do conhecimento envolve uma sequ-
ência de fases que devem ser obedecidas, iniciando-se
com a coleta de informações, passando pelo tratamento
e, por fim, a apresentação do resultado final da extração
do conhecimento.
38 SQL Magazine • Edição 149
Fique por dentro
As técnicas de mineração de dados tem ganhado bastante espaço
nos últimos anos, sendo processos essenciais para a descoberta de co-
nhecimento em bases de dados. Essas técnicas visam explorar grandes
quantidades de dados com o intuito de encontrar padrões consistentes
de relacionamentos entre os atributos das bases de dados. Isso pode
ser utilizado, por exemplo, para auxiliar na tomada de decisões sobre
estratégias e vantagens competitivas na gestão de pizzaria. Por meio
da aplicação de algoritmos específicos de mineração de dados em
uma base de dados de pizzaria, o resultado dessas análises pode ser
utilizado para planejamento estratégico. Por exemplo, a previsão de
vendas pode ser utilizada para planejamento de compra de matéria
prima, a identificação dos sabores das pizzas pode levar a empresa a
realizar algum tipo de promoção de vendas, enquanto que a identi-
ficação de grupos de clientes pode levar a empresa a planejar uma
estratégia de marketing para recomendação de produtos similares.
Ou seja, a aplicação de técnicas de mineração de dados pode ser
considerada como um diferencial competitivo para as empresas, já
que este tipo de conhecimento não pode ser obtido pela utilização
de softwares tradicionais.
Para trabalhar com o processo de KDD, faz-se necessário ter
objetivos definidos, saber quais resultados deseja-se atingir e
ter conhecimento do domínio da aplicação. Nesse processo, três
profissionais são envolvidos:
Analista de dados: conhece as ferramentas aplicadas ao processo,
como algoritmos e inteligência computacional, mas nem sempre
conhece o domínio ao qual os dados pertencem;
Especialista no domínio: tem conhecimento do domínio dos
dados e sabe onde aplicá-los;
Usuário (pessoa ou empresa): quem fará uso das informações
resultantes do processo de KDD.
Processos de extração do conhecimento - KDD
O processo de KDD é composto por cinco fases: seleção
de dados, pré-processamento, transformação, mineração e in-
terpretação/avaliação. Trata-se de um processo iterativo, pois
poderá ser repetido quantas vezes for necessário na busca de
melhores resultados, mas também é considerado um processo
interativo devido à participação de profissionais como o usuário
final, o especialista do domínio e o analista do domínio. Esse
processo é aplicado na identificação de padrões compreensíveis,
válidos, novos e potencialmente úteis a partir de grandes bases
de dados. Embora cada fase do processo de KDD seja indepen-
dente, podendo ser tratada individualmente, existe uma forte
dependência entre elas. Assim, para que seja feita uma correta
transformação dos dados, é necessário ter uma base de dados
corretamente modelada. Da mesma maneira, para que os dados
sejam devidamente preparados, é necessário ter como objetivo
a aplicação de ferramentas de extração do conhecimento, como
um algoritmo da mineração de dados para atingir o objetivo
pretendido. Na Figura 1 são representadas as fases do processo
KDD e as próximas seções têm o objetivo de apresentar de forma
simplificada o objetivo de cada uma delas.
Figura 1. Fases do processo de KDD. Fonte: FAYYAD (2006)
Nas etapas operacionais do processo de KDD é importante
considerar que as variáveis do problema (também chamadas de
atributos) podem ser classificadas sob dois aspectos distintos:
quanto à representação de seus valores (tipo de dados) e quanto
à natureza da informação (tipo de variável). Os tipos de dados
indicam a forma como estão armazenados e os tipos de variáveis
indicam a forma com que a informação deve ser interpretada.
As variáveis podem ser classificadas como:
• Nominais ou Categóricas: são responsáveis por nomear ou rotular
objetos. Os valores das variáveis nominais podem ser represen-
tados por tipos de dados alfanuméricos;
• Discretas: são semelhantes às variáveis nominais, mas os valores
que elas podem assumir possuem um ordenamento, por exemplo,
o dia da semana, no qual “sábado” vem após a “sexta-feira” e antes
de “domingo” e assim sucessivamente.
• Continuas: são variáveis cujos valores tem uma relação de ordem
entre eles e podem ser finitos ou infinitos, como renda ou idade.
Normalmente são representados por tipos numéricos.
Seleção dos dados
Nessa fase é feita a seleção dos dados alvos, podendo ser gerados
subconjuntos dessas informações. Nessa etapa é definida a base
de dados a ser trabalhada que contem todas as possíveis variáveis
que farão parte da análise. Normalmente a escolha dos dados fica
a critério de um especialista do domínio. O processo de seleção é
bastante complexo, uma vez que os dados podem vir de uma série
de diferentes fontes e quase sempre possuem diversos formatos.
As fontes as quais os dados se originam podem ser classificadas
como internas e externas. As fontes internas são formadas pelas
informações coletadas e armazenadas ao longo do tempo na base
de dados operacional, já as fontes externas normalmente são in-
formações que não estão incorporadas ao sistema, compostas por
outros tipos de dados, como documentos, relatórios e informações
oriundas, por exemplo, de web sites da internet.
A seleção de dados é a primeira etapa do processo de KDD e tem
por objetivo reunir os dados que serão trabalhados numa única
base. Essas informações serão captadas de diferentes fontes, tais
como: listas de pedidos de clientes, bancos de dados, planilhas
de controle, entre outros. Após a criação do conjunto de dados
“modelo”, as informações estarão aptas a serem submetidas à
próxima fase do processo de extração do conhecimento.
Normalmente os dados encontram-se organizados em bases de
dados transacionais, que frequentemente sofrem alterações devido
a atualizações constantes e é bastante comum que os dados sejam
armazenados em uma única tabela.A junção dos dados em uma
única tabela pode ocorrer de duas formas:
a) Junção direta: todos os dados são incluídos em uma única
tabela, sem preocupação com a análise crítica quanto a possíveis
deformidades, o que pode afetar no resultado final da mineração
de dados;
b) Junção orientada: nessa forma o especialista no domínio da
aplicação em conjunto com o especialista em KDD definem quais
atributos e registros podem de fato ser úteis para o processo de
extração de conhecimento.
A seleção de dados é a seleção do conjunto de dados necessários
ao entendimento do problema que se busca uma solução e sobre o
qual o processo de descobrimento de conhecimento será aplicado
contendo os registros e suas variáveis, conhecidas também como
características ou atributos.
Pré-processamento e Limpeza dos dados
O pré-processamento é a etapa do processo de extração do
conhecimento em que a limpeza dos dados deve ocorrer. Ela en-
volve a verificação da consistência das informações, a correção de
possíveis erros e o preenchimento ou eliminação de valores des-
conhecidos, redundantes ou não pertencentes ao domínio. Nessa
fase também são utilizados métodos de redução para diminuir
o número de variáveis envolvidas no processo, objetivando com
isso melhorar o desempenho do algoritmo de análise.
É no pré-processamento que se qualifica e determina a eficiência
dos algoritmos de mineração, sendo uma etapa muito importante,
porque o resultado final depende da qualidade dos dados sele-
cionados. Essa etapa compreende a preparação das informações
da base de dados. Normalmente os dados apresentam problemas
como informações ausentes, errôneas, grandes desproporções
Edição 149 • SQL Magazine 39
Descoberta de conhecimento utilizando o processo KDD
entre outros. Essas deformidades nos dados devem ser corrigidas
para que não comprometam a qualidade final do processo de
mineração.
As operações de correções de ruídos dos dados no Pré-proces-
samento compreendem:
• Padronização dos valores dos atributos: em uma base de dados
formada por diferentes fontes, pode ocorrer que uma informação
possua diferentes valores e tipos com o mesmo significado, por
exemplo, “Unidade da Federação” pode assumir valores como:
“Paraná”, “PR”.
• Remoção de registros duplicados: pode ocorrer que na base de dados
apareçam dados iguais em diferentes registros, por exemplo, o
nome de um cliente pode em um momento aparecer por completo
e em outro abreviado;
• Tratamento e eliminação de ruídos: são comuns em uma base de
dados ocorrerem erros ocasionados por diversos fatores, como
perda parcial de dados de um campo por uma interferência exter-
na como a falta de energia. Nesses casos, os campos que contêm
esses ruídos devem ser corrigidos ou as informações eliminadas;
• Tratamento de valores ausentes: quase sempre a base que recebe
a entrada de informações tem valores ausentes. Essas falhas são
comuns por diversos fatores, principalmente pelo erro humano,
pois no momento em que um operador estiver cadastrando infor-
mações pode acontecer de ignorar alguns campos;
• Exclusão de Casos: Trata-se de um método de limpeza simples que
consiste em excluir do conjunto de dados sequências que tenham
pelo menos um atributo não preenchido;
• Preenchimento Manual de Valores: nesse método, os dados pesqui-
sados devem ser complementados via digitação, o que demanda
alto consumo de tempo e recursos, sendo muitas vezes inviável
na prática;
• Preenchimento com Valores Globais Constantes: método que con-
siste em substituir valores ausentes de um atributo por um valor
padrão, por exemplo, valor “null”.
• Preenchimento com Medidas Estatísticas: medidas estatísticas são
empregadas como alternativa à utilização de constantes padrões
no processo de preenchimento de valores ausentes. Como exem-
plo, podemos citar média para atributos numéricos;
• Preenchimento com Métodos de Mineração de dados: nesse método,
valores ausentes podem ser substituídos por valores sugeridos
através de modelos preditivos. Redes neurais, modelos bayesianos
e árvores de decisão são alternativas na construção de modelos
preditivos.
Além da preocupação com a limpeza dos dados, outro fator
que deve ser levado em consideração no pré-processamento é o
tamanho do conjunto de dados, pois alguns algoritmos usados
na mineração de dados conseguem tratar apenas um número
limitado de registros, daí a necessidade de se utilizar técnicas
que reduzam o tamanho do conjunto de dados.
É interessante que essa fase do processo de extração do conhe-
cimento seja feita com o acompanhamento do especialista do
domínio, pois devido ao seu amplo conhecimento sobre o domínio
40 SQL Magazine • Edição 149
de dados, poderá determinar com autoridade quais dados podem
ser de fato aproveitados e quais poderão ser descartados.
Transformação dos dados
A transformação consiste em formatar os dados de um estado
bruto para um estado mais “limpo”. Esse processo demanda a
combinação de diferentes bases de dados modificando o formato e
enriquecendo as informações. Após a fase do pré-processamento,
os dados precisam ser formatados e armazenados para que os
algoritmos possam ser aplicados.
Em uma base de dados, é comum encontrar os dados dispersos.
Após passar pela filtragem inicial, eles devem ser agrupados
observando a uniformidade dos dados e corrigindo eventuais
falhas, como informações incompletas.
Na transformação dos dados, deve-se levar em consideração os
tipos de algoritmos que irão ser trabalhados e preparar os dados
para o formato adequado ao algoritmo a ser aplicado, por exemplo,
alguns tipos de algoritmos só trabalham com valores numéricos.
Diversas técnicas podem ser usadas na transformação de dados,
tais como: suavização (remove valores errados dos dados), agru-
pamento (agrupa valores em faixas sumarizadas), generalização
(converte valores específicos para valores mais genéricos), nor-
malização (organiza variáveis em uma mesma escala e criação de
novos atributos gerados a partir de outros já existentes).
Mineração de dados
Nessa etapa os dados estão com alto padrão de qualidade e aptos
a receber aplicações de ferramentas de extração do conhecimento,
como algoritmos de mineração. Trata-se da fase mais importante
do processo de KDD, sendo comparados grandes volumes de
dados com o objetivo de extrair padrões a partir de dados, usando
técnicas de inteligência computacional.
As principais tarefas da mineração de dados são:
• Associação: tem por objetivo encontrar padrões frequentes que
ocorrem em um conjunto de dados. Consiste em identificar asso-
ciações entre variáveis no mesmo elemento ou associações entre
elementos diferentes que ocorram simultaneamente, de forma
frequente em uma base de dados. É também comum a procura
de associações entre elementos durante um intervalo temporal.
Algoritmos como o Apriori, GSP, DHP, entre outras ferramentas
são responsáveis por descoberta de associações;
• Classificação: a classificação consiste em predizer um deter-
minado resultado com base em um conjunto de informações,
baseando-se em árvores de decisão, regras de decisão e análises.
Essa tarefa pode ser compreendida como a busca por uma função
que permita associar corretamente cada registro;
• Sumarização: a sumarização, também chamada descrição de
conceitos, consiste em identificar e apresentar, de maneira com-
preensível, as principais características dos dados contidos em
um conjunto de dados;
• Clusterização: a clusterização, também denominada de agru-
pamento, é responsável por particionar as informações de uma
base de dados em clusters ou subconjuntos, de maneira que esses
clusters compartilhem um conjunto de propriedades comuns.
O objetivo principal é maximizar sua similaridade. A clusteriza-
ção pode ser definida como uma tarefa básica da mineração de
dados que auxilia o usuário a realizar agrupamentos naturais
de registros.
A fase da mineração de dados também pode ser definida como
uma sequência de etapas dentro do processo de extração do conhe-
cimento, que pode envolver repedidas iterações da aplicação de
determinado algoritmo com o objetivo de extrair padrões de dados.
Interpretação e Avaliação dos dados
Essa etapa deve ser realizada ao final do processamento de
cada método do processo KDD. Nela os resultados devem ser
confrontados com as expectativas definidas inicialmente e os
padrões encontrados na fase da mineração de dados devem ser
validados a partir da interpretação e avaliação. É importante que
essas análises sejam feitas com a participação de todos os envol-
vidos no processo de extração do conhecimento, por exemplo,
para que o analista tenha condições de avaliar se foi descoberto
conhecimento relevante ou não é importante a participação do
especialista do domínio.
A interpretação e/ou avaliação mostra os padrões encontrados
nas etapas anteriores. Consiste na última etapa do processo KDD,
quando é avaliado o conhecimento extraído das bases de dados
e de acordo com esse conhecimento será possível definir estraté-
gias para tomadas de decisões. No entanto para que se alcance a
confiabilidade desejada é importante que o resultado seja claro e
compreensível para os tomadores de decisão. Caso os resultados
não sejam satisfatórios, é necessário repetir as etapas anteriores
do processo KDD.
Estatística na extração de conhecimento
Estatística é uma ciência exata que auxilia os analistas na coleta,
organização, análise e apresentação dos dados. Trata de parâ-
metros extraídos de uma população de dados, tais como média
ou desvio padrão. Com as técnicas oferecidas pela estatística é
possível extrair informação de dados para obter uma melhor
compreensão dos mesmos. Com os dados de uma base de dados
devidamente organizados, procura-se agrupá-los e reduzi-los, na
forma de amostra, com o objetivo de entregar técnicas e cálculos
convenientes para tirar conclusões acerca de uma população de
dados. As técnicas de mineração de dados têm grandes ligações
com as técnicas estatísticas, pois as usam para realizar a desco-
berta de padrões, calcular aproximações, médias, taxas de erros
e desvios. Alguns conceitos importantes de ser conhecidos no
contexto deste artigo são:
• População: é qualquer conjunto de pessoas ou objetos com uma
característica comum que se deseja medir;
• Amostra: refere-se a qualquer subconjunto de uma população;
• Rol: ordenação dos dados brutos, independente da ordem de
sua classificação;
• Variável: pode ser classificada em quantitativa ou qualitativa. A
variável quantitativa é aquela que mede a quantidade, por exem-
plo, altura, idade. A qualitativa mede a qualidade, por exemplo,
médio, superior.
Aplicação do processo de KDD na base de dados de uma Pizzaria
Esta seção apresenta os procedimentos necessários para a
aplicação prática do processo KDD sobre a base de dados de
uma pizzaria, abordando cálculos estatísticos de distribuição de
frequência. A base de dados da pizzaria foi armazenada em uma
planilha do Excel chamada de Pedidos.xlsx.
Seleção da base de dados
Os dados da pizzaria submetidos ao processo de extração do
conhecimento foram coletados através dos pedidos de pizza re-
cebidos de clientes entre os meses de outubro de 2011 e fevereiro
de 2012, esses dados foram somente armazenados na planilha
Pedidos, não se preocupando com relação à formatação das infor-
mações inseridas. A cada novo pedido recebido foram registradas
informações, tais como o nome do cliente, data do pedido, hora
do pedido, endereço da entrega, telefone para contato, tipo de
entrega, valor da pizza, valor total, hora da entrega e tempo de
entrega, entre outras informações, formando dessa maneira a
base de dados.
Pré-processamento da base de dados da pizzaria
Nessa fase, a planilha na qual os dados foram gravados foi
nomeada para Pedidos de Clientes, e as informações contidas
nela foram formatadas e organizadas. Os dados da base foram
classificados em ordem crescente por número do pedido. Em todas
as informações foram aplicadas a fonte Calibri e o tamanho de
fonte 11. Além disso, dados incompletos foram eliminados, bem
como as informações errôneas, e os valores relativos a preços
foram convertidos para o formato de moeda, padronizando a
planilha de dados.
Transformação dos dados
Com os dados organizados na etapa anterior, os valores que
compõem a data do pedido, hora do pedido e valor total da pi-
zza foram separados, sendo que cada valor foi colocado em uma
coluna, conforme é mostrado nas seções a seguir, tornando os
dados aptos a receberem a aplicação do método de distribuição
de frequência.
Mineração de dados com distribuição de frequência
A distribuição de frequência é uma sequência de valores que
uma variável pode assumir em uma amostra. É normalmente uma
lista, ordenada por quantidades ou por classes, que apresenta o
número de vezes que um valor aparece na amostra. Para traba-
lhar com uma amostra grande ou quando as variáveis podem
ter valores contínuos é recomendável organizar os dados em
distribuições de frequência.
A distribuição de frequência é um método que agrupa dados
em classes de modo a fornecer a quantidade ou percentagem de
dados em cada classe.
Edição 149 • SQL Magazine 41
Descoberta de conhecimento utilizando o processo KDD
Dessa forma, podemos resumir e visua-
lizar um conjunto de dados sem precisar
levar em conta os valores individuais.
Quando um conjunto de dados é for-
mado por um grande número de dados,
recomenda-se colocá-los em uma tabela
de distribuição de frequência ou tabela
de frequência. Os dados nessa tabela são
organizados em classes pré-organizadas,
observando-se a frequência de cada classe.
Podemos dizer que uma tabela de frequ-
ência é um arranjo tabular dos dados com
frequências parecidas.
O método de distribuição de frequência
foi aplicado sobre o dia do pedido, a hora
do pedido e o valor total vendido, com o
objetivo de encontrar padrões. Por exem-
plo, qual dia do mês mais vendeu pizza,
em quais horários foram mais recebidos
pedidos e qual valor de pizza foi mais
vendido. Assim, os elementos definidos
foram:
Figura 2. Separação dos valores da coluna Data do Pedido
Figura 3. Planilha DF Data do Pedido
42 SQL Magazine • Edição 149
• Número de classes: define a quantidade
de classes a serem trabalhadas. Esse valor
é encontrado através da aplicação da fór-
mula de Sturges i = 1 + 3,3 . log n.
• Amplitude do intervalo: determina a
amplitude do intervalo de classe. Para en-
contrar a amplitude do intervalo é aplicada
a formula . buição de frequência do pedido demanda
• Frequência Simples (fi): identifica no rol
de valores a ser trabalhado a quantidade
de elementos em cada classe;
• Ponto médio (Xi): o ponto médio de uma
classe é o ponto que divide o intervalo
de classe em duas partes iguais. O ponto
médio é obtido pela fórmula , sendo
li igual a limite inferior e Li igual a limite
superior;
• Frequência Acumulada (Fi): é a soma
dos valores das frequências simples (Fi);
• Frequência Relativa (Fr): a frequência
relativa é obtida trabalhando com os
valores da frequência simples e são repre-
sentados em porcentagens. Para encontrar
os valores da frequência relativa é aplicada
a fórmula .
Aplicação do método de distribuição de frequência
sobre a data do pedido
O primeiro passo para análise da distri-
alguns processamentos na coluna da data
do pedido. A motivação para essa análise é
obter um entendimento sobre a frequência
em que os pedidos são feitos de acordo
com a data.
Para aplicar o método de distribuição
de frequência sobre os valores da coluna
data do pedido, devemos seguir os pro-
cedimentos:
1 –Definir o rol de valores. Nesse caso, o rol
de valores selecionados para a aplicação
foram os valores da coluna Data do Pedido;
2 – Organizar todos os valores da planilha
Pedidos de Clientes em ordem crescente
por Data do Pedido.
3 – Acrescentar novas colunas à planilha
Pedido de Clientes e em cada uma das
novas colunas colocar um dos valores que
compõe a Data do Pedido, como mostra o
exemplo da Figura 2.
4 – Abrir uma nova planilha e nomeá-la
para DF Data do Pedido (Distribuição de
Frequência por Data do Pedido);
5 – Na nova planilha DF Data do Pedido,
efetuar os cálculos do número de classes,
da amplitude do intervalo, da frequência
simples, do ponto médio, da frequência
acumulada e da frequência relativa.
A Figura 3 apresenta a planilha DF Data
do Pedido com todos os elementos da
distribuição de frequência já calculados.
Descrição dos cálculos dos elementos da
distribuição de frequência sobre o dia
do pedido
Cálculo do Número de Classes
Para calcular o Número de Classes,
representados na Figura 4, foi aplicada
a fórmula de Sturges:=1+ 3,3 . log(2272) =
14,43. O número de classes encontrado com
a aplicação da fórmula de Sturges foi 14,43.
Como o cálculo foi realizado sobre a data
do pedido e cada mês tem 30 dias, foram
necessárias apenas 11 classes.

Figura 4. Número de classes da planilha DF Data do Pedido
Cálculo da Amplitude do Intervalo
Cada classe é associada a uma amplitude de intervalo de forma
a distribuir os dados de forma representativa dentre as possíveis
classes, como pode ser observado na Figura 3.
Para encontrar a amplitude do intervalo, representada na
Figura 5, foi aplicada a fórmula= 31 - 1 = 30 / 14,43 = 2,07, sobre os
valores da coluna Dia da Data do Pedido. O número 31 é o maior
valor e o número 1 é o menor valor encontrado na coluna Dia.
O resultado da subtração foi dividido pelo número total de classes
encontradas,14,43, chegando ao resultado 2,07.
A amplitude do intervalo deve ser sempre arredondada para
cima, neste caso o valor encontrado 2,07 foi arredondado para o
valor 3. A amplitude do intervalo na primeira classe iniciou-se
com o número 1 e foi até o número 3, e seguiu essa sequência até
fechar com o valor 33 na última classe.
Figura 5. Amplitude do intervalo da planilha DF Data do Pedido
Frequência Simples
Após a determinação das classes e dos respectivos intervalos
é necessário fazer o cálculo da frequência simples dos pedidos
realizados dentro de cada intervalo. A frequência simples repre-
senta a quantidade absoluta de pedidos realizados dentro de cada
intervalo, logo serve para claramente identificar quantos pedidos
foram feitos para aquele intervalo.
A frequência simples (fi), representada na Figura 6, foi encontra-
da com a contagem dos elementos em cada intervalo. Por exemplo,
entre o número 1 e o número 3 da amplitude do intervalo existem
95 pedidos de pizza recebidos.
Figura 6. Frequência simples da planilha DF Data do Pedido
A contagem dos elementos foi feita através da fórmula CONT.
NÚM(‘Pedidos de Clientes’!1:3).
Cálculo do Ponto Médio
Para encontrar o ponto médio (Xi), foram somados os valores da
amplitude do intervalo e o resultado foi divido por 2. Por exemplo,
como representado na Figura 7, na primeira classe foi aplicada a
fórmula = 1 + 3 / 2, obtendo o resultado igual a 2, e dessa maneira
foram feitos os demais cálculos com relação ao ponto médio. Esse
cálculo, por mais que não seja utilizado diretamente em nossos
exemplos, é importante posteriormente para cálculos de desvio
padrão que podem vir a serem realizados.
Figura 7. Ponto médio da planilha DF Data do Pedido
Cálculo da Frequência Acumulada
A frequência acumulada (Fi) é a soma dos valores da frequência
simples (fi). Por exemplo, foi somado o valor 95 da primeira classe
mais o valor 276 da segunda classe, obtendo o resultado 371. Em
seguida, foi somando o resultado 371 mais o valor da frequência
simples da próxima classe, e nessa ordem até a última classe.
Cálculo da Frequência Relativa (Fr)
Para encontrar a frequência relativa (Fr), foram divididos
os valores de cada classe da frequência simples pelo total,
exemplo 95/2272 =0,04181338. Todos os valores da frequência
relativa foram colocados em porcentagens, conforme representa
a Figura 8.
Edição 149 • SQL Magazine 43
Descoberta de conhecimento utilizando o processo KDD
Com base nos cálculos apresentados, podemos concluir que
entre os dias 03 a 06 e 18 a 21 de cada mês, foram os dias que mais
receberam pedidos de pizza.
Aplicação da distribuição de frequência sobre Hora do Pedido, Total Valores
Fixos e Valor Total da Pizza
Os mesmos cálculos descritos anteriormente no cálculo da dis-
tribuição de frequência sobre a data do pedido, também foram
aplicados sobre a hora do pedido, total de valores fixos e valor
total da pizza.
Figura 8. Frequência relativa da planilha DF Data do Pedido
Figura 9. Separação dos valores da coluna Hora do Pedido
44 SQL Magazine • Edição 149
O motivo para essa análise complementar é aumentar a
granularidade dos resultados, de forma que seja possível
identificar a concentração dos pedidos também em relação ao
horário em que foram realizados. Para calcular a distribuição
de frequência sobre a hora do pedido, os valores que compõem
a hora do pedido foram separados, ficando cada valor em uma
coluna diferente, conforme mostra a Figura 9. Em seguida, foi
criada uma nova planilha, nomeada para DF Hora do Pedido,
e foi então calculada a distribuição de frequência.
Além da quantidade de pedidos, também é importante
analisar os valores totais desses, de forma que seja possível
perceber se os pedidos variam nesse quesito devido aos
elementos que os compõe. O total de valores fixos originou-
-se da soma do valor da borda, valor do refrigerante e valor
da entrega. Conforme mostra a Figura 10, foi criada uma
nova coluna e foi feita a soma desses três itens, calculando
a distribuição de frequência em uma nova planilha que foi
chamada DF Total Valores Fixos.
Para o cálculo da distribuição de frequência do valor total
da pizza, foi criada uma nova planilha e aplicada sobre os
valores da coluna valor total da pizza a mesma sequência de
cálculos descritos no cálculo da distribuição de frequência
sobre a data do pedido.
 Figura 10. Coluna Total Valores Fixos
Definir estratégias bem planejadas pode ser um diferencial
significativo na hora de conquistar novos clientes e mercados
ou na criação e lançamentos de novos produtos. Com base nos
resultados da planilha de cálculos da distribuição de frequência,
podemos concluir que os clientes têm tendência a comprarem
pizza nos primeiros dias de cada mês, conforme os cálculos apon-
taram, mais especificamente entre os dias 03 e 06 de cada mês, o
que nos leva a relacionar as compras efetuadas nesses dias com
os pagamentos que normalmente são feitos até o quinto dia útil.
Ainda de acordo com os resultados obtidos, aproximadamente
47% dos pedidos de pizza aconteceram no intervalo de horas que
compreendem 19h e 21h. Com relação a valores, as combinações
que mais se destacaram foram combinações com valores de pizza
entre R$ 29,00 e 32,00.
Este artigo procurou apresentar técnicas que pudessem contri-
buir para o crescimento e/ou aperfeiçoamento das estratégias de
marketings comerciais, usando como exemplo a base de dados de
uma pizzaria. As técnicas aqui apresentadas poderão ser aplicadas
em outras bases de dados de outros segmentos comerciais.
Autor
Jones Granatyr
Doutorando em Informática bolsista CAPES e Mestre em Ciência
da Computação bolsista CNPq, ambos na área de Inteligência
Artificial. É fundador do portal IA Expert e trabalha em projetos
de pesquisa relacionados a área de Inteligência Artificial, tais como
Sistemas Especialistas, Mineração de Dados, Mineração de Textos e
Sistemas Multiagente.
Autor
José Adair Fabricio
Graduando em Ciência da Computação na Universidade do
Contestado no campus de Porto União - SC. Já atuou como
professor de Informática, Assistente Técnico em Informática e
atualmente trabalha com Suporte à Tecnologia da Informação.
Autor
Heitor Murilo Gomes
Doutor em Informática pela PUCPR. Tem experiência na área de
ciência da computação com ênfase em Inteligência Artificial,
especialmente na área de mineração de dados e aprendizagem
de máquina. Atualmente trabalha como pesquisar de pós-doutorado no
instituto Télécom ParisTech da Université Paris Saclay, Paris - França.
Referências e Links:
MACEDO, DAYANA CARLA DE; MATOS, SIMONE NASSER. Extração de Conhecimento Atra-
vés da Mineração de dados. Revista de Engenharia e Tecnologia, UTFPR/ UEPG, 2010.
GOLDSCHMIDT, RONALDO; PASSOS, EMMANUEL. Data Mining Um Guia Prática, 2005.
CASTANHEIRA, LUCIANA GOMES. Aplicação de Técnicas de Mineração de Dados em
Problemas de Classificação de Padrões, 2008.
SILVA FILHO, LUIZ ALBERTO. Mineração de regras de associação utilizando KDD e
KDT: uma aplicação em segurança pública. 2009.
Martins, Matusalém Viera. Vídeos Aulas.
http://www.professormatusalem.com/video-aulas/aula-28-cap-5-distribuicao-de-
-frequencia-com-intervalo-exemplo-2
Guimarães, Inácio Andruski. Estatística.
http://unesav.com.br/ckfinder/userfiles/files/Apostila%20de%20Estatistica.pdf
Edição 149 • SQL Magazine 45
Descoberta de conhecimento utilizando o processo KDD

46 SQL Magazine • Edição 149