Questão de Banco de Dados — Otimização (Tuning) em Banco de Dados — FCC 2026
Banco de Dados›Otimização (Tuning) em Banco de Dados
Código
fc142377
Banca
FCC
Órgão
MPE SE
Ano
2026
Cargo
Ana ( )
No Ministério Público, a análise e o devido ajuste dos recursos de hardware e software para bancos de dados são fundamentais para garantir a disponibilidade de informações em processos judiciais eletrônicos. Considerando as boas práticas de gestão de desempenho e otimização de ambientes de dados, a ação mais adequada para assegurar o funcionamento eficiente do sistema é:
ADirecionar esforços para o aumento da área de swap do sistema operacional, pois a memória virtual resolve integralmente as necessidades de caching do banco de dados.
BPriorizar o aumento da capacidade de CPU como estratégia de otimização, uma vez que maior poder de processamento elimina gargalos de desempenho.
CFocar em técnicas de compressão de dados para reduzir espaço de armazenamento, já que a diminuição do volume físico é suficiente para manter a performance estável.
DRealizar monitoramento contínuo de métricas críticas, como tempo de resposta, uso de I/O e bloqueios de transação, ajustando parâmetros do banco e recursos de hardware conforme a demanda real identificada.
EOptar pela troca de plataforma de banco de dados quando a aplicação apresentar lentidão recorrente, considerando que novas tecnologias tendem a oferecer ganhos imediatos de desempenho.
Revelar gabarito e comentário▾
GabaritoD — Realizar monitoramento contínuo de métricas críticas, como tempo de resposta, uso de I/O e bloqueios de transação, ajustando parâmetros do banco e recursos de hardware conforme a demanda real identificada.
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”.
Otimização de desempenho em banco de dados
Gabarito: letra D. A gestão eficiente de desempenho de um banco de dados exige monitoramento contínuo das métricas críticas — tempo de resposta, uso de I/O, bloqueios de transação — e ajuste de parâmetros e recursos com base na demanda real identificada. As demais alternativas propõem soluções simplistas e pontuais (aumentar swap, CPU, compressão ou trocar de plataforma) que não resolvem gargalos de forma sustentável, pois ignoram a necessidade de diagnóstico baseado em evidências.
A otimização de desempenho (tuning) é o processo de escolha de uma estratégia adequada para processar consultas e operações, visando minimizar o tempo de resposta e obter ganho de desempenho. Esse processo envolve várias áreas: melhoria nas consultas SQL e uso adequado de índices, gerenciamento eficiente de memória e processamento, controle das operações de entrada/saída (I/O) e armazenamento, e monitoramento contínuo para identificar e corrigir problemas. O monitoramento é a base de todo o processo: sem ele, não se sabe onde estão os gargalos, e qualquer ação de ajuste é feita às cegas.
Na prática, um administrador de banco de dados (DBA) deve acompanhar métricas como tempo de resposta das consultas, taxa de acerto do buffer cache, uso de CPU e memória, e ocorrência de bloqueios (locks) e deadlocks. Com base nesses dados, ele pode decidir, por exemplo, criar um índice para acelerar uma consulta específica, ajustar o tamanho da SGA (System Global Area) no Oracle, ou redistribuir dados entre discos para reduzir contenção de I/O. A otimização é um processo contínuo e iterativo, não uma ação pontual.
A pegadinha desta questão está em apresentar soluções mágicas e imediatistas: aumentar swap, CPU, compressão ou trocar de plataforma. Essas ações podem até ajudar em casos específicos, mas não são a abordagem correta para "assegurar o funcionamento eficiente do sistema" de forma geral. A alternativa correta reflete a prática recomendada: monitorar, diagnosticar e ajustar com base em dados reais.
Guarde o critério decisivo: a otimização eficaz é baseada em monitoramento e ajuste contínuo, não em soluções pontuais de hardware ou software. É exatamente esse critério que separa a alternativa correta das demais.
Otimização de desempenho (tuning): Base: monitoramento contínuo (Tempo de resposta, Uso de I/O, Bloqueios de transação, Taxa de acerto do buffer cache); Ajustes com base em evidências (Parâmetros do banco (ex.: SGA), Índices, Recursos de hardware); Soluções pontuais (não resolvem) (Aumentar swap, Aumentar CPU, Compressão de dados, Trocar de plataforma)
Alternativa A — ❌ Incorreta
Aumentar a área de swap do sistema operacional não resolve integralmente as necessidades de caching do banco de dados. A memória virtual (swap) é muito mais lenta que a RAM e não substitui o buffer cache do banco, que armazena blocos de dados em memória principal para reduzir leituras em disco. A memória virtual pode até ajudar em casos de falta de RAM, mas não é uma solução para caching eficiente.
Alternativa B — ❌ Incorreta
Aumentar a capacidade de CPU não elimina gargalos de desempenho por si só. Gargalos podem estar em I/O, memória, bloqueios de transação, consultas mal otimizadas, entre outros. A CPU é apenas um dos recursos; sem diagnóstico, o aumento de CPU pode ser inútil se o gargalo for, por exemplo, em disco.
Alternativa C — ❌ Incorreta
A compressão de dados reduz espaço de armazenamento, mas não é suficiente para manter a performance estável. A compressão pode até melhorar o desempenho em alguns casos (menos I/O), mas também pode aumentar o uso de CPU para descompressão. Não é uma solução abrangente para otimização de desempenho.
Alternativa D — ✅ Correta ⟵ GABARITO
Esta alternativa reflete a prática recomendada de otimização: monitoramento contínuo de métricas críticas (tempo de resposta, uso de I/O, bloqueios de transação) e ajuste de parâmetros do banco e recursos de hardware conforme a demanda real identificada. É a abordagem baseada em evidências, que permite identificar gargalos e agir de forma direcionada.
Alternativa E — ❌ Incorreta
Trocar de plataforma de banco de dados quando a aplicação apresenta lentidão recorrente não é uma boa prática. A troca de plataforma é uma decisão complexa, cara e arriscada, que não garante ganhos imediatos de desempenho. O problema de lentidão geralmente está em consultas mal otimizadas, índices inadequados, configuração incorreta ou recursos insuficientes — não na plataforma em si.