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      COL2COL3

--------- ---------- ------

    100100        rec1

    102102        rec2

    100102    rec3

    102100    rec4

    101100    rec5

    101101        rec6

    101102        rec7

    201100    rec8

    201101    rec9

    201102     rec10

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

select * from ptab1 partition (p1);

   COL1    COL2     COL3

---------- ---------- ------

   100   100   rec1

   100102        rec3

   101100        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

---------- ---------- -----

   102102 rec2

   102100 rec4

   101101 rec6

   101102 rec7

   201100 rec8

   201101 rec9

   201102 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.