No momento, estamos com alguns problemas de desempenho, já que nosso banco de dados está ficando muito grande. Existem dados armazenados dos últimos 10 anos e não vejo uma razão pela qual os dados com mais de 2 anos tenham que ser armazenados nas mesmas tabelas que os novos dados.

Agora, como não tenho uma experiência muito profunda na administração de bancos de dados, estou procurando as melhores maneiras de arquivar dados antigos.

Informações

• Existem cerca de 310'000'000 registros no banco de dados no total.

• O banco de dados precisa de 250 GB no disco rígido.

• A versão do servidor é o SQL Server 2008 com nível de compatibilidade SQL Server 2005 (90), mas estamos planejando atualizar para o SQL Server 2012 em breve

Eu pensei em duas possibilidades:

Novo banco de dados

Crie um banco de dados semelhante ao do servidor de produção e insira todos os dados antigos no novo banco de dados.

• Desvantagem: como os servidores vinculados não são permitidos em nosso ambiente, seria difícil associar os dados antigos, se necessário

Esquema de histórico

Crie um novo esquema fe [hist] com as mesmas tabelas que no banco de dados de produção. Insira todos os dados antigos nessas novas tabelas no novo esquema.

• Vantagem: união fácil, se dados antigos forem necessários no futuro

• Você prefere uma das soluções em detrimento da outra?
  • Por quê?
• Existem melhores possibilidades?
• Existem ferramentas existentes com as quais essa tarefa é facilmente possível?
• Quaisquer outros pensamentos?

desde já, obrigado

Editar

Pergunta adicional:

A tabela de archive recém-criada também precisaria de chaves primárias / estrangeiras?

Ou eles deveriam apenas ter as colunas, mas sem chaves / restrições?

Penso que a resposta para muitas das suas perguntas é que depende. Quais problemas de desempenho você está tendo? Parece incomum que um banco de dados tenha problemas de desempenho apenas do tamanho de 250 GB.

Talvez suas consultas estejam executando verificações de tabela em toda a tabela de fatos, mesmo quando apenas uma pequena parte (por exemplo, o último ano) do período é necessária? Se houver uma consulta específica mais importante para otimizar, considere postar seu esquema, consulta e um plano de execução real em outra pergunta para ver se ela pode ser otimizada.

Você prefere uma das soluções em detrimento da outra?

Geralmente, prefiro o banco de dados de histórico e acho que Guy descreve boas razões para isso em sua resposta .

A principal desvantagem que vejo para um banco de dados histórico (ao contrário de um esquema) é que você não pode mais usar chaves estrangeiras para sua tabela de arquivamento. Isso pode ser bom para você, mas é algo para estar ciente.

A desvantagem que você listou para esta abordagem não é precisa; você poderá consultar facilmente bancos de dados no mesmo servidor e o otimizador de consultas geralmente lida muito bem com consultas entre bancos de dados.

Existem melhores possibilidades?

Se você precisar consultar regularmente os dados do arquivo morto, considere particionar a tabela por data . No entanto, essa é uma grande mudança que pode trazer muitas implicações de desempenho, tanto positivas (por exemplo, eliminação de partições, carregamento de dados mais eficiente) quanto negativas (por exemplo, buscas mais lentas em singleton, maior potencial de distorção de encadeamento em consultas paralelas). Portanto, eu não tomaria essa decisão de ânimo leve se fosse um banco de dados muito usado.

A tabela de archive recém-criada também precisaria de chaves primárias / estrangeiras? Ou eles deveriam apenas ter as colunas, mas sem chaves / restrições?

Eu recomendaria ter pelo menos a chave primária e índices exclusivos para que você possa obter os benefícios de integridade de dados que eles oferecem. Por exemplo, isso impedirá que você insira acidentalmente um ano de dados na tabela de histórico duas vezes. E, como benefício colateral, pode melhorar o desempenho se você precisar consultar a tabela de histórico.

Quaisquer outros pensamentos?

Como você está usando a edição Enterprise e planejando atualizar para o SQL 2008+, considere a compactação de dados para esta tabela. A compactação certamente reduzirá o espaço em disco, mas, dependendo dos recursos de disco e CPU do servidor, também poderá melhorar o desempenho da consulta para leituras, reduzindo a E / S do disco e melhorando a utilização da memória (mais dados cabem no cache ao mesmo tempo).

Eu preferiria ter um esquema de histórico ou um segundo banco de dados histórico em vez de um servidor vinculado a qualquer dia. Isso economiza custos de licença e é mais fácil de gerenciar e consultar. Você também pode usar um esquema mais simples e eliminar alguns índices, tornando o banco de dados menor

