DW Recomendações

[Rodrigo AlmeidaParticipante]

Marcelo,

Segue algumas dicas sobre DW:

HARDWARE
========

O servidor deve ter muita memória e CPU, pois o DW por natureza consome muitos esses recursos devido ao alto processamento de dados e a instruções SQL e PL/SQL que são executadas que necessita de memória.

O hardware deve estar de modo exclusivo para o banco de dados que se encarregará de suportar o DW da empresa, pois o DW também tem um alto consumo de DISCO, naturalmente pelo seu tamanho e tráfego de REDE, pois caso tenha servidores de apoio, como um Data Mart, Data Mining, SAS, Discover, Cube Apps e etc, irá gerar um alto tráfego, então fique de olho nisso.

BANCO DE DADOS PARA DW
===================

Como dito, consumo de área temporária e UNDO é normal e elevado mesmo, isso é normal, existem DWs que a área temporária chega a ser 1/4 do tamanho da base devido aos tipos de processamento e configuração utilizada no ETL.

Outro ponto que deve ser levado em consideração, seja com os projetistas, se está utilizando o modo Snow flake ou Start Schema, pois dependendo do modelo de dados que o seu DW está utilizando, você pode configurar a instância de acordo com o modelo utilizado.

Exemplo, é um parâmetro chamado star_transformation_enabled, que trabalha bem com as dimensões e eu diria a “NORMALIZAÇÂO” do modelo Start Schema.

Onde esse parâmetro pode impactar se utilizar Snow Flake, onde as dimensões trabalham de forma diferente sobre as tabelas de fato.

Tabelas de FATO
===========

Esse é o calcanhar de aquiles no DW, as tabelas de FATO, por natureza, são enormes e vão dar origens as suas dimensões, então, essas tabelas DEVEM SIM, ser particionadas de acordo com a regra de negócio do DW.

Geralmente são SUBPARTICIONADAS por Mês (Range Partition) e a coluna que será a chave de Particionamento (Hash Parition), e alocadas em diferentes tablespaces conforme o ciclo de vida da informação no DW. A latência de dados que será armazenada.

Evite utilizar muitos índices nas FATOS, pois desde consumir muito espaço em disco, operações de INSERT do ETL ficaram mais lentas impactando no processo no geral! O número de índice irá depender de ambiente para ambiente.

Geralmente suas tablespaces possuem uma blocagem diferente, de 32KB, habilitando assim o Buffer para blocos de 32KB, por armazenar grande quantidade de informação.

DIMENSÕES
========

Alocadas sempre em tablespaces diferentes e com blocagem diferente, 8KB para baixo, pois pega apenas as informações necessárias das FATOS organizados os dados para outros processos ou relatórios.

As dimensões trabalham muito mais em memória, usando o SORT, PGA e SHARED_POOL. Por isso, esses parÂmetros serão alterados.

Para achar um valor adequado, use o AWR (10g) ou Statspack (8i/9i) para analisar o consumo das querys vindas das Dimensões.

Um detalhe importante é o uso do SQL MODEL, que tem um utilização anormal para MERGE JOINS e uso de SORT para agragação dos dados para os relatórios.

DICAS PARA INSTÂNCIA
================

• Trabalhar com Paralelismo nos processos de ETL, configurar os parâmetros parallel_max_servers, parallel_threads_per_cpu e parallel_min_servers de acordo com a quantidade de CPU.

• Trabalhar em NOARCHIVELOG, a recuperação é apartir de backup FULL ou por arquivos de FLAT FILE ou outra arquivo de carga para o DW.

• Distribuição dos datafiles entre os Volumes do Storage.

• db_writer_processes para um valor que a controladora suporte!

• Use sempre HBA!

  E acho que é isso… hehehehe…

  Abraços,