Ouvi dizer que armazenar índices em um grupo de arquivos e unidade diferentes aumenta o desempenho em um banco de dados porque a unidade não precisa ir e voltar entre o índice e os dados aos quais o índice se refere. Também ouvi dizer que isso é um mito.
Quando é aconselhável armazenar índices não clusterizados em um grupo de arquivos e uma unidade separados? Que evidência de perfmon/profiler me levaria a chegar a essa conclusão? O hardware desempenha um papel na decisão (se um RAID/SAN é usado em uma única unidade)?
A parte mais lenta de um sistema de banco de dados são as unidades de disco. A eliminação de gargalos no nível do disco melhorará o desempenho. Quando os dados estão sendo pesquisados e um índice é usado, o índice é primeiro pesquisado e, em seguida, os dados correspondentes são buscados. Se o índice e os dados estiverem nos mesmos discos, haverá alguma contenção acontecendo. Considerando que, se os dados estiverem em um disco (físico) diferente, haverá IO mais rápido acontecendo, aumentando assim o desempenho. A parte principal a observar é que os dados ou índice estão em discos físicos separados ou LUNs.
Você usaria esse cenário se precisasse obter melhor desempenho de seu sistema, desde que tivesse os discos. Para seus contadores de perfmon, você pode usar
Physical Disk – Avg. Disk sec/Read,Physical Disk – Avg. Disk sec/Write,Physical Disk – Disk Reads/sec,Physical Disk – Disk Writes/secpara ter uma comparação antes e depois de suas alterações.Certamente é verdade que espalhar sua E/S simultânea entre diferentes unidades aumentará o desempenho - isso não é mito. É um mito que fazer isso duas vezes melhorará o desempenho novamente.
Se você SAME , dividir sua matriz em duas partições e colocar índices em uma e tabelas em outra é uma perda de tempo.
Separando índices de dados em grupos de arquivos separados = a melhoria de desempenho é altamente discutível. A melhoria de desempenho "pode" acontecer se você tiver o hardware subjacente para suportá-lo, mas apenas pelo fato de separá-los em grupos de arquivos diferentes não oferece aumento de desempenho. E também NÃO é fácil medir o aumento de desempenho por causa disso.
Ref: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx
Você deve fazer a pergunta primeiro. Por que você tem que fazer isso?
Eu olhei para esta tarefa para apoiar a necessidade de # 5 na lista acima e parece uma boa proposta para mim, embora ainda não tenhamos agido sobre isso.
Observe que esta decisão NÃO é tão fácil de tomar e você precisa descobrir o que está tentando fazer e certificar-se de que possui o hardware para suportar. Não faça alterações como essa, a menos que você tenha testado bem e veja um aumento significativo no desempenho, caso contrário, você também pode abandonar essa ideia. NÃO vale a pena se você espera um aumento de desempenho simplesmente separando os índices em grupos de arquivos separados.
Vou contar minha experiência pessoal em relação a este item. Os índices não clusterizados devem ser armazenados em um grupo de arquivos separado quando a unidade de disco atual não for grande o suficiente para o espaço necessário :-). Você pode rir disso... mas acontece.
Portanto, uma correção de emergência para nós, quando estávamos prestes a ficar sem espaço livre em uma unidade de dados, foi criar um bom script para recriar todos os índices não clusterizados online em um novo grupo de arquivos em uma unidade com espaço livre. Alguém poderia pensar que é fácil e rápido comprar um novo armazenamento... mas não é bem assim.
Com relação ao desempenho, não vimos nada fora do comum após a mudança. Mas é uma grande caixa de armazenamento SAN onde tudo é mantido junto :-).
No geral; a divisão de dados e índices em discos separados com desempenho semelhante pode aumentar o desempenho para operações de gravação substanciais nessa tabela ou grandes operações de leitura que utilizam esse índice. Uma metodologia semelhante a algumas outras operações de E/S, como uma tabela particionada espalhada por vários discos físicos.
No entanto, também depende muito do armazenamento . Por exemplo; se você tiver um servidor com um bom Fushion ioDrive (ou algo semelhante) e também tiver discos giratórios individuais. Pode ser mais benéfico manter tudo no ioDrive (a menos que o espaço seja limitado). Há também outras coisas a serem consideradas - configuração de RAID, configuração de armazenamento de rede.
Faça algumas comparações em um servidor de teste com hardware semelhante ou (somente se um servidor secundário não for uma opção) durante os horários de pico com dados temporários. O link DBA-Monkey de Sankar acima é um bom alimento para reflexão.