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)
Presumindo que não posso adicionar unidades adicionais a este servidor, fiz o melhor uso da configuração que tenho disponível? Ou devo considerar outro esquema aqui onde 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 3,5 polegadas SATA
- As unidades SAS usadas nas outras matrizes são: Seagate 15K RPM 6 Gb/s SAS de 3,5 polegadas
- O controlador RAID usado é um: LSI 9260-8i SAS/SATA 6 Gb 8 portas
Atualização 2:
Com base no feedback 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 o melhor no ambiente que descrevi:
- Deixe tudo como está - provavelmente não farei muito melhor
- Mova minhas 2 unidades SAS RAID 1 para minha matriz RAID 10 existente para que ela seja composta por 6 discos no total
- Mover meus arquivos de log para o SAS RAID 1 e/ou realocar o TempDB (dados ou logs) de volta para o RAID 10
Variantes desta questão surgem semirregularmente:
Também há 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 conforme fornecido anteriormente.
Raramente há algum ponto em uma divisão com tão poucos fusos disponíveis. Um único array com uma capacidade de IOPs maior normalmente absorverá os altos e baixos de sua carga de trabalho melhor do que 2 arrays menores.
Uma variante que pode valer a pena testar é colocar o tempdb na unidade do sistema operacional. Faça isso apenas se tiver uma carga de trabalho representativa que possa reproduzir repetidamente, para garantir uma comparação justa da configuração. Se você optar por esse arranjo na produção, certifique-se de que o crescimento do tempdb seja restrito para que você não consuma inadvertidamente todo o espaço livre na unidade do sistema operacional.
Dado que as unidades do seu sistema operacional são montanhas-russas de 7200 RPM, ficaria surpreso se o tempdb na configuração da unidade do sistema operacional trouxesse algum benefício.
Tudo depende da sua carga de trabalho, mas com apenas 6 unidades isso limita suas opções. Se sua carga de trabalho não depende muito de tempdb para itens como classificações, tabelas de hash e isolamento de instantâneo, talvez seja melhor usar as 6 unidades SAS juntas no RAID 10. No entanto, se você souber ou tiver as métricas para provar isso tempdb é muito utilizado, então você deve mantê-lo separado como você tem.
A resposta real depende de suas necessidades, mas geralmente "colocar dados e fazer logon em matrizes diferentes" é mais importante do que "colocar tempdb em sua própria matriz".
Dado o número de unidades disponíveis, meu ponto de partida seria:
O que deve fazer é usar o SQLIO para testar o desempenho de diferentes configurações de drive.
Depende muito do que você entende por "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 fuso.
Para uma situação de gravação pesada, separar os logs dos dados pode fazer uma diferença significativa, pois cada gravação envolve a atualização do log e dos arquivos de dados, portanto, envolve uma quantidade razoável de rotação extra do cabeçote se ambos os conjuntos de arquivos estiverem no mesmo conjunto de eixos .
Sem mais referências à sua carga de trabalho (e às especificações dessas unidades e qualquer controlador que esteja entre elas e a máquina), eu estaria inclinado a optar por três volumes: um para programas OS+ e tempdb (dados), um para o banco de dados principal dados e o terceiro para logs (ambos tempdb e bancos de dados principais).
Claro, se suas cargas de trabalho são muito leves em operações de gravação, você não deve gastar muito tempo se preocupando em manter dados e logs separados, pois isso fará pouca diferença no desempenho e dedicar um volume inteiro para eles seria um desperdício de recursos disponíveis. espaço.
Dependendo do que você está usando o banco de dados para (OLTP vs warehousing), sua configuração parece uma boa configuração geral. Se você tivesse mais discos, teria mais opções.
Você poderia obter melhor desempenho se trocasse o disco do TempDB para RAID 0 (stripe). Isso aumenta o risco de falha, mas como o TempDB apenas armazena dados em buffer, você não pode sofrer perda de dados. Portanto, a maioria das pessoas considera isso uma compensação razoável. Apenas mantenha um sobressalente por perto (ou um sobressalente).
Uma coisa que você não mencionou, mas poderia tentar (se ainda não o fez): a Microsoft recomenda dividir seu TempDB em vários arquivos (um por CPU). Claro, é melhor se eles estiverem em discos separados, mas simplesmente ter arquivos separados ajuda. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx