{"id":8779,"date":"2026-09-29T13:00:51","date_gmt":"2026-09-29T16:00:51","guid":{"rendered":"https:\/\/powertuning.com.br\/blog\/?p=8779"},"modified":"2026-09-29T09:52:06","modified_gmt":"2026-09-29T12:52:06","slug":"de-mais-de-2-horas-para-16-segundos-como-reduzimos-em-9980-o-tempo-de-um-relatorio-no-sql-server","status":"publish","type":"post","link":"https:\/\/powertuning.com.br\/blog\/de-mais-de-2-horas-para-16-segundos-como-reduzimos-em-9980-o-tempo-de-um-relatorio-no-sql-server\/","title":{"rendered":"De mais de 2 horas para 16 segundos: como reduzimos em 99,80% o tempo de um relat\u00f3rio no SQL Server"},"content":{"rendered":"

\u201cAntes eu podia colocar o relat\u00f3rio para executar e ir tirar uma soneca. Agora n\u00e3o d\u00e1 nem tempo de se levantar da cadeira.\u201d<\/strong> \ud83d\ude02<\/p>\n

Imagino que essa tenha sido a rea\u00e7\u00e3o do cliente ap\u00f3s ver o resultado de um trabalho de Tuning realizado em seu ambiente SQL Server:<\/p>\n

\"\"<\/p>\n

O relat\u00f3rio analisado levava mais de duas horas para ser conclu\u00eddo. Durante sua execu\u00e7\u00e3o, consumia uma quantidade expressiva de CPU, realizava centenas de milh\u00f5es de leituras l\u00f3gicas e provocava press\u00e3o sobre recursos importantes do ambiente.<\/p>\n

Ap\u00f3s a otimiza\u00e7\u00e3o, o mesmo relat\u00f3rio passou a executar em aproximadamente 16 segundos.<\/strong><\/p>\n

Mais do que reduzir o tempo de uma consulta, o trabalho eliminou um importante ponto de conten\u00e7\u00e3o no ambiente.<\/p>\n

\n
\n
<\/div>\n<\/div>\n

O problema foi identificado pelo Power Alerts<\/h3>\n

O diagn\u00f3stico come\u00e7ou a partir das nossas rotinas de monitoramento do Power Alerts, que identificaram a consulta ofensora de CPU.<\/p>\n

Com apenas 40 minutos de execu\u00e7\u00e3o, a consulta j\u00e1 havia consumido mais de 34 milh\u00f5es de milissegundos de CPU, atingindo o pico de 100% de uso da CPU do servidor.<\/p>\n

\n
\n
<\/div>\n<\/div>\n

Mas por que alertou s\u00f3 depois de 40 minutos em execu\u00e7\u00e3o?<\/h3>\n

Pensando em diversos cen\u00e1rios para uma variedade de clientes, nossos alertas possuem thresholds configur\u00e1veis,<\/strong> por raz\u00f5es internas, esse cliente havia configurado o threshold para alertar apenas quando a CPU atingisse 98%<\/strong> de uso, e isso permanecesse por mais de 5 minutos seguidos<\/strong>, se n\u00e3o fosse isso, o alerta j\u00e1 teria sido disparado muito antes.<\/p>\n

Um detalhe, \u00e9 que este cliente est\u00e1 utilizando uma vers\u00e3o mais antiga dos alertas, e mesmo assim atendeu a necessidade para este ambiente, agora imagine com vers\u00e3o atual que tem mais de 98 mil linhas de c\u00f3digo?!\u00a0<\/strong><\/p>\n

A seguir um print de uma parte do e-mail enviado para o cliente, j\u00e1 era poss\u00edvel identificar pela coluna CPU Delta<\/strong>, o ofensor com maior consumo:<\/p>\n

\"\"<\/p>\n

Esse ponto \u00e9 essencial em trabalhos de performance: antes de alterar uma consulta, \u00e9 necess\u00e1rio entender qual processo est\u00e1 realmente impactando o ambiente, com que frequ\u00eancia isso acontece e quais recursos est\u00e3o sendo consumidos.<\/p>\n

Nesse caso, o monitoramento permitiu encontrar uma consulta que, apesar de representar apenas um relat\u00f3rio para o usu\u00e1rio, tinha um impacto significativo no SQL Server.<\/p>\n

\n
\n
<\/div>\n<\/div>\n

O cen\u00e1rio encontrado<\/h3>\n

A consulta apresentava uma estrutura complexa, com:<\/p>\n