Questão de Banco de Dados — Administração de banco de dados — FGV 2026
Banco de Dados›Administração de banco de dados
Código
fg127349
Banca
FGV
Órgão
AL-RO
Ano
2026
Nível
Superior
Cargo
Analista Legislativo (Tecnologia da Informação - Banco de Dados)
Um sistema de emissão de relatórios está lento. Após analisar o plano de execução, o DBA identifica que o SGBD está realizando um Table Scan em uma tabela de milhões de registros, mesmo com um filtro no campo DATA_OCORRENCIA.O princípio fundamental de tunning a ser aplicado e o impacto esperado na performance da consulta é
Aaumentar a quantidade de memória RAM alocada para o buffer pool, o que melhorará o cache hit ratio, mas não o plano de execução da consulta.
Bcriar um índice Non-Clustered na coluna DATA_OCORRENCIA, o que permitirá ao otimizador utilizar a busca por índice em vez da varredura completa.
Calterar o tipo de dado da coluna DATA_OCORRENCIA para VARCHAR, o que facilita as operações de string.
Dforçar o uso de um Merge Join em vez de um Nested Loop Join, pois o Merge Join é sempre mais rápido.
Edesativar todas as Stored Procedures relacionadas ao relatório, pois elas introduzem latência no processamento.
Revelar gabarito e comentário▾
GabaritoB — criar um índice Non-Clustered na coluna DATA_OCORRENCIA, o que permitirá ao otimizador utilizar a busca por índice em vez da varredura completa.
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”.
Tuning de consultas SQL: índices e Table Scan
Gabarito: letra B. Criar um índice Non-Clustered na coluna DATA_OCORRENCIA permite ao otimizador utilizar a busca por índice (Index Seek) em vez da varredura completa (Table Scan), reduzindo drasticamente o número de páginas lidas e melhorando a performance da consulta.
A situação descrita é clássica: uma tabela de milhões de registros com um filtro em DATA_OCORRENCIA, mas o SGBD opta por Table Scan. Isso indica que não há um índice adequado na coluna filtrada. O princípio fundamental de tuning é fornecer ao otimizador um caminho de acesso mais eficiente por meio de índices.
NÃO CAIA NESSA!
A alternativa A (aumentar a memória RAM) parece tentadora, pois melhora o cache hit ratio. Porém, isso não altera o plano de execução: a consulta continuará fazendo Table Scan, lendo todas as páginas da tabela (ainda que algumas estejam em cache). O gargalo não é a falta de memória, mas a falta de um índice que permita acesso seletivo.
PEGA ESSA DICA!
Sempre que uma consulta com filtro em uma coluna não indexada realizar Table Scan, considere criar um índice nessa coluna (se a seletividade do filtro for boa). É a primeira ação de tuning a ser avaliada.
Aspecto
Descrição
Impacto na Performance
Problema identificado
Table Scan em tabela com milhões de registros, mesmo com filtro em DATA_OCORRENCIA
Consulta lê todas as páginas da tabela, causando lentidão
Princípio de tuning
Fornecer caminho de acesso eficiente via índices
Permite ao otimizador usar Index Seek em vez de varredura completa
Solução correta (B)
Criar índice Non-Clustered na coluna DATA_OCORRENCIA
Melhora cache hit ratio, mas não altera o plano de execução
Solução incorreta (C)
Alterar tipo de dado para VARCHAR
Não resolve o problema de acesso; prejudica operações de data
Solução incorreta (D)
Forçar Merge Join
Não se aplica ao problema (filtro, não junção)
Solução incorreta (E)
Desativar Stored Procedures
Não elimina a causa raiz (falta de índice)
Alternativa A — ❌ Incorreta
Aumentar a memória RAM para o buffer pool melhora o cache hit ratio, mas não altera o plano de execução. O SGBD continuará realizando Table Scan, pois não há índice que o optimizer possa usar. A lentidão persiste, pois todas as páginas da tabela ainda precisam ser lidas (embora algumas possam vir do cache). O erro está em confundir ajuste de buffer pool com criação de índices.
Alternativa B — ✅ Correta ⟵ GABARITO
Criar um índice Non-Clustered na coluna DATA_OCORRENCIA permite que o otimizador realize um Index Seek, acessando apenas as páginas do índice que correspondem ao filtro, e depois utilize operações de RID Lookup (ou, se o índice cobrir a consulta, fazer apenas a leitura do índice). Isso reduz drasticamente o número de páginas lidas, eliminando o Table Scan. É a solução de tuning mais direta para o problema descrito.
Alternativa C — ❌ Incorreta
Alterar o tipo de dado de DATA_OCORRENCIA para VARCHAR não resolve o Table Scan e ainda degrada a performance: comparações de string são mais lentas que comparações de data, e o índice (se existir) passaria a ser ineficiente para ordenação temporal. A alteração de tipo não guarda relação com a falta de índice.
Alternativa D — ❌ Incorreta
Forçar um Merge Join é uma intervenção no método de junção, mas o problema descrito é de acesso a uma única tabela (Table Scan), não de junção entre tabelas. Mesmo que houvesse um join, o Merge Join não é "sempre mais rápido" — depende do tamanho das tabelas e da ordenação dos dados. Além disso, forçar o plano de execução é uma prática de último recurso; o correto é criar índices para que o otimizador escolha o melhor plano naturalmente.
Alternativa E — ❌ Incorreta
Desativar Stored Procedures não elimina o Table Scan. Procedures são conjuntos de comandos SQL que podem ser otimizados independentemente. A lentidão está na consulta específica que faz o scan, e a procedure apenas a encapsula. A solução é ajustar a consulta (criar índices, reescrever etc.), não desativar o encapsulamento. Além disso, procedures podem melhorar a performance ao reduzir o tráfego de rede e permitir planos de execução reutilizáveis.