grupos de arquivos / arquivos padrão do SQL Server 2005 para desempenho em SAN

Question

Enviei isso para o estouro de pilha ( aqui ), mas percebi que deveria estar em serverfault. então peço desculpas pelo lançamento incorreto e duplicado:

Ok, acabei de participar de um curso do SQL Server e discutimos os cenários de uso de vários grupos de arquivos e arquivos quando em uso em locais RAID e discos locais, mas não tocamos em cenários de SAN, então minha pergunta é a seguinte;

Atualmente, tenho um banco de dados de 250 gig em execução no SQL Server 2005, onde algumas tabelas têm um grande número de gravações e outras são bastante estáticas. O banco de dados e todos os objetos residem em um único grupo de arquivos com um único arquivo de dados. O arquivo de log também está no mesmo volume. Minha interpretação é que arquivos de dados separados devem ser usados em diferentes discos para diminuir a contenção de disco e que os grupos de arquivos devem ser usados para particionamento de dados. No entanto, com uma SAN você obviamente não tem o mesmo problema de contenção de disco que você faz com uma configuração RAID pequena (ou pelo menos não no momento), e a edição padrão não suporta particionamento.

Então, para melhorar o paralelismo, o que devo fazer?

Meu entendimento de várias publicações da Microsoft é que, se eu aumentar o número de arquivos de dados, segmentos separados podem atuar em cada arquivo separadamente. O que me leva a questão de quantos arquivos devo ter. Um por núcleo? Devo colocar tabelas e índices com altos níveis de atividade em grupos de arquivos separados, cada um com o mesmo número de arquivos de dados que nós temos?

Obrigado

    

Answer 1

• Cada grupo de arquivos deve ter dados X e arquivos de log, com X sendo o número de núcleos visíveis do gerenciador de tarefas - isso permite o comportamento ideal de E / S.

• Isso é particularmente importante para o tempdb - os arquivos às vezes são completamente bloqueados para o SQL Server, quando extensões (grupos de 8 páginas) são alocadas / liberadas. Tempdb allcoates muitos objetos.

• A distribuição de vários discos faz sentido apenas para melhor IO. Uma boa SAN - pode saturar os excelentes recursos de E / S do driver (a duração da fila geralmente é de 256 por DISC), portanto, uma boa SAN pode exigir vários discos para manter IO excelente pendente para utilizá-la completamente.

• Mas, mesmo sem uma boa SAN, vários arquivos evitam o gargalo de ter acesso a arquivos únicos ao fazer inserções, etc.

• Ter mais do que o X mencionado não faz sentido - no máximo, cada núcleo pode executar um thread em um determinado momento. A localização é atômica, portanto, cada núcleo não irá alternar os segmentos ao fazer isso. Mas todos os núcleos X podem querer estender ao mesmo tempo;)

• Como importante: formate corretamente os discos. Certifique-se de que as partições (do servidor pré-2008) estejam alinhadas, certifique-se de formatar os discos com um tamanho de nó de 64kb - caso contrário, você poderá perder até 40% do seu desempenho de E / S aqui.

• O particionamento não entra neste jogo;)

Answer 2

Você deve ponderar cuidadosamente o tempo para usar vários arquivos apenas para evitar a contenção de alocação (ou seja, não distribuí-los em vários eixos) ou não. Especialmente para tempdb . Depois que a melhor prática foi publicada originalmente, algumas coisas mudaram na forma como o mecanismo funciona e há também uma melhor compreensão geral do problema.

A versão curta é que você deve realmente fazer alguns testes para ver se você realmente tem esse problema de contenção. Você pode ler mais neste post (e links relacionados):

link