Eu tenho uma pergunta de arquivamento.
Temos um banco de dados de histórico usado para arquivar registros antigos do nosso sistema principal e o aplicativo sabe consultá-lo
No entanto, torna-se muito grande.
Eu gostaria de reinicializar o History DB. Minha ideia foi - em poucas palavras:
Feche este banco de dados,
Torne-o APENAS LEITURA,
Renomeie para *antigo
Crie um banco de dados de histórico semelhante (mesma estrutura/tabelas).
Com a ajuda de visualizações/sinônimos, o aplicativo poderá consultar os dados de ambos os bancos de dados sem alteração de código.
Minha pergunta é sobre a última parte
Isso funcionará?
Posso criar uma visualização/sinônimo (a visualização consultará ambos os bancos de dados da tabela com UNION ALL) que será o nome do objeto padrão em vez do nome da tabela original real?
Nosso principal problema são os backups, como o arquivamento é feito diariamente, precisamos também fazer backup desse banco de dados, e como é um banco de dados enorme, é uma perda de tempo e recursos.
Obrigado, Rony.
A maneira integrada de reduzir o tamanho do backup para VLDBs com dados somente leitura é particionar suas tabelas grandes, colocando partições mais antigas em grupos de arquivos somente leitura e, em seguida, fazer backups pouco frequentes dos grupos de arquivos somente leitura (ou banco de dados inteiro), combinados com backups regulares dos grupos de arquivos de leitura e gravação. Em seguida, você pode executar uma restauração fragmentada .
Sim, normalmente você pode substituir uma tabela por uma visualização sem alterar o aplicativo, a menos que o aplicativo faça algo incomum. O risco está no desempenho, pois a exibição UNION ALL em vários bancos de dados não tem o mesmo desempenho.
Você pode tentar usar a compactação columnstore nas tabelas grandes no banco de dados de arquivo morto.
Sim, você pode criar uma visão/sinônimo para consultas entre bancos de dados.
aqui estão alguns efeitos colaterais que vêm à mente ao implementar isso:
Restrições/relações entre as duas tabelas nos dois bancos de dados não funcionarão. Isso pode resultar em chaves primárias duplicadas, referências de chave estrangeira não funcionando, ....
...
Um exemplo de uma visão sobre duas tabelas em dois bancos de dados
Consultando esta visão recém-criada no novo banco de dados
Resultado
Uma alternativa
A melhor alternativa seria David Browne - a resposta da Microsoft.
Se isso não for uma opção, aqui está uma solução menos ideal:
Para fazer backup dos grupos de arquivos read_write:
Isso resulta na única vantagem real de dividi-lo em vários bancos de dados quando na edição padrão seria restaurar primeiro o banco de dados não histórico, tornando-o acessível para consultas enquanto o banco de dados histórico está restaurando.