

Seu próximo nível começa aqui
Com a Assinatura Ilimitada, você tem tudo que precisa para sua aprovação.
Com a Assinatura Ilimitada, você combina prática, teoria e método em uma única assinatura com tudo que você precisa para sua aprovação.
Um Tribunal de Justiça identificou degradação de desempenho em consultas que filtram registros por múltiplas colunas combinadas por operadores lógicos AND na cláusula WHERE. A equipe de administração de banco de dados (DBA) decide criar um índice composto (multi-column index) para otimizar essas operações.
Considerando o funcionamento de índices compostos baseados em árvores balanceadas (B-Tree), em sistemas gerenciadores de bancos de dados relacionais, assinale a afirmativa correta.
A ordem das colunas na definição do índice não interfere em sua eficiência, uma vez que o otimizador de consultas reordena os predicados automaticamente para garantir o uso do índice.
A utilização do índice composto é otimizada quando os predicados da consulta seguem a ordem de definição das colunas no índice, respeitando a regra do prefixo à esquerda (leftmost prefix).
Um índice composto só pode ser utilizado pelo motor de execução se todas as colunas que o compõem forem obrigatoriamente referenciadas na cláusula de filtragem da consulta.
A criação de índices compostos em colunas com baixa seletividade garante, de forma determinística, a substituição do escaneamento sequencial de tabela (table scan) pelo escaneamento de índice (index scan).
Índices compostos tornam-se desnecessários em sistemas modernos que implementam técnicas como index skip scan, sendo a ordem das colunas irrelevante para o desempenho das consultas.
Um desenvolvedor backend está otimizando um sistema bancário que registra milhões de transações diárias na tabela TRANSACAO(id_transacao, id_conta, data, valor, tipo). Após análise dos logs do SGBD, ele identifica que consultas de extrato por id_conta estão consumindo tempo excessivo. Ao criar um índice sobre o atributo id_conta, as consultas passam a responder em milissegundos. Porém, durante os horários de pico, nos quais centenas de novas transações são registradas por segundo, o tempo de resposta das inserções aumenta visivelmente em comparação ao período anterior à criação do índice. Com base nesse cenário e nos conceitos sobre indexação em bancos de dados relacionais, assinale a alternativa correta.
O comportamento observado é uma limitação do tipo de índice utilizado, que só é eficiente para chaves primárias e chaves estrangeiras, sendo inadequado para atributos como id_conta por não garantir unicidade dos valores indexados.
O comportamento observado indica um problema de configuração, pois índices bem projetados devem melhorar indistintamente todas as operações SQL, incluindo inserções, atualizações e exclusões, sem qualquer impacto negativo no desempenho de escrita.
O comportamento observado ocorre porque o índice criado armazena uma cópia completa da tabela TRANSACAO ordenada pelo atributo id_conta, duplicando o espaço em disco e exigindo sincronização integral entre a cópia e a tabela original a cada operação de escrita.
O comportamento é esperado, pois índices melhoram o desempenho de consultas de busca ao reduzir o número de páginas acessadas, mas introduzem overhead nas operações de escrita, já que cada inserção ou atualização exige a manutenção das estruturas de índice correspondentes.
O comportamento observado indica que o otimizador de consultas do SGBD está ignorando o índice criado nas operações de leitura, priorizando varreduras completas da tabela por serem mais eficientes em tabelas com alto volume de inserções concorrentes.
Um Ministério Público Estadual tem posse de uma base de dados intitulada processos, criada no PostgreSQL 11+, em condições ideais, majoritariamente append-only nas quais são utilizados planos do tipo index-only scan. Contudo, ainda apresenta muitos heap fetches quando comandos são executados com EXPLAIN (ANALYZE, BUFFERS). A ação operacional que tende a viabilizar a leitura somente pelo índice com maior consistência é
alterar o nível de isolamento para REPEATABLE READ na sessão de leitura, pois isso torna as tuplas implicitamente visíveis ao índice.
forçar enable_seqscan = off na sessão, pois isso converte o plano em index-only scan evitando leituras no heap.
ajustar random page_cost para reduzir a penalidade de acesso aleatório e induzir o otimizador a evitar o heар.
executar VACUUM (rotineiro/automático bem ajustado) para aumentar a marcação alI-visible e reduzir a necessidade de visitar o heap.
criar um índice B-tree com INCLUDE nas colunas projetadas, pois isso elimina a dependência de visibilidade de tuplas no heap.
A criação de múltiplos índices nas tabelas de acompanhamento físico-financeiro da INFRA S.A. pode impactar negativamente o desempenho de operações de INSERT, UPDATE e DELETE nessas tabelas.
Certo
Errado
Considere a seguinte situação hipotética:
O sistema acadêmico de uma Universidade utiliza MySQL 8 como banco de dados principal. Durante o período de matrícula, o sistema começou a apresentar lentidão severa e, em alguns momentos, indisponibilidade. Em períodos anteriores de matrícula, foi necessário realizar reinicializações manuais diárias no servidor de banco de dados devido a instabilidades e degradação de desempenho.
Durante a análise, a equipe de Tecnologia da Informação identificou que:
Assinale a alternativa que apresenta a abordagem CORRETA para prevenir o problema de travamento e alta contenção no MySQL, bem como otimizar o desempenho do servidor nesse cenário:
Aumentar significativamente o parâmetro max_connections no MySQL para suportar mais requisições simultâneas.
Implementar uma rotina que reinicie automaticamente o banco de dados sempre que o número de conexões atingir 90% do limite configurado.
Refatorar o código para reduzir o padrão N+1, consolidar consultas, encurtar o tempo de transações abertas e implementar pool de conexões adequado na aplicação.
Alterar o mecanismo de armazenamento das tabelas de InnoDB para MyISAM para reduzir o uso de locks transacionais.
Considere a seguinte situação hipotética:
Uma universidade utiliza um sistema acadêmico para gerenciar informações de estudantes, dados cadastrais de pessoas e emissão de cartões institucionais. Um analista de dados precisa identificar estudantes ativos que ainda não possuem cartão institucional emitido.
Para isso, foi utilizada a seguinte consulta SQL em um banco de dados MySQL:

