Manutenção de índices: o guia definitivoIvan Lima                            Luciano Caixeta Moreira – {Luti}“PASS Support...
AgendaConhecimento geral de índicesFill factor padrão de x%Shrink após um rebuildLimites de fragmentação 10% e 30%Fragment...
Conhecimento geral de índices   Índices = B+tree   Cluster e não-cluster   1 cluster por tabela - Nível folha contém da...
Fill factor padrão de x% Qual o fill factor padrão da sua instância? Qual o fill factor recomendado?       90%? 80%? 70...
DEMOFill factor padrão de 80%5
Shrink após o rebuild Rebuild cria um novo índice em outro local do arquivo Meu banco de 1,6TB cresceu 200GB depois dos ...
DEMORebuild + shrink7
Limites de fragmentação 10% e 30%   Limites de reorganize vs. rebuild   É a recomendação padrão que utilizamos e vemos p...
Fragmentação de ramo (da B+tree) Caso os seus índices sejam muito grandes, além do custo de manutenção o que pode acontec...
DEMOFragmentação de ramo10
Compressão de índice não-cluster Índices cluster usualmente são bons candidatos para uma compressão de registro (muitos c...
DEMOCompressão de índice não-cluster12
O guia definitivo Se no seu ambiente a janela de manutenção é de 10 horas e o tempo para rebuild completo é de 3 horas......
O guia definitivo Reorganize sempre        Respeite a sua janela de manutenção        É leve mas tem impacto. Caso de j...
O guia definitivo Considere a ordem de manutenção dos índices        Casos onde o cliente limita a janela e faz diariame...
O guia definitivo Fill factor específico para cada índice        Basta executar uma vez com o fill factor que deseja, na...
Mais outros... Limitar paralelismo        MAXDOP = 1        Janela mais longa, porém impacto de CPU menor (online) Sor...
De acordo com o guia do DBA dasgaláxias... Oh, excelentíssima e maior potência intelectual da galáxia, qual é o fill fact...
Questions?Ivan Lima                             Luciano Caixeta Moreira – {Luti}“PASS Supporter - SQLServerDF ”   PASS Cha...
Thank You for Attending
Upcoming SlideShare
Loading in …5
×

MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO

1,350 views
1,205 views

Published on

Apresentação feita para o evento 24hs of PASS PT
Autor: Luciano Moreira

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
1,350
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO

  1. 1. Manutenção de índices: o guia definitivoIvan Lima Luciano Caixeta Moreira – {Luti}“PASS Supporter - SQLServerDF” PASS Chapter Leader - SQLServerDFhttp://ivanglima.com/ http://luticm.blogspot.com@sqlinsane @luticmhttp://www.srnimbus.com.br http://www.srnimbus.com.br
  2. 2. AgendaConhecimento geral de índicesFill factor padrão de x%Shrink após um rebuildLimites de fragmentação 10% e 30%Fragmentação de ramo (da B+tree)Compressão de índice não-clusterO guia definitivo2
  3. 3. Conhecimento geral de índices Índices = B+tree Cluster e não-cluster 1 cluster por tabela - Nível folha contém dados N índices cluster - Nível folha contém referência para registro  RID (heap) ou KEY (clustered)  Composto, INCLUDE, Filtered Ausência de cluster = heap SYS.DM_DB_* Sys.dm_db_index_physical_stats (DBCC SHOW_CONTIG) Rebuild vs. Reorganize Tipos de fragmentação3
  4. 4. Fill factor padrão de x% Qual o fill factor padrão da sua instância? Qual o fill factor recomendado?  90%? 80%? 70%? 50%? Somente é válido para índices que se fragmentam Deixa espaço em branco na página = impacto no data cache! Fill factor = fator de preenchimento, não quanto você deixa vazio na página de dados!  AKA => Fill factor de 1% é “um pouco” ruim...! Vamos fazer cálculos...  Índice com 50GB acumulado em 2 anos de sistema em produção  Rebuild semanal  Fillfactor de 80% = 10GB de inserção em uma semana?!!!4
  5. 5. DEMOFill factor padrão de 80%5
  6. 6. Shrink após o rebuild Rebuild cria um novo índice em outro local do arquivo Meu banco de 1,6TB cresceu 200GB depois dos rebuilds  Normal, isso é o esperado quando se tem objetos grandes O log de transação também cresce muito!  Mas eu estou com Recovery Model Simple?  Sim meu caro, mas é uma transação então o minLSN prende seus VLFs! Mas eu tenho espaço livre, o SSMS me mostra! O que fazer?  Shrink do arquivo de log (não funciona com recovery model full?)  Shrink do arquivo de dados  NNNNNNÃÃÃÃÃÃÃÃÃÃOOOOOOO Problema de espaço não se resolve com “jeitinho”6
  7. 7. DEMORebuild + shrink7
  8. 8. Limites de fragmentação 10% e 30% Limites de reorganize vs. rebuild É a recomendação padrão que utilizamos e vemos por aí? Qual fragmentação? Lógica? Física? Interna? É uma boa recomendação?  Em geral sim! Mas... E se o seu índice não fragmenta mais de 30% entre a frequência de entrada do reorganize?  Rebuild NUNCA é executado! Você pode sobreviver com isso, talvez sim, mas com ressalvas...  Index interleaving e fragmentação física  Aplicar o fill factor (baixar % uso da página)  Estatísticas8
  9. 9. Fragmentação de ramo (da B+tree) Caso os seus índices sejam muito grandes, além do custo de manutenção o que pode acontecer? Uma fragmentação importante passar despercebida Como? Fragmentando um ramo da sua árvore, aquele ramo que você mais utiliza Resultado: DMV não te mostra um ramo, mas sim de toda a árvore.  Pode causar impacto similar ao fill factor de 80%, só que de 50% Artigo escrito em Fev/2012: No significant fragmentation? Look closer  http://www.simple-talk.com/sql/database-administration/no-significant- fragmentation-look-closer%E2%80%A6/9
  10. 10. DEMOFragmentação de ramo10
  11. 11. Compressão de índice não-cluster Índices cluster usualmente são bons candidatos para uma compressão de registro (muitos campos tamanho fixo, null, etc.) E os índices não-cluster, em especial tipos VARCHAR(x)?  Maria da Silva Silva, Maria da Silva Silvania, Maria da Silva Souza  Compressão de prefixo vai ficar interssante. Considerar o impacto de CPU! Qual o ganho potencial? Mais registros por página => melhor eficiência do data cache => menor quantidade de I/O => melhor desempenho Potencialmente ganho significativo na janela de manutenção dos seus índices (I/O bound)11
  12. 12. DEMOCompressão de índice não-cluster12
  13. 13. O guia definitivo Se no seu ambiente a janela de manutenção é de 10 horas e o tempo para rebuild completo é de 3 horas... REBUILD ALL!!! Script auxiliares:  http://ola.hallengren.com/  http://sqlfool.com/2011/06/index-defrag-script-v4-1/  Diversas opções, como por exemplo, limitar tempo da janela de manutenção Scripts do seu ambiente SQL Server Management Studio  Pode dar mais trabalho  Pode levar a erros ou problemas quando seus bancos de dados crescerem Tabelas com menos de 10.000 páginas (~ 80MB)  Rebuild com a maior frequência (diário)13
  14. 14. O guia definitivo Reorganize sempre  Respeite a sua janela de manutenção  É leve mas tem impacto. Caso de jobs simulâneos, ISCSI = timeout Índices grandes (de verdade)  Particionar índices  Campo data? Últimos 6 meses, 1 ano e ½ e restante  RAIDs diferentes (melhor desempenho para o hot spot)  Rebuild de partição Índices muito utilizados e grandes  Analisar fragmentação de ramos (índices filtrados ajudam)  Considere particionamento Pode trabalhar com 10% e 30%  Force o rebuild com certa regularidade  Como saber se houve reorganize ou rebuild de um índice?  Alterar script da Michele para guardar comandos14
  15. 15. O guia definitivo Considere a ordem de manutenção dos índices  Casos onde o cliente limita a janela e faz diariamente reorganize dos mesmos índices que fragmentam mais de 10% em um dia Solução não é um script genérico  São vários script menores para controlar objetos, ordem de execução, dias e horários, etc. Lembre-se da atualização de estatísticas  Reorganize não o faz  Depois de um rebuild completo ou do índice, não atualize a estatística dos índices (UPDATE STATISTICS ... COLUMNS) Cuidado com sys.dm_db_index_physical_stats  Principalmente com o DETAILED  Guarde os registros do resultado quando consultar a DMV (No I/O waste!)15
  16. 16. O guia definitivo Fill factor específico para cada índice  Basta executar uma vez com o fill factor que deseja, na próxima execução se não especificado o SQL Server usa o mais recente  Cuidado com geração de código que muda o fill factor  Leve em conta o percentual de atualização e novos dados  Se não sabe o fill factor e não tem ideia das características do objeto, deixe em 95% e monitore Monitoramento constante  Os padrões da sua aplicação não mudam com tanta frequência  Mas novos builds e sistemas novos podem trazer comportamentos inesperados16
  17. 17. Mais outros... Limitar paralelismo  MAXDOP = 1  Janela mais longa, porém impacto de CPU menor (online) Sort in TempDB  Trade-off de overhead com resultados intermediários do sort ONLINE  Impacto na tempdb (version store)  Limitações: LOB (SQL 2012 NCL LOB included), partição, XML, spatial  Online não é 100% online  Início: Shared lock no objeto de origem  Fim: Shared lock no objeto de destino e SCH-M lock na origem17
  18. 18. De acordo com o guia do DBA dasgaláxias... Oh, excelentíssima e maior potência intelectual da galáxia, qual é o fill factor padrão que devo adotar para TODAS as minhas instâncias SQL Server? (384833 anos processando a resposta e....) 42! Piadinha, ok?18
  19. 19. Questions?Ivan Lima Luciano Caixeta Moreira – {Luti}“PASS Supporter - SQLServerDF ” PASS Chapter Leader - SQLServerDFhttp://ivanglima.com/ http://luticm.blogspot.com@sqlinsane @luticm
  20. 20. Thank You for Attending

×