ustify>Capa SQl 33

Clique aqui para ler todos os artigos desta edição

­Microsoft Analysis Services 2000 na prática – Parte 2

Administrando o servidor OLAP

Não é muito comum ouvirmos comentários sobre a administração do MSAS. Talvez seja por isso que ouvimos tanto expressões como “OLAP requer uso intensivo de hardware” ou que “a manutenção dos cubos é muito trabalhosa”.

Da próxima vez que ouvir estes comentários, questione.

A seguir, apresentamos alguns pontos sobre a administração do servidor OLAP e a manutenção de seus objetos.

Instalação e configuração do MSAS

O processo de instalação do MSAS é bastante simples, adotando o famoso estilo Microsoft de NNF (Next, Next, Finish). Na realidade, a instalação é padrão, praticamente sem recursos de personalização.

Se puder instalar o MSAS em um servidor dedicado, melhor. Mas é importante que haja na sua rede ao menos um servidor onde rodem o SQL Server e o SQL Server Agent. Estes componentes se integrarão com o MSAS em várias funções, inclusive com respeito à automação de processos, que é tratada no próximo artigo desta série.

Uma vez instalado, abriremos o MSAS no atalho:

 

INICIAR => PROGRAMAS => MS SQL SERVER => ANALYSIS SERVICES => ANALYSIS MANAGER

 

O conceito e a aparência do Analysis Manager são semelhantes aos do SQL Server Enterprise Manager, mas infelizmente ele não é tão poderoso quanto este último. Pessoalmente, acho que os recursos que deixam mais a desejar são as ferramentas de backup e gerenciamento de segurança, que comentaremos adiante.

Para iniciarmos o trabalho com o MSAS, expanda a árvore do Analysis Servers até conectar-se ao servidor OLAP desejado. Se esta é a primeira vez que você se conecta a um servidor já existente, certifique-se que sua conta do Windows faz parte do grupo OLAP Administrators (solicite ajuda ao administrador da rede de sua empresa). Caso o servidor desejado não esteja disponível, você pode registrá-lo como faria com um servidor SQL Server: clique com o botão direito sobre o nó Analysis Servers, selecione Register Server e informe o nome do servidor.

Assim como fizemos no primeiro artigo desta série, vale comentar o conceito de Database usado pelo MSAS, pois ele é um componente básico no processo de manutenção. Um Database comporta vários cubos, dimensões e objetos que podem ser compartilhados entre si. Isso facilita bastante na construção e manutenção dos objetos, simplesmente por podermos reaproveitar objetos pré-existentes. Desta forma, é uma boa prática incentivar os desenvolvedores a:

·         Construir dentro do mesmo Database os cubos que possuem informações compartilhadas, o que permitirá a criação de cubos virtuais que cruzem estes dados;

·         Sempre criar as dimensões com a opção Share this dimension with other cubes, de modo a reaproveitarmos as dimensões que criarmos;

·         Quando possível, criar dimensões virtuais ou novas hierarquias ao invés de construir uma nova dimensão independente, o que minimiza manutenção;

·         Quando possível, criar cubos virtuais ao invés de construir um cubo independente, novamente para minimizarmos manutenção.

Analisando o armazenamento dos dados

Em primeiro lugar, temos que ter em mente que os dados que são armazenados no cubo não devem ser iguais aos que temos na fonte de dados. Esta redundância é desnecessária e considero mesmo indesejável, mas já vi muitos sistemas OLAP desenhados desta forma.

O que carregamos no cubo é uma visão consolidada dos dados, como uma View. Caso o usuário necessite de informações mais detalhadas, então poderemos habilitar o recurso de Drill Through.

Para quem não conhece, o Drill Through é uma extensão do que chamamos de Drill Down, que é a capacidade de detalhar uma informação que inicialmente é exibida de forma consolidada. Vamos a um exemplo: observe o relatório exibido na Figura 1. Originalmente, o relatório exibia resultados consolidados para o ano corrente. Ao clicarmos duas vezes sobre o ano de 2006 (células em amarelo), detalhamos os resultados por Trimestre. E ao clicarmos duas vezes sobre Quarter 1 (células em verde), exibiremos resultados por mês. Isso é Drill Down. A diferença do Drill Through é que ele permite que o cubo vá buscar na fonte de dados informações que ele próprio não armazena. Isto funciona de forma transparente para a aplicação, e o MSAS gerencia a operação. Neste exemplo, seria como exibirmos resultados de demanda por dia, já que o cubo contém informações detalhadas por mês e a demanda diária seria lida diretamente da fonte de dados. 

 

