Qual a fragmentação dos Indices

É importante verificar a fragmentação de um indice, pois isso pode indicar tanto problema na manutenção em Geral dos Bancos de Dados como problemas de Design dos Índices .

Podemos ter problemas diretos e indiretos relacionados a fragmentação de um indice.

Problemas Diretos

  • Aumento de leituras, sobrecarregando os discos
    Quando um indice esta fragmentado é como se tivessemos um livro onde após a página 89 você passa a ter a página 90, assim se você quer copiar da pagina 85 a 95 você terá o trabalho extra de localizar as páginas que estão fora de ordem.
  • Ordem de colunas incorreta ou FillFactor incorreto
    Normalmente deve ser criado indices colocando primeiro colunas que tem mais valores distintos, mas as vezes essa organização não satisfaz bem determinada consulta “então precisamos analisar caso a caso”.
    Campos que possuem campos como chave que são frequentemente alterados , devem utilizar um fillfactor entre 70 e 90, pois quando um registro é alterado para “continuar na mesma pagina” ele deve ter espaço para isso , se a pagina esta totalmente preenchida o registro acaba sendo colocado em outra pagina ocasionando assim a fragmentação.

Problemas Indiretos

  • Estatisticas Desatualizadas
    Se o indice estão fragmentados provavelmente as estatisticas não sejam atualizadas também, pois normalmente a estatistica de um indice é atualizada automaticamente quando o SQL Server esta habilitado “mas quase nenhum DBA confia nisso … neu eu =)” , outras possibilidades é atualizando diretamente a estatistica ou com Rebuild do indice “lembre-se que reorganzine não atualiza a estatistica”.
  • Plano de Execução de Consultas Inconsistente
    Com indices fragmentados e estatisticas desatualizadas provavelmente o SQL Server  não consiga gerar um plano de execução adequado para uma consulta. Isso além de gerar problema de consultas irá gerar mais IO, CPU e Memória, pois o Servidor precisara de mais recursos por não estar utilizando o melhor caminho de execução.

Com todos esses problemas que podem ser ocasionados, podemos ter um Cenário que aparentemente o Servidor necessite de mais memória, processador e CPU , mas na verdade o mesmo está com esse sintoma por estar realizando mais trabalho que ele realmente precisa fazer.

Por isso é importante analisar todos os pontos antes de decidir que decisão tomar pra solucionar um problema.

Identificando Fragmentação: http://blog.sqlauthority.com/2010/01/12/sql-server-fragmentation-detect-fragmentation-and-eliminate-fragmentation/

 

SQL Server – Tuning para Desenvolvedores – Geral

Quando se fala de tuning primeiro passo é coletar informações do estado atual do ambiente, um problema de perfomance pode ser simples como a criação de um indice ou complexo como mover tabelas e indices para novos discos ou trocar um raid 5 por um raid 10. Pode também ser necessárias  várias ações em conjunto.

Um ponto de partida seria responder algumas perguntas como esta abaixo:

  1. A lentidão é em todas as partes do sistema?
  2. A Lentidão afeta todos os sitemas que possuem Bases de Dados nesse servidor?
  3. Esta lento o tempo todo ou apenas em alguns periodos do dia ou dias da semana?
  4. O Servidor é dedicado para o SQL Server?
  5. As bases de dados estão numa storage ou em disco no proprio servidor?
  6. Quantos discos fisicos o servidor possui?Quanto de memória dedicada para o SQL Server ?
  7. Qual a fragmentação dos Indices?
  8. Quando ocorreu a última atualização de estatisticas?
  9. Existe alguma ação que quando tomada resolve temporariamente o problema?Por quanto tempo?
  10. Número de deadlocks e de Blocks?

Respondendo todas essas perguntas é um bom inicio para investigar o problema. No caso de ser um problema apenas em alguma parte especifica do sistema podemos já utilizar o profiler e focar nas tabelas especificas.

Após o questionário ser respondido começa a coleta de informações:

  1. Utilizar Profiler utilizando template Tuning “adicione as colunas StartTime , CPU, reads e writes” pegando consultas acima de 1 segundo (ajuste esse número para mais ou menos dependendo do volume retornado ).
  2. Utilizar o PerfMon para coletar informações de disco, processador, memoria e estatiscas do SQL Server
  3. Verficar os logs do windows e sql.
  4. Analisar se foram aplicadas boas praticas ao TempDB
  5. Coletar informações Consultas mais pesadas (IO e  CPU)
  6. Verificar Contenção  “gargalos” que podem afetar a performance Geral
  7. Verificar Blocks e DeadLocks
  8. Montar ambiente de teste para utilizar DTA

Nos próximos posts vou detalhar cada etapa.

Primeira Letra de Cada Palavra em Maiusculo

Outro dia um amigo me perguntou e então dei uma pesquisada e encontrei um código simples que faz isso … como estava em C# converti para VB.Net
 

‘Fonte Original em C# http://csharpaspnet.blogspot.com/2007/04/c-string-totitlecase-intial-letter.html

Public Shared Function ToTitleCase(ByVal inputString As String) As String

 

