SQL Server 2K / 2K5 / 2K8 e discos de estado sólido: otimizações específicas?

Alguém aqui está executando o SQL Server em unidades de estado sólido? Você encontrou alguma dica específica de otimização? Estou especificamente interessado em maneiras de reduzir a frequência com que o SQL Server executa pequenas operações de gravação aleatória, uma vez que são o inimigo do desempenho do SSD, principalmente as unidades SSD MLC.

Existem algumas otimizações óbvias que podemos fazer, é claro: dados pesados ​​de leitura devem ser fornecidos a partir do SSD e coisas pesadas de gravação devem ser deixadas para os discos giratórios tradicionais. Isso inclui logs de transações, naturalmente!

Dado um orçamento suficiente, é claro, alguém desejaria usar discos SSD SLC como as séries X25-E ou Vertex Ex ou várias ofertas em nível empresarial. Mas também estou interessado em dicas que possam beneficiar as configurações de SSD da MLC. Eu acho que é uma área interessante. Um dos clientes de meus clientes tem um orçamento pequeno e um conjunto de dados que cresce imensamente e eles estão enfrentando uma reescrita completa de quase uma centena de consultas para manter um nível de desempenho decente. No entanto, tenho uma suspeita furtiva de que menos de US $ 500 em espaço em RAM e SSD podem proporcionar um ganho de desempenho maior que milhares (possivelmente dezenas de milhares) de dólares em tempo de desenvolvedor.

Não sei o que você quer dizer com reduzir a quantidade de gravações aleatórias pequenas que o SQL Server faz. O SQL Server grava páginas de dados somente durante os pontos de verificação - portanto, a única maneira de limitar o número de gravações é alterar o intervalo do ponto de verificação ou não fazer tantas operações de DIU. Você quis dizer outra coisa?

Em todas as implementações de SSDs que eu vi (algumas), é exatamente o oposto do que você está sugerindo - o melhor uso de SSDs parece ser para logs de transações com gravação pesada e tempdb - basicamente, onde está o maior I / O gargalo do subsistema e cole os SSDs nele - pois o tempo e a latência de busca são reduzidos a uma constante baixa.

Confira este documento de pesquisa que a MS produziu (infelizmente não muito detalhado sobre os detalhes do SQL Server): Migrando o armazenamento do servidor para SSDs: análise de tradeoffs .

Espero que isto ajude!

Você não pode modificar as características de E / S dos Servidores SQL. Sua unidade básica de acesso ao disco, para arquivos de dados, é uma página de 8 KB. Ele os escreverá principalmente durante um ponto de verificação, mas também os escreverá preguiçosamente quando puder.
O SQL não espera que as gravações no disco de dados sejam concluídas antes de retornar, são apenas as gravações de log que devem ser concluídas. Se você puder manter apenas um log de banco de dados em um disco, ele será gravado em seqüência e ficará bem em discos rígidos rápidos e normais.
O impacto no desempenho do ponto de vista do SQL é quando ele precisa ler os discos. Se você puder fornecer mais memória, o SQL manterá mais páginas de dados na memória, o que é mais rápido do que qualquer tipo de disco, SSD ou outro. Obviamente, você também pode reduzir o número de leituras de disco criando índices apropriados. Espero que um SSD também ajude com essas leituras, porque é provável que sejam aleatórias e permaneçam aguardando a movimentação dos cabeçotes.
Não sei de que tamanho de banco de dados estamos falando aqui, mas você pode dar uma olhada no HyperOS. Eles criam discos sata que são na verdade apenas uma carga de RAM DDR2, com um disco SSD ou de 2,5 polegadas como backup. O padrão de acesso do servidor não terá importância. Eu não colocaria os logs em nada parecido com isso. Os logs são o que mantêm seus dados consistentes, eles precisam ser executados em um meio confiável e, apesar do SSD e da bateria de backup, e o servidor provavelmente possui um no-break etc., eu ainda me sentiria pouco à vontade por não ter meus logs em um disco rígido real em algum tipo de matriz RAID tolerante a falhas.

Pequenas operações aleatórias são o inimigo dos discos tradicionais, devido à latência de busca principal ... Os SSDs são ótimos para resolver exatamente isso.

Com operações longas e seqüenciais, os discos padrão têm um desempenho muito bom, portanto não haveria sentido em usar SSDs (do ponto de vista do desempenho, é claro).

Não basta apontar aqui ainda para adicionar ao thread de comentários, mas se você definir o tamanho da página do banco de dados / contagem de várias leituras para qualquer coisa nos SSDs para um múltiplo do tamanho da página do SSD, isso não deve ser um problema.

Não trabalho há muito tempo no SQL Server, por isso não tenho certeza se essas opções estão disponíveis lá. Trabalho com Oracle e DB2 nos últimos anos e isso resolveria suas preocupações, pois o banco de dados seria ajustado adequadamente às características do disco.

Eu recomendaria alinhar a partição onde os arquivos do banco de dados são armazenados.

Eu também recomendaria decidir o que acontece no RAID 0 para perf (ldf e TempDB) e colocar dados críticos no RAID 1 (mdf).

Em terceiro lugar, você realmente deve atualizar o firmware da unidade, bem como o firmware / drivers do controlador SATA. Ao fazer isso, você oferece à empresa de hardware e aos desenvolvedores a chance de otimizar o desempenho para você.