Share via

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.

Comments

  • Anonymous
    September 22, 2010
    Interessante, pena que não pude estar presente, mas vale as recomendações !!!

  • Anonymous
    September 22, 2010
    Felizmente nos encontramos próximos a sala dos palestrantes. Foi um prazer conhecê-lo!

  • Anonymous
    September 22, 2010
    The comment has been removed

  • Anonymous
    September 22, 2010
    Grande Felipe, quem sabe você aparece na próxima! Abraços - Fabricio

  • Anonymous
    September 22, 2010
    A palestra foi muito interessante e, com certeza, uma das melhores de SQL que vi no teched! Agora é esperar o PPT para poder fazer alguns testes.

  • Anonymous
    September 22, 2010
    Muito bom Vladimir! Agradeço por prestigiar a palestra e nos vemos novamente ano que vem. Abraços, Fabricio