Ainsi, dans SQL Server 2016, les mises à jour de statistiques utilisant le mode échantillon s'exécutent désormais en parallèle sous le niveau de compatibilité 130, et c'est ainsi que cela fonctionne par défaut, pour toutes les mises à jour de statistiques automatiques et manuelles. Ceci est expliqué brièvement ici :
- Compléments de l'optimiseur de requêtes dans SQL Server 2016
(La documentation a également été mise à jour, à la fois la rubrique Niveau de compatibilité et la rubrique MISE À JOUR DES STATISTIQUES.)
Ne serait-il pas agréable, cependant, de pouvoir spécifier combien de processeurs peuvent réellement être utilisés pour ces opérations (autre que de simplement autoriser le plafond de 16) ? Je pense que pouvoir limiter cela à 4 ou 8 serait une chose évidente et logique à soutenir. Surtout pour les clients exécutant des systèmes avec 16 cœurs ou moins, ou plusieurs instances sur une boîte, qui ne peuvent pas compter sur des fonctionnalités d'entreprise telles que le gouverneur de ressources (que la plupart des clients d'entreprise ne pourraient pas être dérangés d'utiliser non plus, à mon humble avis).
La justification commerciale de cela serait la même que les justifications utilisées pour ajouter le support MAXDOP REBUILD, DBCC CHECKDB et sa famille d'opérations de maintenance, etc. Vous voulez empêcher ce type d'activité de prendre en charge tous les cœurs, sans faire quelque chose d'aussi drastique comme désactiver les mises à jour automatiques ou utiliser MAXDOP à l'échelle de l'instance, car tout le monde n'a pas le luxe d'avoir des fenêtres de maintenance.
Et dans ce cas, MAXDOP à l'échelle de l'instance n'aidera de toute façon pas , car SQL Server 2016 RTM a un bogue où MAXDOP est ignoré pour les mises à jour des statistiques échantillonnées. Un correctif est à venir, mais je pensais que vous devriez le savoir ; si cela vous pose problème, une option consiste à utiliser un niveau de compatibilité inférieur.
Mais je vais répéter quelque chose que je dis souvent :le niveau de compatibilité devient beaucoup trop encombré. Si je veux des statistiques échantillonnées parallèles sur ma base de données mais que j'ai suffisamment de régressions d'estimation de cardinalité pour exiger l'ancien CE, je dois choisir l'une ou l'autre.
Et autre chose :le gouverneur de ressources est exagéré pour ce cas d'utilisation, et limiter l'utilisation du cœur à partir des mises à jour de statistiques ne devrait pas vraiment être une fonctionnalité d'entreprise (tout comme REBUILD et CHECKDB mentionnés ci-dessus). S'il vous plaît, ne me dites pas que RG est une alternative acceptable, car cela n'est possible que pour les utilisateurs avec Enterprise Edition *et* les classifications de charge de travail qui devraient être limitées par MAXDOP tout le temps . Je devrais pouvoir limiter cela par une opération spécifique (ou, disons, uniquement pour mes tables les plus importantes/problématiques), et non en limitant la session entière d'une connexion.
Comme j'aimerais qu'ils le fassent
Idéalement, nous pourrions définir cela au niveau de la base de données, en utilisant la nouvelle option DATABASE SCOPED CONFIGURATION, et au niveau de l'instruction, en utilisant la syntaxe familière OPTION (MAXDOP n). Le niveau d'instruction l'emporterait et toutes les mises à jour de statistiques en mode échantillon (y compris automatiques) sans indice MAXDOP explicite reviendraient au paramètre de niveau de base de données. Cela me permettrait de définir un MAXDOP de 4, par exemple, pour toutes les mises à jour automatiques des statistiques qui se produisent à des moments imprévisibles, mais de 8 ou 16 pour les opérations manuelles dans des fenêtres de maintenance connues. Par exemple.
Si vous souhaitez voter pour cela, veuillez consulter l'élément Connect suivant et ajouter une justification commerciale pour cela (à la Michael Campbell) :
- Connect #628971 :Ajouter le paramètre MAXDOP aux statistiques de mise à jour
Bien sûr, cet élément existe depuis 2010, il n'y a donc aucune mention de l'avenue DATABASE SCOPED CONFIGURATION, c'est pourquoi j'ai également laissé un commentaire.
En attendant, si vous souhaitez désactiver le parallélisme pour le mode échantillon, il existe un indicateur de trace pour revenir efficacement à un comportement plus ancien (vous pouvez également le faire en revenant à un niveau de compatibilité inférieur à 130, mais je ne le recommande pas car il affecte beaucoup d'autres choses). Je mettrai à jour cet espace lorsque j'aurai reçu l'autorisation de divulguer publiquement l'indicateur de trace, mais pour le moment, Microsoft le tient fermement sur sa poitrine.