Dim cultureInfo As System.Globalization.CultureInfo = System.Threading.Thread.CurrentThread.CurrentCulture

Dim textInfo As System.Globalization.TextInfo = cultureInfo.TextInfo

 

Return textInfo.ToTitleCase(inputString.ToLower())

End Function

 
 

Windows Workflow Foundation

Reflection No Dia a Dia – Parte 01

Geralmente quando falamos de Reflection pensamos em códigos sendo gerados em runtime, carregar uma dll dinamicamente e coisas que assustam, mas por outro lado podemos usar reflection para coisas bem menos complexas, porém muito uteis.

Por exemplo no código abaixo uso reflection para pegar o nome do método onde a exception foi gerada.

Utilizo o getype().tostring para pegar o nome do objeto e com  MethodBase.GetCurrentMethod().Name pego o nome do método , assim logo o nome da classe e do método onde o erro ocorreu, poderia estar logando o tempo de execução do método.
…..
catch (Exception ex) {
               
                retorno = false;

                System.Diagnostics.Trace.WriteLine(this.GetType().ToString() + " – " + System.Reflection.MethodBase.GetCurrentMethod().Name + "[" + ex.Message + "]");
           
            }

Para uma visão geral dos recursos da utilização de Reflection sugiro os links : http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=264
e http://iamacamera.org/default.aspx?section=home&id=58

Comparação de Texto (String)

Embora seja uma das tarefas mais triviais da programação a comparação entre strings costuma gerar muito bugs nos sistema por um simples detalhe.
No .Net assim como na maioria das linguagens de programação por padrão a comparação de string é case sensitive, com isso temos erros como

var1 = "teste";
var2 = "Teste";

if (var1 == var2)
//aos olhos do programador inexperiente o código deveria executar essa parte
else
// mas como a comparacao é case sensitive o bloco executado será esse

/////////////////////// Para corrigir esse pequeno Bug devemos usar o código abaixo //////////////////////////////////
if (var1.Equals(var2, StringComparison.OrdinalIgnoreCase))
  // Agora sim esse código sera executado
else
 //E esse sera ignorado

Outra forma  de evitar esse erro seria usar a função ToLower (caixa baixa) ou  ToUpper (caixa baixa) para que ambos as variaveis fiquem com a mesma caixa.

Links de referência:
http://msdn.microsoft.com/en-us/library/system.stringcomparison.aspx

http://msdn.microsoft.com/en-us/library/ms973919.aspx

Padrão para Métodos – Part 1

Muito ja li sobre padrões de como os métodos devem ser feitos , ja vi muito código de outros programadores e também os meus códigos antigos, com base nessa experiência vou listar os pontos positivos e negativos que ja vi nesses quase 10 anos de profissão:
 
Métodos com mais de 100 linhas, porque:

Nunca Faça
    • Nem você vai entender o código direito depois de duas semanas
    • Dificil entendimento , terrível para dar manutenção
    • Mais dificil de evoluir
    • Está fazendo mais do que o nome do método Diz …

Tente Fazer

    • Métodos que possam ser lidos na resolução de 1024  sem precisar de scroll
    • Crie métodos auxiliares para decompor o código, assim fica facil de melhorar e debugar problemas
    • O código do método deve fazer o que o nome sugere assim o código fica de facil entendimento , ficando quase auto documentado

Métodos com 30 parametros
Nunca Faça

  • Fica complicado  de ver todos os parametros. Provavelmente você esteja fugindo da orientação a objeto
  • Fica facil inverter a ordem de algum valor e daí haja debug para achar o erro

Tente Fazer

  • Procure criar objetos e passar os objetos para o método ou trabalhar com propriedades

 

Duplicação de código Ctrl + C , Ctr + V

Nunca Faça

  • Código duplicado significa dois lugares para corrigir e/ou melhorar
  • Torna o código mais extenso do que o necessário
  • Aumenta em muito as chances de bug na aplicação, pois qualquer alteração tem que mapear os lugares onde o código esta duplicado

Tente Fazer

  • Quando precisar de uma funcionalidade que esta embutida em algum método, extraia a mesma para um método separado
  • Métodos com poucas linhas tendem a ser reutilizados, pois são bem especializados numa tarefa

 

Regra de Negócio  utilizando exception

Nunca Faça

  • Utilizar exception para regra de negócio degrada a performance
  • Falta de planjemanento

Tente Fazer

  • Trabalhe com o envio de mensagens
  • Planeje a troca de mensagens, para facilitar tanto a camada de negócios como a interface da aplicação

 

 

 

Convert.ToString/(String) X objeto.ToString


Embora o uso do ToString  seja  bem comodo para nós , acaba nos trazendo uma dor de cabeça desnecessária, pois para usar o ToString temos que garantir que  o valor não seja um nulo ou o famoso dbnull , senão uma exception nos aguarda.

Poucos sabem que existe uma maneira simples de corrigir isso que é utilizando o Convert.toString , no código abaixo se executado vocês poderam ver que o erro de conversão só ocorre na linha do tostring …

 

Dim teste As Object = Nothing

Dim teste2 As String

teste2 = Convert.ToString(teste)

teste2 = teste.ToString()