Perigos e Armadilhas do Particionamento - Etapa 2 – Parte 01

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Neste artigo conheceremos perigos e armadilhas do particionamento.

Perigos e Armadilhas do Particionamento - Etapa 2 – Parte 01

por Arup Nanda 

Chaves de Partição Multi-colunadas (Multi-Column Partition Keys)

A maioria dos documentos, artigos, livros e outras publicações, falam sobre o uso de uma única coluna para chave de particionamento, mas que tal usar duas ou mais colunas? Definitivamente é possível, mas em tal caso, como deveríamos proceder?
 

Muitas pessoas têm a impressão de que especificando mais de uma coluna como chave de particionamento cria-se uma tabela particionada multidimensional. Por exemplo, se você tem uma tabela chamada "faixa de empregado" particionada em (DEPTNO, ZIPCODE), isso significa que são avaliados os valores de ambas as colunas quando se está decidindo sobre a colocação da linha em uma partição? 
Infelizmente, a resposta é não. 
 

A segunda coluna na chave de particionamento só é usada em alguns casos especiais. Ambos os valores não precisam ser satisfeitos para uma linha  ir para uma partição específica. A primeira coluna é avaliada antes; se satisfizer a condição, então a segunda coluna não é avaliada. Porém, se o primeiro valor da coluna não for totalmente satisfatório, a próxima coluna é considerada. 

Isto será mais bem entendido talvez utilizando-se um exemplo. Considere o seguinte:

create table ptab1

col1 number(10),
  col2 number(10),
col3 varchar2(20)
)
partition by range (col1, col2)
(
partition p1 values less than (101, 101),
partition p2 values less than (201, 201)
)

 

 

É uma percepção popular que quando uma linha é inserida, se ambos os valores de col1 e col2 são menores que 101, então vão para a partição P1; se os valores são menores que 201, porém maiores ou igual a 101, vão para a partição P2; caso contrário, vão para a partição PM. Em nosso exemplo, vejamos para qual partição serão direcionados. Aqui estão todas as linhas da tabela: 

select * from ptab1;
    COL1      COL2    COL3
--------- ---------- ------
    100        100        rec1
    102        102        rec2
    100        102        rec3
    102        100        rec4
    101        100        rec5
    101        101        rec6
    101        102        rec7
    201        100        rec8
    201        101        rec9
    201        102        rec10

Em quais partições os registros serão inseridos? Confiramos o primeiro: 

select * from ptab1 partition (p1);
   COL1        COL2        COL3
---------- ---------- ------
   100           100        rec1
   100           102        rec3
   101           100        rec5


O registro REC1 está na partição P1, como esperado. Mas REC3 deveria estar na partição P1? O valor da coluna COL1, que é 100, é menor que 101 e então satisfaz a condição. Porém COL2 tem 102, e é maior que 101, o valor de limite de COL2. Como é que COL2 foi para a partição P1? A razão é bastante simples: P1 é a primeira partição, o valor é avaliado pela primeira coluna (COL1) e satisfaz, assim o valor da coluna COL2 não é nem mesmo avaliado. O registro vai para P1, embora o critério de COL2 não seja satisfeito. 

Assim, se a segunda coluna, COL2, não é nem mesmo considerado em alguns casos, onde entraria em jogo e por que seria definido assim? Considere o registro REC5 no qual o valor de COL1 é 101, para a chave de particionamento é um valor incerto daquela coluna. Mas neste caso, é considerada a segunda coluna. Neste caso, o valor de COL2 é 100, menor que o valor de limite de COL2 na chave de particionamento (101); então, entra na partição P1. Veja os registros na partição P2. 

select * from ptab1 partition (p2);


  COL1         COL2      COL3
---------- ---------- -----
   102        102      rec2
   102        100      rec4
   101        101      rec6
   101        102      rec7
   201        100      rec8
   201        101      rec9
   201        102      rec10

Os registros REC2, REC4, e REC7 satisfazem as colunas e são, como esperado, inseridos na partição P2. Porém, para REC6, o valor de COL1 é 101, que é o valor limite para a primeira coluna da chave de particionamento. Assim, REC6 cai na consideração especial para chaves de particionamento multi-colunados. Porque o valor 101 de COL2 é maior que o valor limite da coluna COL2 da partição P1 (101), as linhas foram para a partição P2. 

Pela mesma lógica, para os registros REC8, REC9 e REC10, o valor de COL1 é 201 exatamente no limite para o valor daquela coluna na chave de particionamento. Porém, o valor de COL2 é menor que 201 e o valor limite daquela coluna em P2. Então, as linhas foram para a partição P2. 

O que acontece quando você insere uma linha com COL1 = 201 e COL2 = 201? 

Esta linha entrará na partição PM, desde que ambas as colunas não podem estar fora dos limites. Esquematicamente, a decisão para inserir em uma partição pode ser explicada pela figura abaixo.

 

pb_27_05_09_pic01.JPG 

  

Então o que acontece no caso da lista de particionamento no Oracle 9i, onde não há nenhum conceito de uma faixa e, portanto, não há nenhum valor de limite? Felizmente, a lista de particionamento não permite colunas múltiplas, assim esta situação não surge.

Aparentemente, considerando a confusão potencial sobre a colocação de linhas em partições, não vale a pena o uso de chaves de particionamento multi-colunadas. Porém, em alguns casos especiais, pode ser muito útil. Por exemplo, considere uma tabela chamada SALES com colunas SALES_YEAR, SALES_MONTH e SALES_DAY, em vez de uma única coluna chamada SALES_DATE. Isto é útil em alguma implementação de projeto de datawarehouse para habilitar dimensões e hierarquias. Em tal caso, você poderia usar uma chave de particionamento em todas as três colunas para efetivamente projetar as partições. 

Armadilha potencial: Tenha cuidado quando for definir colunas múltiplas como chave de particionamento. Se tiver que faze-lo, use casos de teste precisamente em torno dos valores limite. 

 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?