Fonte: dados do elaborador
Considere ainda que o analista avalia o seguinte plano de execução simplificado obtido por meio do comando EXPLAIN:

Com base na consulta apresentada, na semântica das operações de junção e em aspectos de otimização de consultas SQL, analise as afirmações a seguir.
I. A consulta apresentada pode ser reescrita de forma logicamente equivalente, utilizando uma subconsulta com NOT EXISTS para identificar estudantes que não possuem registros correspondentes na tabela cartoes_acesso.
II. No plano de execução apresentado, o tipo ALL, na tabela estudantes, indica que o otimizador está realizando uma varredura completa da tabela, o que pode ocorrer quando não há índice adequado para a condição de busca utilizada.
III. Caso a condição ca.id_cartao IS NULL fosse movida da cláusula WHERE para a cláusula ON do LEFT JOIN, o resultado da consulta permaneceria o mesmo.
IV. A consulta utiliza um padrão conhecido como anti-join, frequentemente empregado para localizar, em uma tabela, registros que não possuem correspondência em outra tabela.
Assinale a alternativa CORRETA.
As afirmações I, II, III e IV estão corretas.
Apenas as afirmações I e III estão corretas.
Apenas as afirmações I, II e IV estão corretas.
Apenas as afirmações II, III e IV estão corretas.
Os Extended Events no Microsoft SQL Server são ferramentas de monitoramento e diagnóstico, que permitem rastrear eventos com baixo impacto de desempenho, com maior flexibilidade e precisão, substituindo o SQL Profile.
Certo
Errado
Um desenvolvedor precisa listar todos os Funcionarios que não possuem nenhum Dependente cadastrado. Ele considera duas abordagens: uma usando NOT EXISTS e outra usando LEFT JOIN / IS NULL. Do ponto de vista de desempenho em um SGBD relacional, qual abordagem é geralmente considerada mais eficiente e por quê?
LEFT JOIN / IS NULL, porque junções são sempre mais rápidas que subconsultas.
NOT EXISTS, porque a subconsulta pode ser anti-join usando o índice da chave estrangeira em Dependentes.
NOT IN, porque é a sintaxe mais simples e direta para esta necessidade.
FULL OUTER JOIN, porque verifica a ausência de dados em ambas as tabelas.
Ambas têm desempenho idêntico, pois o otimizador as converte para o mesmo plano.
Seja o seguinte esquema relacional de banco de dados:
tb_processos(id_processo, numero_processo, tipo, status, data_abertura)
Restrições:
• id_processo é chave primária
• numero_processo não pode ser nulo
• tipo pode assumir os valores {"Ação de Alimentos", "Defesa Criminal"}.
• status pode assumir os valores {"Em andamento", "Arquivado", "Sentenciado"}
tb_movimentacoes(id_movimentacao, descricao, data_movimentacao, id_processo<FK>)
Restrições:
• id_movimentacao é chave primária
• descricao não pode ser nulo
• descricao pode assumir os valores { "Petição inicial protocolada", "Audiência realizada"}.
• id_processo é chave estrangeira e referencia a tabela tb_processos
Submeteu-se ao sistema que gerencia esse banco de dados relacional a consulta:
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov
where exists
( select proc.id_processo from tb_processos proc
where proc.id_processo=mov.id_processo
and proc.status='Arquivado' )
O otimizador de consultas do sistema, ao avaliar a consulta, identificou tratar-se de um caso de consulta correlata, com uma subconsulta aninhada referenciando um elemento de dado da consulta externa.
Considerando que o otimizador decidiu e é capaz de implementar a melhor opção de otimização, qual das opções apresenta uma consulta equivalente à anteriormente proposta, após a aplicação da técnica de desalinhamento?
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov
where mov.id_processo in
(select proc.id_processo from tb_processos proc
where proc.status='Arquivado')
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov left join tb_processos proc
on proc.id_processo=mov.id_processo
where proc.status='Arquivado'
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov natural join tb_processos proc
where proc.status='Arquivado'
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov
where mov.id_processo any
(select proc.id_processo from tb_processos proc
where proc.status='Arquivado')
select mov.descricao, mov.data_movimentacao
from tb_movimentacoes mov
union
select proc.id_processo from tb_processos proc
where proc.status='Arquivado'
Um relatório de alta demanda da Controladoria-Geral da União (CGU) executa consultas simples em Structured Query Language (SQL), com latência mínima e mapeamento leve. Qual escolha é a mais adequada?
Dapper para consultas simples e de altíssimo desempenho, com SQL explícito e parametrização segura, evitando overhead de um mapeamento objeto-relacional completo.
Entity Framework (EF) Core com change tracking avançado, usando Language Integrated Query (LINQ) e rastreamento para acelerar materializações em leitura intensiva.
ORM completo com migrações automáticas, mesmo sem necessidade de tracking, para padronizar acesso e facilitar evolução de esquema.
ADO.NET (ActiveX Data Objects para .NET) puro é sempre superior ao Dapper, pois elimina qualquer camada e reduz todos os custos ao mínimo possível em qualquer cenário
Abstração total do SQL, delegando ao provedor a geração de comandos para garantir portabilidade sem escrever consultas.
Em um banco de dados relacional, a criação de índices compostos em colunas frequentemente utilizadas em filtros de consulta não melhora o desempenho da busca, pois não evita a necessidade de leitura sequencial da tabela.
Certo
Errado
Em um ambiente MySQL InnoDB com alta carga transacional OLTP, o DBA está otimizando parâmetros de configuração. Sobre ajustes de performance no MySQL InnoDB, analise as afirmativas:
I. O parâmetro innodb_buffer_pool_size deve ser configurado para aproximadamente 70-80% da RAM em servidores dedicados.
II. Configurar innodb_flush_log_at_trx_commit=2 oferece bom equilíbrio entre performance e durabilidade, gravando no OS cache a cada commit.
III. O tamanho de innodb_log_file_size deve ser suficiente para aproximadamente 1-2 horas de atividade de escrita.
Está correto o que se afirma em
I, apenas
II, apenas
I e III, apenas
I, II e III
II e III, apenas
O SQL Server Profiler é utilizado para realizar auditoria em servidores SQL Server a partir do rastreamento de atividades. Durante um rastreamento, os dados capturados são armazenados em uma tabela, em que cada linha representa uma requisição (query) e cada coluna apresenta informações sobre as requisições. Durante uma auditoria no sistema de banco de dados do TCE de Roraima, uma requisição (query) capturada pelo SQL Server Profiler retornou os seguintes dados:

