Práticas Recomendadas para Data

Warehousing com o SQL Server 2008

Arquivo Técnico do SQL Server

Autores: Mark Whitehorn, Solid Quality Mentors; Keith Burns, Microsoft

Revisor Técnico: Eric N. Hanson, Microsoft

Publicado: Julho de 2008

Aplica-se a: SQL Server 2008

 

Resumo: Há evidências consideráveis de que projetos de data warehousing de sucesso

freqüentemente geram um retorno de investimento muito alto. Ao longo dos anos foi coletada uma

grande quantidade de informação sobre os fatores que levam a uma implementação bem ou mal-

sucedida. Eles estão encapsulados aqui, em um conjunto de práticas recomendadas, que são

apresentadas com referência particular aos recursos do SQL Server 2008. A aplicação de práticas

recomendadas em um projeto de data warehouse é um dos melhores investimentos que você

pode fazer no sentido de estabelecer uma infra-estrutura de Business Intelligence de sucesso.

Introdução

O Microsoft SQL Server 2008 representa uma excelente escolha para a construção e manutenção

de data warehouses em empresas de todos os tamanhos.

O termo Business Intelligence (BI) descreve o processo de extrair informações de dados. Os dados

operacionais na maioria das empresas são mantidos em sistemas baseados em transações com

funções específicas (RH, Vendas, Finanças e etc.). Freqüentemente a informação solicitada pelos

responsáveis por decisões dentro da empresa requer dados de vários sistemas operacionais. De

fato, quanto mais geral a pergunta, como “Qual é nosso lucro atual?”, mais sistemas operacionais

provavelmente serão envolvidos em fornecer os dados.

Uma parte integrante de qualquer sistema de BI é o data warehouse – um repositório central de

dados que é regularmente renovado a partir de sistemas de origem. Os dados novos são

transferidos a intervalos regulares (geralmente à noite) por processos de ETL (extract, transform,

and load - extração, transformação e carregamento).

Tipicamente os dados no data warehouse são estruturados como um esquema em estrela [Kim08],

embora também possa ser estruturado como dados relacionais normalizados [Inmon05] ou um

híbrido dos dois. Não importa qual estrutura é escolhida, depois de os dados novos serem

carregados no data warehouse, muitos sistemas de BI copiam subconjuntos dos dados para data

marts de função específica em que os dados são tipicamente estruturados como um cubo de OLAP

multidimensional como mostrado na Figura 1.

Figura 1: Plano geral de um data warehouse

 

Data warehouses têm sido construídos de uma forma ou de outra há mais de 20 anos. No começo

de sua história tornou-se aparente que construir um data warehouse de sucesso não é uma tarefa

trivial. O relatório do IDC de 1996 [IDC96] é um estudo clássico do estado do data warehousing na

época. Paradoxalmente, foi usado tanto por defensores como por detratores do data warehousing.

Os defensores alegavam que ele provava como o data warehousing é eficaz, citando que, para os

63 projetos estudados, o retorno do investimento (ROI) médio em três anos era pouco mais de 400

por cento. Quinze daqueles projetos (25 por cento) apresentaram um ROI de mais de 600 por

cento.

Os detratores mantinham que o relatório era uma condenação inflamada das práticas de data

warehouse na época porque de 45 projetos (com exceções descontadas), 34 por cento falharam

em retornar até mesmo o custo do investimento após cinco anos. Um warehouse que não

apresentou nenhum retorno naquele tempo não é um bom investimento.

Os dois conjuntos de números são precisos e, juntos, refletem as descobertas gerais do próprio

documento que diz “Uma das histórias mais interessantes é encontrada na variedade de

resultados. Embora as 45 organizações incluídas na análise do resumo tenham relatado resultados

de ROI entre 3% e 1,838%, a faixa total variou de – 1,857% a 16.000%!”

De maneira preocupante, a tendência para o fracasso de projetos de data warehouse continua

hoje em dia: alguns apresentam um enorme ROI, outros claramente fracassam. Em um relatório

alguns anos depois (2005), a Gartner predisse que “Mais de 50 por cento dos projetos de data

warehouses terão aceitação limitada ou serão fracassos em 2007” (Gartner press release [Gart07]).

Isso significa que não aprendemos nada nesse meio-tempo? Não, aprendemos muito sobre como

criar data warehouses de sucesso e um conjunto de data warehouses e outro de práticas

recomendadas evoluíram. O problema parece ser que nem todo mundo no campo tem

conhecimento dessas práticas.

Neste documento nós cobrimos alguns dos recursos de data warehousing mais importantes do SQL

Server 2008 e descrevemos práticas recomendadas para usá-los eficientemente. Além disso,

cobrimos algumas das práticas recomendadas mais gerais para se criar um projeto de data

warehouse de sucesso. Seguir essas práticas recomendadas não pode, é claro, garantir que seu

projeto de data warehouse terá sucesso; mas melhorará imensamente suas chances. E é

inegavelmente verdadeiro que aplicar práticas recomendadas é o investimento mais eficaz em

termos de custo que você pode fazer em um data warehouse.

Um documento complementar [Han08] discute como escalonar seu data warehouse com o SQL

Server 2008. Este documento enfoca o planejamento, projeto, modelagem e desenvolvimento

funcional da infra-estrutura de seu data warehouse. Consulte o documento complementar para

mais detalhes sobre questões de desempenho e escalonamento associados com configuração,

consultas e gerenciamento de data warehouses.

Benefícios do Uso de Produtos Microsoft para Data Warehousing e Business Intelligence

Sistemas de BI são, inevitavelmente, complexos. Os dados de origem são mantidos em um

conjunto de aplicativos operacionais e bancos de dados distintos. Um sistema de BI deve

transformar esses conjuntos heterogêneos em um conjunto coeso, preciso e oportuno de

informações úteis.

Várias arquiteturas diferentes podem ser empregadas com sucesso para data warehouses;

contudo, devem envolver:

         Extrair dados de sistemas de origem, transformá-los e depois carregá-los em um data

warehouse

         Estruturar os dados no warehouse como tabelas de forma normal ou em um esquema em

estrela/floco de neve que não é normalizado

         Mover os dados para data marts, onde freqüentemente são gerenciados por um mecanismo

multidimensional

         Relatar em seu sentido mais amplo, o que ocorre a partir de dados no warehouse e/ou data

marts: criar relatórios pode tomar qualquer forma, de resultados e planilhas do Microsoft Office

Excel® impressos através de análise multidimensional rápida a data mining.

O SQL Server 2008 fornece todas as ferramentas necessárias para executar essas tarefas

[MMD07].

         O SSIS (SQL Server Integration Services) permite a criação e manutenção de rotinas de ETL.

         Se você usar o SQL Server como uma fonte de dados, o recurso de Captura de Dados de

Alterações (Change Data Capture) simplifica muito o processo de extração.

         O mecanismo de banco de dados do SQL Server detém e gerencia as tabelas que formam seu

data warehouse.

         O SSAS (SQL Server Analysis Services) gerencia uma forma multidimensional dos dados,

otimizada para relatórios rápidos e facilidade de compreensão.

         O SSRS (SQL Server Reporting Services) possui uma grande variedade de capacidades de

relatórios, inclusive excelente integração com o Excel e Microsoft Office Word. O PerformancePoint

Server™ facilita a visualização de dados multidimensionais.

Além disso, o MOSS (Microsoft Office SharePoint Server®) 2007 e o Microsoft Office 2007

proporcionam um ambiente de usuário final integrado e fácil de usar, permitindo que você

distribua por toda a sua organização análises e relatórios derivados de dos dados de seu data

warehouse. O SharePoint pode ser usado para construir soluções de portal e de painel de BI. Por

exemplo, você pode construir um aplicativo de scorecard no SharePoint que permita aos

funcionários obter uma exibição personalizada da métrica e dos KPIs (Key Performance Indicators –

Indicadores-Chave de Desempenho) dependendo do cargo deles.

Como se esperaria de uma solução fim a fim completa, o nível de integração entre os

componentes é altíssimo. O Microsoft Visual Studio® oferece uma UI consistente a partir da qual

controlar o SQL Server e o Analysis Services e, é claro, ela pode ser usada para desenvolver

aplicativos de BI em uma variedade de linguagens (Visual C#®, Visual C++®, Visual Basic.Net® e

outras).

O SQL Server é lendário por seu TCO (total cost of ownership – custo total de propriedade) baixo

em soluções de BI. Uma razão é que as ferramentas de que você precisa o acompanham sem

custo adicional — outros fornecedores cobram (e bastante) por ferramentas de ETL, mecanismos

multidimensionais e assim por diante. Outro fator é o conhecido foco da Microsoft na facilidade de

uso que, quando combinada com o ambiente de desenvolvimento integrado que o Visual Studio

proporciona, reduz significativamente o tempo de treinamento e os custos de desenvolvimento.

Práticas Recomendadas: Criando Valor para a Sua Empresa

O foco principal deste documento é em práticas técnicas recomendadas. Contudo, a experiência

demonstra que muitos projetos de data warehouse e de BI fracassam não por motivos técnicos,

mas por causa de três fatores: personalidades, lutas pelo poder e política.

Encontre um patrono

Seu patrono deve ser alguém no nível mais alto da organização, alguém com a vontade e a

autoridade de dar ao projeto o forte apoio político de que ele precisará. Por quê?

Alguns empresários aprenderam que o controle da informação significa poder. Eles podem ver o

warehouse como uma ameaça a seu poder porque ele torna informações disponíveis livremente.

Por motivos políticos, essas pessoas podem manifestar apoio total ao sistema de BI, mas, na

prática, ser efetivamente um obstáculo.

A equipe de BI pode não ter a influência necessária para superar tais obstáculos ou a inércia que

pode advir dos escalões mais altos da gerência: essa é a tarefa do patrono.

Acerte na arquitetura logo no início

A arquitetura geral de todo o sistema de BI deve ser cuidadosamente planejada nas etapas iniciais.

Um exemplo de parte deste processo é decidir sobre alinhar a estrutura com os princípios de

design de Ralph Kimball ou Bill Inmon (consulte Referências).

Desenvolva uma Verificação de Conceito

