Há um grupo que concorda que em um HDD seria benéfico separar, eles ainda afirmam que para unidades SSD isso não é mais necessário.
Então, para eles, eu quero perguntar "se não há problema de contenção, por que um RAID 10? Não há mais necessidade de remover! Então, apenas o mirrowing seria o suficiente e, é claro, não há necessidade de 8 unidades, 2x o banco de dados tamanho deve ser suficiente! "
No entanto, a realidade é que, se algo precisa de um RAID 10, é o arquivo de log!
Isso não ocorre apenas por causa do problema de seqüencial x aleatório (consulte os recursos abaixo), mas é realmente muito crucial quando você entende como as unidades SSD funcionam.
Para resumir uma longa história (para uma descrição mais longa, consulte
http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), uma unidade SSD é muito eficiente nas leituras e na escrita de zeros; no entanto, para escrevê-las, não é tão eficiente quanto precisa apagar a seção inteira para escrever uma única!
Embora esse não seja um problema para gravações gerais, pois elas são armazenadas em buffer na memória e gravadas nos limites da página, é um problema importante para o arquivo de log, pois ele ignora qualquer cache e, em vez disso, bloqueia o SQL Server até o os logs são gravados no disco !, o que significa que, para cada gravação, provavelmente haverá uma seção completa apagada.
Então, para otimizá-lo, sugiro dedicar todos os discos extras (além do tamanho do banco de dados, sem a necessidade de remover!) Para o arquivo de log, desta forma ele poderá processar o maior número possível em um período mais curto.
RESPOSTA ANTIGA
A resposta é sim, por três razões. 1) Aleatório x seqüencial - Embora esteja claro que o SSD aumentou significativamente o desempenho para gravações aleatórias, ainda permanece o problema de aleatório x seqüencial, como pode ser visto nos seguintes documentos e links:
2) Confiabilidade - Há uma forte chance de que todas as unidades SSD falhem simultaneamente; nesse caso, o RAID não oferece proteção; no entanto, uma vez que uma unidade SSD usada apenas para sequencial tem uma vida útil diferente, esse pode ser o seu salva-vidas
3) Contenção de gravação - A razão para colocar os logs em seu próprio eixo-árvore não é apenas por causa de aleatória vs seqüencial, mas também por causa de contenção de gravação, como se pode ver pelo fato de que também é recomendável ter tempdb em um volume separado, o que indica que o problema aqui também é sobre contenção de gravação.
E isso deve se aplicar ainda mais ao arquivo de log, pois as gravações no log impedem que as transações sejam consideradas confirmadas até que sejam gravadas na superfície do disco.
De fato, para os registros, você pode usar unidades de disco rígido regulares como o white paper da Dell em http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf
EDITAR
A colocação do tempdb em sua própria matriz para discos giratórios é recomendada pela Microsoft, consulte
e muitos outros e é a noção geral aceita no Sql Server, enquanto ninguém expressou um problema ao dividir a matriz.
Além disso, a equipe do SQL Server criou os conceitos de particionamento de grupo de arquivos e particionamento, com a única intenção de poder movê-los em uma matriz separada.
De fato, o MSDN em http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) recomenda que haja um benefício de desempenho ao separar o índice não clusterizado em sua própria matriz (embora isso não deve ser tomado como um conselho geral para todas as situações, apenas para cargas de trabalho específicas; veja mais informações em http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).
Como tal, é apenas uma extensão lógica dizer que a razão da separação em discos giratórios não está ligada apenas à questão das leituras sequenciais versus aleatórias, mas à contenção geral de gravação, algo que também se aplica aos SSDs.
Embora possa ser que algumas pessoas não concordem com esse conselho e considerem que não há benefício em colocar o tempdb e seu próprio volume (como Jack Douglas), você pode até afirmar que não há benefício em separar os arquivos de log (como Mark Storey -Smith) e, em vez disso, afirma que a divisão da matriz é muito pior, ainda assim não se esqueça de que esta é uma nova abordagem que vai contra a abordagem geral aceita sugerida pela Microsoft e pela comunidade, e até agora ninguém forneceu links para nenhuma testes de benchmark para apoiá-lo.
Portanto, minha palavra para todos os que rejeitam o voto é: acho muito antiético votar um post apenas porque ele tem uma opinião diferente da sua, especialmente quando 1) sua opinião vai contra a teoria geral aceita 2) e é contra os fornecedores (Microsoft ) própria documentação 3) e você não forneceu nenhuma prova apenas uma opinião.
Mas, nesse caso, é ainda mais ridículo, já que meu post nada mais é do que a extensão lógica dessa teoria; portanto, alguém que considere esse post como um conselho de cama precisa, é claro, voltar a todos os posts que aconselham essa teoria e os rebaixam. .
Digamos que alguém decida que o RAID é uma teoria da velha escola e reduz a votação de todas as postagens que a recomendam, como isso faz sentido?