O sistema de gerenciamento de banco de dados oferece ao administrador diferentes indicadores para obter informações sobre o ambiente. No caso do SGBD SQL Server, quando se trata de analisar a performance de consultas, um dos indicadores observados é o chamado tipo de espera (Wait Type). Considere que o sistema de controle de pagamentos da metalúrgica Ferro Forte está no SGBD SQL Server, e vem apresentando perda de performance no processo de fechamento da folha de pagamento. O analista de banco de dados constata que o tipo de espera mais comum se refere ao paralelismo do plano de execução (CXPACKECT). Visando a otimizar a performance da consulta em relação aos recursos de CPU e de memória do servidor, assinale a opção que lista os parâmetros que devem ser ajustados para melhorar o paralelismo.
- A)Parâmetro da Instância Maximum worker threads.
Errada, porque Maximum worker threads controla quantidade de threads de trabalho, não é o ajuste típico para conter ou calibrar paralelismo de consultas.
- B)Parâmetro do banco de dados Query Optimizer Fixes.
Errada, porque Query Optimizer Fixes apenas habilita correções do otimizador e não regula diretamente o grau de paralelismo.
- C)Parâmetro da Instância Maximun number of concurrent connections.
Errada, porque Maximum number of concurrent connections trata de conexões simultâneas, não do comportamento paralelo de uma consulta.
- D)Parâmetro do banco de dados Cost Threshold for Parallelism e MaxDOP.
Errada, porque Cost Threshold for Parallelism e MaxDOP são parâmetros ligados ao servidor, e a alternativa ainda omite a configuração de banco citada no enunciado do gabarito.
- E)Parâmetro da Instância Cost Threshold for Parallelism e MaxDOP, e o parâmetro no banco de dados MaxDOP.
Certa, porque Cost Threshold for Parallelism e MaxDOP são os ajustes clássicos para controlar paralelismo, e o SQL Server também pode ter MaxDOP configurado em escopo de banco.
Gabarito: E
No SQL Server, o tipo de espera CXPACKET costuma aparecer quando a consulta foi executada em paralelo. Em outras palavras, o otimizador dividiu o trabalho entre vários threads, e depois esses threads precisam se coordenar. Quando isso vira excesso, a consulta pode gastar mais CPU do que deveria e ainda pressionar memória e sincronização. É o famoso caso em que o paralelismo ajuda, mas sem ajuste vira bagunça organizada. Para controlar isso, os dois parâmetros mais clássicos são o Cost Threshold for Parallelism e o MaxDOP (Max Degree of Parallelism). O primeiro define a partir de qual custo estimado o SQL Server considera montar um plano paralelo. O segundo limita quantos processadores podem ser usados por uma única consulta paralela. Ajustar esses valores é justamente a forma padrão de reduzir paralelismo desnecessário e melhorar o uso de CPU e memória. A alternativa E é a correta porque reúne esses controles e ainda menciona o ajuste de MaxDOP em nível de banco, que existe nas versões mais novas do SQL Server como configuração de escopo de banco de dados. Na prática, a ideia é conter consultas que estão exagerando no paralelismo, evitando que a máquina fique ocupada demais com coordenação de threads em vez de execução útil. Resumo de prova: quando a banca falar em espera ligada a paralelismo, pense logo em Cost Threshold for Parallelism e MaxDOP. Isso é o coração da otimização desse cenário. O resto costuma ser distração com nomes bonitos de configurações que não atacam o problema central.