Figura 1. Relatório de demanda por Força de Vendas, mostrando o Drill Down pela dimensão DATA.

 

 

Existem três aspectos importantes a serem comentados sobre o armazenamento de dados: (1) o nível de pré-consolidação de cada cubo; (2) como os dados são fisicamente armazenados em disco; (3) como se comportam os objetos virtuais.

 

1. Nível de Pré-Consolidação

No MSAS, não há como definir índices para melhorar a performance de consultas específicas. Isso porque todas as informações que estão no cubo estão, de certo modo, “indexadas”. E quem gerencia estes índices é o MSAS.

O que o administrador pode fazer é definir alguns parâmetros que orientam o MSAS sobre como lidar com esta indexação. Mais precisamente, o administrador irá atuar na maneira como os dados são armazenados.

Um artifício comum no universo OLAP é pré-calcular os resultados para que as consultas sejam mais rápidas. O MSAS oferece um assistente muito interessante para projetar a relação entre nível de pré-consolidação dos dados e o tamanho final do cubo (veja Figura 2). Vamos entendê-lo melhor.

 

Figura 2. Análise da relação entre nível de pré-consolidação e tamanho do cubo DEMANDA.

 

 

A relação pré-consolidação versus tamanho se baseia no modelo do cubo estudado e nos dados nele existentes. Portanto, a análise precisa ser calculada para cada cubo que estudarmos. Mais do que isso, ainda que consideremos o mesmo cubo, a relação vai mudar sempre que tivermos alterações significativas no número de dimensões, ou número de níveis hierárquicos (mudança no modelo), ou número de elementos existentes (mudança nos dados).

A relação exibida na Figura 2 é válida para o cubo DEMANDA, que utilizamos como exemplo no primeiro artigo desta série sobre o MSAS (ver SQL Magazine 39).

Observe que temos no eixo horizontal do gráfico o espaço em disco requerido exclusivamente para as agregações. Por esta razão, o gráfico parte de 0 Mb, que representa que não há nenhuma agregação salva em disco. Portanto, lembre-se que este gráfico não informa o espaço total em disco requerido por seu cubo, pois em nenhum momento nos referimos ao espaço necessário para armazenamento dos dados e dos objetos auxiliares usados no cubo.

No eixo vertical do gráfico temos o percentual de agregação de dados. Muitas vezes ele é confundido com o percentual de ganho de performance, mas não existe uma relação linear entre a pré-consolidação de dados e o ganho de performance.

O nível de pré-consolidação de 0% significa que todas as consolidações serão calculadas em tempo de execução, tornando as consultas mais lentas.

Em contrapartida, nível de pré-consolidação de 100% significa que todas as possíveis combinações entre os elementos das dimensões estarão “pré-calculadas” e gravadas em disco, o que irá reduzir significativamente o tempo de resposta das consultas.

E é aqui que está o problema. Raramente temos consciência do que significa a expressão “todas as combinações”. O número de combinações cresce exponencialmente em relação ao tamanho das dimensões.

Vamos a um exemplo. Vamos consultar no Analysis Manager quantos elementos existem em cada dimensão do cubo DEMANDA.

Para isso, expanda o nó Shared Dimensions do Database SQLMAGAZINE e clique com o botão direito sobre a dimensão DATA e selecione Edit para acessar o Dimension Editor. Marque o nível hierárquico Month. Em seguida, clique o botão Properties e selecione a aba Advanced. Aqui temos a propriedade Member Count, que nos mostra que existem 24 elementos no nível Month da dimensão DATA. Marque cada nível hierárquico da dimensão para obter a contagem de elementos.

Repita o processo para cada dimensão do cubo. Teremos finalmente as informações que são apresentadas na Tabela 1.

 

DIMENSÃO

DATA

FORCAVENDA

PRODUTO

BRICK

nível 0

24

4176

83

1392

...
Quer ler esse conteúdo completo? Tenha acesso completo