A tabela Custos possui os campos id (INT), numero documento (VARCHAR(20)), centro custo ((VARCHAR(30)), data_lancamento (DATE) e valor (DECIMAL(12,2)) e pertence ao banco de dados MS SOL Server da SCGE, instalado e funcionando em condições ideais. A equipe da SCGE está enfrentando lentidão em consultas sobre a tabela Custos, que registra documentos financeiros por centro de custo. Durante uma auditoria de desempenho, foi executado o seguinte comando SQL no MS SQL Server: SELECT qs.total logical reads AS LeituraTotal, qs.execution count AS Execucoes, qs.total worker time AS TempoCPU, DB NAME(qt.dbid) AS Banco, OBJECT NAME(qt.objectid, qt.dbid) AS Objeto, qt.text AS Consulta FROM sys.dm exec query stats qs CROSS APPLY sys.dm exec sql text (qs.sql handle) qt WHERE qt.text LIKE '%FROM Custost' ORDER BY qs.total logical reads DESC; Analisando a consulta realizada, o comando
Aexibe as consultas DML (INSERT, UPDATE, DELETE) mais recentes executadas sobre a tabela Custos, ordenadas pela quantidade de registros de leitura lógica.
Bverifica as estatísticas de desempenho do SQL Server e lista as queries mais custosas à tabela Custos, exibindo quantidade de leituras, tempo de CPU e número de execuções.
Capresenta os índices da tabela Custos que estão fragmentados e precisam ser reorganizados para melhorar o desempenho.
Dexibe os planos de execução armazenados para todas as consultas que acessaram a tabela Custos, ordenando pelo tempo total de leituras realizadas.
Elista os comandos executados através de consultas à tabela Custos, agrupando por centro de custo e exibindo a quantidade de leituras, o tempo de CPU e o tempo de execução.
Revelar gabarito e comentário▾
GabaritoB — verifica as estatísticas de desempenho do SQL Server e lista as queries mais custosas à tabela Custos, exibindo quantidade de leituras, tempo de CPU e número de execuções.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
SQL Server: DMVs de desempenho (sys.dm_exec_query_stats)
Gabarito: letra B. A consulta apresentada utiliza as DMVs (Dynamic Management Views) sys.dm_exec_query_stats e sys.dm_exec_sql_text para obter estatísticas de execução das consultas que referenciam a tabela Custos, exibindo leituras lógicas, tempo de CPU e número de execuções — exatamente o que descreve a alternativa B. O comando não mostra índices fragmentados, nem planos de execução, nem agrupa por centro de custo.
As DMVs são visões dinâmicas de gerenciamento do SQL Server que expõem informações internas sobre o estado e o desempenho do servidor. Elas são a principal ferramenta para diagnóstico de lentidão, pois permitem identificar quais consultas estão consumindo mais recursos. A consulta do enunciado cruza duas DMVs: sys.dm_exec_query_stats, que guarda estatísticas agregadas por consulta (como leituras lógicas, tempo de CPU e contagem de execuções), e sys.dm_exec_sql_text, que, a partir do sql_handle, recupera o texto SQL da consulta. O CROSS APPLY faz a junção entre elas, e o filtro LIKE '%FROM Custos%' restringe o resultado às consultas que mencionam a tabela Custos. O ORDER BY total_logical_reads DESC ordena pelas consultas com maior número de leituras lógicas — ou seja, as mais custosas em termos de I/O.
É importante entender o que cada coluna representa: total_logical_reads é o número total de leituras lógicas (páginas lidas do buffer pool) realizadas por todas as execuções da consulta; execution_count é quantas vezes a consulta foi executada; total_worker_time é o tempo total de CPU consumido (em microssegundos). Essas métricas são acumuladas desde que o plano foi compilado ou desde a última limpeza das estatísticas. A consulta não distingue o tipo de comando (SELECT, INSERT, UPDATE, DELETE) — ela captura qualquer consulta que tenha sido compilada e executada, desde que o texto contenha a string 'FROM Custos'.
A pegadinha da questão está em confundir o propósito da consulta: ela não analisa índices (isso seria feito com sys.dm_db_index_physical_stats), não exibe planos de execução (isso seria com sys.dm_exec_query_plan), e não agrupa por centro de custo (não há GROUP BY). O foco é puramente estatístico: quais consultas estão pesadas em leituras e CPU. A alternativa B captura exatamente isso.
Guarde a distinção entre as DMVs: sys.dm_exec_query_stats = estatísticas de execução (leituras, CPU, duração, execuções); sys.dm_exec_sql_text = texto da consulta; sys.dm_exec_query_plan = plano de execução; sys.dm_db_index_physical_stats = fragmentação de índices. É nessa fronteira que as alternativas se dividem.
DMVs de desempenho (SQL Server)
1sys.dm_exec_query_stats
total_logical_reads (leituras lógicas)
execution_count (nº de execuções)
total_worker_time (tempo de CPU)
2sys.dm_exec_sql_text
recupera o texto SQL (sql_handle)
3sys.dm_exec_query_plan
plano de execução (XML)
4sys.dm_db_index_physical_stats
fragmentação de índices
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que a consulta exibe as consultas DML mais recentes. O erro está em "mais recentes": a DMV sys.dm_exec_query_stats não armazena a data/hora da última execução (não há coluna de timestamp no resultado), e o filtro não restringe a DML — qualquer consulta que contenha 'FROM Custos' aparece, inclusive SELECTs. Além disso, a ordenação é por leituras lógicas, não por recência.
Alternativa B — ✅ Correta ⟵ GABARITO
Descreve com precisão o que a consulta faz: verifica as estatísticas de desempenho do SQL Server (via DMVs) e lista as queries mais custosas à tabela Custos, exibindo quantidade de leituras (total_logical_reads), tempo de CPU (total_worker_time) e número de execuções (execution_count). O ORDER BY total_logical_reads DESC garante que as mais custosas apareçam primeiro. É exatamente o propósito da consulta.
Alternativa C — ❌ Incorreta
Afirma que a consulta apresenta índices fragmentados. Isso é feito com a DMV sys.dm_db_index_physical_stats, que retorna informações de fragmentação (avg_fragmentation_in_percent, page_count, etc.). A consulta do enunciado não toca nessa DMV — ela lê estatísticas de execução de consultas, não de índices.
Alternativa D — ❌ Incorreta
Afirma que a consulta exibe planos de execução. Planos de execução são obtidos com sys.dm_exec_query_plan (que retorna o plano em XML) ou sys.dm_exec_text_query_plan. A consulta usa sys.dm_exec_sql_text, que retorna apenas o texto SQL, não o plano. Além disso, a ordenação é por leituras lógicas, não por "tempo total de leituras" (que nem é uma métrica padrão).
Alternativa E — ❌ Incorreta
Afirma que a consulta agrupa por centro de custo. Não há cláusula GROUP BY na consulta — ela apenas filtra consultas que mencionam a tabela Custos e ordena por leituras. O agrupamento por centro de custo seria feito em uma consulta sobre os dados da tabela (ex.: SELECT centro_custo, SUM(valor) FROM Custos GROUP BY centro_custo), não sobre as DMVs. Além disso, a consulta não exibe "tempo de execução" (duration), apenas tempo de CPU.