A Diretoria de Tecnologia de um órgão público responsável pela gestão de benefícios sociais mantém um banco de dados relacional que sustenta o sistema de cadastro e concessão de auxílios. Nos últimos meses, a área de atendimento relatou aumento significativo no tempo de resposta durante consultas de histórico de beneficiários e atualização de cadastros. A equipe técnica observou elevação constante do tempo médio de espera por E/S em disco, crescimento da taxa de bloqueios entre transações concorrentes e aumento do tempo de execução de consultas complexas envolvendo múltiplas junções. Acerca do monitoramento de banco de dados, à luz de métricas de desempenho e identificação de gargalos, o diagnóstico adequado indica que
Ao crescimento da base de dados implica na migração para banco de dados não relacional, considerando as métricas coletadas.
Ba principal causa do problema está na insuficiência de memória RAM, devendo ser priorizada sua ampliação para a otimização do desempenho.
Ca inconsistência está no gargalo em subsistema de armazenamento e em concorrência transacional, exigindo análise de índices, planos de execução e contenção de locks.
Da elevação do tempo médio das consultas indica a necessidade de reescrita do sistema em linguagem de maior desempenho computacional.
Ea existência de múltiplas junções em consultas complexas demonstra falha conceitual do modelo de dados, exigindo desnormalização de todas as tabelas do sistema.
Revelar gabarito e comentário▾
GabaritoC — a inconsistência está no gargalo em subsistema de armazenamento e em concorrência transacional, exigindo análise de índices, planos de execução e contenção de locks.
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”.
Diagnóstico de gargalos em banco de dados relacional
Gabarito: letra C. O quadro descrito — elevação do tempo de espera por E/S em disco, crescimento de bloqueios entre transações concorrentes e lentidão em consultas com múltiplas junções — aponta para gargalos clássicos de subsistema de armazenamento e de concorrência transacional, cuja solução passa por análise de índices, planos de execução e contenção de locks. As demais alternativas propõem remédios genéricos ou equivocados (migrar para NoSQL, ampliar RAM, reescrever o sistema, desnormalizar tudo), que não atacam as causas identificadas.
O monitoramento de desempenho de um SGBD relacional exige correlacionar sintomas com causas. O aumento do tempo de espera por E/S em disco indica que o subsistema de armazenamento está saturado — seja por falta de índices adequados (que forçam varreduras completas de tabela), seja por configuração inadequada de buffers, seja por contenção física no disco. O crescimento da taxa de bloqueios entre transações concorrentes aponta para contenção de locks: transações disputando os mesmos recursos (linhas, páginas, tabelas) sem que o SGBD consiga escalonar adequadamente. Já o aumento do tempo de execução de consultas complexas com múltiplas junções sugere que o otimizador de consultas não está encontrando bons planos de execução — muitas vezes por falta de estatísticas atualizadas, índices ausentes ou mal projetados, ou por junções que poderiam ser reescritas.
A diagnose correta não é trocar de paradigma (NoSQL), nem apostar cegamente em mais memória RAM, nem reescrever o sistema em outra linguagem, nem desnormalizar todas as tabelas. São medidas paliativas ou desproporcionais. O caminho técnico adequado é investigar o plano de execução das consultas lentas (via EXPLAIN), verificar a utilização de índices, analisar a contenção de locks (através de sys.dm_tran_locks no SQL Server, pg_locks no PostgreSQL, SHOW ENGINE INNODB STATUS no MySQL, etc.) e, a partir dessas evidências, decidir por ajustes como criação/refinamento de índices, reescrita de consultas, particionamento de tabelas ou ajuste de parâmetros de concorrência.
Um exemplo concreto: uma consulta que junta as tabelas beneficiario, auxilio e historico sem índice na coluna de junção (beneficiario.id em historico) força o SGBD a varrer toda a tabela historico para cada linha de beneficiario — um nested loop catastrófico. A criação de um índice em historico.beneficiario_id reduz drasticamente o custo. Da mesma forma, se duas transações atualizam a mesma linha de beneficiario em sequência, a segunda fica bloqueada até a primeira commitar — e se houver muitas transações assim, a taxa de bloqueios dispara. A solução pode envolver reduzir o tempo de transação, usar isolamento adequado ou particionar dados.
A pegadinha da banca está em oferecer soluções genéricas e aparentemente plausíveis (RAM, NoSQL, reescrita) que não se sustentam diante das métricas específicas apresentadas. O candidato que conhece os fundamentos de otimização de SGBD identifica que o enunciado descreve exatamente os sintomas de gargalo de I/O e de concorrência, e que a resposta correta é a que propõe investigar índices, planos de execução e locks.
Critério
Diagnóstico correto (C)
Diagnósticos equivocados (A, B, D, E)
Causa identificada
Gargalo em subsistema de armazenamento (E/S) e concorrência transacional (locks)
Migração para NoSQL (A); insuficiência de RAM (B); linguagem de programação (D); falha conceitual do modelo (E)
Ação proposta
Análise de índices, planos de execução e contenção de locks
Troca de paradigma (A); ampliação de hardware (B); reescrita do sistema (D); desnormalização total (E)
Aderência às métricas
Correlaciona diretamente E/S, bloqueios e junções com técnicas de otimização
Trata sintomas genéricos ou causas não demonstradas pelas métricas
Solução única e desproporcional, sem base nas evidências apresentadas
Alternativa A — ❌ Incorreta
O crescimento da base de dados não implica, por si só, migração para banco não relacional. Bancos relacionais lidam bem com grandes volumes quando bem projetados e indexados. A migração para NoSQL seria uma decisão de arquitetura baseada em requisitos de escalabilidade horizontal, flexibilidade de esquema ou tipos de dados específicos — não uma consequência automática de crescimento. As métricas apresentadas (E/S, locks, junções) são problemas de desempenho que se resolvem dentro do próprio SGBD relacional.
Alternativa B — ❌ Incorreta
A insuficiência de memória RAM pode contribuir para mais E/S em disco (menos cache), mas não é a "principal causa" dedutível das métricas. O crescimento de bloqueios entre transações é um sintoma de contenção de locks, que não se resolve apenas com mais RAM. A resposta correta exige análise de índices, planos de execução e locks — não uma ampliação genérica de hardware.
Alternativa C — ✅ Correta ⟵ GABARITO
A alternativa sintetiza corretamente o diagnóstico: gargalo em subsistema de armazenamento (E/S em disco) e em concorrência transacional (bloqueios). A solução proposta — análise de índices, planos de execução e contenção de locks — é exatamente o conjunto de técnicas que um DBA utiliza para diagnosticar e resolver esses problemas. É a única alternativa que conecta os sintomas às causas e às ações corretas.
Alternativa D — ❌ Incorreta
Reescrever o sistema em outra linguagem de programação não ataca a causa do problema. O gargalo está no banco de dados (E/S, locks, planos de execução), não na linguagem da aplicação. Trocar de linguagem pode até piorar se o problema for no SGBD. A otimização deve ocorrer no nível do banco: índices, consultas, configuração.
Alternativa E — ❌ Incorreta
Múltiplas junções em consultas complexas não indicam falha conceitual do modelo de dados. Junções são operações normais e esperadas em bancos relacionais. A desnormalização de todas as tabelas seria uma medida extrema e inadequada — desnormalização se aplica pontualmente para melhorar desempenho de leitura em casos específicos, não como regra geral. O problema está na otimização das consultas, não no modelo.