Quando os índices não clusterizados devem ser armazenados em grupos de arquivos separados?

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. Eu também ouvi dizer que isso é um mito.

Quando é aconselhável armazenar índices não clusterizados em um grupo de arquivos e 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. Eliminar gargalos no nível do disco melhorará o desempenho. Quando os dados estão sendo pesquisados ​​e um índice é usado, o índice é pesquisado primeiro e, em seguida, os dados correspondentes são buscados. Se o índice e os dados estiverem nos mesmos discos, haverá alguma contenção. Considerando que, se os dados estavam em um disco (físico) diferente, ocorre uma E / S mais rápida, aumentando assim o desempenho. A principal parte a ser observada é que os dados ou o índice estão em discos físicos ou LUNs separados.

Você usaria esse cenário se precisar obter melhor desempenho do seu sistema, desde que tenha os discos. Para que sua contadores perfmon você poderia usar Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/secpara ter um antes e depois da comparação das suas alterações.

Certamente, é verdade que espalhar sua E / S simultânea entre unidades diferentes aumentará o desempenho - isso não é mito. É um mito que fazer isso duas vezes melhorará o desempenho novamente.

Se você MESMO , dividir sua matriz em duas partições e colocar índices em uma e tabelas em outra é uma perda de tempo.

Separar índices dos dados em grupos de arquivos separados = a melhoria do 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 diferentes grupos de arquivos não oferece um 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?

1. Você deseja melhorar o desempenho dos backups NÃO incluindo os índices?
2. Você está procurando melhorar o desempenho de leituras e gravações nesses índices?
3. Você está fazendo isso para uma melhor capacidade de gerenciamento da colocação dos objetos subjacentes?
4. Você tem grandes volumes de dados com diferentes necessidades de desempenho?
5. Você está procurando usar SSDs para índices não agrupados em cluster para melhorar o desempenho etc ...

Eu olhei para esta tarefa para apoiar a necessidade do número 5 na lista acima e parece uma boa proposta para mim, embora ainda não tenhamos adotado isso.

Observe que essa decisão NÃO é tão fácil de tomar e você precisa descobrir o que está tentando fazer e garantir 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 idéia. NÃO vale a pena se você está esperando 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 agrupados em cluster 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, era criar um bom script para recriar todos os índices não agrupados on-line 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 é assim, realmente.

Em 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 em conjunto :-).

Em geral; dividir dados e índices em discos separados com desempenho semelhante pode aumentar o desempenho de operações substanciais de gravação nessa tabela ou em operações de leitura grandes 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 é amplamente dependente do armazenamento . Por exemplo; se você possui um servidor com um bom ioDrive do Fushion (ou algo semelhante) e também possui discos giratórios individuais. Pode ser mais benéfico manter tudo no ioDrive (a menos que o espaço seja limitado). Também há outras coisas a serem levadas em consideração - configuração RAID, configuração de armazenamento em rede.

Faça alguma marcação de bancada em um servidor de teste com hardware semelhante ou (apenas se um servidor secundário não for uma opção) durante o horário não de pico com dados temporários. O link DBA-Monkey de Sankar acima é um bom alimento para reflexão.