Perigos e Armadilhas do Particionamento - Etapa 2 – Parte 01

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. 

 

 

   

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.