Existe algum benefício em desfragmentar índices SQL em um ambiente SAN?


16

Nosso servidor SQL vive em uma SAN. Ele contém dezenas de bancos de dados OLTP, alguns com várias tabelas contendo mais de 1 milhão de registros.

Temos vindo a executar scripts de manutenção do índice de Ola Hallengren semanal, e ele é executado por várias horas de cada vez. Com base no limite de fragmentação, o script irá reorganizar ou reindexar um índice. Observamos que durante a reindexação, os arquivos de log ficam enormes, o que leva a um consumo excessivo de largura de banda durante o envio do log.

Em seguida, vem um artigo de Brent Ozar, no qual ele diz para parar de se preocupar com os índices SQL :

Seus discos rígidos são compartilhados com outros servidores que também fazem solicitações de unidade ao mesmo tempo, para que as unidades estejam sempre pulando por todo o lugar para obter dados. Desfragmentar seus índices é apenas um trabalho ocupado sem sentido.

Pesquisar esta questão no Google leva a opiniões divergentes, mais apoiadas por argumentos que parecem breves ou fracos demais. Nosso plano preliminar é ajustar o limite de fragmentação em nosso script de manutenção para que ele se reorganize com muito mais frequência do que reindexa.

Qual é o veredicto final? Vale a pena desfragmentar os índices SQL em uma SAN, considerando os encargos associados à execução de tarefas de manutenção semanais?

Respostas:


10

As estratégias de desfragmentação ajudam a melhorar a velocidade da digitalização para / do disco .

A grande variedade de opiniões ocorre porque a estratégia ideal de desfragmentação de um ambiente depende de muitos fatores diferentes. Existem também várias camadas potenciais de fragmentação em jogo.

Dizer que seus bancos de dados estão armazenados em uma SAN não é informação suficiente. Por exemplo:

  • Os arquivos de banco de dados são armazenados em grupos RAID físicos separados ou no mesmo grupo RAID? Quais outros processos estão ativos no mesmo dispositivo? Seus arquivos de backup também estão chegando lá? Talvez seja necessário solicitar essas informações ao administrador da SAN, porque elas nem sempre são transparentes.

  • Quais são os padrões de acesso para os bancos de dados? O OLTP geralmente é um acesso aleatório, mas às vezes um aplicativo fica satisfeito com a verificação da tabela e você não pode alterar seu comportamento (aplicativo ISV). Os aplicativos são principalmente de leitura, principalmente de gravação ou em algum lugar intermediário?

  • Existem SLAs de desempenho em execução durante um período de recuperação / failover ?

O post de Brent assume que há um gigantesco pool de armazenamento e tudo o compartilha. Isso significa que os discos físicos raramente ficam ociosos e, portanto, a maior parte do acesso é aleatória. Se essa é a sua situação, o conselho se aplica e eu concordo com ele em sua maior parte. Embora esse tipo de estratégia seja muito mais fácil de gerenciar, não é necessariamente (a) o que você tem em seu ambiente ou (b) qual é a melhor solução para seu ambiente.

Se a manutenção do índice for onerosa, considere fazê-lo de forma menos agressiva e / ou amortize o custo durante a semana (por exemplo, execute manutenção leve uma vez por dia, em vez de manutenção pesada uma vez por semana).

Você também pode ativar a SortInTempdbopção de reduzir potencialmente a quantidade de log que ocorre nos bancos de dados do usuário.


Uau, resposta completa. Provavelmente levará algum tempo para eu fazer toda a pesquisa, mas não duvido que você esteja me levando no caminho certo. Nossa estratégia atual é de fato executar a manutenção de forma menos agressiva, tanto do ponto de vista de reconstrução quanto de reorganização. A partir daí, farei mais pesquisas sobre o restante dos fatores que você mencionou.
dev_etter

11
@ dev_etter: listei apenas alguns fatores; há muito mais O ponto principal é a primeira frase. Se você se lembrar disso ao pensar em seu ambiente, ele direcionará corretamente sua decisão. Tudo deriva disso. (Além disso, tudo isto assume nenhuma SSD estão envolvidos.)
Jon Seigel

FWIW, eu tinha esquecido completamente de algo - o script real na etapa do trabalho (em vez da fonte) foi configurado para abordar todos os índices que tinham uma porcentagem mínima de fragmentação de 1. Aumentei até 15 e também o limite de reconstrução de 30 a 35. O trabalho agora é executado em pouco mais de 3 horas, em vez de 8. Sua sugestão de ser menos agressivo estava correta. Minha culpa estava no fato de eu achar que o trabalho já havia sido implementado para ser menos agressivo. Essa abordagem é provavelmente a melhor para nós, ainda tocamos e continuamos, mas já aliviou alguma dor.
Dev1_setter '

@ JonSeigel Concordo totalmente com esta resposta. Nas minhas viagens, vejo a maioria dos DBAs compartilhando um único pool ou pelo menos uma matriz no mesmo nível RAID. Eu tive DBAs ativos às 03:00 24x7 apenas para desfragmentar grupos de arquivos individuais de mais de 100 bancos de dados de TB ... e para o que exatamente? Tivemos IO totalmente aleatório nos discos e a latência foi de 15ms. Nesse ponto, devo apontar apenas 15ms e dizer aos desenvolvedores para me deixarem em paz.
ooutwire

2

Idealmente, você deve reorganizar / reindexar APENAS os índices que precisam de atenção; caso contrário, você está desperdiçando recursos e potencialmente causando outros problemas.

Você precisa estabelecer uma linha de base de desempenho e, sempre que fizer alterações, compare a alteração de desempenho com a linha de base para determinar se vale a pena implementá-la.


Nossa estratégia imediata é fazer exatamente isso - vamos ajustar as configurações das variáveis ​​minFragmentation e rebuildThreshold neste script: sqlfool.com/2011/06/index-defrag-script-v4-1
dev_etter

0

Ok, a pergunta é sobre índices de banco de dados, que são uma construção de um arquivo ou conjunto de arquivos. A leitura das respostas acima levaria uma pessoa a acreditar que estamos falando de fragmentação no nível do disco e não dos índices dentro de um arquivo. Estes assuntos totalmente separados.

A abordagem míope aqui é o desempenho ao recuperar dados no banco de dados OLTP e melhorar se os índices forem fragmentados ou reconstruídos. A resposta é sim! No entanto, é importante observar que a fragmentação do disco também é um fator.

"Custo" mais baixo em geral? Faça sua manutenção de banco de dados. Segundo menor custo, desanexe o banco de dados, mova-o para outro lugar, formate novamente seus discos e siga as práticas recomendadas para o alinhamento de partições de disco http://msdn.microsoft.com/en-us/library/dd758814.aspx . Por último, mas não menos importante, use um desfragmentador avançado de terceiros como o Diskkeeper.

Lembre-se de que isso APENAS é recomendado para armazenamento do tipo NTFS (por exemplo, sistema operacional Windows) e não é um endosso a nenhum produto, nem sou afiliado à Condusiv Technologies ou suas subsidiárias.


2
Você provavelmente deseja evitar categoricamente dizer "A resposta é SIM!" para espaços problemáticos que foram discutidos longamente por outros pôsteres. Embora possa ser verdade que, às vezes, a resposta seja "Sim", como Brent Ozar mostrou em seu blog, esse nem sempre é o caso.
Max Vernon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.