Decidir sobre um projeto de Verificação de Conceito é uma excelente maneira de conquistar apoio

e influenciar pessoas. Isso pode envolver a criação de um cubo de OLAP e o uso de software de

visualização para uma ou várias unidades de negócios. O projeto pode ser usado para mostrar a

pessoas de negócios o que podem esperar do novo sistema e também para treinar a equipe de BI.

Escolha um projeto com um escopo pequeno e bem-definido que seja relativamente fácil de

concretizar. Executar uma Verificação de Conceito requer um investimento de tempo, esforço e

dinheiro, mas, limitando o escopo, você limita os gastos e assegura um retorno rápido do

investimento.

Selecione projetos de Verificação de Conceito com base no ROI rápido

Quando escolher um projeto de Verificação de Conceito, pode ser um exercício útil conversar com

cerca de dez unidades de negócios sobre as necessidades delas. Pontue os requisitos por

dificuldade e ROI. A experiência sugere que freqüentemente há pouca relação entre o custo de

desenvolver um cubo e o ROI que ele pode gerar, portanto este exercício deve identificar vários

projetos de esforço baixo e retorno alto, cada um dos quais devendo ser excelente candidatos para

projetos de Verificação de Conceito.

Forneça projetos de alto valor incremental

Construindo as soluções mais lucrativas primeiro, um bom ROI pode ser garantido para todo o

projeto de data warehouse depois das etapas iniciais. Se o primeiro incremento custar, digamos

US$ 250.000 e o ROI for de US$ 1 milhão por ano, depois dos três primeiros meses de operação o

gasto inicial terá sido recuperado.

A facilidade de uso e alto nível de integração entre componentes de BI Microsoft são ativos

valiosos que ajudam a proporcionar resultados em tempo hábil; isso ajuda você a conquistar apoio

rápido de seus usuários comerciais e patronos. O valor permanece aparente à medida que você

constrói com base no projeto de Verificação de Conceito e começa a proporcionar benefícios na

organização.

Projetando sua solução de Data Warehouse/BI

Nesta seção discutimos duas áreas de práticas recomendadas. A primeira é composta das

diretrizes gerais de design que devem ser consideradas no início do projeto. Elas são seguidas por

orientação para especificação de hardware.

Práticas Recomendadas: Design Inicial

Mantenha o design alinhado com os requisitos analíticos dos usuários

Assim que começamos a discutir bom design de data warehouse, devemos apresentar Bill Inmon

[Inmon05] e Ralph Kimball [Kim08]. Ambos contribuíram muito para nossa compreensão de data

warehousing e ambos escrevem sobre muitos aspectos do design de warehouses. As visões deles

são freqüentemente caracterizadas das seguintes maneiras:

         Inmon favorece um data warehouse normalizado.

         Kimball favorece um data warehouse dimensional.

Warehouses com essas estruturas freqüentemente são mencionadas como warehouses Inmon ou

warehouses Kimball. A Microsoft não tende a nenhum dos dois e o SQL Server é perfeitamente

capaz de suportar ambos os projetos. Observamos que a maioria de nossos clientes favorece um

warehouse dimensional. Em resposta, introduzimos otimização em esquema em estrela para

acelerar consultas em grandes tabelas de fatos e de dimensões.

A indústria dos computadores entendeu como projetar sistemas transacionais desde a década de

1970. Comece com os requisitos do usuário, que podemos descrever como o modelo do Usuário.

Formalize-os em um modelo Lógico com que os usuários concordem e aprovem. Adicione os

detalhes técnicos e transforme aquilo em um modelo Físico. Depois disso, é apenas uma questão

de implementação…

Projetar um data warehouse deve seguir os mesmos princípios e focar o processo de design nos

requisitos dos usuários. A única diferença é que, para um data warehouse, aqueles requisitos não

são operacionais, mas analíticos.

Em uma grande empresa, os usuários tendem a separar-se em muitos grupos, cada qual com

diferentes requisitos analíticos. Os usuários em cada grupo geralmente articulam a análise de que

precisam (o modelo de análise de Usuário) em termos de gráficos, grades de dados (planilhas) e

relatórios impressos. Eles são muito diferentes, mas todos essencialmente representam medições

numéricas filtradas e agrupadas pelos membros de uma ou mais dimensões.

Assim, podemos capturar os requisitos analíticos de um grupo simplesmente através da

formalização das medições e dimensões usadas. Como mostrado na Figura 2, elas podem ser

capturadas junto com as informações hierárquicas relevantes em um modelo solar, que é o

modelo Lógico dos requisitos analíticos.

Figura 2: Um modelo solar usado para capturar os requisitos analíticos de usuários em termos de

medições, dimensões e estrutura hierárquica. Este é o modelo Lógico derivado do modelo de

Usuário.

Uma vez que esses requisitos analíticos tenham sido capturados com sucesso, podemos

acrescentar os detalhes técnicos. Isso transforma o modelo Lógico em Físico, o esquema em

estrela, ilustrado na Figura 3.

Figura 3: Uma representação de um esquema em estrela, que é um exemplo de modelo Físico de

requisitos analíticos

Os esquemas em estrela podem, em última análise, ser implementado como um conjunto de

tabelas dimensionais e de fatos no data warehouse e/ou como cubos (ROLAP, HOLAP ou MOLAP),

que podem ser alojados em múltiplos data marts.

Para projetar o sistema de ETL para distribuir os dados para essa estrutura, devemos entender a

natureza dos dados nos sistemas de origem.

Para distribuir a analítica que os usuários descreveram em seus requisitos, devemos encontrar os

dados apropriados nos sistemas de origem e transformá-los adequadamente. Em um mundo

perfeito, os sistemas de origem vêm com documentação excelente, que inclui nomes expressivos

de tabelas e de colunas. Além disso, os aplicativos de origem são perfeitamente projetados e

permitem que apenas dados que se enquadrem no domínio apropriado sejam inseridos. No mundo

real, os sistemas de origem raramente atendem a esses padrões exigentes.

Você pode saber que os usuários precisam analisar vendar pelo sexo do cliente. Infelizmente, o

sistema de origem é completamente não-documentado, mas você encontra uma coluna chamada

Gen (gênero: M/F) em uma tabela chamada CUS_WeX4. Investigação adicional mostra que a

coluna pode armazenar dados relacionados ao sexo do cliente. Suponha que você possa

determinar que ela contém 682.370 linhas e que a distribuição de dados é como se segue:

 

M 234543

F 342322

Mail 5

Femal 9

Female 4345

Yes 43456

No 54232

Male 3454

Girl 4

 

Agora você tem mais evidências de que essa é a coluna correta e também tem uma idéia dos

desafios que o aguardam no projeto do processo de ETL.

Em outras palavras, o conhecimento da distribuição dos dados é essencial em muitos casos, não

apenas para identificar as colunas apropriadas, mas também para começar a entender (e, em

última análise, projetar) o processo de transformação.

Use o perfil de dados para examinar a distribuição deles nos sistemas de origem

No passado, obter uma compreensão da distribuição de dados em sistemas de origem significava

executar várias consultas (geralmente GROUP BYs) nas tabelas do sistema de origem para

determinar o domínio de valores em cada coluna. As informações podiam ser comparadas àquelas

fornecidas pelos peritos em domínio e pelas transformações definidas.

O Integration Services possui uma tarefa de Criação de Perfil de Dados (Data Profiling) que torna a

primeira parte dessa tarefa muito mais fácil. Você pode usar as informações que coleta usando o

Criador de Perfil de Dados para definir regras de transformação de dados apropriadas para

assegurar que seu data warehouse contenha dados “limpos” depois do ETL, o que leva a

resultados analíticos mais precisos e confiáveis. O Criador de Perfil de Dados é uma tarefa de fluxo

de dados no qual você pode definir as informações de perfil de que precisa.

Oito perfis de dados estão disponíveis; cinco deles analisam colunas individuais:

         Razão Nula de Coluna

         Distribuição de Valor de Coluna

         Distribuição de Comprimento de Coluna

         Estatísticas de Coluna

         Padrão de Coluna

Três analisam várias colunas ou relações entre tabelas e colunas:

         Chave Candidata

         Dependência Funcional

         Inclusão de Valor

Vários perfis de dados para várias colunas ou combinações delas podem ser computados com uma

tarefa do Criador de Perfil de Dados e o resultado pode ser direcionado para um arquivo XML ou

variável de pacote. O primeiro é a melhor opção para trabalho de design de ETL. Um Visualizador

de Perfil de Dados, mostrado na Figura 4, é fornecido como um executável autônomo que pode ser

usado para examinar o arquivos XML e, assim, o perfil dos dados.

Figura 4: Visualizador de Perfil de Dados

Projete desde o início para dividir grandes tabelas, particularmente grandes tabelas de

fatos

Não importa como a indexação é boa e o hardware rápido, tabelas grandes podem levar a

operações de gerenciamento de sistema demoradas, como criação de índices e remoção de dados

antigos. Isso pode ser particularmente aparente para grandes tabelas de fatos. Assim, divida as

tabelas em partições se forem grandes. Em geral, se uma tabela for maior que 50 GB, você deve

dividi-la (consulte Gerenciamento, Consulta e Instalação de Data Warehouse Relacional mais adiante neste white

paper).

Planeje eliminar dados antigos desde o início

Uma das principais funções de um data warehouse é acompanhar o histórico de negócios da

empresa — algo que os sistemas de origem geralmente fazem de maneira particularmente ruim.

Acompanhar o histórico significa que o data warehouse adquirirá vastas quantidades de dados ao

longo do tempo. Conforme os dados envelhecem, são acessados com cada vez menos freqüência

e também de maneira diferente (tipicamente como agregações em vez dos detalhes). No fim

torna-se necessário tratar dados antigos de maneira diferente, talvez usando armazenamento

mais lento e mais barato, talvez armazenando apenas as agregações, removendo-os

completamente ou outro plano. É vital planejar isso logo no começo. A divisão em partições facilita

muito isso (consulte Gerenciamento, Consulta e Instalação de Data Warehouse Relacional mais adiante neste

white paper).

Práticas Recomendadas: Especificando o Hardware

Projete para desempenho de operação de manutenção, não apenas de consulta

