• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Melhores Práticas de Data Warehousing com SQL Server 2008.doc
 

Melhores Práticas de Data Warehousing com SQL Server 2008.doc

on

  • 4,951 views

 

Statistics

Views

Total Views
4,951
Views on SlideShare
4,951
Embed Views
0

Actions

Likes
2
Downloads
236
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Melhores Práticas de Data Warehousing com SQL Server 2008.doc Melhores Práticas de Data Warehousing com SQL Server 2008.doc Document Transcript

    • 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 IsCurrent 1 Jones Mrs. Yes 2 Smith Prof. Yes 3 Brown Mr Yes 4 Wilson Dr. Yes 5 Carlton Dr. Yes e uma tabela de alterações: EmpID Name Title IsCurrent
    • 1 Jones Prof. Yes 6 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 Title INSERT 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 Title INSERT 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 d where f.ProductKey=p.ProductKey and p.ProductAlternateKey like N'BK-%' and f.OrderDateKey = d.DateKey and d.MonthNumberOfYear = 1 and d.CalendarYear = 2008 and d.DayNumberOfMonth between 1 and 7 group by p.ProductKey order 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 d where f.ProductKey=p.ProductKey and p.ProductAlternateKey like N'BK-%' and OrderDateKey between 20030101 and 20030107 and f.OrderDateKey=d.DateKey group by p.ProductKey, d.CalendarYear, d.EnglishMonthName order 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 2004 Produto 1 Produto 2 2 Produto 3 Produto 4 5 Produto 5 Produto 6
    • Produto 7 3 1 Produto 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: 2003 Produto 2 2 Produto 7 3 2004 Produto 4 5 Produto 7 1 Os resultados são comparados: 2003 2004 Produto 2 2 Produto 4 5 Produto 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.