Eu tenho uma tabela de log que atualmente contém milhões de registros. Eu quero habilitar o particionamento nessa tabela, então o que eu fiz por enquanto é:
- Criou uma função de partição e um esquema de partição.
- Criou uma tabela vazia com a mesma estrutura nesse esquema de partição.
- Dados copiados da tabela de log atual deste ponto no tempo (vamos chamá-lo de
T1
) voltando para a nova tabela particionada.
As próximas etapas seriam copiar os últimos registros restantes e renomear T1
as Tnow
duas tabelas para que o aplicativo comece a gravar na nova tabela particionada.
Claro que a tabela de log é acessada com frequência, então minha pergunta é:
Como posso ter certeza de que não perderei nenhum dado durante esse processo? Posso fazer com que os usuários não percebam nada ou preciso necessariamente parar o aplicativo por esse breve período? Ou posso apenas bloquear essa tabela para que o aplicativo continue em execução? Se sim, como?
Considere a criação de uma nova tabela com a estratégia de particionamento desejada e adicione uma exibição em ambas as tabelas que faça uma união de todos. Faça com que as pessoas usem a visualização e escrevam gatilhos em vez de nas tabelas e visualizações subjacentes.
As inserções devem ser enviadas para a nova tabela, as atualizações devem mover os dados para a nova tabela e as exclusões devem ser aplicadas a ambas as tabelas.
Em seguida, faça movimentos em lote em segundo plano, movendo tantos registros de cada vez quanto possível para a nova tabela. Você ainda pode ter problemas de simultaneidade enquanto isso está acontecendo e alguns planos de execução terríveis, mas permite que você fique online enquanto os movimentos estão acontecendo.
Idealmente, você inicia o processo em uma tarde de sexta-feira para minimizar o efeito sobre os usuários finais e tenta fazê-lo antes da manhã de segunda-feira. Uma vez que esteja no lugar, você pode mudar a visão para apontar apenas para a nova mesa, e os terríveis planos de execução desaparecem. Idealmente.
Para evitar que os gatilhos sejam disparados quando os dados estiverem sendo migrados em lotes, observe o número de linhas nas tabelas excluídas/inseridas no gatilho e ignore as atividades se estiverem próximas ao número de linhas em seu lote.
Quanto mais transparente você quiser que isso seja para seus usuários finais, mais trabalho (e testes) será necessário. Isso vale especialmente se você estiver usando particionamento: muitas vezes as pessoas acreditam que isso tornará todas as suas consultas mais rápidas e, no entanto, algumas delas acabam muito mais lentas. Tente testar o máximo de sua carga de trabalho em um servidor de desenvolvimento com as tabelas particionadas, se puder.
Você pode querer considerar uma tabela de log menor e uma tabela de arquivo maior para fazer o particionamento de que você falou:
Aqui no hospital onde trabalho tivemos o mesmo problema há uns 15 anos. As pessoas estavam tentando acessar o log de auditoria para relatórios enquanto o log de auditoria estava sendo bloqueado por esses relatórios. Portanto, separamos o relatório do log, separando o log em outro banco de dados para fins de relatório. Para evitar falhas no serviço, configuramos um cronômetro para separar porções dos dados na nova tabela - 100.000 registros possíveis por vez. No seu caso, depois de obter os dados para sua nova tabela, você pode particionar como quiser.
Usando essa estratégia, sua tabela de log original sempre permanecerá pequena e sua tabela de arquivos aumentará e será a que você deseja particionar. Para nós, foi um benefício imenso separar o registro atual das informações históricas. Eu acho que você precisará pesar esse benefício para si mesmo. Mas, pelo menos, você ainda poderá gravar na tabela original sem afetar o registro em log que está acontecendo - quando você exporta os dados para o banco de dados/tabela de arquivo.
Os usuários que fazem relatórios históricos, no seu caso, podem perceber porque têm uma nova tabela para acessar. Mas o registro continuará na tabela original sem impedimentos.
Aqui está o código, minhas desculpas, é um pouco duro - onde newaudit é o banco de dados de log e audit é o banco de dados de arquivamento. (É claro que você gostaria de testar isso em um ambiente de desenvolvimento antes de qualquer produção entrar em vigor):