Questão de Banco de Dados — SQL Server — INSTITUTO AOCP 2024

Otimização de desempenho no SQL Server 2022

Gabarito: letra C. A abordagem mais adequada para otimizar o desempenho de uma aplicação web com aumento de usuários e transações é implementar melhorias no mecanismo de consulta, gerenciamento de memória e processamento paralelo do SQL Server 2022, pois são esses os componentes internos que afetam diretamente a velocidade de execução das consultas e a capacidade de processamento sob carga. As demais alternativas, embora possam contribuir em cenários específicos, não atacam diretamente o gargalo de desempenho do banco de dados relacional.

O problema descrito é clássico em bancos de dados relacionais: o aumento de usuários e transações gera maior concorrência, mais consultas simultâneas e maior volume de dados processados. O desempenho de um SGBD como o SQL Server depende de vários fatores, mas os principais são: a eficiência do otimizador de consultas (que decide como executar cada SELECT), a gestão de memória (buffer pool, cache de planos) e o uso de processamento paralelo (para dividir consultas pesadas entre múltiplas CPUs). O SQL Server 2022 trouxe melhorias significativas nesses três pilares, como o novo otimizador de cardinalidade, o recurso de "Intelligent Query Processing" (que inclui o "Parameter Sensitive Plan Optimization" e o "Memory Grant Feedback") e aprimoramentos no paralelismo. Essas melhorias são internas ao mecanismo e beneficiam todas as aplicações que usam o banco, sem exigir mudanças na aplicação ou na infraestrutura.

A otimização de desempenho em bancos de dados relacionais é um processo contínuo que envolve várias frentes. A primeira é o tuning de consultas: analisar os planos de execução, identificar consultas lentas e reescrevê-las ou adicionar índices adequados. A segunda é o gerenciamento de memória: configurar corretamente o buffer pool (que armazena páginas de dados em memória para reduzir leituras em disco) e o cache de planos (que evita recompilações desnecessárias). A terceira é o processamento paralelo: permitir que consultas pesadas sejam divididas em múltiplas threads, aproveitando múltiplos processadores. O SQL Server 2022 aprimorou esses três aspectos, tornando-o mais eficiente sob alta carga.

Um exemplo concreto: imagine uma aplicação de comércio eletrônico que, durante uma promoção, recebe milhares de pedidos simultâneos. Sem otimização, cada consulta de verificação de estoque pode demorar segundos, causando timeout para os usuários. Com o SQL Server 2022, o otimizador de consultas pode escolher planos mais eficientes, o buffer pool mantém os dados mais acessados em memória e o processamento paralelo divide as consultas pesadas entre CPUs, reduzindo o tempo de resposta. Essas melhorias são transparentes para a aplicação, que continua usando as mesmas consultas SQL.

É importante distinguir a otimização de desempenho de outras estratégias como replicação, que distribui a carga entre servidores, mas não melhora a eficiência de cada consulta individual. A replicação é útil para escalabilidade horizontal e alta disponibilidade, mas não resolve o gargalo de processamento de consultas em um único servidor. Da mesma forma, o processamento de consultas em big data é voltado para dados externos, não para o banco transacional. A inteligência artificial e o machine learning podem ajudar a prever padrões de uso, mas não otimizam diretamente a execução de consultas. E a escolha do sistema operacional (Linux vs. Windows) tem impacto marginal no desempenho do SQL Server, que é otimizado para ambos.

A pegadinha desta questão é que a banca apresenta alternativas que são tecnicamente válidas em outros contextos, mas não são a abordagem mais direta e eficaz para o problema específico de desempenho de consultas em um banco relacional sob alta carga. O candidato pode ser tentado a escolher a replicação (A) ou o Linux (E), mas a resposta correta é a que ataca diretamente o mecanismo de banco de dados.

Alternativa A — ❌ Incorreta

A replicação de dados distribui a carga entre múltiplos servidores, mas não melhora a eficiência de cada consulta individual. Ela é útil para escalabilidade horizontal e alta disponibilidade, mas não resolve o gargalo de processamento de consultas em um único servidor. A replicação pode até aumentar a complexidade e a latência em cenários de escrita intensiva, como o descrito no enunciado.

Alternativa B — ❌ Incorreta

O processamento de consultas em big data é voltado para consultar dados armazenados em fontes externas, como Hadoop ou Azure Data Lake. Não é a abordagem adequada para otimizar o desempenho de um banco de dados transacional como o SQL Server, que lida com dados estruturados e consultas OLTP. Essa alternativa confunde o escopo do problema: o gargalo está no mecanismo do banco, não na integração com fontes externas.

Alternativa C — ✅ Correta

Esta é a abordagem mais adequada. O SQL Server 2022 trouxe melhorias significativas no mecanismo de consulta (como o novo otimizador de cardinalidade e o Intelligent Query Processing), no gerenciamento de memória (como o Memory Grant Feedback) e no processamento paralelo. Essas melhorias atacam diretamente os gargalos de desempenho sob alta carga, melhorando a velocidade de execução das consultas e a capacidade de processamento. É a solução mais direta e eficaz para o problema descrito.

Alternativa D — ❌ Incorreta

A inteligência artificial e o machine learning podem ser usados para analisar padrões de uso e prever demandas, mas não otimizam diretamente a execução de consultas. Eles podem ajudar a dimensionar recursos ou a identificar gargalos, mas não são a abordagem principal para melhorar o desempenho de um banco de dados relacional sob alta carga. Essa alternativa confunde análise preditiva com otimização de desempenho.

Alternativa E — ❌ Incorreta

O SQL Server 2022 suporta execução em Linux, mas a escolha do sistema operacional tem impacto marginal no desempenho do mecanismo de banco de dados. O SQL Server é otimizado para ambos os sistemas, e a migração para Linux não é uma abordagem de otimização de desempenho. Essa alternativa é um distrator que explora o conhecimento de que o SQL Server agora roda em Linux, mas não é relevante para o problema de desempenho descrito.

Gabarito: letra C