🎯 Saiba o que estudar

Avançado com Treinador a partir de R$ 0,76/dia

Uma administradora de banco de dados (DBA) constatou que o s...

Próximas questões
Com base no mesmo assunto
Q4234692 Banco de Dados
Uma administradora de banco de dados (DBA) constatou que o servidor PostgreSQL frequentemente atinge o limite de conexões simultâneas e apresenta elevado consumo de CPU em razão da criação constante de novas conexões por parte das aplicações judiciais de um Tribunal de Justiça. Diante disso, para otimizar o uso de conexões, reduzir o overhead operacional e manter o controle de acesso adequado, decidiu-se adotar a seguinte abordagem, em condições ideais:
Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

Gabarito: D

Fundamento decisivo: A decisão estava em identificar a solução que reduz a criação constante de conexões sem perder o controle de acesso: um pooler externo de conexões para PostgreSQL.

Tema central: Pool de conexões
Análise das alternativas
A
Errada
Está errada porque não implementa reutilização de conexões; apenas tenta mexer no limite de conexões aceitas pelo servidor. Além disso, a formulação max_connections = 0 para crescimento dinâmico não se sustenta como configuração válida indicada pela documentação.
B
Errada
Está errada porque listen_addresses só define em quais endereços IP o PostgreSQL escuta conexões. Isso amplia acessibilidade de rede, mas não reduz o custo de criação de conexões nem melhora desempenho por esse motivo.
C
Errada
Está errada porque atribui ao PostgreSQL um suposto recurso nativo de pooling por meio de ALTER SYSTEM SET connection_pooler_mode = 'session', o que não corresponde a parâmetro oficial do servidor na forma descrita. Portanto, não há base para tratá-la como solução real do problema.
D
Certa
A alternativa D é a única que adota o mecanismo tecnicamente adequado ao problema narrado: um pool externo de conexões para PostgreSQL. Em pool_mode = transaction, o PgBouncer reutiliza as conexões de servidor ao fim de cada transação, reduzindo o overhead de novas conexões e o consumo de recursos.
E
Errada
Está errada porque a regra host all all 0.0.0.0/0 trust elimina autenticação efetiva para qualquer origem permitida. Isso contraria diretamente a exigência de manter controle de acesso adequado e, além disso, não resolve o problema central de pooling e reaproveitamento de conexões.
Pegadinha da questão
A questão mistura o problema real de pooling com alternativas que parecem administrativas, mas tratam de outra coisa: aumentar/liberar conexões, abrir escuta de rede, inventar parâmetro nativo de pooling ou reduzir autenticação. O trecho sobre manter controle de acesso adequado elimina especialmente a opção com trust amplo.
Dica para questões semelhantes
  • Se o problema é criação constante de conexões e limite de sessões, procure mecanismo de pooling, não apenas ajuste de limite de conexões.
  • Parâmetro de escuta de rede, como listen_addresses, trata de acessibilidade, não de desempenho por reutilização de conexões.
  • Se a solução proposta depende de recurso nativo do PostgreSQL, confirme se o parâmetro ou mecanismo realmente existe na forma indicada.
  • Quando o enunciado exige controle de acesso adequado, descarte soluções que removem autenticação efetiva, mesmo que prometam reduzir overhead.

Clique para visualizar este gabarito

Visualize o gabarito desta questão clicando no botão abaixo