Configuração ideal da unidade para o SQL Server 2008R2

19

Eu tenho um servidor de banco de dados bastante ocupado executando o SQL Server 2008 R2 que possui a seguinte configuração:

SATA RAID 1 (2 unidades) - SO / Programas
SAS RAID 10 (4 unidades) - arquivos de banco de dados SQL (dados e logs)
SAS RAID 1 (2 unidades) - TempDB (dados e logs)

Supondo que não posso adicionar unidades adicionais a este servidor, fiz o melhor uso possível da configuração disponível? Ou devo considerar outro esquema aqui em que os logs são isolados dos arquivos de dados, por exemplo?

Atualizar:

Para aqueles que solicitaram mais detalhes de hardware:

As unidades SATA (usadas para a partição OS / Programa) são: WD 7200 RPM 3 Gb / s SATA de 3,5 polegadas
As unidades SAS usadas nas outras matrizes são: Seagate 15K RPM 6 Gb / s SAS de 3,5 polegadas
O controlador RAID usado é uma: porta LSI 9260-8i SAS / SATA 6 Gb 8

Atualização 2:

Com base nos comentários que recebi, parece que tenho as seguintes opções viáveis para escolher - concederei a recompensa a alguém que possa me dizer qual provavelmente será o melhor no ambiente que descrevi:

Deixe tudo como está - provavelmente não vou me sair muito melhor
Mova minhas 2 unidades RAID 1 SAS para minha matriz RAID 10 existente para que ela seja composta por 6 discos no total
Mova meus arquivos de log para o SAS RAID 1 e / ou mude o TempDB (dados ou logs) de volta para o RAID 10

sql-server hardware

— DanP
fonte

Sua segunda atualização está fazendo exatamente as mesmas perguntas que sua pergunta original; portanto, a resposta original se aplica. "... o que provavelmente será o melhor no ambiente que descrevi" ... você não nos mostrou nenhuma análise da carga de trabalho, apenas que ela é "bastante ocupada", então novamente a mesma resposta se aplica .

— Mark-Storey-Smith

Com o NVMe de alto desempenho e outros discos SSD do mercado, o RAID não é mais muito importante da perspectiva das melhores práticas de configuração de disco do servidor SQL . Conjuntos de discos (espaços de armazenamento) são o caminho a seguir. Você, no entanto, precisaria separar logicamente os volumes para solucionar melhor os problemas de desempenho relacionados ao disco.

— Faces Of IT

14

Variantes desta pergunta surgem semi-regularmente:

Há também brigas ocasionais sobre a "melhor prática" de separação de dados / log.

Sem uma análise mais detalhada do que este servidor está fazendo, o mesmo conselho se aplica como fornecido anteriormente.

RAID 1 para SO
RAID 10 (6 discos) para dados / logs / tempdb

Raramente existe um ponto em uma divisão com tão poucos eixos disponíveis. Uma única matriz com uma capacidade maior de IOPs normalmente absorve os altos e baixos da sua carga de trabalho melhor do que duas matrizes menores.

Uma variante que pode valer a pena testar é colocar o tempdb na unidade do SO. Faça isso apenas se você tiver uma carga de trabalho representativa que possa ser reproduzida repetidamente, para garantir uma comparação justa da configuração. Se você optar por esse arranjo na produção, verifique se o crescimento do tempdb é restrito, para não consumir inadvertidamente todo o espaço livre na unidade do SO.

Dado que suas unidades de sistema operacional são montanhas-russas de 7200 RPM, ficaria surpreso se o tempdb na configuração da unidade de sistema operacional tivesse algum benefício.

— Mark Storey-Smith
fonte

7

Tudo depende da sua carga de trabalho, mas com apenas 6 unidades, limita suas opções. Se sua carga de trabalho não depende muito do tempdb para itens como classificações, tabelas de hash e isolamento de instantâneo, é melhor usar as 6 unidades SAS juntas no RAID 10. No entanto, se você conhece ou possui as métricas para provar isso, tempdb é muito utilizado, então você deve mantê-lo separado como você o fez.

