Particionamento de tabela para arquivamento de dados

13

Cenário:

  • dois bancos de dados: DB_A e DB_Archive com uma tabela muito grande chamada tableA.
  • todos os dias, os registros com mais de 60 dias são excluídos do DB_A e movidos para o DB_Archive, principalmente para deixar o item "separado" porque a tabelaA é muito consultada no DB_A para registros dos últimos 2 meses.

Eu quero me livrar desse processo porque é lento e consome muitos recursos. Estou pensando em implementar o particionamento de tabela no DB_A com uma função de partição em uma coluna de data e armazenar todos os registros <2 meses em uma partição e todos os registros> 2 meses em outra partição. Minhas perguntas:

  • esse cenário se comportará como se eu tivesse 2 bancos de dados diferentes? Se eu consultar minha tabelaA para registros> getdate () - 30, ela lerá a partição de arquivamento?
  • Eu deveria ter que particionar os índices também, certo?
  • Como faço para lidar com o fato de que amanhã minha função de partição "mudará", quero dizer, se eu criar a função hoje (2 de julho, seu intervalo será 2 de maio, mas amanhã será 3 de maio). Posso criar uma função de partição dinâmica?
sql-server sql-server-2005 partitioning Diego
fonte
Eu não acho que uma função dinâmica seja uma boa idéia, mesmo que permitida (acho que não) ... podemos entrar em mais detalhes em breve, mas acho que você provavelmente deve particionar com base na data do calendário e sair uma partição de cada vez ... Mas há uma variedade de opções aqui.
JNK
Criei um exemplo seguindo o que você deseja fazer no ano passado. Foi um caso um tanto especial em que queríamos manter x dias de dados em uma matriz rápida (cara) e mover os dados de arquivo para um armazenamento mais barato. Se eu puder higienizar um script de exemplo, eu o publicarei, caso contrário, será apenas um resumo do processo.
MarkJacky-Smith
oi marca, sim, por favor, e se você pode compartilhar sua experiência também. foi bem sucedido?
Diego
Funciona, mas acabou sendo desnecessário (seguimos uma rota mais simples). Talvez você possa expandir por que o limite de 60 dias existe no seu caso? Ajudaria todos a apontar na direção certa.
Mark-Storey-Smith

Respostas:

6

Com o particionamento, você teria que fazer uma partição por dia, o que coloca o limite de 1000 partições pré-SQL 2012 em uma nova perspectiva, pois permitiria apenas 3 anos de arquivamento. Com o SQL Server 2012, você obtém 15000 partições, o que é suficiente para 1 partição por dia.

Todos os dias você adicionaria uma nova partição. Se você deseja mover a partição do 61º dia anterior, pode fazê-lo com eficiência, mas ainda é uma operação offline. Consulte Mover uma partição para um grupo de arquivos diferente com eficiência .

Todos os seus índices precisariam ser alinhados, consulte Diretrizes especiais para índices particionados .

Comprar no particionamento não é uma decisão fácil e pode ser uma grande mordida para mastigar ... consulte Como decidir se você deve usar o particionamento de tabela . Especificamente, você não deve esperar melhorias no desempenho do particionamento. Você deve abordar problemas de desempenho no horário mais seriado, agrupando por data e hora.

Remus Rusanu
fonte
O novo limite está disponível no 2008 SP2 e 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
Jon Seigel
@ Jon: a implementação do SP2 em 2008, 2008R2 SP1 vem com um grande aviso . As explained in this white paper, there are implications on certain features, including performance. . O suporte ao SQL 2012 vem sem avisos.
Remus Rusanu
Obrigado por apontar isso; é verdade que existem algumas advertências para usá-lo no 2008/2008 R2, mas é uma opção disponível, se necessário.
Jon Seigel
Obrigado por seu comentário. Vou ler o comentário do material mais tarde
Diego
2

Não sei se a função de partição pode ser dinâmica, mas duvido. Algumas opções para você sem seguir esse caminho:

1 - Partição no calendário DATE e saia da partição mais antiga todos os dias

2 - Crie uma visualização que filtre na data e aponte todas as suas consultas existentes para ela (isso pode ser facilmente gerenciado renomeando a tabela subjacente para outra coisa e nomeando a visualização como é o nome da tabela atual). Isso pode ser otimizado também com alterações de índice.

Lembre-se de que a primeira opção acima funcionará MUITO melhor se você usar o campo de data em suas consultas. Caso contrário, ainda será mais rápido que o processo atual, mas as consultas não terão uma grande melhoria. O particionamento em geral funciona melhor se você pode filtrar o campo de partição e o otimizador sabe em qual partição procurar.

JNK
fonte
Eu gostaria de evitar as operações manuais "todos os dias"
Diego
2

Aqui está o que deve funcionar para você: DB_A - tableA com uma partição diferente para cada um dos últimos 60 dias - stagingTable para mover dados da partição mais antiga

DB_Archive tableA - armazena todos os dados com mais de 60 dias. (não particionado)

Processo: 1. antes do final do dia: altere a função da partição - divida o intervalo para adicionar uma nova partição para o novo dia. (NB: em vez de criar partições para "data de hoje + 1 dia", convém dar alguns passos à frente. Por exemplo: "data de hoje + 5 dias"

  1. Após o final de cada dia, você primeiro alterna a partição mais antiga em DB_A.tableA para DB_A.stagingTable; Mesclar as partições mais antigas.

  2. Importe dados de DB_A.stagingTable para DB_Archive.tableA. Finalmente trunacte DB_A.stagingTable

O acima é chamado Rolling Window e é um cenário bastante comum para os VLDBs. Consulte este white paper da Microsoft sobre particionamento: Tabela de partição e estratégias de índice ou tente isso especificamente no cenário Sliding Window

Dharmendar Kumar 'DK'
fonte
0

Você pode usar a abordagem dinâmica de arquivar e limpar dados no SQL Server. Por favor, siga o link abaixo para isso.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html

Asif Ghanchi
fonte
1
Você poderia incluir na sua resposta os principais pontos desse post? Você sabe, os links vêm e vão e, quando vão, sua postagem terá apenas um link inoperante.
Dez17