Estou mantendo o código de outra pessoa. Há um procedimento armazenado que é executado uma vez por dia ou semana (dependendo da configuração), que migra vários registros de uma tabela ativa para um arquivo. Mas não é um verdadeiro arquivo, pois existem vários processos ativos que incluem a tabela de arquivos em consultas SQL, devidamente indexada para o efeito.
Agora a história dessa história é que a mesa de arquivamento foi crescendo e crescendo, e o SP de arquivamento começou a demorar muito. Então, Alguém decidiu que seria uma boa ideia no início do SP descartar todos os índices na tabela de arquivo e recriá-los no final. Claro, recriá-los também leva eras, mas sem dúvida não tanto quanto inserir os novos registros com os índices no lugar.
Esta situação grita para mim: " ISSO É PECADO! " Parece errado, errado, errado brincar com índices em tempo de execução. Tenho certeza de que não é uma situação incomum, então qual é a maneira "correta" de lidar com uma situação como essa?
Em vez de descartar os índices, recomendo desativá-los e ativá-los. De preferência por meio de um cursor (ignorando o índice clusterizado) para que, se um índice for adicionado ou removido da tabela de arquivo, o procedimento armazenado não precise ser modificado.
Isso é bastante normal ao fazer grandes carregamentos de data warehouse, que é basicamente o que você está fazendo.
ATUALIZAÇÃO: Esfregue isso. Com a carga de trabalho muito pequena que você está fazendo, basta inserir os registros sem descartar e ler os índices. Se você estivesse movendo centenas de milhões de linhas, a remoção dos índices valeria a pena.
Acho que a pista para a resposta está na observação da minha pergunta:
Se a tabela de arquivo estiver sendo usada ativamente para consultas, não é um arquivo e todo o objetivo de arquivar registros foi perdido.
Todo esse problema remonta a uma má decisão de design. Originalmente, os registros deveriam ser arquivados por grupos de dados completos - em nosso domínio, isso é "pedidos" (como em pedidos feitos por um cliente). Assim, quando um pedido foi concluído, pago e não mais uma preocupação contínua, ele e todos os seus dados relacionados seriam arquivados. Então alguém apareceu e decidiu que precisávamos da capacidade de arquivar parcialmente um pedido, já que alguns pedidos tinham um ou dois itens que se arrastavam por meses, mas 99% do pedido estava completo, então eles queriam colocar esses 99% no arquivo . Mas, para obter todas as informações associadas a esse pedido, você precisa acessar o arquivo. Então, eles criaram uma exibição que abrange as tabelas ao vivo e arquivadas para o aplicativo de chão de fábrica usar. E claro, assim que você fizer isso, você violei o conceito de arquivo, ou seja, que deveria ser uma informação que você não precisa consultar regularmente. E depois de fazer isso, você inevitavelmente começa a seguir o caminho de erros como esse que afetam drasticamente o desempenho de seus sistemas de software de missão crítica.
Portanto, neste caso específico, seguirei o caminho de corrigir a decisão original de design ruim e parar com esse absurdo de arquivamento parcial. Em seguida, o arquivo pode fazer o que os arquivos devem fazer (ou seja, sentar e aproveitar a aposentadoria) e deixar as consultas ativas funcionando apenas nas tabelas ativas.