Os logs de transações geralmente são isolados em um volume separado. A lógica para essa prática, como eu a entendo, é que os dados do log de transações são gravados seqüencialmente - e os discos rígidos podem executar operações de gravação com velocidade muito maior sequencialmente, em vez de aleatoriamente. Isso ocorre devido à pequena agulha dentro da unidade, que precisa se mover muito mais longe ao gravar blocos de dados seqüenciais, em oposição a gravações aleatórias.
(Desculpe pela interpretação ingênua. Só estou tentando entender o que li.)
Com isso em mente ... Ocorre-me que as unidades de estado sólido não têm pequenas agulhas, bandejas e outras coisas movendo-se dentro delas. Se meu banco de dados e log de transações estiverem localizados em um único RAID 5 de oito unidades de estado sólido, há realmente alguma vantagem em mover o log de transações para seu próprio volume separado? Se o suposto aumento de eficiência é baseado na premissa de gravações seqüenciais, reduzindo a distância que as agulhas se movem e os pratos giram, e uma unidade de estado sólido não possui nenhuma dessas partes móveis, o que ganho ao isolar o registro?
fonte
Respostas:
Resposta curta, use uma única matriz, é improvável que haja ganho de desempenho ao separar logs de dados em 8 unidades SSD. Veja SQL on SSDs: Hot and Crazy Love para um comentário mais detalhado (e divertido) sobre SSDs. Preste atenção especial às notas sobre falhas correlatas dos SSDs.
Separar logs de dados em SSDs é mais um RPO (objetivo do ponto de recuperação) do que um problema de desempenho. A noção de que você pode reduzir seu RPO separando logs de dados, de modo que, no caso de a matriz de dados falhar, sua matriz de logs deve / pode permanecer acessível. O cauteloso consideraria uma marca / modelo de unidade diferente em cada uma das duas matrizes para mitigar o problema de falha correlacionada se o RPO fosse crítico.
Os comentários sobre a largura de banda do barramento são irrelevantes. Se você precisar mudar esse IO, terá problemas maiores com que se preocupar.
fonte
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?
fonte