Atualmente, nosso banco de dados possui apenas um Grupo de Arquivos, PRIMARY, que contém aproximadamente 8 GB de dados (linhas da 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 dos quais devo estar ciente?
Respostas:
Há duas partes nessa pergunta: quando adicionar um novo FILEGROUP e quando adicionar um novo FILE em um grupo de arquivos. Primeiro vamos falar de teoria:
Mark está certo sobre a principal razão de 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 restaurar primeiro apenas o seu grupo de arquivos principal 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 para data warehouses que precisam carregar dados nas tabelas atuais sem precisar 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 que recebem atividades de leitura intensas, é possível criar diferentes tipos de armazenamento para acomodar essas necessidades. Você pode colocar o material de gravação pesada no RAID 10 e deixar o material com tendência de leitura no RAID 5 mais barato.
Agora, vamos falar sobre arquivos versus grupos de arquivos. Ao colocar objetos no SQL Server, você deve colocá-los no nível do grupo de arquivos. Você pode pousar uma tabela ou um índice em um grupo de arquivos, mas não pode escolher um arquivo específico. Então, 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, existem algumas maneiras de quebrá-lo:
Diferentes subsistemas de armazenamento têm perfis de desempenho diferentes. Trabalhei com algumas SANs que tiveram melhor desempenho com matrizes de 12 a 16 unidades e qualquer coisa maior que isso não teve uma melhoria de desempenho. Outro exemplo são as SANs com caminhos múltiplos: se você possui vários HBAs conectando o servidor ao armazenamento e se o software de caminhos múltiplos não é ativo / ativo real, pode ser necessário um array por caminho para distribuir a carga. Quatro caminhos, quatro conjuntos 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 use pontos de montagem e, mesmo assim, pastas diferentes) e precisará de quatro arquivos separados no SQL Server. Esses arquivos separados podem estar no mesmo grupo de arquivos.
O principal motivo é o desempenho. Ao ficar sem capacidade de IOPS na unidade de disco principal do grupo de arquivos, você precisará expandir para um segundo grupo de arquivos para dividir o 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 composto SSD / SATA / FC, convém ter grupos de arquivos diferentes em diferentes tipos de armazenamento. Em seguida, você pode colocar suas tabelas de requisitos de IOPS extremos no grupo de arquivos SSD, enquanto as tabelas de histórico / estatísticas podem ser armazenadas em grupos de arquivos SATA baratos.
Eu também apontaria que há um aspecto de capacidade de recuperação / disponibilidade de dados para essa pergunta também. Ao usar vários grupos de arquivos e não colocar nenhum objeto definido pelo usuário no grupo de arquivos primário, você tem mais flexibilidade para ativar restaurações online. isso permite a restauração fragmentada no nível do grupo de arquivos.
A restauração online está disponível nas edições Enterprise e Developer do sql server depois de 2005
Outro pensamento que vem à mente é separar apenas 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.