Your SlideShare is downloading. ×
0
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MANUTENÇÃO DE ÍNDICES: O GUIA DEFINITIVO

1,013

Published on

Apresentação feita para o evento 24hs of PASS PT …

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,013
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  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. 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. 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. 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. DEMOFill 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. DEMORebuild + shrink7
  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. 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. DEMOFragmentação de ramo10
  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. DEMOCompressão de índice não-cluster12
  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 comandos14
  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 inesperados16
  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. 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. Questions?Ivan Lima Luciano Caixeta Moreira – {Luti}“PASS Supporter - SQLServerDF ” PASS Chapter Leader - SQLServerDFhttp://ivanglima.com/ http://luticm.blogspot.com@sqlinsane @luticm
  20. Thank You for Attending

×