Especificar o hardware nunca é fácil, mas é uma prática comum (e boa) quando se tomam

decisões sobre hardware concentrar a maior parte da atenção no desempenho das consultas pelo

simples motivo de que isso é vital. Contudo, também é importante não deixar de lado outras

considerações.

Pense sobre o desempenho de pesquisas. Uma visão simplista é que ele se escalona de maneira

linear com o tamanho dos dados. Gerações de DBAs aprenderam da maneira mais difícil que ele

freqüentemente não se dimensiona dessa maneira — dobre o tamanho dos dados e a consulta

pode demorar dez vezes mais para se executar — assim eles podem planejar os requisitos de

hardware de acordo. Mas essa é uma abordagem um tanto simplista.

Por exemplo, considere uma consulta executada em uma tabela de 1 terabyte. Seu desempenho é

limitado por muitos fatores — indexação, memória, número de linhas examinadas, número de

linhas retornadas, etc. Imagine que a consulta use índices eficientemente, examine um número

fixo de linhas e retorne apenas algumas linhas. Se executarmos a mesma consulta em 2 terabytes

de dados na mesma tabela e supusermos que a indexação foi aplicada de maneira eficiente e que

o número de linhas examinadas e retornadas não seja significativamente diferente, o tempo de

resposta é aproximadamente o mesmo. Certamente não será nada como o dobro do tempo. Em

outras palavras, o desempenho de consulta às vezes pode escalonar-se de uma forma não-linear

para nossa vantagem. Contudo, outros fatores, como tempo de backup, se escalonam de forma

linear da maneira esperada. Fazer o backup do dobro dos dados consome o dobro dos recursos

(como tempo de CPU e largura de banda de E/S), que podem afetar as especificações de hardware

necessário para atender aos seus requisitos.

Em outras palavras, quando projetamos grandes sistemas de BI, devemos ter o cuidado de

considerar todos os fatores relevantes. Isso não significa que o desempenho de consulta não seja

importante; ele ainda é a consideração mais importante. Mas também é um erro enfocar apenas

essa questão. Outros fatores, como a manutenção do sistema de BI (tanto os componentes

relacionais como os multidimensionais) também deve ser considerada cuidadosamente.

Especifique memória principal suficiente para que a maioria das consultas nunca faça

E/S

Segundo os engenheiros do Microsoft SQL Server Customer Advisory Team, na maioria dos data

warehouses os dados são acessados de maneira muito irregular. De longe, a maioria das consultas

acessa alguma proporção dos mesmos 20% do total; em outras palavras, cerca de 80% dos dados

raramente são acessados. Isso significa que, no geral, a E/S do disco para o warehouse se reduz

muito se houver memória principal suficiente para conter cerca de 20% dos dados totais.

ETL

O campo de ETL é a área mais complexa do data warehousing [Hath07]. Os dados em si são

complexos e exigem a aplicação de uma grande quantidade de técnicas e processos antes que

sejam carregados no warehouse. Elas incluem mesclagem, carimbo de data/hora, desduplicação e

sobrevivência, conversão de tipo de dados, normalização e/ou desnormalização, inclusão de

chaves substitutas e limpeza geral.

Práticas Recomendadas: Simplifique o Processo de ETL e Melhore o Desempenho

Use p SSIS para simplificar a programação de ETL

O SSIS foi projetado desde o início para simplificar o processo de desenvolvimento de seu código

de ETL. Suas ferramentas automatizadas e transformações e conectores predefinidos reduzem

muito o número de linhas de código de ETL que você tem de escrever em comparação com a

programação em uma linguagem de alto nível tradicional ou de script. É uma prática recomendada

usar o SSIS no lugar desses métodos caso a redução na quantidade de código para ETL e

simplificação da manutenção de tarefas de ETL forem importantes para você.

O SSIS fornece um conjunto abrangente de recursos para construir data warehouses, incluindo:

         Uma arquitetura de pipeline escalonável que fornece uma plataforma 64 bits multithreaded

para transformar volumes de dados crescentes em janelas de lote menores,

         Conectividade para RDBMs não-SQL Server, mainframes, sistemas de ERP e outras fontes de

dados heterogêneas.

         Um grande número de transformações complexas para consolidar dados a partir de vários

sistemas.

         Transformações de limpeza de dados avançadas para reduzir a duplicação e dados sujos.

         Compatibilidade com data warehouse pela capacidade pronta de gerenciar dimensões de

mudança lenta.

         Integração direta com a plataforma de BI do SQL Server BI para construir diretamente cubos

do Analysis Services e carregar diretamente em partições dele.

         Extensibilidade com o poder do .NET pela incorporação de scripts personalizados e

componentes conectáveis diretamente no fluxo de integração de dados.

Simplifique o processo de transformação usando tarefas de Criação de Perfil de Dados

A nova tarefa de Criação de Perfil de Dados no Integration Services pode ser usada para

compreender-se inicialmente a natureza dos dados de origem para fins de projeto (consulte Criando

sua Solução de Data Warehouse/BI). Contudo, os perfis que ela produz também podem ser usados para

aplicar regras comerciais a dados como parte do processo de transformação. Suponha, por

exemplo, que a regra comercial diga que os dados de uma determinada fonte são aceitáveis

apenas se o número de nulos não exceder 1%. Os perfis produzidos por uma tarefa de Criação de

Perfil de Dados podem ser usados para aplicar essa regra.

Note que as tarefas de Criação de Perfil de Dados fazem o perfil de tabelas do SQL Server; dados

em outros locais devem ser carregados em tabelas de preparo antes que o perfil possa ser criado.

Simplifique usando MERGE e INSERT INTO

Quer esteja extraindo dos sistemas de origem para um ODS (Operational Data Store) ou do ODS

para as tabelas de fatos ou de dimensões, você deve gerenciar o movimento das mudanças (os

deltas) que ocorreram. Durante essa fase você freqüentemente precisa de múltiplas consultas de

DML (Data Manipulation Language – Linguagem de Manipulação de Dados) para executar um

movimento lógico dos deltas para dentro da tabela relevante. Isso é particularmente verdadeiro

quando você tem de lidar com dimensões de alteração lenta (e quem não tem?).

O SQL Server 2008 permite a você combinar essas consultas múltipas em uma instrução MERGE.

MERGE

A instrução MERGE executa operações de inclusão, atualização ou exclusão em uma tabela de

destino com base nos resultados de uma junção com uma tabela de origem.

A instrução MERGE fornece três tipos de cláusulas WHEN:

         WHEN MATCHED permite que você faça UPDATE ou DELETE da linha determinada na tabela de

origem quando as linhas de origem e de destino corresponderem a algum(ns) critério(s).

         WHEN NOT MATCHED [BY TARGET] permite que você faça INSERT de uma linha no destino

quando ela existir na origem, mas não no destino.

         WHEN NOT MATCHED BY SOURCE permite que você faça UPDATE or DELETE da linha

determinada na tabela de destino quando ela existir no destino, mas não na origem.

Você pode especificar uma condição com cada uma das cláusulas WHEN para escolher que tipo de

operação de DML deve ser executado na linha.

A cláusula OUTPUT para a instrução MERGE inclui uma nova coluna virtual chamada $action que

você pode usar para identificar a ação de DML que foi executada em cada linha.

Para ilustrar o uso da instrução MERGE, imagine que tem uma tabela de Employee (Funcionário):

 

EmpID Name Title IsCurrent1 Jones Mrs. Yes2 Smith Prof. Yes3 Brown Mr Yes4 Wilson Dr. Yes5 Carlton Dr. Yes 

e uma tabela de alterações:

 

EmpID Name Title IsCurrent1 Jones Prof. Yes6 Heron Mr. Yes 

Dimensão de alteração lenta Tipo 1

Suponha que a tabela Employee seja uma dimensão de alteração lenta Tipo 1, o que significa que

as alterações no campo Title simplesmente têm permissão de substituir o valor existente e

nenhum histórico da alteração nem o valor anterior são mantidos. Suponha também que novas

linhas na origem também sejam incluídas na tabela. Você pode gerenciar este caso simples com

uma instrução MERGE:

MERGE Employee as TRG

USING EmployeeDelta AS SRC

ON (SRC.EmpID = TRG.EmpID)

WHEN NOT MATCHED THEN

INSERT VALUES (SRC.EmpID, SRC.Name, SRC.Title, 'Yes')

WHEN MATCHED THEN

UPDATE SET TRG.Title = SRC.Title

Se incluirmos uma cláusula OUTPUT como esta:

OUTPUT $action, SRC.EmpID, SRC.Name, SRC.Title;

teremos o seguinte conjunto de linhas de resultado além do efeito na tabela Funcionários:

 

$action EmpID Name TitleINSERT 6 Heron Mr.UPDATE 1 Jones Prof. 

Isso pode ser muito útil com depuração, mas também se revela muito útil com dimensões de

alteração lenta Tipo 2.

Dimensões de alteração lenta Tipo 2

Lembre-se de que em uma dimensão de alteração lenta Tipo 2 Recall um novo registro é

acrescentado na tabela de dimensão Funcionários independentemente de se um registro de

funcionário já existe, Por exemplo, queremos preservar a linha existente para Jones, mas definir o

valor IsCurrent naquela linha em ‘Não’. Então queremos inserir as duas colunas da tabela delta (a

origem) no destino.

 

MERGE Employee as TRG

USING EmployeeDelta AS SRC

ON (SRC.EmpID = TRG.EmpID AND TRG.IsCurrent = 'Yes')

WHEN NOT MATCHED THEN

INSERT VALUES (SRC.EmpID, SRC.Name, SRC.Title, 'Yes')

WHEN MATCHED THEN

UPDATE SET TRG.IsCurrent = 'No'

OUTPUT $action, SRC.EmpID, SRC.Name, SRC.Title;

Esta instrução define o valor de IsCurrent em ‘Não’ na linha existente para Jones e insere a linha

para Heron da tabela delta na tabela Funcionários. Contudo, ela não insere a nova linha para

Jones, Isso não representa um problema porque podemos tratar disso com a nova funcionalidade

INSERT, descrita a seguir. Além disso, temos o resultado que, neste caso, é:

 