— Patrick Keisler
fonte

Obrigado pela resposta, alterar a configuração dos intervalos (infelizmente) não é uma opção, pois este servidor está em produção. Estou curioso para mudar o tempdb de volta para o RAID 10 e colocar todos os arquivos de log no RAID 1 - essa é uma opção inteligente?

— danp

2

Lembre-se de que o SQL Server precisa gravar fisicamente todas as transações no log como parte da confirmação, para que você queira o desempenho de gravação mais rápido possível na sua configuração. O RAID 10 oferece melhor desempenho de gravação que o RAID 1, portanto, deixaria os logs no volume mais rápido.

— 22413 Patrick Keisler

2

Depende muito do que você quer dizer com "muito ocupado": diferentes padrões de carga de trabalho (gravação pesada ou não, operações em massa comuns ou não, nível de acesso simultâneo, para citar apenas três das muitas variáveis) podem ter um efeito drástico no desempenho de qualquer disposição de eixo.

Para uma situação de gravação pesada, a separação dos logs dos dados pode fazer uma diferença significativa, pois cada gravação envolve a atualização dos arquivos de log e de dados, o que implica uma quantidade considerável de inversão de cabeça se os dois conjuntos de arquivos estiverem no mesmo conjunto de eixos. .

Sem referência adicional à sua carga de trabalho (e às especificações dessas unidades e de qualquer controlador que esteja entre elas e a máquina), eu estaria inclinado a usar três volumes: um para programas do OS + e tempdb (dados), um para o banco de dados principal dados e o terceiro para logs (tempdb e DBs principais).

Obviamente, se suas cargas de trabalho são muito leves nas operações de gravação, você não deve gastar muito tempo se preocupando em manter os dados e os logs separados, pois isso fará pouca diferença no desempenho e dedicar um volume inteiro a elas seria um grande desperdício de informações disponíveis. espaço.

— David Spillett
fonte

Certamente descreveria nosso ambiente como "gravação pesada" - atualizarei minha pergunta com especificações de hardware mais detalhadas na segunda-feira.

— 23413 DanP

Alguma idéia sobre o número de unidades que o OP possui? Estou pensando mais no Raid 1 que ele possui para os arquivos de log. Isso não soa como uma ótima opção para fins de gravação e arquivos de log AFAIK não são lidos limitado, mas write ..

— Marian

Eu adicionei especificações adicionais sobre o hardware da máquina.

— DanP 23/03

1

Esse mal-entendido pode estar na raiz de muitos discursos de separação de dados / log, então peço desculpas, mas eu vou chamá-lo. "... como cada gravação envolve a atualização dos arquivos de log e de dados" - não, não. As gravações nas páginas de dados ocorrem no ponto de verificação, não em todas as modificações.

— Mark-Storey-Smith

1

@DavidSpillett É verdade que sempre haverá casos em que a divisão é benéfica. A chave é que você testou e validou que a configuração foi benéfica para essa carga de trabalho específica.

— Mark Storey-Smith

2

A resposta real depende das suas necessidades, mas geralmente "colocar dados e efetuar logon em diferentes matrizes" é de maior importância do que "colocar tempdb em sua própria matriz".

Dado o número de unidades disponíveis, meu ponto de partida seria:

Duas unidades, RAID 1 - Sistema operacional, executável, arquivo de paginação.
Quatro unidades, RAID 5 - todos os arquivos de dados (como alternativa, RAID 1 + 0)
Duas unidades, RAID 1 - todos os arquivos de log

O que você deve fazer é usar o SQLIO para testar o desempenho de diferentes configurações de unidades.

— Andarilho de Pedra Verde
fonte

