Assumindo memória constante (32 gb) e CPU (4), 2 x matrizes de disco, tenho os seguintes discos
- 2 x 150 (10k)
- 6 x 150 (15k)
Eles são todos discos locais.
meus requisitos
- Meu banco de dados é de 350 GB e definido como padrão de 10% de crescimento
- Meu SO e SQL Server são Server 2k8R2 (C: drive OS + página + aplicativos = 55Gb)
- Os requisitos de log são de cerca de 70 GB e definidos como padrão de crescimento de 10% e são rotineiramente truncados
- Meu TempDb é de cerca de 12 GB atualmente e definido como padrão de 10% de crescimento
Meu problema é que estou tentando entender onde colocar melhor o TempDB e o SO e o Log. Minha experiência é limitada na configuração ideal desses dois
Este não é um sistema transacional online. Ele tem gravação pesada de dados (novos dados + reconstrução/reorganização de índices), leitura pesada de dados (estou estimando em cerca de 50/50) processamento por cerca de 13 horas e, em seguida, apenas silêncio.
Meu entendimento é que o TEMPDB é muito usado durante o processamento normal em comparação com o log.
minha ideia é a seguinte
- 2 x 150g (15k) Raid 1 = 150g para SO + TempDB
- 2 x 150g (10k) Raid 1 = 150g para LOG (observe os discos mais lentos aqui)
- 4 x 150g (15k) Raid 5 = 150g para dados
Isso soa como uma boa ideia? Eu poderia então trocar o Log + TempDB, se necessário.
Estou quebrando uma regra fundamental, como nunca colocar TempDB no disco do sistema operacional devido a problemas de paginação ou talvez nunca colocar log em um disco mais lento que os dados ?
Editar:
Também temos um SSAS no sistema e os usuários finais acessam apenas o Cubo. Os 50% lidos acima são baseados no tempo necessário para processar o banco de dados SSAS.
2 * 10k RAID1 para sistema operacional, 6 * 15k RAID10 para todo o resto. Honestamente, com tantos discos, 1 array é a aposta mais segura e geralmente mais rápida.
Se você tiver tempo para testar e tiver uma carga de trabalho real, repetível e mensurável, faça um teste com seu tempdb na unidade do sistema operacional (advertência: limite o crescimento do arquivo tempdb para garantir que você não estrague o sistema operacional) . Por outro lado, você pode ver melhorias moderadas em sua carga de dados e manutenção com o log lá, então vale a pena fazer um teste ou dois, se o tempo permitir.
Concordo com Mark que a abordagem ideal é colocar as duas unidades mais lentas em RAID 1 apenas para sistema operacional e o restante das unidades em RAID 10 para todo o resto. Isso seria o ideal.
Com base nos tamanhos que você forneceu, no entanto, isso praticamente o maximiza para começar, com muito pouca margem de erro e sem espaço para crescimento. E, a propósito, se alguém lhe disser que as unidades têm 150 GB, elas podem ser menores que isso (146 GB?), Não formatadas, o que provavelmente significa que nem tudo vai caber logo de cara.
Infelizmente, a carga de trabalho envolve gravações pesadas e, para isso, o RAID 5... não é seu amigo.
Se você conseguir arranjar um pouco de orçamento extra, existem algumas abordagens:
Mais duas unidades de 15k do mesmo tamanho. Dependendo do significado de "2 matrizes de disco", > 8 unidades no total podem significar a necessidade de um novo controlador RAID. (E/ou um chassi maior, possivelmente.)
Dois SSDs de aproximadamente 120 GB (PCI-express ou SATA) no software RAID 1 para dados/log do TempDB e o arquivo de log do banco de dados. Na verdade, essa pode ser a solução mais rápida, ponto final, e pode custar consideravelmente menos do que 2 unidades de 15k de classe empresarial (sem falar em um controlador RAID comparável). Isso pressupõe que haja slots/portas disponíveis na placa-mãe, o que provavelmente existe.
Se o gerenciamento não seguir o orçamento (essa situação parece que o hardware antigo está sendo reaproveitado para um novo projeto... o que significa que o orçamento é zero), você terá que usar o RAID 5 por questões de espaço, porque não há maneira de evitá-lo sem mais discos disponíveis. Nesse ponto, a melhor jogada é provavelmente colocar os 2 discos mais lentos no RAID 1 apenas para O/S e o restante no RAID 5 para maximizar o espaço. Se você for forçado a usar o RAID 5 para qualquer parte disso, o gerenciamento deve aprovar (por escrito) a compreensão do que isso significa em termos de desempenho.