$action EmpID Name TitleINSERT 6 Heron Mr.UPDATE 1 Jones Prof. 

Nova funcionalidade para INSERT

Podemos combinar a capacidade de lançar os dados com uma nova capacidade no SQL

Server 2008 fazer instruções INSERT consumirem os resultados das instruções de DML. Essa

capacidade de consumir resultados pode, é claro, ser usada com muita eficiência (e simplicidade)

como se segue:

INSERT INTO Employee (EmpID, name, Title)

      SELECT EmpID, name, Title from EmployeeDelta

Se combinarmos essa nova capacidade com o resultado acima, temos a capacidade sinérgica de

extrair a linha que foi atualizada (Jones) e inseri-la na tabela Funcionários para conseguir o efeito

desejado no contexto de dimensões de alteração lenta Tipo 2:

INSERT INTO Employee( EMPID, Name, Title, IsCurrent)    

SELECT EMPID, Name, Title, 'Yes'

FROM

(       

MERGE Employee as TRG

        USING EmployeeDelta AS SRC

        ON (SRC.EmpID = TRG.EmpID AND TRG.IsCurrent = 'Yes')

        WHEN TARGET NOT MATCHED THEN

            INSERT VALUES (SRC.EmpID, SRC.Name, SRC.Title, 'Yes')

        WHEN MATCHED THEN

UPDATE SET TRG.IsCurrent = 'No'

OUTPUT $action, SRC.EmpID, SRC.Name, SRC.Title

)

As Changes (action, EmpID, Name, Title)

WHERE action ='UPDATE';

MERGE no SQL Server 2008 foi implementado para obedecer ao padrão SQL-2006. O principal

motivo para a introdução MERGE no padrão SQL e no SQL Server 2008 é sua utilidade em

gerenciar dimensões de alteração lenta, mas vale lembrar que tanto MERGE como INSERT com

resultado têm muitas outras aplicações tanto dentro do data warehousing especificamente como

em bancos de dados em geral.

Termine todas as instruções SQL com ponto-e-vírgula no SQL Server 2008

Antes do SQL Server 2005, o Transact-SQL era relativamente relaxado a respeito do ponto-e-

vírgula; agora algumas instruções (inclusive MERGE) exigem esse terminador. Se você terminar

todas as instruções de SQL com um ponto-e-vírgula, evita problemas quando o uso deles for

obrigatório.

Se você não puder tolerar o tempo de inatividade, considere usar partições “pingue-

pongue”

Imagine que você tem uma tabela de fatos que é particionada por mês. Estamos em agosto. Você

precisa carregar os dados de hoje na partição de agosto, mas seus usuários não podem tolerar o

impacto no desempenho e conflitos de bloqueio potenciais em que você incorrerá ao carregá-los.

Copie a partição de agosto em outra tabela (uma tabela de trabalho), carregue os dados naquela

tabela, indexe-a como necessário e depois simplesmente alterne as partições entre as duas

tabelas.

Use registro mínimo para carregar dados com precisão onde você os quiser o mais

rápido possível

Gravar dados em um banco de dados tipicamente envolve dois processos de gravação em disco

separados, gravando uma vez no banco de dados e outra no log (assim as transações podem ser

revertidas ou refeitas). Quando da inclusão de dados em uma tabela existente é, de fato, possível

gravar apenas uma vez em alguns casos usando-se o recurso INSERT registrado minimamente.

O registro mínimo permite que transações sejam revertidas, mas não suporta recuperação de

ponto no tempo. Ele está disponível apenas nos modelos de registro em lotes e de recuperação

simples. No SQL Server 2008, o registro mínimo pode ser usado com instruções Transact-SQL

INSERT INTO…SELECT FROM Transact-SQL quando se insere um grande número de linhas em uma

tabela existente se forem inseridas em uma tabela vazia com um índice clusterizado e nenhum

índice não-clusterizado, ou um heap, vazio ou não, sem índices. (Para detalhes completos e

qualquer alteração mais recente, consulte os SQL Server 2008 Books Online.)

Isso estende o suporte para registro mínimo, que no SQL Server 2005 incluía operações de

importação em lotes, SELECT INTO, criação de índices e reconstrução.

Um grande benefício do registro mínimo é que ele acelera o carregamento de partições ou tabelas

vazias que estão em grupos de arquivos específicos. No SQL Server 2005, você podia conseguir

efetivamente o mesmo efeito usando uma solução de contorno que envolvia mudar o grupo de

arquivos padrão e executar um SELECT INTO para obter registro mínimo. Em seguida o grupo de

arquivos padrão seria devolvido a seu estado inicial. Agora você pode simplesmente criar uma

tabela no(s) grupo(s) de arquivos em que quiser que ela esteja, definir o esquema de partições e

em seguida carregá-la com INSERT INTO tbl WITH(NOLOCK) SELECT FROM e conseguir registro

mínimo.

O registro mínimo facilita muito colocar os dados onde você os quer e gravá-los no disco apenas

uma vez. Como um bônus adicional, o desempenho do carregamento é aumentado e a quantidade

de espaço de log necessário é reduzido.

Simplifique a extração de dados usando Captura de Dados de Alterações nos sistemas

de origem do SQL Server

O SQL Server 2008 tem um novo recurso de rastreamento de dados que é particularmente

benéfico em data warehousing. O processo de Captura de Dados de Alterações rastreia mudanças

em tabelas de usuários e as reúne em um formato relacional. Um uso típico seria rastrear

mudanças em um banco de dados operacional para inclusão posterior no warehouse.

O processo de captura coleta dados de alterações a partir do log de transações do banco de dados

e os insere em uma tabela de mudanças. Metadados sobre cada transação também são inseridos

em uma tabela para que as mudanças possam ser organizadas com relação ao tempo. Isso

permite a identificação, por exemplo, do tipo de alteração feita em cada coluna ou de colunas

alteradas em uma linha atualizada. Também é possível solicitar todas as linhas que mudaram

entre dois horários/datas. A Captura de Dados de Alterações é um grande passo na direção da

melhoria do desempenho de extração, e torna a programação da porção de captura de alterações

de suas tarefas de ETL muito mais fácil.

Simplifique e acelere o ETL com Pesquisa Aprimorada

O desempenho do componente de Pesquisa foi muito aprimorado no SQL Server 2008 Integration

Services e está muito mais fácil de programar.

Uma Pesquisa confirma se cada linha em uma seqüência possui uma correspondente em um

conjunto de dados de referência. Isso é usado freqüentemente dentro do processo de ETL para

verificar, por exemplo, a coluna ProductID em uma tabela de fatos (atuando como a fonte de

dados) em comparação com uma tabela de dimensões contendo um conjunto completo de

produtos (o conjunto de referência).

No SQL Server 2008, a transformação de Pesquisa suporta dois tipos de conexão quando se

conecta ao conjunto de dados de referência: o gerenciador de conexão de Cache e o gerenciador

de conexão de DB OLE. O conjunto de dados de referência pode ser um arquivo de cache, uma

tabela ou exibição existente ou o resultado de uma consulta SQL.

Dados de referência geralmente são armazenados em cache para eficiência e agora um fluxo de

dados pode ser usado para popular o cache. Muitas fontes potenciais podem ser usadas como

dados de referência: Excel, XML, texto, serviços da Web — qualquer coisa dentro do alcance de um

provedor ADO.Net. No SQL Server 2005, o cache podia ser populado apenas por uma consulta SQL

e uma Pesquisa podia apenas tomar dados de conexões OLE/DB específicas. O novo componente

de Transformação de Cache (Cache Transform) popula um cache definido pelo gerenciador de

conexão de Cache.

O cache não precisa mais ser recarregado cada vez que é usado: isso elimina a penalidade de

tempo incorrida pelo recarregamento a partir de uma fonte relacional. Se um conjunto de dados de

referência for usado por dois pipelines, o cache pode ser salvo em armazenamento de arquivos

permanente assim como na memória virtual para ficar disponível a várias Pesquisas dentro de um

pacote. Além disso, o formato de arquivo do cache é otimizado para velocidade e seu tamanho é

ilimitado.

O recurso miss-cache também é novo. Quando executado diretamente em um conjunto de dados,

um componente de Pesquisa pode adicionar ao cache quaisquer valores de chave a partir da fonte

onde não houver nenhum valor correspondente no conjunto de dados de referência. Assim, se a

Pesquisa tiver determinado que o conjunto de referência não contém, por exemplo, o valor 885,

não perde tempo inspecionando o conjunto de referência se ele aparecer nos dados de origem.

Sob certas condições este recurso pode produzir uma melhora de desempenho de 40%.

Finalmente, agora há um ‘resultado de Consulta sem correspondência’ (‘Lookup no match output’)

para o qual linhas ‘miss-cache’ podem ser direcionadas em vez de irem para o resultado de erro.

Configuração, Consulta e Gerenciamento de Data Warehouse Relacional

O banco de dados relacional é o coração de qualquer sistema de BI. Práticas recomendadas aqui

afetam não apenas o desempenho de todo o sistema, mas também sua flexibilidade e valor para a

empresa. Para uma discussão mais profunda sobre como obter o melhor desempenho de seu data

warehouse do SQL Server 2008 para data warehouse de larga escala, consulte o documento

complementar [Han08].

Práticas Recomendadas: Geral

Use o gerenciador de recursos para reservar recursos para trabalho importante como

carregamento de dados e para evitar consultas desgovernadas

A carga de trabalho em um data warehouse pode ser considerado como uma série de solicitações

que competem pelos recursos disponíveis. No SQL Server 2005, havia um único pool de recursos e

as solicitações competiam igualmente por eles. O gerenciador de recursos do SQL Server 2008

permite que os recursos disponíveis sejam alocados em vários pools (até 20). As solicitações são

classificadas de modo a se enquadrar em grupos específicos e estes são alocados para os pools de

recursos – muitas solicitações para cada pool de recursos. Podem-se alocar altos recursos para

processos que devem completar-se rapidamente (como o carregamento dos dados) quando são

executados. Além disso, relatórios importantes podem receber recursos suficientes para assegurar

que se completem rapidamente [Bar08].

Muitos usuários acham a imprevisibilidade de desempenho altamente frustrante. Se isso ocorrer, é

