Particionamento de tabela para arquivamento de dados

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?

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.

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.

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

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