it-swarm-pt.tech

No SQL Server, quando você deve dividir seu grupo de arquivos de dados PRIMARY em arquivos de dados secundários?

Nosso banco de dados atualmente tem apenas um grupo de arquivos, PRIMARY, que contém cerca de 8 GB de dados (linhas de tabela, índices, catálogo de texto completo).

Quando é um bom momento para dividir isso em arquivos de dados secundários? Quais são alguns critérios que devo estar ciente?

11
Jarrod Dixon

Essa pergunta tem duas partes: quando adicionar um novo FILEGROUP e quando adicionar um novo FILE a um grupo de arquivos. Primeiro vamos falar de teoria:

Mark está certo sobre o motivo principal ser o desempenho.

O motivo secundário é a recuperação de desastres. Com o SQL Server 2005 e mais recente, você pode fazer restaurações de grupos de arquivos. Quando ocorre um desastre, você pode primeiro restaurar apenas seu grupo de arquivos primário e colocar o banco de dados parcialmente online para consultas. Os usuários podem executar consultas enquanto você restaura outros grupos de arquivos. Isso é útil para bancos de dados com uma grande quantidade de dados históricos que podem não ser necessários imediatamente ou data warehouses que precisam carregar dados nas tabelas atuais sem a necessidade de dados históricos para acesso.

Outro motivo é o perfil de leitura/gravação de grupos de dados. Se você tiver alguns dados que são constantemente gravados e outros dados que geram muita atividade de leitura, poderá construir diferentes tipos de armazenamento para acomodar essas necessidades. Você poderia colocar o material pesado no raid 10 e deixar o material com viés de leitura no raid 5 mais barato.

Agora, vamos falar de arquivos versus grupos de arquivos. Ao colocar objetos no SQL Server, você deve colocá-los no nível do grupo de arquivos. Você pode acessar uma tabela ou índice em um grupo de arquivos, mas não pode escolher um arquivo específico. Portanto, tudo o que discutimos até agora foi sobre quando adicionar um grupo de arquivos - mas quando você adiciona um arquivo?

Se você estiver projetando armazenamento e tiver 80 discos rígidos, há algumas maneiras de dividi-lo:

  • Um pool de 80 drives
  • Duas piscinas de 40 unidades
  • Quatro pools de 20 drives, etc ...

Diferentes subsistemas de armazenamento têm diferentes perfis de desempenho. Trabalhei com alguns SANs que tiveram melhor desempenho com matrizes de unidade de 12-16, e qualquer coisa maior do que isso não teve uma melhoria de desempenho. Outro exemplo são as SANs com multipathing: se você tiver vários HBAs conectando seu servidor ao armazenamento e se o software de multipathing não for realmente ativo/ativo, talvez seja necessário um array por caminho para distribuir a carga. Quatro caminhos, quatro pools de unidades obterão melhor desempenho nesses tipos de unidades.

Nesses casos, você acaba com quatro matrizes diferentes, quatro unidades diferentes no Windows (a menos que você use pontos de montagem e, mesmo assim, sejam pastas diferentes) e precisará de quatro arquivos separados no SQL Server. Esses arquivos separados podem estar no mesmo grupo de arquivos.

20
Brent Ozar

O principal motivo é o desempenho. Quando você ficar sem capacidade de IOPS em sua unidade de disco de grupo de arquivos principal, você precisará expandir em um segundo grupo de arquivos para dividir IOPS em vários discos/LUNs, dependendo da configuração de armazenamento.

EDIT: Brad Wilson fez um bom comentário sobre SSDs. Se você estiver usando um sistema de armazenamento SSD/SATA/FC composto, pode querer ter grupos de arquivos diferentes em tipos diferentes de armazenamento. Você pode então colocar suas tabelas de requisitos extremos de IOPS em filegropus SSD, enquanto as tabelas de histórico/estatísticas podem ser armazenadas em grupos de arquivos SATA baratos.

6
Mark S. Rasmussen

Também gostaria de apontar que há um aspecto de recuperabilidade/disponibilidade de dados para essa questão também. Usando vários grupos de arquivos e não colocando nenhum objeto definido pelo usuário no grupo de arquivos principal, você tem mais flexibilidade para habilitar restaurações online. isso permite a restauração gradativa no nível do grupo de arquivos.

A restauração online está disponível nas edições Enterprise e Developer do sql server posteriores a 2005

Outro pensamento que vem à mente é separar os dados de referência estáticos de leitura dos dados transacionais. Para bancos de dados maiores, isso pode reduzir a quantidade de tempo e/ou espaço necessário para executar um backup.

1
Jason Horner