benéfico usar o gerenciador para alocar recursos de uma forma que assegure um desempenho

mais previsível. Ao longo do tempo, conforme a experiência com o gerenciador de recursos

aumenta, esperamos que isso evolua para uma prática recomendada.

Suponha, como freqüentemente é o caso, que o data warehouse seja usado para relatórios e para

processos de ETL e que seja configurado para tempo de inatividade zero ou mínimo durante

carregamentos. Em algumas empresas (apesar do que a equipe de BI possa preferir), a geração de

relatórios em tempo hábil é considerada mais importante que a conclusão do carregamento diário.

Neste caso, o grupo de carga de trabalho de relatórios receberia uma prioridade alta.

Ou, por contraste, os processos de carregamento podem receber uma prioridade alta para garantir

o tempo de inatividade mínimo que os negócios exigem.

Finalmente, vale notar que o gerenciador de recursos também permite a você monitorar o

consumo de recursos de cada grupo, o que significa que o uso de recursos pode ser mais bem

entendido, o que, por sua vez, permite um gerenciamento melhor.

Planeje cuidadosamente quando reconstruir estatísticas e índices

O otimizador de consultas usa informações das estatísticas do banco de dados (número de linhas,

distribuição de dados, etc.) para ajudar a determinar o plano de consulta ideal. Se as estatísticas

forem imprecisas, um plano menos ideal pode ser escolhido, o que degrada o desempenho da

consulta.

Se você puder dispor do tempo durante seu processo de ETL, reconstrua as estatísticas depois de

cada carregamento do data warehouse. Isso assegura que as estatísticas estejam sempre exatas.

Contudo, reconstruir estatísticas consome tempo e recursos. Além disso, o tempo entre

reconstruções é menos importante que a mudança na distribuição dos dados que ocorreu.

Quando o data warehouse é novo e está em evolução e também é relativamente pequeno, faz

sentido atualizar as estatísticas freqüentemente, possivelmente após cada carregamento.

Conforme o warehouse amadurece você pode, às vezes, reduzir a freqüência de reconstrução sem

degradar significativamente o desempenho das consultas. Se for importante reduzir o custo da

atualização de estatísticas, você pode determinar o ritmo de renovação apropriada monitorando o

desempenho das pesquisas à medida que reduz a freqüência de renovações. Tenha em mente que

se o grosso de suas pesquisas visar somente os dados carregados mais recentemente, você não

terá estatísticas para aqueles dados a menos que as atualize depois de cada carregamento. Essa é

uma situação bastante comum, e é por isso que recomendamos estatísticas após cada

carregamento do data warehouse por padrão.

Práticas Recomendadas: Data/Hora

Use o tipo correto de dados de hora/data

O SQL Server 2008 possui seis tipos de data e hora:

         date

         datetime2

         datetime

         datetimeoffset

         smalldatetime

         time

Eles armazenam informações temporais com graus variáveis de precisão. Escolher o tipo certo

permite que você mantenha informações de hora e data exatas de uma forma que se ajusta

melhor a seu aplicativo, poupa espaço de armazenamento e melhora o desempenho das

pesquisas. Por exemplo, muitas aplicações mais antigas do SQL Server usam datetime para

datas, mas deixam a porção da hora em branco. Isso ocupa mais espaço do que o necessário.

Agora você pode usar o novo tipo date para essas colunas, o que ocupa apenas três bytes contra

oito com datetime.

Considere usar datetime2 em algumas portas de banco de dados

datetime2 pode ser considerado uma extensão do tipo datetime existente – ele combina uma

data e um horário com base no sistema de 24 horas. Contudo, datetime2 possui uma faixa de

data maior, uma precisão fracionária padrão maior e uma precisão opcional definida pelo usuário.

A precisão é tal que ele pode armazenar frações de segundo com até sete dígitos — em outras

palavras, dentro de dez milionésimos de segundo. Esse novo recurso pode influenciar a

importação de alguns aplicativos de data warehouse.

Por exemplo o tipo de dado TimeStamp DB2 possui uma precisão de um milionésimo de segundo.

Em um aplicativo de data warehouse escrito em DB2, se a lógica do aplicativo for construída para

assegurar que novos registros sejam criados com um intervalo mínimo de um microssegundo (que

não é uma limitação particularmente onerosa), hora/data podem ser usados como uma ID

exclusiva. Podemos debater se é uma prática melhor projetar um aplicativo de banco de dados

dessa maneira, mas o fato é que isso às vezes é feito com DB2.

Antes do advento do datatime2, se um aplicativo desses fosse importado para o SQL Server, sua

lógica teria de ser reescrita porque o datetime fornece uma precisão de somente um milésimo de

segundo. Como o datetime2 é dez vezes mais preciso que o TimeStamp do DB2, o aplicativo

agora pode ser importado sem alteração na lógica.

Práticas Recomendadas: Compressão e Criptografia

Use compressão PAGE para reduzir o volume de dados e acelerar as consultas

Uma capacidade completa de compressão de dados foi adicionada ao SQL Server 2008; as

melhorias vêm em dois tipos — linha e página.

A compressão de linhas armazena todos os campos em formato de largura variável. Se os dados

forem compactáveis, a compressão de linha reduz o número de bytes necessários para armazená-

los.

A compressão de página faz o mesmo, mas a compactação ocorre entre as linhas dentro de cada

página. Um dicionário no nível da página é usado para armazenar valores comuns, que são então

referenciadas a partir das próprias linhas em vez de armazenadas de maneira redundante. Além

disso, prefixos comuns de valores de coluna são armazenados somente uma vez na página. Como

uma ilustração de como a compressão de prefixos pode ajudar, considere códigos de produto em

que os prefixos são freqüentemente similares.

 

Code Quantity

A-F234-10-1234 1834

A-F234-10-1235 1435

A-F234-10-1236 1237

A-F234-10-1237 1546

A-F234-10-1238 1545

A-F234-10-1239 1543

A-F234-10-1240 1756

A-F234-10-1241 1435

A-F234-10-1242 1544

 

Isso pode ser comprimido para:

 

A-F234-10-12 1000

 

Code Quantity

34 834

35 435

36 237

37 546

38 545

39 543

40 756

41 435

42 544

 

Mesmo uma coluna como Quantity (Quantidade) pode beneficiar-se da compressão. Para mais

detalhes sobre como a compressão de linhas e páginas funciona no SQL Server 2008, consulte os

SQL Server 2008 Books Online.

Tanto a compressão de página como a de linha podem ser aplicadas a tabelas e índices.

O benefício óbvio é que você precisa de mesmo espaço em disco. Em testes, houve compressão

de duas a sete vezes, com três vezes sendo típica. Isso reduz seus requisitos de disco em cerca de

dois terços.

Um benefício menos óbvio, mas potencialmente mais valioso, é encontrado na velocidade de

consulta. O ganho aqui vem de dois fatores. A E/S de disco é substancialmente reduzida porque

menos leituras são necessárias para adquirir a mesma quantidade de dados. E a percentagem dos

dados que podem ser mantidos na memória principal aumenta como uma função do fator de

compressão.

A vantagem da memória principal é o ganho em desempenho possibilitado pela compressão e

aumento de tamanho da memória principal.

O desempenho de consultas pode melhorar dez vezes ou mais se você puder colocar e manter na

memória principal todos os dados que vai consultar. Seus resultados dependem da velocidade

relativa de seu sistema de E/S, memória e CPUs. Um data warehouse moderadamente grande

pode caber completamente na memória principal de um servidor de quatro processadores

comercial que possa acomodar até 128 GB de RAM — RAM que está cada vez mais acessível em

termos financeiros. Essa quantidade de RAM pode conter todo um data warehouse típico de 400

GB, compactado. Existem servidores maiores, com até 2 terabytes de memória, disponíveis que

podem acomodar um data warehouse de 6 terabytes inteiros na RAM.

Há, é claro, o custo de CPU associado com a compressão. Isso é visto principalmente durante o

processo de carregamento. Quando a compressão de página é empregada, vimos a utilização da

CPU aumentar a um fator de 2.5. Alguns números específicos para compressão de página,

gravados durante testes em data warehouses de 600 GB e de 6 terabytes com uma carga de

trabalho de mais de cem consultas diferentes, são uma melhoria de 30 a 40% no tempo de

resposta de pesquisa com uma penalidade de tempo de CPU de 10 a 15%.

Assim, em data warehouses que não estão atualmente vinculados à CPU, você deve ver melhorias

significativas no desempenho de consultas a um custo de CPU baixo. Gravações têm mais

overhead de CPU que leituras.

Esta descrição das características de compressão deve permitir que você determine sua estratégia

de compressão ideal para tabelas e índices no warehouse. Pode não ser tão simples quanto aplicar

compressão a todas as tabelas e índices.

Por exemplo, suponha que você divida sua tabela de fatos em partições por tempo, tais como

Trimestre 1, Trimestre 2 e assim por diante. A partição atual é Trimestre 4. Ela é atualizada todas

as noites, o Trimestre 3 muito menos freqüentemente e os Trimestres 1 e 2 nunca são atualizados.

Contudo, todas são consultadas intensivamente.

Depois de fazer testes, você pode descobrir que a melhor prática é aplicar compressão de linha e

página aos Trimestres 1 e 2, compressão de linhas ao Trimestre 3 e nenhuma ao Trimestre 4.

Seu desempenho variará, é claro, e testes são essenciais para estabelecer as melhores práticas

para seus requisitos específicos. Entretanto, a maioria dos data warehouses deve obter um

benefício significativo com a implementação de uma estratégia de compressão. Comece usando

compressão de página em todas as tabelas de fato e índices delas. Se isso causar problemas de

desempenho para carregamento ou consultas, considere reverter para compressão de linhas ou

nenhuma compressão em algumas ou em todas as partições.

Se você usar compressão e criptografia, faça nessa ordem

O SQL Server 2008 permite que os dados de tabela sejam criptografados. A prática recomendada

para usar isso depende das circunstâncias (consulte acima), mas tenha em mente que muito da

compressão descrita na prática recomendada anterior depende de se encontrar padrões repetidos

nos dados. A criptografia reduz ativa e significativamente os padrões nos dados. Assim, se você

