{"id":4841,"date":"2025-08-12T13:00:27","date_gmt":"2025-08-12T16:00:27","guid":{"rendered":"https:\/\/powertuning.com.br\/?p=4841"},"modified":"2025-08-12T14:02:35","modified_gmt":"2025-08-12T17:02:35","slug":"um-caso-real-de-quando-o-tuning-salva-relatorios-e-economiza-memoria","status":"publish","type":"post","link":"https:\/\/powertuning.com.br\/blog\/um-caso-real-de-quando-o-tuning-salva-relatorios-e-economiza-memoria\/","title":{"rendered":"Um caso real de quando o tuning salva relat\u00f3rios e economiza mem\u00f3ria"},"content":{"rendered":"

Um cliente nos procurou reclamando de lentid\u00e3o extrema em um relat\u00f3rio. Ao nos conectarmos ao ambiente, consultamos o\u00a0Power Alerts,<\/strong>\u00a0nossa solu\u00e7\u00e3o de monitoramento, e percebemos que o relat\u00f3rio frequentemente apresentava o\u00a0wait type RESOURCE_SEMAPHORE<\/strong>.<\/p>\n

\"\"<\/p>\n

Para quem n\u00e3o est\u00e1 familiarizado, esse tipo de espera ocorre quando uma thread precisa aguardar a libera\u00e7\u00e3o de mem\u00f3ria para iniciar a execu\u00e7\u00e3o de uma consulta. E foi esse detalhe que nos permitiu conduzir uma investiga\u00e7\u00e3o muito mais precisa.<\/p>\n

A Descoberta<\/h3>\n

Durante a an\u00e1lise, identificamos que a consulta estava solicitando uma\u00a0concess\u00e3o de mem\u00f3ria de 49 GB<\/strong>. Agora imagine o impacto se essa mesma consulta fosse executada simultaneamente por 4 sess\u00f5es diferentes: estar\u00edamos falando de quase\u00a0200 GB de mem\u00f3ria<\/strong>\u00a0utilizados apenas para gerar um relat\u00f3rio. Um verdadeiro pesadelo para qualquer ambiente!<\/p>\n

\"\"<\/p>\n

Seguindo a investiga\u00e7\u00e3o, percebemos que o alto consumo de mem\u00f3ria estava sendo causado por uma opera\u00e7\u00e3o de\u00a0classifica\u00e7\u00e3o (sort)<\/strong>\u00a0dentro da consulta. Essa ordena\u00e7\u00e3o vinha de uma\u00a0VIEW<\/strong>, que realizava jun\u00e7\u00f5es com outras tabelas. O ponto crucial aqui \u00e9 que a forma como a consulta foi escrita impedia o SQL Server de aplicar o filtro diretamente na VIEW, o que fazia com que ela retornasse\u00a0mais de 400 milh\u00f5es de registros<\/strong>\u00a0at\u00e9 o ponto da jun\u00e7\u00e3o onde o filtro, de fato, era aplicado.<\/p>\n

A Solu\u00e7\u00e3o<\/h3>\n

Reescrevemos a consulta, ajustando a l\u00f3gica para que o filtro pudesse ser aplicado de forma mais inteligente e antecipada. O resultado foi surpreendente:<\/p>\n