Mas como você possui a edição corporativa, você tem a terceira opção, que é particionar suas tabelas , que, quando implementadas, facilita o arquivamento dos dados e a consulta dos dados antigos é transparente para os usuários e você não precisará fazer alterações no aplicativo .

Na minha experiência, um segundo banco de dados seria a escolha preferida por dois motivos.

1. Você pode restaurar os dados de um backup histórico e soltar as tabelas e índices de que não precisa.
2. Você pode movê-lo para um servidor diferente para fins de geração de relatórios, pois possui os benefícios de não usar os recursos do servidor principal

Você ainda precisaria excluir todos os dados históricos do banco de dados primário, mas isso poderia ser agendado.

Ignorando a licença por enquanto, pois não é onde eu passo meu tempo.

IMHO, banco de dados de arquivamento é mais simples de implementar e manter. São entidades distintas e pouco acopladas. A movimentação de dados e os controles de carga / recurso têm limites claros. É fácil mudar para uma instância ou servidor diferente para melhor gerenciamento de desempenho e custo, não é um problema importante. Observe que o mais simples! = Esforço mais barato ou menos. Na verdade, ele tem um pouco mais de tarefas, mas todas são tarefas simples, com duas exceções importantes:

1. aplicação de restrições - não há restrições entre bancos de dados no SQL Server; portanto, você precisa decidir se isso é um disjuntor.
2. consultas entre bancos de dados usam consultas distribuídas que ainda dependem do OLEDB, que está obsoleto. Isso significa que você pode encontrar problemas com novos tipos de dados e, se encontrar problemas de desempenho, é improvável que eles sejam corrigidos

O esquema de arquivamento ou apenas a tabela de arquivamento é um pouco mais complexo de implementar, mas muito mais fácil de usar. Todos os objetos no mesmo banco de dados significa que você não precisa replicar e manter os controles de acesso. Não há consultas entre bancos de dados, facilitando o ajuste, o monitoramento, a solução de problemas, etc.

O particionamento de tabela é uma ótima solução e oferece muitos dos benefícios de uma tabela / esquema de arquivamento, mas fornece transparência aos usuários / consultas. Dito isto, é o mais complexo de implementar e requer cuidados contínuos que não são fáceis para iniciantes.

Algumas considerações importantes:

• As consultas retornam dados históricos / frios regularmente ou os dados frios são acessados ​​com pouca frequência?
• Os dados históricos são imutáveis ​​ou são atualizados / excluídos regularmente?
• As linhas de 310 m são "moderadas" (assumindo tudo em uma tabela), dependendo do tamanho da linha. Você tem dados de tamanho de linha? Quantos GB são essa linha de 310m?
• Qual é a taxa de crescimento dessa tabela?
• Você consegue modificar o código do aplicativo e suas consultas SQL?

Essas são considerações importantes, pois podem ter um impacto significativo na solução escolhida ou até permitir determinadas soluções. Por exemplo, se seus dados históricos são modificados / atualizados regularmente (mais de uma vez por semana), o uso de um banco de dados separado significa que você deve usar o DTC para essas consultas ou gerenciar manualmente a segurança da transação (não trivial para garantir sempre a correção). O custo é significativamente maior que os dados históricos imutáveis.

Além disso, se você estiver pensando em atualizar, considere 2016 e o ​​novo recurso Stretch Database: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Eu preferiria dividir o banco de dados em um banco de dados lógico separado pelos seguintes motivos:

1. Requisitos de Recursos

Dividindo isso em um banco de dados separado, ele pode ser armazenado em uma unidade diferente e monitorado em uma taxa diferente dos principais dados de produção.

2. Desempenho

Ao dividir os dados em um banco de dados separado, o banco de dados principal de produção é reduzido em tamanho, ajudando o desempenho geral.

3. Backups mais simples

O backup dos dados arquivados pode não ser considerado tão essencial quanto os registros 'ativos / atuais' no banco de dados SQL principal. Isso pode significar que os dados arquivados podem ser copiados com menos frequência. Também devido à natureza seqüencial de como os dados arquivados são registrados, pode ser possível fazer backup de seções do banco de dados arquivados uma vez e nunca mais. Por exemplo, uma vez que os dados do arquivo morto sejam gravados no banco de dados do arquivo morto de alterações para 2014, nunca mais haverá nenhuma alteração nesses dados.

Nota: Acho que a resposta para muitas de suas perguntas depende de suas circunstâncias, natureza dos dados e dos problemas de desempenho que você estava tendo.