pretender usar ambos, é imprudente primeiro criptografar e depois compactar.

Use compressão de backup para reduzir o consumo de memória para armazenamento

A compressão de backup está disponível agora e deve ser usada a menos que você encontre bons

motivos para não fazê-lo. Os benefícios são os mesmo de outras técnicas de compactação — há

ganhos em velocidade e volume. Prevemos que para a maioria dos data warehouses o ganho

primário da compressão de backup é a quantidade de memória de armazenamento reduzida e o

secundário é que o backup termina mais rapidamente. Além disso, uma restauração se executa

mais rápido porque o backup é menor.

Práticas Recomendadas: Particionamento

Particione grandes tabelas de fatos

Particionar uma tabela significa dividi-la horizontalmente em componentes menores (chamados

partições). O particionamento tem vários benefícios. Essencialmente, permite que os dados sejam

separados em grupos. Isso apenas tem várias vantagens em termos de gerenciamento. Partições

podem ser colocadas em diferentes grupos de arquivos para que seu backup possa ser feito

independentemente. Isso significa que podemos posicionar os dados em diferentes eixos por

motivos de desempenho. Em data warehouses isso significa que podemos isolar as linhas que

tenham mais probabilidade de alteração e executar atualizações, exclusões e inclusões naquelas

linhas apenas.

O processamento de consultas pode ser aprimorado pelo particionamento porque ele às vezes

permite que planos de consulta eliminem partições inteiras da consideração. Por exemplo, tabelas

de fato são freqüentemente particionadas por data, como por mês, por exemplo. Assim, quando

um relatório é executado nos números de julho, em vez de acessar um bilhão de linhas, ele pode

ter de acessar apenas 20 milhões.

Índice, assim como tabelas, podem ser (e freqüentemente são) particionados, o que aumenta os

benefícios.

Imagine uma tabela de fatos de um bilhão de linhas que não esteja particionada. Cada

carregamento (tipicamente noturno) significa inclusão, exclusão e atualização naquela tabela

enorme. Isso pode incorrer em altos custos de manutenção de índice, ao ponto em que pode não

ser praticável fazer as atualizações durante sua janela de ETL.

Se a mesma tabela for particionada por tempo, geralmente somente a partição mais recente deve

ser tocada, o que significa que a maior parte da tabela (e índices) permanece intocada. Você pode

descartar todos os índices anteriores ao carregamento e reconstruí-los posteriormente para evitar

overhead de manutenção de índice. Isso pode melhorar bastante seu tempo de carregamento.

Alinhe suas exibições indexadas com as partições

O SQL Server 2008 permite que você crie exibições indexadas alinhadas com suas tabelas de fatos

particionadas e ative e desative partições das tabelas de fatos. Isso funciona se as exibições

indexadas e a tabela de fatos forem particionadas usando-se a mesma função de partição.

Tipicamente, as tabelas de fatos e as exibições indexadas são particionadas pela chave substituta

que faz referência à tabela de dimensão Data. Quando você ativa uma nova partição, ou desativa

uma antiga, não tem de descartar as exibições indexadas primeiro e depois recriá-las. Isso pode

poupar muito tempo durante o processo de ETL. De fato, pode viabilizar o uso de exibições

indexadas para acelerar suas consultas quando não era praticável antes por causa do impacto

sobre seu ciclo de carregamento diário.

Projete seu esquema de particionamento para facilidade de gerenciamento acima de

tudo

No SQL Server 2008, não é necessário criar partições para obter paralelismo, como em produtos

concorrentes. O SQL Server 2008 suporta vários threads por partição para processamento de

consultas, o que simplifica significativamente o desenvolvimento e gerenciamento. Quando você

projetar sua estratégia de particionamento, escolha a largura de sua partição para a conveniência

de gerenciamento de seu ETL e ciclo de vida de dados. Por exemplo, não é necessário particionar

por dia para obter mais partições (o que pode ser necessário no SQL Server 2005 e outros

produtos de DBMS) se o particionamento por semana for mais conveniente para o gerenciamento

do sistema.

Para melhor desempenho paralelo, inclua um predicado de faixa de data explícito na

tabela de fatos em consultas, em vez de uma junção com a dimensão Data

O SQL Server geralmente faz um bom trabalho do processamento de consultas como a seguinte,

em que um predicado de faixa de data é especificado usando-se uma junção entre a tabela de

fatos e a dimensão de data:

 

select top 10 p.ProductKey, sum(f.SalesAmount)from FactInternetSales f, DimProduct p, DimDate dwhere f.ProductKey=p.ProductKey and p.ProductAlternateKey like N'BK-%'and f.OrderDateKey = d.DateKeyand d.MonthNumberOfYear = 1and d.CalendarYear = 2008and d.DayNumberOfMonth between 1 and 7group by p.ProductKeyorder by sum(f.SalesAmount) desc 

Contudo, uma consulta como esta normalmente usa uma junção de loop aninhado entre a

dimensão de data e a tabela de fatos, o que pode limitar o paralelismo e o desempenho geral das

consultas porque, no máximo, um thread é usado para cada linha de dimensão de data

qualificada. Em vez disso, para o melhor desempenho possível, coloque um predicado de faixa de

data explícito na coluna de chave de dimensão da tabela de fatos e certifique-se de que as chaves

da dimensão de data estejam em ordem crescente de data. A seguir está um exemplo de consulta

com um predicado de faixa de data explícito:

 

select top 10 p.ProductKey, d.CalendarYear, d.EnglishMonthName,      sum(f.SalesAmount)from FactInternetSales f, DimProduct p, DimDate dwhere f.ProductKey=p.ProductKey and p.ProductAlternateKey like N'BK-%'and OrderDateKey between 20030101 and 20030107and f.OrderDateKey=d.DateKeygroup by p.ProductKey, d.CalendarYear, d.EnglishMonthNameorder by sum(f.SalesAmount) desc 

Este tipo de consulta tipicamente obtém um plano de consulta de junção hash e se paraleliza

totalmente.

Prática Recomendada: Gerencie Vários Servidores Uniformemente

Use Gerenciamento Baseado em Diretiva para impor boas práticas em vários servidores

O SQL Server 2008 introduz o Gerenciamento Baseado em Diretiva, que possibilita declarar

diretivas (como “todos os arquivos devem ser armazenados em um disco diferente do de dados”)

em um local e depois aplicá-las a vários servidores. Assim, uma prática recomendada (um tanto

recursiva) é configurar práticas recomendadas em um servidor e aplicá-las a todos. Por exemplo,

você pode construir três data marts que extraem dados de um data warehouse principal e usam

Gerenciamento Baseado em Diretiva para aplicar as mesmas regras a todos os data marts.

Recursos Adicionais

Você pode encontrar dicas adicionais relacionadas, na maioria, a obter a melhor escalabilidade e

desempenho do SQL Server 2008 no white paper complementar [Han08]. Essas dicas cobrem uma

variedade de tópicos, inclusive configuração de armazenamento, formulação de consultas,

indexação, agregados e mais.

Análise

Existem vários excelentes white papers sobre Práticas Recomendadas para análise tais como

Práticas Recomendadas de Design de OLAP para Analysis Services 2005, Práticas Recomendadas de Processamento para

Analysis Services, e 10 Práticas Recomendadas de Desempenho de Consulta para Analysis Services. Em vez de repetir

seu conteúdo, neste white paper nós enfocamos mais especificamente práticas recomendadas

para análise no SQL Server 2008.

Práticas Recomendadas: Análise

Considere seriamente o conselho de prática recomendada oferecido por avisos dos AMO

Bom projeto é fundamental para sistemas robustos e de alto desempenho, e a disseminação de

diretrizes de práticas recomendadas encoraja o bom projeto. Uma maneira completamente nova

de indicar onde práticas recomendadas podem ser úteis está incorporada no SQL Server 2008

Analysis Services.

O SQL Server 2008 Analysis Services mostra sugestões e avisos sobre design e práticas

recomendadas em tempo real enquanto você trabalha. Eles são implementados nos AMO (Analysis

Management Objects – Objetos de Gerenciamento de Análise) e exibidos na UI como sublinhados

ondulados azuis: pairar sobre um objeto sublinhado exibe o aviso. Por exemplo, um nome de cubo

pode ser sublinhado e o aviso pode dizer:

Os grupos de medidas ‘SalesProfit’ e ‘Profit’ possuem a mesma

dimensionalidade e granularidade. Considere unificá-los para melhorar

o desempenho. Evite cubos com uma única dimensão.

Mais de 40 avisos diferentes indicam onde a prática recomendada não está sendo seguida. Os

avisos podem ser descartados individualmente ou desligados globalmente, mas nossa

recomendação é segui-las até que você tenha uma razão ativa para não fazê-lo.

Use o writeback de MOLAP no lugar do writeback de ROLAP

Para certas classes de aplicativos comerciais (previsão, orçamento, what if, e assim por diante), a

capacidade de gravar dados de volta no cubo pode ser muito vantajosa.

Por algum tempo foi possível fazer o write-back de valores de células no cubo, nos níveis de folha

e de agregação. Uma partição especial de write-back é usada para armazenar a diferença (os

deltas) entre o original e o novo valor. Este mecanismo significa que o valor original continua

presente no cubo; se uma consulta MDX solicitar o novo valor, ele acessa as duas partições e

retorna o valor agregado do original e do delta.

Contudo, em muitos casos, apesar da necessidade comercial, considerações de desempenho têm

limitado o uso do write-back.

Na implementação anterior, a partição de write-back tinha de usar armazenamento ROLAP e isso

era freqüentemente a causa de desempenho insatisfatório. Para recuperar dados era necessário

consultar a fonte de dados relacionais e isso pode ser lento. No SQL Server 2008 Analysis Services,

partições de write-back podem ser armazenadas como MOLAP, o que remove esse afunilamento.

Embora seja verdade que esta configuração pode reduzir de maneira insignificante a velocidade da

operação de confirmação de write-back (tanto a tabela de write-back como a partição de MOLAP

devem ser atualizadas), o desempenho de consulta melhora muito na maioria dos casos. Um teste

no local de uma atualização de dois milhões de células mostrou uma melhoria de desempenho de

