Administração de índices (Parte 2).

Depois de vários dias sem postar, finalmente consegui um tempinho para escrever a segunda parte da série de posts que falarão sobre a sua rotina de desfragmentação dos índices.

Como foi falado no Post anterior, muitos DBA’s usam o seguinte script para realizar a desfragmentação de seus índices: http://technet.microsoft.com/en-us/library/bb838727(v=office.12).aspx

Eu também já usei, mas hoje no ambiente em que trabalho esse script não serve mais e listo aqui o porquê que essa rotina já não é tão eficiente para mim.

  1. O ambiente não há uma janela muito flexível para esse tipo de manutenção;
  2. O ambiente é muito grande, pois temos várias instâncias e em cada instância temos no mínimo 50 bases de dados;
  3. Apesar de existirem tabelas que fragmentam mais de 15% diariamente, nem todas podem entrar na rotina, pois são muito grande (20GB cada uma) e se elas fizerem parte dessa rotina automática, podem causar um estouro no disco (justamente por não ter um controle de quais tabelas serão fragmentadas no dia);
  4. Essa rotina não faz a validação do tamanho da tabela. Apesar de a tabela estar fragmentada, se ela for pequena o SQL Server não realiza o REBUILD da mesma.

Pelo que eu me lembre, eu trabalhava em um ambiente em que a rotina de desfragmentação dos índices era esse script. Na época a base de dados tinha em torno de 200GB e essa rotina executava diariamente. O tempo de duração em média era 2h podendo demorar 1h e tinha dias de demorava até 4h, porém tinha dias também que essa rotina não executava, pois ocorria um DeadLock.  Naquele ambiente, apesar de demorar muito e ter essa concorrência no banco, essa rotina não tinha nenhum efeito colateral, pois a janela era realmente grande e não causava impacto para o usuário final.

Atualmente temos que reindexar algumas tabelas relativamente grandes, porém a minha janela diária de manutenção é de no máximo 30min, se passar disso já tem um impacto para o usuário final podem causar até um prejuízo financeiro para instituição. Nesse caso qual é a minha solução? Atualmente faço o Rebuild da forma “simples” com o seguinte comando:

 ALTER INDEX ALL ON Tabela REBUILD WITH (ONLINE=ON) 

Sim! É um trabalho bastante manual, pois tenho que saber direitinho quais são as tabelas que necessitam ser desfragmentadas, saber a frequência de fragmentação das mesmas, assim como o seu tamanho e dividir a rotina fazendo com que ela não estoure o nosso disco de log (isso porque tenho bastante espaço disponível). Lembrando que na minha rotina deve ter no máximo umas 30 tabelas (sendo que cada banco eu tenho em volta de 1700 tabelas). Essas 30 tabelas não são desfragmentadas tudo de uma única vez, temos rotinas que rodam diariamente, outras 2 vezes na semana e outra no Domingo.

Então, levando em consideração que temos 50 bases por instâncias, 1700 tabelas por base e somente 30min de janela por dia para realizar o Rebuild, concluímos que é muito arriscado colocar uma rotina automática para realizar a desfragmentação, pois não temos controle de quanto de log será gerado no momento da rotina…

Quero que pensem bem, sei que muitos ao realizarem essa rotina, não se preocupam com o log que será gerado nem com o espaço em disco utilizado por esse arquivo… Pensem um pouco sobre o quanto o Log pode sofrer com essas rotinas, lembrando que em um banco de dados, temos várias funcionalidades que utilizam o Log, alguém se habilita a dizer qual dessas funcionalidades “sofre” bastante com essa rotina de Rebuild? No próximo post (daqui um mês quem sabe rsrs) eu falo mais. Falarei também qual solução achamos para que os índices não fragmentem tanto, diminuindo assim, a frequência da rotina de desfragmentação.

Anúncios