Definitivamente, isso representa o "outro lado" dos conselhos que li. Eu gostaria que houvesse um método definitivo para determinar qual das opções seria melhor sem recorrer à "experimentação" em um ambiente de produção.

— 21413 DanP

2

@ DanP Bem, eu pessoalmente teria seguido o conselho de Mark e escolhido um RAID10 com o restante das unidades (exceto o OS). Os arquivos de log são intensivos em gravação e precisam de um desempenho melhor do que o RAID 1 tem a oferecer, na minha opinião. Mas eu não sou especialista em hardware. Apenas meus 2 centavos.

— Marian

2

Devo mencionar que minha opinião vem apenas da experiência de uma migração passada (meio que) falhada para um servidor melhor, mas com desempenho pior. Nunca testamos uma carga real neste novo servidor, nunca tivemos uma chance, o servidor não estava pronto a tempo. Acontece que o teste do servidor ANTES de migrar para a produção deve ser OBRIGATÓRIO. Desculpe pela ênfase. Portanto, meu mantra para todas as migrações / atualizações é: TEST, TEST, TEST, ... teste o máximo possível.

— Marian

1

Não tenho certeza se deve começar com RAID 5 ou SQLIOSIM ... vamos com o posterior, pois o primeiro fala por si. SQLIOSIM é uma ferramenta de teste de correção e de estresse , não é uma ferramenta de teste de desempenho ou de carga. Não há absolutamente nenhum lugar na comparação do desempenho de config-X vs config-Y para a carga de trabalho-Z. Tudo o que lhe diria é o desempenho do config-X em relação ao config-Y em uma execução SQLIOSIM. Se você deseja comparar o desempenho da carga de trabalho-Z, teste a carga de trabalho-Z.

— Mark-Storey-Smith

1

@GreenstoneWalker "O RAID1 é mais rápido para escrever do que o RAID1 + 0" é um absurdo. De onde veio essa ideia?

— Mark Storey-Smith

-1

Dependendo do que você está usando o banco de dados (OLTP x armazenamento), sua configuração parece uma boa configuração geral. Se você tivesse mais discos, teria mais opções.

Você poderia obter um desempenho melhor se alternasse o disco do TempDB para RAID 0 (faixa). Isso aumenta seu risco de falha, mas como o TempDB armazena apenas os dados em buffer, você não pode sofrer perda de dados. Portanto, a maioria das pessoas considera isso uma troca razoável. Basta manter um sobressalente por perto (ou um hot-spare).

Uma coisa que você não mencionou, mas pode tentar (se ainda não o fez): a Microsoft recomenda dividir o TempDB em vários arquivos (um por CPU). Obviamente, é melhor que eles estejam em discos separados, mas simplesmente ter arquivos separados ajuda. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

— TimG
fonte

4

O Tempdb é usado para muitas coisas, mas não o trate como um banco de dados descartável e o coloque em um RAID 0. Lembre-se de que, se esse volume RAID 0 falhar, o SQL Server não poderá inicializar.

— Patrick Keisler

De fato tenho criado um db temporário por núcleo como sugerido, mas graças para levantar esse ponto, bem :)

— danp

1

Bem, essas sugestões não são muito boas e não são apropriadas para todos os ambientes. O primeiro é mencionado por @PatrickKeisler anteriormente. O segundo é um mito que Paul Randal desmascarou há algum tempo. O artigo é este: Um mito do DBA do SQL Server por dia: (12/30) o tempdb sempre deve ter um arquivo de dados por núcleo do processador . Portanto, a documentação da MS pode estar errada, não leve isso de cor.

— Marian

2

"como o TempDB armazena apenas os dados em buffer, você não pode sofrer perda de dados" ... e tenho certeza que os usuários do sistema apreciarão que durante as X horas de inatividade sofridos enquanto a) as operações vasculham o porão disco de substituição ou b) um DBA tenta explicar ao suporte técnico como mover o tempdb do seu celular.

— Mark Storey-Smith