cinco vezes.

Use o backup do SQL Server 2008 Analysis Services em vez de cópia de arquivo

No SQL Server 2008 Analysis Services, o subsistema de armazenamento de backup foi reescrito e

seu desempenho foi bastante aprimorado, como mostrado na Figura 5.

Figura 5: Desempenho de backup no SQL Server 2005 Analysis Services versus SQL Server 2008

Analysis Services. X = Tempo, Y=Volume de dados

O backup agora é escalonado de forma linear e pode lidar com um banco de dados do Analysis

Services de mais de um terabyte. Além disso, as limitações no tamanho do backup e de arquivos

de metadados foram eliminadas. Sistemas lidando com grandes volumes de dados agora podem

adotar o sistema de backup e abandonar a cópia de sistema de arquivos brutos e apreciar os

benefícios da integração com o sistema transacional e da execução de backup em paralelo com

outras operações.

Embora a extensão fique inalterada, o formato do arquivo de backup mudou. Ele é totalmente

compatível com versões anteriores, assim é possível restaurar no SQL Server 2005 Analysis

Services um banco de dados com backup feito no SQL Server 2005 Analysis Services. Não é

possível, porém, salvar arquivos no formato antigo.

Escreva MDX mais simples sem se preocupar com o desempenho

Um novo recurso, computação em bloco (também conhecido como computação subespacial), foi

implementado no SQL Server 2008 Analysis Services e um dos principais benefícios que oferece é

desempenho de consulta MDX aprimorado. NO SQL Server 2005, contornos complexos eram

possíveis em alguns casos; agora o MDX pode ser escrito de maneira muito mais simples.

Cubos comumente contêm dados esparsos: é freqüente haver relativamente poucos valores em

uma grande quantidade de nulos. No SQL Server 2005 Analysis Services, consultas que tocavam

um grande número de nulos podiam realizar um cálculo com um valor nulo pela simples razão de

que mesmo que fosse logicamente inútil executar um cálculo com um valor nulo a consulta

processaria inutilmente todos os valores nulos da mesma forma que não-nulos.

A computação em bloco trata dessa questão e aumenta muito o desempenho dessas consultas. A

estrutura interna de um cubo é altamente complexa e descrição que se segue sobre como a

computação em bloco funciona é uma versão simplificada do tema todo. Ela dá, contudo, uma

idéia de como o ganho em velocidade é atingido.

O cálculo de MDX calcula um total acumulado de dois anos consecutivos:

CREATE MEMBER CURRENTCUBE.[Measures].RM

   AS ([Order Date].[Hierarchy].PrevMember,[Measures].[Order Quantity])+

      Measures.[Order Quantity],

FORMAT_STRING = "Standard",

VISIBLE = 2 ;

Estas tabelas mostram pedidos de pequenos subconjuntos de produtos e ilustram que há

pouquíssimos valores para os principais produtos e, 2003 e 2004:

 

  2003   2004Produto 1      Produto 2 2    Produto 3      Produto 4     5Produto 5      Produto 6      Produto 7 3   1Produto 8      Produto 9      

 

Esta consulta:

SELECT [Order Date].[Hierarchy].[all].[2004] on columns,

[Dim Product].[Product Key].[All].children on rows

From Foo

Where Measures.RM

retorna a medida RM calculada para todos os produtos pedidos em 2004.

No SQL Server 2005 Analysis Services, o resultado é gerando tomando o valor de uma célula de

2004 (o ano atual), encontrando-o na célula correspondente para o ano anterior e resumindo os

valores. Cada célula é tratada dessa maneira.

Esta abordagem contém dois processos lentos. Primeiro, para cada célula, o processador de

consultas navega até o período anterior para ver se um valor está presente. Na maioria das

estruturas hierárquicas sabemos que se dados para uma célula estiverem presentes em 2003,

estarão lá para todas as células daquele ano. A viagem para ver se há dados para o período

anterior precisa ser realizada apenas uma vez, que é o que acontece no SQL Server 2008 Analysis

Services. Esta faceta da computação em bloco acelera consultas independentemente da proporção

de valores nulos no cubo.

Depois, a soma de cada par de valores é calculada. Com um cubo esparso, uma alta proporção dos

cálculos resulta em nulo e tempo é desperdiçado fazendo-se esses cálculos. Se olharmos as

tabelas anteriores, é fácil ver que somente os cálculos dos produtos 2, 4 e 7 terão resultados que

não são nulos. Assim, no SQL Server 2008 Analysis Services, antes que qualquer cálculo seja

executado, linhas nulas são removidas dos dados de ambos os anos:

 

  2003Produto 2 2Produto 7 3

 

 

  2004Produto 4 5Produto 7 1

 

Os resultados são comparados:

 

  2003   2004Produto 2 2    Produto 4     5Produto 7 3   1

 

e os cálculos realizados somente nas linhas que gerarão um resultado significativo.

O ganho de velocidade pode ser impressionante: em teste, uma consulta que levava dois minutos

e 16 segundos no SQL Server 2005 Analysis Services levou apenas oito segundos no SQL

Server 2008 Analysis Services.

Escalone horizontalmente se precisar de mais capacidade de hardware e o preço for

importante

Para melhorar o desempenho sob carga, você pode escalonar vertical ou horizontalmente.

Escalonar verticalmente é de uma simplicidade inegável: coloque o cubo em um servidor grande

de alto desempenho extra. Esta é uma excelente solução – é rápida e fácil e a decisão correta em

muitos casos. Contudo, também é cara porque esses servidores custam mais por CPU que vários

servidores melhores.

Versões anteriores do Analysis Services ofereciam uma solução de escalabilidade horizontal que

usava vários servidores eficazes em termos de custo. Os dados eram replicados nos servidores e

uma solução de balanceamento de carga, como o Microsoft NLB (Network Load Balancing –

Balanceamento de Carga de Rede) era instalado entre os clientes e os servidores. Isso funcionava,

mas incorria em custos adicionais de configuração e manutenção constante.

O SQL Server 2008 Analysis Services possui uma solução de escalabilidade horizontal chamada

SSD (Scalable Shared Database). Seu funcionamento é muito semelhante ao recurso de SSD no

mecanismo de banco de dados relacional do SQL Server 2005. Ele é formado por três

componentes:

         Banco de dados de somente leitura – permite que um banco de dados seja designado para

‘somente leitura’

         Alocação de armazenamento de banco de dados – permite que um banco de dados resida fora

da pasta Dados do servidor

         Banco de dados de anexação/desanexação – um banco de dados pode ser anexado a ou

destacado de qualquer caminho UNC

Usados juntos, esses componentes facilitam construir uma solução de escalabilidade horizontal

para cubos de somente leitura do Analysis Services. Por exemplo, você pode conectar quatro blade

servers a um banco de dados de somente leitura compartilhado em uma SAN, e direcionar

consultas do SSAS a qualquer dos quatro, melhorando assim sua taxa de transferência a um fator

de quatro com hardware barato. O melhor tempo de resposta possível a consultas continua

limitado pelos recursos de um servidor individual, já que apenas um servidor executa cada

consulta.

Relatórios

Esta seção oferece práticas recomendadas para diferentes aspectos da criação de relatórios, tais

como melhorar o desempenho.

Práticas Recomendadas: Apresentação de Dados

Permita que usuários de TI e comerciais criem relatórios simples e complexos

Relatórios sempre caíram entre duas opiniões — pessoal de TI ou comercial deve projetá-los? O

problema é que usuários comerciais entendem o contexto comercial no qual os dados são usados

(o significado dos dados), enquanto o pessoal de TI entende a estrutura subjacente dos dados.

Para ajudar os usuários comerciais, no SQL Server 2005, a Microsoft introduziu o conceito de um

modelo de relatório. Ele foi construído por gente de TI para os usuários comerciais que então

escrevia relatórios com ele usando uma ferramenta chamada Configurador de Relatórios. Ele será

fornecido com o SQL Server 2008 e funcionará como antes.

Uma ferramenta nova, o Configurador de Relatórios, dirigida diretamente ao usuário avançado, foi

aperfeiçoada no SQL Server 2008. Este produto autônomo, completo com uma interface do Office

System 12, ostenta os recursos de layout completos do Designer de Relatórios e está disponível

como um download da Web.

Profissionais de TI eram bem servidos no SQL Server 2005 por uma ferramenta chamada Designer

de Relatórios no Visual Studio, que lhes permitia criar relatórios bastante detalhados. Uma versão

aperfeiçoada do Designer de Relatórios é fornecida com o SQL Server 2008 e é mostrada na Figura

6.

Figura 6: Designer de Relatórios no Visual Studio

Apresente dados da maneira mais acessível possível

Tradicionalmente, dados de grade foram apresentados aos usuários em tabelas, matrizes e listas.

Cada qual tinha suas forças, que é outra maneira de dizer que cada qual tem suas fraquezas. O

SQL Server 2008 Reporting Services combina as três em uma região de dados chamada Tablix.

Na Figura 7, a tabela à esquerda mostra o crescimento percentual e a matrix à direita mostra os

números reais.

 

Figura 7: Uma tabela e uma matriz

A Tablix mostrada na Figura 8 combina estes e acrescenta alguns totais.

Figura 8: Uma região de dados Tablix combinando recursos de tabela e de matriz

A região de dados Tablix dá aos usuários muito mais controle sobre o layout que tabelas, listas e

matrizes. Ela também permite a eles adicionar grupos de colunas, especificar aninhamentos

arbitrários em cada eixo, omitir cabeçalhos de linhas e de colunas opcionalmente e ter vários

membros linha/coluna paralelos em cada nível.

Apresente dados em relatórios que podem ser entendidos facilmente

A razão para gerar relatórios é transformar dados em informações para o usuário comercial. Muitos

acham gráficos mais fáceis de entender que números. O SQL Server 2008 Reporting Services

introduz o mostrador, uma nova forma de resultado visual. Um mostrador exibe um único valor a

partir dos dados. Como a Figura 9 mostra, mostradores são particularmente úteis para se criar

exibições fáceis de ler que comparam vários valores.

Figura 9: Exemplos dos mostradores que podem ser criados no SSRS

