Sugestão para o design de banco de dados grande do SQL Server

Estamos criando um banco de dados no MSSQL 2008 R2 Standard em que armazenaremos um grande número de registros. Estimamos mais de 200 milhões de registros em uma tabela anualmente e, principalmente, estamos inserindo com muito poucas atualizações ou exclusões nos dados. É um sistema de arquivamento de dados onde inserimos registros históricos diariamente. Como geraremos diferentes tipos de relatórios sobre esse registro histórico, a pedido do usuário, teremos algumas preocupações e exigiremos informações e conselhos técnicos.

• Qual é a melhor maneira de gerenciar esse tipo de tabelas e banco de dados de arquivamento?

Aqui está a minha opinião:

1. Se você estiver com poucas atualizações / exclusões, poderá aumentar o fator de preenchimento de página para 95%. Isso economizará espaço e lê. Faça alguns testes embora.
2. Particione a tabela com base em uma categoria ampla como o ano.
3. Coloque essas partições em diferentes grupos de arquivos.

200 milhões de linhas por ano não são especialmente grandes (a menos que as linhas sejam extraordinariamente grandes). Você precisa prestar atenção aos sólidos princípios de design do banco de dados (normalização) e usar recursos padrão como indexação e particionamento. Obviamente, o hardware certo também é importante.

Não há informações suficientes aqui para dar conselhos específicos. Considere contratar alguém se achar que precisa de ajuda com o design e a implementação detalhados.

• Verifique se o seu design possibilita que suas inserções estejam sempre no final da tabela. Dica Índice agrupado.

• Apenas poucos índices não agrupados suportam os relatórios que você precisa fazer para mantê-los no mínimo. Esses relatórios são pré-gerados? se sim, considere a seguinte pergunta: Tudo bem se o relatório levar 2 horas para gerar? (sem índice) ou 1mins (com índice). Talvez seja bom deixar o relatório levar duas horas para ter um índice a menos? ou talvez não? Se o relatório não for bem gerado, isso é outra pergunta, já que os usuários não gostam de esperar e você pode precisar implementar mais índices para dar suporte a seus relatórios.

• De como você descreve esse banco de dados, parece que você espera muitas linhas e os dados serão adicionados e aumentados muito. Você considerou como fazer backup deste sistema? Eu meen a maioria dos dados será o mesmo e apenas adicionando novos? Não conheço os requisitos de negócios desse sistema, mas para mim parece que em um ou dois anos esse poderá ser um banco de dados de tamanho considerável e você poderá ter problemas para fazer muitos backups completos. Considere fazer um backup completo com logs de transação periódicos (semanais?) E diferenciais (diários?) E de transações (a cada hora). O tamanho pode ser um problema nos sistemas de arquivamento.