Menu de navegação

[brazaParticipante]

Boa tarde,

Eu tenho uma tabela “T” com 237.794.482 linhas (cerca de 30GB). Estou querendo migrar para uma tabela particionada no modo hash, pois, esta não apresenta uma chave de partição clara.

Uma empresa, do mesmo grupo, com uma tabela semelhante, realizou esse particionamento com 4 partições e obteve um ganho significativo no seu desempenho.

A equipe de DBAs daqui da empresa sujere seguirmos esse exemplo só que utilizando 10 partições.

Acontece que nenhum critério foi utilizado para determinar essa quantidade de partições. O que eu poderia analisar para determinar a quantidade de partições para essa tabela com essa quantidade de linhas ???

No ambiente de teste fiz esse particionamento (com 10 partições). Exportei a tabela com os dados e estou importando para a tabela particionada. O problema é que tá demorando muito para importar os dados. Já se passaram 1 dia e meio e ainda está em andamento essa importação. Essa demora se deve ao fato de eu ter criado muitas partições ??? Existe outros métodos mais rápidos de particionar uma tabela ???

Obrigado.

Braza.

[Marcos BragaParticipante]

Olá Braza,

Só uma opinião.

Trabalhei, recentemente, com uma tabela particionada com cento e poucos milhões de registros. E cada vez que tínhamos que efetuar algum teste de performance, era um parto, pois tudo demora. Infelizmente, a demora deve-se a capacidade de processamento do hardware (CPU + Storage); pois efetuando um teste com a mesma volumetria em uma importação de uma tabela particionada em um Exadata, o negócio é outro (a vida muda completamente), nesse ambiente tudo é mais rápido (isso deve-se ao conjunto de hardware implementado).

Portando não quero “botar a culpa” no banco de dados ou nos métodos de importação.

Agora…, algo que deve observar:

1. Está utilizando os parâmetros de otimização para importação? (como RECORDLENGTH ou BUFFER)
2. Apagou os índices antes de efetuar a importação? (dependendo do índice, pode demorar muito uma importação)
3. Invalidou as constraints antes da importação? (para tabelas grandes é bom invalidar as constraints para evitar que o banco tente validar qualquer dado importado)

Bom…, creio que esses três processos devem ser levados em consideração na hora de pensar em trabalhar com tabelas grandes, sejam elas particionadas ou não.

Outra coisa que deve levar em consideração é que nenhum DBA que se preze fica particionando tabela só por particionar. O particionamento deve ser pensado e estudado. E o mais importante: o particionamento depende muito das operações que são efetuadas com essa tabela. Essas operações que vão determinar o tipo de particionamento e as colunas candidatas para isso.

Nem sempre “particionar” uma tabela indica que uma query ficará mais rápida. Dependendo do procedimento executado, pode ficar mais lenta.

Só algumas palavras para pensar antes de particionar tabelas.

[]s
Braga

[brazaParticipante]

Valeu Braga pelas dicas.

Vou revisar com os analistas de sistemas o processo que apresenta desempenho ruim, pra definir o método de particionamento e aplicar as dicas das constraints na tabela.

Pelo menos já sei que é normal demorar um pouco esse tipo de trabalho.

Obrigado.

[Autor]

Posts