Posicionamento ideal de arquivos tempdb, mdf e ldf no SQL Server 2012 em SSDs?

Sei que essa é provavelmente uma pergunta muito aberta e as respostas podem variar, mas qual é o posicionamento ideal para os arquivos tempdb, mdf e ldf no SQL Server 2012 quando se fala de SSDs?

Antes da nova compra, eu tinha um SSD existente com os arquivos principais do SQL Server 2012 e o tempdb instalado e tinha o mdf / ldf em um HDD de 7200 rpm. Comprei 2 SSDs com a intenção original de colocar mdf em um e ldf no outro.

Mas, lendo mais, discos físicos separados para arquivos mdf e ldf realmente não se aplicam quando se trata de SSDs. Corrigir?

Então, eu estava pensando no seguinte:

SSD 1 - Arquivos principais do SQL Server 2012 e
SSD do Windows 2 - tempdb
SSD 3 - mdf e ldf

Se isso fizer diferença, isso será dedicado a apenas um banco de dados, para que não haja disputa entre vários bancos de dados.

Minha configuração de "pensamento" é boa ou é simplesmente um desperdício (ou seja, não há razão para separar o tempdb) onde agora tenho um SSD extra para usar em outro lugar?

sql-server sql-server-2012 storage

— Kevin
fonte

A tolerância a falhas é uma opção na sua configuração? Se seu banco de dados é importante, as unidades mdf e ldf devem ser armazenadas em unidades tolerantes a falhas (por exemplo, espelhadas).

— datagod 14/09/12

Um possível problema que vejo na sua configuração é que você não foi responsável por uma única falha na unidade. Se você tiver apenas três SSDs para trabalhar, recomendo considerar uma matriz RAID5 e colocar todos os arquivos relacionados ao SQL Server nessa matriz.

— Matt M

Este é um servidor da camada de produção ou você se importa se ele ficar inativo se uma unidade falhar?

— 21412 Jon Seigel

Esqueci de mencionar que a tolerância a falhas por partes não é uma preocupação, pois os dados são armazenados em backup completo todas as noites, mas são dados estáticos que podem ser facilmente substituídos mesmo se os backups não fossem uma opção. Os únicos dados dinâmicos são principalmente o registro / auditoria que não possui dependências. Qualquer pequena interrupção no serviço que eu teria ao cortar manualmente um backup é tolerável.

— Kevin

Agradeço as respostas, tudo. Eu tenho uma pergunta de acompanhamento sobre "é melhor formatar o ssd para blocos de 64k?", Mas não estou familiarizado com o formato aqui. Devo postar isso como uma nova pergunta ou está bem aqui?

— Kevin

Mas, lendo mais, discos físicos separados para arquivos mdf e ldf realmente não se aplicam quando se trata de SSDs. Corrigir?

O motivo original para dividir os arquivos de log e dados em discos separados foi duas vezes mais latência e largura de banda nas unidades.

Os SSDs não removem essas restrições, mas diminuem / aumentam os limites de maneira bastante significativa (7,9ms para uma leitura com um único HDD vs 0,1ms para uma leitura em um único SSD, aproximadamente).

Então, finalmente, sim e não - ele não se aplica TANTO quanto aos HDDs, mas esses limites ainda estão lá e ainda podem ser atendidos. Tudo depende da sua carga de trabalho.

Minha configuração de "pensamento" é boa ou é simplesmente um desperdício (ou seja, não há razão para separar o tempdb) onde agora tenho um SSD extra para usar em outro lugar?

Assumindo que

Você tem 3 SSDs físicos
Você tem 1 HDD físico
Você precisa que os dados sejam redundantes, mas não necessariamente o próprio sistema

Sua configuração proposta teria alguns problemas (como mencionado anteriormente) e uma única falha na unidade é a principal.

Você poderia optar por algo assim.

Unidade única de 7200 rpm -
matriz Windows OS RAID 5 (3 SSDs) - dividida em 4 unidades (D para dados, L para logs, S para swap e T para Temp)

Unidade única de 7200 rpm -
SSD único do Windows OS -
matriz RAID 1 de temperatura e troca (2 SSDs) - Dados e registros

É a minha preferência pessoal de descarregar o Windows em uma unidade não SSD quando você tem apenas um número limitado, mas isso depende inteiramente do que o servidor está fazendo e do risco que você está disposto a correr.

— Prumo
fonte