none
Particionamento de tabela e índice RRS feed

  • Pergunta

  • Boa tarde pessoal,

    Estou enfrentando problema de reindexão/manutenção de algumas tabelas históricas no data warehouse da empresa onde trabalho. Exemplo: possuímos uma tabela que contas a receber pelo qual mantemos o histórico diário das cargas (snapshot) que atingem 5.000.000/dia. A data da carga/foto faz parte da chave primária. Sempre excluímos o histórico de dados dessa tabela deixando os últimos 4 meses de foto. Hoje, essa tabela possui 780 milhões de linhas, com 215GB de dados + 23GB de índice. Possuo 2 discos separados (dados e log) em um servidor win2003 com 32gb de ram. Acontece que a janela de tenho para manutenção jah não é suficiente.

    Então, a pergunta é a seguinte...Mesmo tenho um único disco para dados, o particionamento podería ser a solução? Caso sim, alguma dica de como ficaría a função, considerando a quantidade de registros carregados/dia e também considerando que as fotos com mais de 4 meses são mensalmente deletadas...

    att.
    Rafael Melo

    • Movido Gustavo Maia Aguiar segunda-feira, 7 de março de 2011 19:16 (De:SQL Server - Desenvolvimento Geral)
    segunda-feira, 7 de março de 2011 19:07

Respostas

  • Boa Tarde,

    Ao contrário do que muito gente pensa, a utilidade do particionamento não está relacionada a desempenho, mas principalmente a auxiliar tarefas administrativas como a sua. Se você particionar sua tabela por exemplo, poderá reindexar várias partições em paralelo ou ainda controlar quando a reindexação de cada partição acontece o que incorre em algumas outras vantagens.

    Agora antes de mais nada, é preciso saber que manutenções você está realizando que estão extrapolando a janela.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    segunda-feira, 7 de março de 2011 19:15
  • Boa Tarde Rafael,

    O particionamento pode sim ajudá-lo muito em tarefas de expurgo. Se você faz a exclusão mensalmente, o ideal seria particionar por um RANGE mensal. Quando for excluir os dados, ao invés de executar um comando de DELETE que provoca grande atividade de log e bloqueios, você irá transformar a partição com os dados a serem excluídos em uma tabela com o comando SWITCH. Isso irá retirar os dados da partição para uma tabela. Posteriormente basta rodar um comando de DROP e excluir milhares de dados em alguns poucos segundos.

    Se o seu índice clustered não favoreça cenários de fragmentação, é possível que você nem tenha de efetuar um REBUILD. No máximo para os índices NonClustered, mas apenas 23GB irá durar no máximo algumas horas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    segunda-feira, 7 de março de 2011 20:06
  • Oi Rafael,

    Se você possui apenas um disco para dados, então é possível afirmar que em princípio, dividir seu banco em FILEGROUPs ou em mais arquivos não irá prover um melhor desempenho. Isso só seria verdade se as requisições de I/O estivessem além da vazão do seu storage, mas é pouco provável para cenários de DW embora seja possível.

    A criação de mais Filegroups ou mais arquivos não influencia o particionamento. Você pode colocar todas as partições no mesmo FILEGROUP ou em FILEGROUPs distintos se preferir. Como o I/O não parece estar sendo o seu problema no momento, eu sugiro implementar a mudança para o particionamento e posteriormente avaliar o uso de mais FILEGROUPs.

    Vale a pena lembrar que a conversão de uma tabela para uma partição ou vice-versa só é totalmente transparente e sem I/O se estiverem no mesmo FILEGROUP.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    terça-feira, 8 de março de 2011 01:39

Todas as Respostas

  • Boa Tarde,

    Ao contrário do que muito gente pensa, a utilidade do particionamento não está relacionada a desempenho, mas principalmente a auxiliar tarefas administrativas como a sua. Se você particionar sua tabela por exemplo, poderá reindexar várias partições em paralelo ou ainda controlar quando a reindexação de cada partição acontece o que incorre em algumas outras vantagens.

    Agora antes de mais nada, é preciso saber que manutenções você está realizando que estão extrapolando a janela.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    segunda-feira, 7 de março de 2011 19:15
  • Boa tarde Gustavo,

    A tarefa que estou tendo problemas é mesmo com o rebuild/reorganize. Conforme disse, excluo mensalmente dados históricos dessa tabela, e posteriormente executo o rebuild/reorganize dos índices. Esse processo estah levando dias para executar... Nesse cenário, com o particionamento, na sua opinião, qual sería um range apropriado?? Mes?

    att.
    Rafael Melo

    • Editado Rafael S. Melo segunda-feira, 7 de março de 2011 19:36 detalhe
    segunda-feira, 7 de março de 2011 19:22
  • Boa Tarde Rafael,

    O particionamento pode sim ajudá-lo muito em tarefas de expurgo. Se você faz a exclusão mensalmente, o ideal seria particionar por um RANGE mensal. Quando for excluir os dados, ao invés de executar um comando de DELETE que provoca grande atividade de log e bloqueios, você irá transformar a partição com os dados a serem excluídos em uma tabela com o comando SWITCH. Isso irá retirar os dados da partição para uma tabela. Posteriormente basta rodar um comando de DROP e excluir milhares de dados em alguns poucos segundos.

    Se o seu índice clustered não favoreça cenários de fragmentação, é possível que você nem tenha de efetuar um REBUILD. No máximo para os índices NonClustered, mas apenas 23GB irá durar no máximo algumas horas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    segunda-feira, 7 de março de 2011 20:06
  • Gustavo, muitíssimo obrigado pela sua ajuda..., a sua idéia se encaixa perfeitamente no meu cenário. Gostaría que me tirasse mais uma(s) dúvida, antes de encerrar essa thread, se possível.

    Com relação a criação de File groups e arquivos secundários. Como eu disse, tenho apenas um disco para dados, nesse cenário, sería desnecessário criar mais que um file group? Sobre os arquivos secundários, sería interessante eu criar 12 arquivos, considerando que eu vou utilizar um range mensal?

     

    att.
    Rafael Melo

     

    segunda-feira, 7 de março de 2011 20:26
  • Oi Rafael,

    Se você possui apenas um disco para dados, então é possível afirmar que em princípio, dividir seu banco em FILEGROUPs ou em mais arquivos não irá prover um melhor desempenho. Isso só seria verdade se as requisições de I/O estivessem além da vazão do seu storage, mas é pouco provável para cenários de DW embora seja possível.

    A criação de mais Filegroups ou mais arquivos não influencia o particionamento. Você pode colocar todas as partições no mesmo FILEGROUP ou em FILEGROUPs distintos se preferir. Como o I/O não parece estar sendo o seu problema no momento, eu sugiro implementar a mudança para o particionamento e posteriormente avaliar o uso de mais FILEGROUPs.

    Vale a pena lembrar que a conversão de uma tabela para uma partição ou vice-versa só é totalmente transparente e sem I/O se estiverem no mesmo FILEGROUP.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Rafael S. Melo quarta-feira, 9 de março de 2011 11:58
    terça-feira, 8 de março de 2011 01:39