Com relação aos dados dessa requisição, assinale a afirmativa correta.
O programa que está rodando o SQL Server Profiler é o Microsoft SQL Server Management Studio.
O usuário que está realizando a auditoria possui login DBA_TI_TCERR.
O banco de dados executou o comando INSERT.
A execução teve uma duração de 45,219 milissegundos.
A máquina que executou a requisição é AUD01_TCERR.
No contexto de otimização de desempenho de consultas em bancos de dados, algumas métricas ajudam a entender melhor o comportamento das consultas e a realizar ajustes necessários para melhorar o desempenho do banco de dados.
Avalie se as seguintes métricas de desempenho devem ser acompanhadas:
I. Duração da execução da consulta: essa métrica mede quanto tempo uma consulta leva para ser concluída, permitindo identificar consultas que podem precisar de otimização.
II. Tempo de carregamento de dados versus tempo de processamento: comparar o tempo gasto para carregar os dados com o tempo gasto em processamento ajuda a identificar gargalos na pipeline de dados.
III. Contagem de consultas concorrentes: é vital monitorar o número de conexões simultâneas para evitar a sobrecarga do banco de dados, o que pode afetar a performance dos usuários.
IV. Utilização de recursos: mede a utilização de recursos como memória, CPU, I/O e rede para identificar padrões que podem indicar problemas ou oportunidades de otimização.
As métricas de desempenho que devem de fato ser acompanhadas são
II, III e IV, apenas.
I e IV, apenas.
III e IV, apenas.
I, III e IV, apenas.
I, II, III e IV.
O seguinte comando retorna o nome dos médicos e a quantidade de atendimentos que cada um realizou, ordenando pela maior quantidade de atendimentos:
SELECT M.nome, COUNT(A.id_atendimento) AS total_atendimentos
FROM Medicos M
LEFT JOIN Atendimentos A ON M.id_medico = A.id_medico
GROUP BY M.nome
ORDER BY COUNT(A.id_atendimento) DESC;;
Certo
Errado
Durante o processo de modelagem de bancos de dados relacionais, a normalização é uma etapa fundamental para eliminar redundâncias e garantir a integridade dos dados. No entanto, após a aplicação das formas normais em um banco de dados relacional, pode surgir a necessidade de realizar a desnormalização. Essa etapa tem como principal objetivo:
Melhorar o desempenho.
Permitir o uso do SQL.
Diminuir a redundância.
Aumentar o número de tabelas.
Em sistemas distribuídos, técnicas de análise de desempenho e otimização de consultas (tuning) envolvem particionamento de dados entre nós, uso de cache distribuído, ajuste de parâmetros de redes, avaliação de latência e análise de balanceamento de carga, com o objetivo de melhorar a eficiência geral do sistema, assegurar sua consistência e reduzir o tempo de resposta das consultas.
Certo
Errado
Um exemplo de técnica bastante utilizada para a otimização do desempenho do banco de dados da empresa consiste na análise de consultas SQL, também conhecida como plano de execução.
Certo
Errado
Em tuning de banco de dados, para alterar expressões SQL sem implicar em alterações físicas do sistema gerenciador de banco dados e sem ajuste do esquema físico do servidor, é utilizado o processo de
ajuste de planos de consulta.
ajuste automatizado de design físico.
ajuste do esquema físico.
view materializada.
particionamento horizontal de relações.
Em bancos de dados relacionais que utilizem a linguagem SQL (não procedural) a otimização de comandos SQL é um fator central no “tuning” de um banco de dados.
A otimização foca na determinação do modo mais eficiente para obter o resultado. Nesse contexto, o “estimator” é o componente que avalia o consumo de recursos num certo plano de execução.
De acordo com o que é preconizado pela Oracle, os fatores pelos quais o custo é estimado são:
Cardinality, Cost, Selectivity.
Disk memory, Indexes, RAM memory.
Filters, Partitions, Primary keys.
Indexes, Join operations, Size.
Joins, Projections, Selection.