Os gráficos também estendidos para incluir polares, de faixas e de formas. A Figura 10 mostra

apenas um subconjunto dos disponíveis.

Figura 10: Um grande número de gráficos está disponível no SQL Server 2008 Reporting Services

Várias séries de dados agora podem ser exibidas em mais de um eixo, o usuário tem o controle

sobre quebras de escala no eixo e há suporte para formulas de tempo de execução.

Apresente dados a usuários em ambientes familiares

Relatórios agora podem ser processados como documentos do Word compatíveis com versões

anteriores e incluindo o Word 2000. Além disso, o processador de Excel foi aprimorado e agora

suporta recursos como regiões de dados aninhados, células mescladas e sub-relatórios.

Práticas Recomendadas

Estruture sua consulta para retornar apenas o nível de detalhe exibido no relatório

Use agregação no nível do relatório somente para subtotais no relatório, não para linhas de

detalhes. Lembre-se de que o agregado mais comumente usado, Sum, pode ser calculado em

qualquer ordem e ainda produzir o mesmo resultado. Embora outros agregados comumente

usados não possam, freqüentemente permitem decomposição em componentes mais simples e

reutilizáveis.

Por exemplo, se você estiver tentando mostra uma média em vários níveis de agrupamento e

também quiser subtotais, em vez de retornar linhas de detalhe e agregar tudo no relatório, você

pode decompor o cálculo em somas e contas. Depois pode reconstituir a média no relatório usando

este tipo de divisão:

 

Sum(Fields!Sum.Value)/Sum(Fields!Count.Value)

 

evitando assim a necessidade de passar linhas de detalhe para o relatório. Deixe que o banco de

dados faça o resumo e agregação em massa e use o SSRS para reunir e formatar resultados para

exibição.

Filtre usando parâmetros que são passados para a consulta

Como regra geral é melhor filtrar na consulta que no relatório (SELECT * FROM xyz WHERE field =

@param). Entretanto, se você fizer isso não poderá criar um instantâneo histórico do relatório sem

bloquear o valor do parâmetro. Se os usuários precisarem mudar o valor do parâmetro no

instantâneo, a prática recomendada é devolver todos os dados ao relatório e filtrar dentro dele.

Classifique dentro da consulta

O SSRS utiliza operações de classificação internamente, assim a ordem dos dados retornados da

consulta não são alterados dentro de cada instância de grupo, permitindo assim que a

classificação seja realizada na consulta.

Contudo, uma classificação que é baseada em valores de agregados é muito mais conveniente (e

geralmente mais eficiente) realizada no próprio relatório.

Evite usar sub-relatórios dentro de um agrupamento

Cada instância de sub-relatório é uma execução de consulta separada e um passo de

processamento separado para o SSRS. Para relatórios de detalhes mestres, é muito mais eficiente

simplesmente juntar os dados-mestres e de detalhes em sua consulta e depois agrupar pela

chave-mestra no relatório, exceto em casos em que o número de registros-mestres for pequeno

(em cujo caso o uso de sub-relatórios não é uma questão de desempenho).

Há dois casos em que sub-relatórios podem ser necessários:

         Quando os dados mestres e de detalhes estiverem em fontes de dados diferentes. Puxar os

dados para um único data warehouse é recomendado neste caso. Se não for possível, servidor

conectado ao SQL Server ou recursos de conjunto de linhas aberto devem ser considerados.

         Quando houver vários conjuntos independentes de registros de detalhes para cada registro-

mestre. Um exemplo pode ser exibir uma lista detalhada de vendas e devoluções de cada cliente.

Neste caso, relatórios detalhados são recomendados em vez de sub-relatórios embutidos, a menos

que o número de relatórios-mestres seja pequeno.

Limite os dados em gráficos ao que o usuário puder ver

Embora possa ser tentador incluir uma grande quantidade de detalhes em gráficos para aumentar

a exatidão, é melhor pré-agrupar os dados na consulta ou no relatório, limitando o número de

pontos de dados. Desenhar centenas de pontos em um espaço que ocupa apenas alguns pixels

degrada o desempenho e não faz nada para aumentar o apelo visual do gráfico.

Pré-classifique e pré-agrupe os dados em sua consulta

Você normalmente pode melhorar o desempenho agrupando e classificando os dados na consulta

para corresponderem à ordem de classificação exigida pelo relatório.

Use drillthrough em vez de drilldown quando volumes de dados de detalhes forem

grandes

Embora o mecanismo de processamento por demanda do SQL Server 2008 otimize a maioria dos

cálculos para itens que não são exibidos, tenha em mente que todos os dados são recuperados

para cada linha de detalhe, mesmo se seu estado de detalhamento inicial tenha recolhido tudo

para o nível mais alto de agregação. Além disso, todo agrupamento, classificação e filtragem

devem ser executados independentemente do estado de visibilidade ou de detalhamento. Assim,

se o usuário estiver tipicamente apenas interessado em ver uma pequena porcentagem dos dados

de detalhe, um relatório de detalhamento associado é uma escolha melhor.

Evite expressões complexas no cabeçalho e rodapé da página

Se o cabeçalho ou rodapé da página contiver expressões complexas (qualquer coisa ale de um

campo simples ou referência de parâmetro), o SSRS deve assumir que ele pode incluir uma

referência ao número total de páginas. Como resultado, o relatório todo deve ser paginado antes

que a primeira página seja processada. Caso contrário, a primeira página pode ser processada e

retornada imediatamente ao usuário, que não terá de esperar que o relatório inteiro seja paginado

primeiro.

Desative CanGrow em caixas de texto e AutoSize em imagens, se possível

Alguns processadores são mais eficientes se os tamanhos de todos os objetos do relatório forem

conhecidos e fixos.

Não retorne colunas de sua consulta que não for usar

Como todos os dados na consulta devem ser recuperados (e armazenados) pelo servidor de

relatórios, é mais eficiente retornar somente as colunas que serão usadas em seu relatório. Se o

conjunto de resultados não puder ser controlado (como quando os resultados são retornados de

um procedimento armazenado), é eficiente remover as definições de campo do conjunto de dados.

Embora as colunas extras sejam recuperadas, isso pelo menos evitará que sejam armazenadas.

Práticas Recomendadas: Arquitetura e Desempenho do Sistema

Mantenha o catálogo e o servidor de relatórios no mesmo computador

O Reporting Services gera e usa um banco de dados que é essencialmente um catálogo. Ele é

usado durante o processamento de relatórios para uma variedade de tarefas, inclusive gerenciar

os dados retornados de consultas. Embora seja possível armazenar esse banco de dados em um

servidor diferente do servidor de relatórios, fazer isso exige que os dados do relatório sejam

enviados por push desnecessariamente através da rede, o que reduz a execução de relatórios. É

uma prática muito mais recomendada manter o banco de dados do catálogo no servidor de

relatórios para evitar esse tráfego na rede e os atrasos associados.

Considere colocar o Reporting Services em um servidor diferente de seu data

warehouse

Embora puxar os dados das consultas pela rede reduza a velocidade das coisas, é benéfico não

deixar seu data warehouse e o SSRS competindo pela memória e pelo tempo de processamento.

Conclusão

Projetar e construir um data warehouse empresarial pode ser um grande esforço com um custo

expressivo. Data warehouses não são construídos como demonstrações de excelência técnica; são

investimentos feitos pela empresa e visam a proporcionar um alto retorno. Como documentos do

IDC e da Gartner demonstram, muito freqüentemente esses projetos têm mais características de

uma aposta que de um investimento inteligente – um retorno potencialmente alto, mas um alto

risco simultâneo de fracasso e perda.

Muito se aprendeu sobre fatores que estão associados com projetos de sucesso. Eles foram

destilados em várias práticas recomendadas, mudas das quais estão descritas aqui, abrangendo

processos comerciais, design e implementação técnica usando o SQL Server 2008. De fato, muitos

dos novos recursos do SQL Server 2008 foram projetados especificamente para permitir que essas

práticas recomendadas sejam implementadas facilmente.

Como uma proporção do esforço total exigido para se criar um data warehouse, aplicar essas

práticas recomendadas é barato e, ainda assim, fazer isso pode ter um grande impacto no sucesso

(e, portanto, no ROI) do projeto como um todo.

 

Para mais informações:

         Site do SQL Server

         SQL Server TechCenter

         SQL Server Developer Center

Este documento foi útil? Envie-nos seus comentários. Diga em uma escala de 1 (ruim) a 5

(excelente), como classificaria este documento e porque o classificou assim? Por exemplo:

         Está dando uma nota alta devido aos bons exemplos, excelentes capturas de tela,

redação clara ou outro motivo?

         Está dando uma nota baixa devido a exemplos ruins, capturas de tela indistintas,

redação vaga?

Estes comentários nos ajudarão a melhorar a qualidade dos white papers que publicamos. Envie-nos

seu feedback.

Referências

[Kim08] Ralph Kimball et al., The Data Warehouse Lifecycle Toolkit: Practical Techniques for

Building Data Warehouse and Business Intelligence Systems, 2ª ed. John Wiley & Sons, 2008.

 [Inmon05] William H. Inmon, Building the Data Warehouse: 4ª ed. John Wiley & Sons, 2005.

 [IDC96] The Foundations of Wisdom: A Study of the Financial Impact of Data Warehousing.

International Data Corporation (IDC), 1996

 [Gart07] More Than 50 Percent of Data Warehouse Projects Will Have Limited Acceptance or Will

Be Failures Through 2007: Gartner Business Intelligence Summit, Chicago, Março 2005

(http://www.gartner.com/it/page.jsp?id=492112).

 [Han08] Eric N. Hanson et al., Scaling up Your Data Warehouse with SQL Server 2008, trabalho em

andamento, 2008.

 [MMD07] William McKnight, Choosing Microsoft SQL Server 2008 for Data Warehousing, 2007.

Graeme Malcolm, Business Intelligence in SQL Server 2008, 2007.

Michelle Dumler, Microsoft SQL Server 2008 Product Overview, 2007.

 [Hath07] Kamal Hathi, An Introduction to SQL Server 2008 Integration Services, 2007.

 [Bar08] Boris Baryshnikov, SQL Server 2008 Resource Governor, trabalho em andamento, 2008.