O documento fornece um guia definitivo sobre manutenção de índices no SQL Server. Ele discute tópicos como: 1) conhecimentos gerais sobre índices e tipos de fragmentação; 2) fill factor padrão e seu impacto no desempenho; e 3) limites de fragmentação para reorganização e reconstrução. O guia também fornece recomendações como monitoramento constante, scripts de manutenção e atenção à ordem de execução para garantir o melhor desempenho dos índices.

1. Manutenção de índices: o guia definitivo
Ivan Lima Luciano Caixeta Moreira – {Luti}
“PASS Supporter - SQLServerDF” PASS Chapter Leader - SQLServerDF
http://ivanglima.com/ http://luticm.blogspot.com
@sqlinsane @luticm
http://www.srnimbus.com.br http://www.srnimbus.com.br

2. Agenda
Conhecimento geral de índices
Fill factor padrão de x%
Shrink após um rebuild
Limites de fragmentação 10% e 30%
Fragmentação de ramo (da B+tree)
Compressão de índice não-cluster
O guia definitivo
2

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ção
3

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. DEMO
Fill factor padrão de 80%
5

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. DEMO
Rebuild + shrink
7

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ísticas
8

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. DEMO
Fragmentação de ramo
10

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. DEMO
Compressão de índice não-cluster
12

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. 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 comandos
14

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. 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
inesperados
16

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 origem
17

18. De acordo com o guia do DBA das
galá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. Questions?
Ivan Lima Luciano Caixeta Moreira – {Luti}
“PASS Supporter - SQLServerDF ” PASS Chapter Leader - SQLServerDF
http://ivanglima.com/ http://luticm.blogspot.com
@sqlinsane @luticm

20. Thank You for Attending