Como qualquer pessoa que gerencia bancos de dados sabe muito bem, o ajuste de desempenho do SQL Server é uma função crítica para garantir o desempenho ideal. Com o desempenho dependente de vários fatores, como memória, configuração, design de consulta e uso de recursos, isolar a causa raiz da degradação do desempenho não é tarefa fácil.
Em vez de esperar pela ocorrência de problemas de desempenho, o ajuste proativo do SQL Server garantirá que suas instruções SQL sejam executadas da maneira mais eficiente possível, ajudando o SQL a encontrar a rota de entrada e saída mais rápida para fornecer os resultados da consulta.
Se você está lutando com um desempenho lento - ou não é do tipo que apenas espera que os problemas surjam - aqui estão três áreas principais para focar seu ajuste de desempenho do SQL Server para obter um desempenho ideal e sistemas mais saudáveis.
Dica nº 1:otimize seu TempDB
O TempDB configurado incorretamente é um culpado comum ao analisar a degradação do desempenho. Se você costuma preencher seu TempDB, é hora de dar uma olhada no que precisa mudar.
Primeiro, verifique o tamanho do TempDB. Não existe uma regra rígida e rápida sobre o tamanho que deve ser, mas uma boa regra geral é manter o TempDB em 25% do seu maior banco de dados ou do mesmo tamanho do seu maior índice. Isso evita ter que aumentar o TempDB durante as reconstruções.
Com o TempDB, quanto mais rápido o drive, melhor. Quando o TempDB é colocado em uma unidade lenta ou na mesma unidade do SO, você certamente verá problemas de desempenho do banco de dados. Se possível, mantenha o TempDB em um SSD local dedicado. Se isso não for possível, sua próxima melhor opção é mantê-lo em seu próprio volume dedicado com espaço em disco pré-alocado suficiente.
Também é importante manter os dados e os arquivos de log separados e definir um valor fixo grande para o crescimento automático do TempDB. Caso contrário, você será atingido por uma sobrecarga desnecessária toda vez que o TempDB for preenchido.
Controlar o número de arquivos de dados TempDB contribui para a otimização do TempDB. Mas a grande questão é:quantos arquivos de dados TempDB você precisa? Idealmente, você terá um arquivo de dados TempDB para cada CPU lógica, mas não mais de oito no total (com algumas exceções). Por exemplo, se você tiver quatro CPUs lógicas, precisará de quatro arquivos de dados TempDB. Se você tiver 12 CPUs lógicas, poderá ter oito arquivos de dados TempDB.
Dica 2:evite gargalos de desempenho
Existem três tipos principais de gargalos de desempenho do SQL Server que contribuem para o baixo desempenho:CPU, memória e E/S. As causas, sintomas e diagnósticos diferem de acordo com o tipo de gargalo, então aqui está um guia rápido sobre o que observar:
Afunilamentos de CPU
Causa: Recursos de hardware insuficientes
Sintomas: Uso constante do processador alto
Métricas a serem monitoradas: % de tempo do processador, solicitações de lote/s, compilações SQL/s e recompilações SQL/s
Afunilamentos de memória
Causa: Limitações na memória disponível e pressão de memória causadas pelo SQL Server, sistema ou outra atividade do aplicativo
Sintomas: Resposta lenta do aplicativo, lentidão geral do sistema e falhas no aplicativo
Métricas a serem monitoradas: Memória disponível (KB), memória total do servidor (KB), memória do servidor de destino (KB), páginas/s, páginas de ponto de verificação/s, gravações lentas/s e taxa de acertos do cache de buffer
Afunilamentos de E/S
Causa: Leitura e escrita excessivas de páginas de banco de dados de e para o disco
Sintomas: Longos tempos de resposta, lentidão de aplicativos e tempos limite de tarefas
Métricas a serem monitoradas: Comprimento médio da fila de disco, média de disco por segundo/leitura, média de disco por segundo/gravação, % de tempo de disco, média de leituras de disco/s e média de gravações de disco/s
Dica 3:certifique-se de que os índices sejam projetados adequadamente
Os índices são uma ótima maneira de acelerar determinadas operações do SQL Server, mas somente se forem bem projetados. Índices mal projetados têm o efeito oposto e são uma maneira segura de matar o desempenho do SQL Server.
A configuração adequada dessas quatro áreas pode ajudar a garantir que os índices sejam projetados corretamente e ajudar em vez de prejudicar o desempenho do SQL Server.
Tamanho da tabela
Nem toda tabela é uma boa candidata para indexação. Na verdade, se uma tabela for muito pequena, é muito mais eficiente para o SQL Server pesquisar a tabela inteira em vez de pesquisar por índices. Obviamente, o oposto é verdadeiro para tabelas grandes, portanto, você precisa avaliar a sobrecarga potencial ao decidir quais tabelas se beneficiariam dos índices.
Tipos de índice
Tecnicamente, cada tabela de banco de dados pode ter um índice clusterizado e um número infinito de índices não clusterizados, mas você sabe o que eles dizem sobre "Só porque você pode fazer alguma coisa"...
Muitos índices não clusterizados podem retardar significativamente as operações de inserção e atualização, portanto, manter um índice clusterizado e o número mínimo de índices não clusterizados absolutamente essenciais é uma opção de design muito melhor.
Armazenamento de índice
Durante a fase de projeto, selecionar os critérios de armazenamento adequados para índices é crucial para o desempenho de E/S. Índices clusterizados particionados e índices não clusterizados podem ser armazenados no mesmo grupo de arquivos que a tabela principal ou podem ser armazenados em um grupo de arquivos diferente. Armazenar um índice não clusterizado em um grupo de arquivos localizado em uma unidade de disco diferente pode melhorar o desempenho das consultas que o utilizam, pois ele não é afetado pela leitura simultânea dos dados e das páginas de índice SQL que ocorrem em diferentes unidades de disco.
FILFATOR
FILLFACTOR especifica a porcentagem de espaço que será preenchida em cada página de dados ao criar um índice. Os valores de FILLFACTOR podem variar de 0 por cento (nenhuma página de dados está preenchida) a 100 por cento (a página de dados está completamente preenchida). Ao projetar seu índice, selecione um valor FILLFACTOR que otimizará o uso da página enquanto minimiza o risco de fragmentação excessiva do índice.
Tornar o ajuste de desempenho do SQL Server parte de sua rotina padrão é uma excelente maneira de garantir que seus bancos de dados sejam executados com desempenho máximo. A incorporação dessas três etapas simples em seus planos regulares de manutenção do SQL Server melhorará notavelmente a velocidade e o desempenho de seus usuários.
