TechEd Brasil 2010 – Falha Nossa

  • Article

Eu e o Fabio Gentile apresentamos a palestra SUP403 - SQL Server com foco em Diagnóstico de Desempenho. Por ser o último horário do último dia, decidimos manter a palestra no nível 300. Engraçado que, durante a fase de montagem da palestra, deparamos com algumas situações inusitadas e que poderiam ser classificadas como nível 400 (nível máximo):

  1. A primeira demonstração de alto consumo de CPU deixou a máquina em um estado devagar quase parando. As queries realizavam operações de Table Scan com paralelismo e não sobrava recurso para o usuário. A solução foi diminuir a prioridade do processo SQLSERVR.EXE para Base Priority = Low.
  2. Na mesma demonstração, um índice não-clustered seria criado para suportar a consulta e, assim, otimizar o consumo de recursos. A execução do comando CREATE INDEX já passava de 9 minutos e não havia terminado. Através da DMV sys.dm_exec_requests, descobrimos que a criação de índice esperava por memória (RESOURCE_SEMAPHORE). A solução foi diminuir o número de clientes concorrentes e aumentar o parâmetro “Max Server Memory” da instância SQL. Após a mudança, o índice foi criado em 17 segundos.
  3. Tentamos criar um cenário em que uma Stored Procedure realizava uma grande quantidade de escritas em uma tabela. Queríamos demonstrar as esperas pelo wait type WRITELOG, mas tudo o que se observava era PREEMPTIVE_OS_WRITEFILEGATHER. O problema estava relacionado com o fato de que o bloco de escrita (LogCache) era tão grande que precisava ser quebrado em pedaços menores. A solução foi evitar usar transações longas, intercalando com transações menores.
  4. No mesmo cenário de inserção de dados, a tabela usava campos INTEGER e CHAR(4000). Queria demonstrar as esperas pelo wait type WRITELOG, mas tudo o que observava era PAGEIOLATCH. A causa desse problema é que o gargalo estava nos Page Splits de dados e não nas operações de log. A solução foi substituir a coluna CHAR(4000) por outra INTEGER. Dessa forma, as páginas de dados armazenariam um maior número de registros e ocorreria um menor número de Page Splits.

Da próxima vez, guarderei todas essas situações para fazer uma palestra que seja 100% nível 400.