Estamos prestes a iniciar um projeto para migrar um grande DWH para novos servidores físicos em um novo data center. A especificação de servidor atual é SQL Server Enterprise 2016 SP2 em execução no Windows 2012 R2. Os novos servidores serão MSSQL 2019 Enterprise rodando no Windows 2019.
O armazenamento SAN para os servidores atuais e novos é uma matriz de armazenamento totalmente flash. No ambiente atual, além de separar dados e arquivos de log em diferentes unidades lógicas, diferentes bancos de dados (somente arquivos de dados) também são divididos em diferentes unidades lógicas.
- SSD local - TempDb
- Unidade lógica 1 - arquivos de log
- Unidade Lógica 2 - arquivos de dados para bancos de dados de teste
- Unidade lógica 3 - arquivos de dados para bancos de dados voltados para o usuário
- Unidade Lógica 4 - arquivos de dados para bancos de dados de suporte (ReportServer, banco de dados MDS)
Como parte da migração do servidor, estou pensando em combinar todos os arquivos de dados em uma única unidade lógica.
- SSD local - TempDb
- Unidade lógica 1 - arquivos de log
- Unidade Lógica 2 - arquivos de dados
Além do gerenciamento de arquivos de banco de dados, há algum benefício de desempenho para manter os arquivos de dados divididos em diferentes unidades lógicas? Várias unidades lógicas oferecem melhor IO, mesmo que, em última análise, seja a mesma matriz de armazenamento físico?
Se todos os volumes forem mapeados para o mesmo conjunto de discos físicos na SAN, normalmente não haverá diferença.
No entanto, se cada volume for mapeado para um SAN LUN diferente, é possível que a SAN aloque recursos de armazenamento de forma diferente para os volumes. Por exemplo, eles podem ser hospedados em controladores SAN separados, ter diferentes políticas de armazenamento em cache, ser monitorados separadamente etc., mesmo que os LUNs compartilhem o mesmo armazenamento subjacente.
Se cada volume for mapeado para um conjunto separado de discos físicos, dividi-los será muito caro, pois você não poderá agrupar e compartilhar recursos de E/S entre os volumes. E como a maioria das E/S de arquivo de banco de dados é E/S em segundo plano, normalmente você deve agrupar todos os recursos de E/S para todos os arquivos de banco de dados para maximizar a eficiência, o compartilhamento e o throughput de pico de E/S por banco de dados.
Portanto, depende, e você precisa trabalhar com seus especialistas em SAN para escolher e configurar adequadamente a SAN e o servidor (por exemplo, profundidade da fila de E/S).
Eu acho que as gravações no arquivo de dados não são feitas "ao vivo". Normalmente, você terá impacto no desempenho quando os arquivos de log estiverem em um armazenamento "mais lento" (já que o SQL precisa gravar o log antes de poder confirmar a transação (*se você não o configurou para não fazê-lo)).
Acho que não haverá benefícios reais em ter os arquivos de dados em unidades diferentes.
Acho que se fosse eu, colocaria todos os arquivos de dados na mesma unidade e verificaria as estatísticas do SQL Waits ou compararia com uma linha de base para verificar o desempenho. Se você tiver problemas, ainda terá a opção de adicionar novas unidades e mover alguns arquivos de banco de dados.
Se você tiver problemas, também pode verificar se não haverá outra opção para "ajudar" como adicionar RAM (como as páginas de dados são armazenadas na RAM quando o SQL as usa), ajuste sua maior solicitação de IO para que você não tem que carregar muita página na RAM (forçando o SQL a liberar o mais antigo com mais frequência), verificar o fator de preenchimento, etc.
Meu artigo de 2007 ainda é muito relevante para essa questão. Sim, você obtém um aumento de velocidade ao usar vários volumes físicos. Aplica-se ao SSD como se aplica aos discos rígidos. Na verdade, dividir um banco de dados SQL em volumes físicos é mais rápido do que usar RAID com base em meus testes. https://www.zdnet.com/article/comprehensive-raid-performance-report/