Vamos falar sobre um assunto que é ignorado na fase inicial de arquitetura de um D.W que é o particionamento das tabelas do banco de dados. Afinal, se queremos dados históricos, se torna mais fácil quando estes já estão pré-prontos.

Em muitos casos o particionamento de tabela pode ajudar a prevenir problemas de performance de um D.W antes mesmo dele surgir principalmente quando este é implementado no ambiente de produção recebendo workloads reais.

Dependendo do problema que surgir pode causar falha de leitura, bloqueios e esperas de dados no banco e nas tabelas, falhas em backups, falhas em index e execuções de queries mais longas que o normal.

A repartição de tabela consiste em: coluna, função e schema

Quando particionamos coluna, a coluna particionada é a que vai manter os valores conectados e agrupados em linhas de dados para a partição correspondente.

Colunas computadas devem ser definidas como persisted no particionamento.

A coluna particionada pode ser definida por dois parâmetros: RANGE LEFT e RANGE RIGHT

  • RANGE LEFT – determina os valores que pertencerão a partição da esquerda; último valor da partição na esquerda.
  • RANGE RIGHT – determina os valores que irão pertencer a partição da direita; Primeiro valor da partição na direita.

NOTA: o número de partições criadas será sempre n+1 (se criou três na função, terão quatro no banco).

Vale ressaltar que devido a criação da partição ter sido especificada como range right o primeiro valor deveria teoricamente começar pelo ano de 2012, isto acontece porque quando criamos a função.

Veja abaixo quando criamos uma partição com range right.

Localização das partições criadas:

Imagine que fôssemos criar uma partição baseada no mês para o banco Wideworldimporters_dw utilizando a versão modificada da tabela fact.sales.

Depois de criar a partição pela função é importante anexá-la em um filegroup. Uma partição só pode ser atribuída para um FG e um FG pode ter diversas partições.

Agora, veja na prática como damos utilidade a tabela particionada criando uma nova tabela fato, atribuindo a partição e inserindo dados do trimestre nela.

Teste na tabela particionada.

VIEW PARTICIONADA

Um outro recurso que pode ser mais econômico e performático para o banco é estabelecer views particionadas da tabela fato ou alguma outra tabela com grande volume de dados.

A solução das views particionadas vêm para minimizar a degradação que as funções de particionamento de tabela causam no banco comprometendo em muito o desempenho do banco.

Um outro ponto positivo é que criando as views particionadas com restrição de datas, otimizamos o engine do SQL Server tanto para consulta quanto para inserção.

Vamos ver na prática a criação da view particionada:

Primeiro irei criar uma tabela com um período de triênio para os anos 2013,14 e 15.


Após, realizar um insert puxando os dados da tabela fato [FACT].[SALE], os dados correspondentes.

Veja que na cláusula where limitamos o período para três anos reforçando a constraint da tabela.

Uma outra solução para esta situação poderia ser uma tabela para cada ano e unir em uma view com Union all as três tabelas.

No imagem abaixo temos o ano de 2014, bastaria criar para os anos de 2015 e 2016, mudando apenas o ano.

Puxar os dados da tabela fato original por cada ano desejado para as tabelas e após, criar a view com este comando abaixo:

E o resultado final.

Este post teve a intenção de apresentar brevemente o recurso de particionamento de tabelas com grandes volumes de dados ou que sofrem muitas alterações. Há alguns recursos complementares que irei abordar em breve.

Antes de implementar um destes recursos analise qual será o melhor para o seu cenário para não comprometer a performance e recursos, caso sejam escassos.

Irei deixar o link para quem quiser baixar o script e testar em casa e o banco utilizado foi o Wideworldimporters_DW.

Espero que gostem, saúde!

Publicidade