SQL Server 2005/2008 - vários arquivos / grupos de arquivos - quantos? Por quê?

Sou um desenvolvedor no coração - mas, de vez em quando, um cliente não tem um DBA decente para lidar com esses problemas, então sou chamado para decidir ....

Quais são suas estratégias / práticas recomendadas para lidar com um banco de dados do SQL Server de tamanho razoável (qualquer coisa maior que Northwind ou AdventureWorks; aproximadamente 2 a 4 GB de dados, mais índices etc.) - você usa vários arquivos / grupos de arquivos?

Se sim: quantos? E porque?

Quais são os seus critérios para decidir quando sair da abordagem "um grupo de arquivos para tudo":

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Se você usa vários grupos de arquivos, quantos você usa? Um para dados, um para índice, um para log? Vários (quantos) para dados? Quais são as suas razões para sua escolha - por que você usa esse número exato de grupos de arquivos :-)

Obrigado por todas as dicas, sugestões, pensamentos!

Marc Cheers

A regra básica é separar arquivos em volumes diferentes para evitar contendas, no entanto, a quantidade de ganho de desempenho que você obtém varia muito de acordo com o subsistema de E / S e a carga de trabalho. Por exemplo, vários arquivos em um único eixo físico serão prejudiciais no desempenho, mas o mesmo arranjo com o volume em um SAN LUN com várias centenas de unidades de matrizes RAID 10 pode ser bom. Os contadores de comprimento de fila de disco são seus amigos como a maneira mais simples de saber se você tem um gargalo de E / S.

Você está observando os padrões de E / S nos bancos de dados - somente leitura, principalmente leitura, leitura e gravação, principalmente gravação e somente gravação - e baseando-se nisso. Você também precisa escolher o nível RAID correto e verificar se as compensações da partição do disco, o tamanho da faixa RAID e o tamanho da unidade de alocação NTFS estão definidos corretamente. Algumas pessoas gostam de separar índices não clusterizados em um grupo de arquivos separado, mas os ganhos de desempenho aqui variam exatamente como expliquei acima.

Além do desempenho, você deve considerar a capacidade de gerenciamento e a capacidade de recuperação. Ter um único arquivo de dados monolítico para um banco de dados de 100 GB significa que sua unidade de restauração é esse arquivo. Dividi-lo em 4 grupos de arquivos de 25 GB significa que você pode usar a disponibilidade parcial do banco de dados e a restauração fragmentada para ter que restaurar apenas um único grupo de arquivos caso seja danificado. Ao particionar tabelas e índices em vários grupos de arquivos, você também pode limitar quais partes do banco de dados são afetadas pelas operações de manutenção (por exemplo, remoção da fragmentação do índice).

O Tempdb é um caso totalmente especial, e eu vou apontar para você em um post no meu blog que explica tudo sobre o porquê e como dividir o tempdb - existem muitos conceitos errados por aí.

Sem fornecer uma recomendação de 'generalização abrangente' aqui, mostrarei vários documentos e postagens de blog para você ler:

• White paper: Design físico de armazenamento de banco de dados
• White paper: Práticas recomendadas de E / S de pré - implantação
• White paper: Tabelas e índices particionados no SQL Server 2005

• White paper: Disponibilidade parcial do banco de dados

• Postagem no blog: Equívocos em torno do TF 1118 (layout tempdb)

• Postagem no blog: Os deslocamentos de sua partição de disco, tamanhos de faixa RAID e unidades de alocação NTFS estão definidos corretamente? (com link para o white paper da partição de disco)

Espero que isso ajude você!

A decisão de dividir um banco de dados em diferentes grupos de arquivos deve ser tomada após a análise do tamanho atual e do crescimento futuro de suas tabelas. Na minha opinião, a menos que você tenha um banco de dados grande ou tabelas com milhões de linhas, considere cuidadosamente os prós e os contras, pois você pode acabar criando mais problemas de desempenho do que corrige.

Existem alguns cenários que podem ser interessantes sob certas premissas:

• 2 grupos de arquivos: dados e índice
• 3 grupos de arquivos: tabelas somente leitura, tabelas de leitura e gravação, índice
• vários grupos de arquivos: somente leitura, leitura e gravação, índice, tabela de chaves 1, tabela de chaves 2, ...

Você precisa analisar seu ambiente para decidir se os grupos de arquivos ajudarão com suas necessidades de crescimento, uso e desempenho do SQL Server.

Alguns indicadores-chave para mudar para vários grupos de arquivos ( deste artigo ):

• Quando o enfileiramento de discos está causando problemas de aplicativo e experiência do usuário
  • Se for esse o caso, considere aproveitar unidades de disco adicionais com novos grupos de arquivos que abrigam tabelas intensivas de E / S
• Quando tabelas específicas são 10% ou mais do banco de dados
  • Se for esse o caso, considere mover essas tabelas particularmente grandes para grupos de arquivos separados em unidades de disco subjacentes separadas
  • Dependendo do tamanho da tabela em proporção ao restante das tabelas, considere a criação de um grupo de arquivos para tabelas individuais
• Quando o índice não clusterizado e o espaço de dados são iguais em tabelas grandes
  • Se for esse o caso, considere dividir os dados e o índice em cluster dos índices não em cluster
• Quando existe uma porcentagem quase igual de dados somente leitura e leitura / gravação no banco de dados
  • Se for esse o caso, considere dividir os dados somente leitura em um grupo de arquivos separado como dados de leitura e gravação
• Quando houver tempo insuficiente para executar a manutenção do banco de dados
  • Se for esse o caso, considere dividir as tabelas grandes em grupos de arquivos separados em diferentes discos subjacentes e execute a manutenção em paralelo
• Quando o negócio ou aplicativo estará mudando significativamente e os dados crescerão a uma taxa muito maior
  • Se for esse o caso, considere trabalhar com os usuários para entender o potencial crescimento
• Quando os dados arquivados residem no mesmo banco de dados que os dados de produção
  • Se for esse o caso, considere grupos de arquivos separados ou uma ou mais das técnicas desta dica - Arquivando dados no SQL Server

Se você achar que os grupos de arquivos podem melhorar o desempenho do banco de dados, escreva o código e teste o processo em um ambiente de preparação antes de implementar as alterações nos servidores de produção. Prepare algumas medidas antes de implementar as alterações e compare-as antes / depois. Como esses processos podem consumir muitos recursos e consumir muito tempo, execute esses procedimentos durante um período de manutenção.

Não se esqueça, ao criar novos objetos (tabelas e índices), verifique se os objetos foram criados no grupo de arquivos correto para garantir o desempenho esperado e validar periodicamente se os objetos do banco de dados estão nos grupos de arquivos corretos e corretos conforme necessário.