No dia 01/02/2012 eu publiquei uma pesquisa no meu blog para analisarmos como está o desperdício no data cache do seu SQL Server (http://luticm.blogspot.com/2012/01/pesquisa-desperdicio-no-data-cache.html).
Como vocês podem ver pelas repostas, é usual termos um desperdício de 8% a 15%, o que isso significa? Se você tem um data cache com 30 GB de tamanho, então algo entre 2,4GB e 4,5GB está sendo desperdiçado.
É claro que não tenho ilusão de que 100% do data cache estará ocupado, pelo contrário, temos fragmentação normal dos índices, níveis não folha e outras páginas de controle usualmente possuem espaço livre, então parte desse espaço em memória vai ser desperdiçado sim! Mas você como DBA deve cuidar para que o desperdício seja o menor possível. Como?
- Modelando corretamente seu banco de dados
- Usando outros recursos, como compressão de dados (cuidado sempre com os trade-offs).
- Garantindo a manutenção dos seus índices
- Tomando muito cuidado com thresholds globais Fillfactor? PADIndex? Fragmentação para reorganize e Rebuild? Na boa, quem já fez treinamento comigo sabe que sou bem ácido em relação a essas recomendações universalmente aceitas, usualmente elas podem te prejudicar muito.
Todos vocês podem ver o que os outros publicaram e tirar suas próprias conclusões, então dentro do que foi mostrado eu gostaria de propor uma nova verificação para todos os ambientes: tentar minimizar o desperdício do data cache!
Qual o threshold? (Opa, acabei de falar mal de thresholds globais! Shame on me :-))
Se o seu negócio permitir (normalmente sim), vamos com uma meta ambiciosa: manter o desperdício do data cache sempre abaixo de 10%.
E claro que nem sempre a coisa é simples e muitos detalhes podem tornar a vida do DBA mais complexa (e divertida, porque não?). Imagine o seguinte... Seu índice apresenta fragmentação interna de 3% mas o desperdício dela no data cache para este objeto é de 50%!
Sim, isso pode acontecer com você, é o que eu chamo de fragmentação de um ramo da árvore (B-tree+), principalmente quando suas tabelas começam a crescer demais e uma fragmentação em um ramo mais utilizado pode passar despercebida, quando analisado todo o índice.
Esse seria um post longo, mas acabei escolhendo por publicar o artigo no SimpleTalk (http://www.simple-talk.com/sql/database-administration/no-significant-fragmentation-look-closer%E2%80%A6/) para ver se tinha aceitação também lá fora.
Então você somente pode considerar que leu esse post depois de ler o artigo inteiro e deixar lá seu comentário e avaliação, seja boa ou ruim.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Infelizmente, nem todo o controle para se ter um ambiente otimizado depende exclusivamente de vontade e ações do DBA, A questão dos thresholds globais, na maioria das vezes definidos pela própria Microsoft em seus KBs fica como referência para 99,99999% dos DBAs e "Gerentes", que barram e batem de frente quaisquer atividades que não condizem com estes...
ResponderExcluirIndependente de com quem, ou se mesmo sozinho, minha opinião é que TODO DBA (sem exceção) deveria estudar o funcionamento interno do SQL Server, para quebrar mitos, fugir dos thresholds globais e atuar no ambiente de acordo com a necessidade do mesmo.. e não simplesmente pelo fato de estar escrito em um KB.
Excelentes artigos (inclusive do Simple Talk)
Abraço...
Keep sharing your knowledge
Edvaldo Castro
Assino embaixo.
ResponderExcluirEm termos profissionais, o conhecimento não só do internals do SQL Server, mas também do sistema operacional, linguagens de programação, rede, enfim, de todos os segmentos da área de TI, colabora para um profissional mais seguro e um ambiente mais estável e controlado.
Espero que de pouco em pouco as pessoas comecem a perceber isso.
Abraços!