Portanto, no SQL Server 2016, as atualizações de estatísticas usando o modo de amostra agora são executadas em paralelo no nível de compatibilidade 130, e é assim que funciona por padrão, para todas as atualizações de estatísticas automáticas e manuais. Isso é explicado brevemente aqui:
- Adições do Otimizador de Consulta no SQL Server 2016
(A documentação também foi atualizada, tanto o tópico Compatibility Level quanto o tópico UPDATE STATISTICS.)
Não seria bom, no entanto, poder especificar quantas CPUs podem realmente ser usadas para essas operações (além de permitir o limite de 16)? Eu acho que ser capaz de limitar isso a 4 ou 8 seria uma coisa óbvia e lógica para apoiar. Especialmente para clientes que executam sistemas com 16 ou menos núcleos, ou várias instâncias em uma caixa, que não podem confiar em recursos corporativos como o Resource Governor (que a maioria dos clientes corporativos também não se incomoda em usar, IMHO).
A justificativa comercial para isso seria a mesma que as justificativas usadas para adicionar suporte MAXDOP REBUILD, DBCC CHECKDB e sua família de operações de manutenção, etc. Você quer evitar que esse tipo de atividade tome conta de todos os núcleos, sem fazer algo tão drástico como desativar as atualizações automáticas ou usar o MAXDOP em toda a instância – porque nem todo mundo tem o luxo de janelas de manutenção.
E, neste caso, o MAXDOP em toda a instância não ajudará de qualquer maneira , porque o SQL Server 2016 RTM tem um bug em que MAXDOP é ignorado para atualizações de estatísticas de amostra. Uma correção está por vir, mas achei que você deveria saber; se isso estiver causando um problema, uma opção é usar um nível de compatibilidade mais baixo.
Mas vou reiterar algo que digo com frequência:o nível de compatibilidade está ficando muito lotado. Se eu quiser estatísticas de amostragem paralela em meu banco de dados, mas tenho regressões de estimativa de cardinalidade suficientes para exigir o CE antigo, tenho que escolher um ou outro.
E outra coisa:o Resource Governor é um exagero para este caso de uso, e limitar o uso do núcleo de atualizações de estatísticas não deve ser realmente um recurso Enterprise (assim como o REBUILD e CHECKDB mencionados acima). Não me diga que RG é uma alternativa aceitável, porque só é possível para usuários com Enterprise Edition *e* classificações de carga de trabalho que devem ser restringidas pelo MAXDOP o tempo todo . Eu deveria ser capaz de limitar isso por uma operação específica (ou, digamos, apenas para minhas tabelas de maiores/problemas), não restringindo a sessão inteira de um login.
Como eu gostaria que eles fizessem isso
Idealmente, poderíamos definir isso no nível do banco de dados, usando a nova opção DATABASE SCOPED CONFIGURATION, e no nível da instrução, usando a sintaxe familiar OPTION (MAXDOP n). O nível de instrução venceria e qualquer atualização de estatísticas do modo de amostra (incluindo automática) sem uma dica MAXDOP explícita retornaria à configuração de nível de banco de dados. Isso me permitiria definir um MAXDOP de 4, por exemplo, para todas as atualizações automáticas de estatísticas que ocorrem em momentos imprevisíveis, mas 8 ou 16 para operações manuais em janelas de manutenção conhecidas. Como um exemplo.
Se você quiser votar nisso, consulte o seguinte item do Connect e adicione uma justificativa comercial para isso (à la Michael Campbell):
- Conexão nº 628971:adicione o parâmetro MAXDOP às estatísticas de atualização
Claro, esse item está lá desde 2010, então não há nenhuma menção sobre a avenida DATABASE SCOPED CONFIGURATION, e é por isso que deixei um comentário também.
Enquanto isso, se você quiser desabilitar o paralelismo para o modo de amostra, há um sinalizador de rastreamento para retornar efetivamente ao comportamento mais antigo (você também pode fazer isso revertendo para um nível de compatibilidade inferior a 130, mas não recomendo isso porque afeta muitas outras coisas). Atualizarei este espaço quando tiver permissão para divulgar publicamente o sinalizador de rastreamento, mas agora, a Microsoft está segurando-o com força.