O disco é a parte mais lenta do servidor.
A configuração de armazenamento adequada é fundamental para o desempenho e a operação ideais do SQL Server.
Abaixo estão algumas das práticas recomendadas mais comuns para armazenamento que a Microsoft recomenda para melhorar o desempenho, a confiabilidade e a segurança do SQL Server.
Hardware de disco
Ao longo das últimas cinco décadas, as unidades de disco rígido (HDD) fizeram melhorias regulares na confiabilidade, capacidade e velocidade. As unidades de estado sólido (SSD) são mais rápidas e consomem menos energia do que os HDDs. Eles têm sido disponíveis a capacidades e preços adequados para uso do servidor na última década. Para melhorar a confiabilidade dos SSDs, use unidades de classe empresarial, que fornecem um desempenho de E/S significativamente melhor e significativamente menos propensas a erros.
Sistema de arquivos
O SQL Server faz a maioria das operações de E/S em blocos de 8K ou 64 KB e executa o melhor quando o armazenamento, onde os arquivos de banco de dados vivem, é formatado usando 64 KB (tamanho do cluster do sistema).
Você pode verificar o tamanho do cluster de disco usando o código abaixo no prompt de comando como administrador. Basta alterar a letra "E" para o seu Drive.
fsutil fsinfo ntfsinfo E:
Não é fácil consertar depois do fato, mas se você conseguir a janela de manutenção, vale a pena fazer a mudança.
Figura1 – Bytes por tamanho de cluster.
Uma maneira simples de fazer isso é adicionar uma nova unidade, formatar a unidade corretamente, mover arquivos SQL para ela, excluir a unidade antiga. Prossiga para outra unidade, etc.
Se você estiver usando uma SAN, também deverá examinar os alinhamentos em relação às divisões de LUNs. No caso de uma máquina virtual, considere essa camada do sistema de arquivos também.
Armazenamento de dados
Separe os arquivos Data (MDF), Log (LDFs) e tempDB em unidades físicas diferentes.
Certifique-se de que você tem tudo separado da unidade do sistema operacional "C:", mesmo se estiver em outra partição no mesmo hardware.
Além disso, nunca compartilhe o mesmo disco com backups e bancos de dados em tempo real. Se o disco falhar, você perderá ambos – Bancos de dados e os backups.
Arquivos de dados e dbs temporários geralmente têm mais acesso aleatório do que arquivos de log, mas isso depende da carga de trabalho. Portanto, quando possível, use RAID 1+0 para melhorar o desempenho de gravação.
Grupos de arquivos e arquivos de dados
Para começar, você deseja ter vários FGs, que contêm vários arquivos.
O ideal é que todos esses arquivos estejam em unidades separadas. O que torna a leitura/gravação de dados e o índice mais rápidos. Como a operação de leitura/gravação agora pode ser multithreaded e, vários discos físicos podem "ajudar".
Se alguns dados estiverem obsoletos e não mudarem muito (digamos, dados antigos), esses dados poderão ser colocados em um FG separado, fazendo backup apenas uma vez e definidos como read_only.
E agora você só precisa fazer backup apenas dos dados mais recentes. O que reduz o tempo necessário para fazer backup, tamanhos de backup, tempos de restauração, etc.
Essa estratégia também nos permite colocar dados mais antigos em um armazenamento mais lento/barato.
Em caso de desastre, você deseja ter a menor quantidade possível de dados dentro do grupo de arquivos PRIMARY porque não é possível colocar o banco de dados online até que ele seja recuperado.
Portanto, é uma boa ideia manter o PRIMARY o menor possível. Dessa forma, durante o desastre, você poderia colocar o PRIMARY online, os dados do ano atual e, nesse ponto, seu banco de dados estará ativo. Em segundo plano, podemos estar restaurando dados mais antigos sem afetar a disponibilidade do banco de dados ou os usuários mesmo sabendo disso. Isso também torna a restauração para ambientes inferiores, como DEV, QA, UAT, menor & mais rápida, pois agora você não precisa restaurar os dados completos.
Referencias: Place Data and Log Files on Separate Drives - SQL Server | Microsoft Learn Database Files and Filegroups - SQL Server | Microsoft Learn Configure storage for SQL Server VMs - SQL Server on Azure VMs | Microsoft Learn.
.
Comments