Então, estou construindo um SQL Server 2008 R2 x64 ... Estarei executando um único banco de dados de usuários de cerca de 2 GB, talvez 80/20 de leitura / gravação e cerca de 100 usuários.
O hardware básico seria o DL380, 12 GB de RAM e dois Xeons de 6 núcleos. Agora estou desligada na configuração do disco ...
Opção 1
SSD de 60 GB RAID 1 (OS, arquivos SQL, TLog, TempDB)
RAID 1 120GB SSD (arquivos DB)
ou
Opção 2
RAID 1 146GB 15K (OS, SQL Files)
RAID 1 146GB 15K (Tlogs, TempDB)
RAID 10 4x148GB 15K (arquivos DB)
Alguns números perfmon do meu servidor de produção atual:
Memória disponível MBytes - 813 (servidor tem 4 GB de memória)
Expectativa de vida da página - 496854avg
Solicitação em lote / s - 7.5avg 97.595max
Compilações SQL - 3.422avg 27.599max
Re-Compilações SQL - 0.002 0.200max
Prioridade de negócios é mais confiabilidade do que desempenho.
Qual das configurações de disco acima você preferiria ter ?? A diferença de custo é de aproximadamente US $ 2700 para os SSDs (também precisa de um segundo servidor espelho). Os SSDs até fazem diferença para um banco de dados tão pequeno? Eu poderia imaginar com 12GB eu teria memória física suficiente para todo o banco de dados, certo ???
Aprecie qualquer feedback ... Obrigado!
Li sobre os SSDs terem um alto nível de falha taxas ; então, se a confiabilidade é a prioridade, eu usaria as unidades SAS de 15k.
De qualquer forma, com RAID você tem tolerância a falhas de disco, mas provavelmente teria melhor sorte com o SAS 15k. Nós executamos vários servidores Dell com unidades SAS de 15k e eles são bem sólidos.
Com o SSD, há uma chance maior de zapeamento de blocos de disco. Se você tem um banco de dados OLTP, isso não é uma boa idéia, mesmo que você obtenha tempos de busca muito mais rápidos para suas leituras / gravações. Você também pode ter que executar verificações de DBCC muito mais freqüentes no banco de dados para descartar seções corrompidas no SSD. Para um sistema OLAP, o SSD se torna um pouco mais aceitável, mas você ainda tem os mesmos prós e contras.
Se a prioridade for confiabilidade, escolha a opção 2 e fique longe do SSD.
Com tanta memória e um banco de dados tão pequeno, o desempenho de armazenamento das leituras não importa muito de qualquer maneira.
Depois de alguma atividade de consulta no banco de dados, tudo estará na RAM. O SQL não deve tocar no disco novamente, exceto para atualizar através do gravador lento.
Eu manteria esse par apenas para o log e colocaria os arquivos de dados tempdb no volume RAID, com outros arquivos de dados. É improvável que você esteja fazendo IO físico em seus arquivos de dados e tempdb ao mesmo tempo. Colocar os logs nesse par tornará mais fácil para os caches de gravação para esse par manter e minimizar o movimento da cabeça do disco, que é o verdadeiro inimigo. Você quer que as gravações de log sejam rápidas porque estão sincronizadas com relação ao seu DML. As gravações de dados podem ser mais lentas porque são armazenadas em cache pelo SQL Server e são assíncronas.
Tags raid sql-server