Mettre à jour les statistiques avec analyse complète sur SQL Server 2014 utilise 100% cpu, sur 2008 R2, 15%

Pourquoi les statistiques de mise à jour de l'analyse complète utilisent-elles 100% du processeur sur SQL Server 2014 alors qu'elles utilisent peut-être 20% du processeur sur SQL Server 2008 R2, pour les mêmes tables, avec des capacités matérielles similaires?

J'ai regardé d' MAXDOPautres options et je ne vois vraiment rien qui se démarque. Je me rends compte qu'il pourrait y avoir des paramètres qui pourraient provoquer cela, mais les paramètres sont très similaires pour les deux bases de données (par exemple, MAXDOP4 pour les deux, les deux ayant plusieurs cœurs). Les deux sont Enterprise Edition.

Y a-t-il quelque chose de "différent" dans SQL Server 2014 par rapport à SQL Server 2008 R2 qui pourrait expliquer cela? J'ai l'option de mémoire à 90% pour les deux serveurs. Des réflexions sur ce qu'il faut rechercher?

J'exécute des statistiques de mise à jour avec une analyse complète (100%) une fois par semaine sur deux serveurs utilisant SQL Server 2008 R2 / SP3 et SQL Server 2014 / SP2, et les bases de données ont la même structure. Sur le serveur 2008 R2, les statistiques de mise à jour de deux très grandes tables prennent plusieurs heures, ce que j'attends, mais le processeur reste en dessous de 20% environ en tout temps. Sur le serveur 2014, cependant, le processeur passe à 100% pendant environ 40 minutes. Les tableaux sont un peu plus petits sur le serveur 2014. Je vois cela en utilisant les menus d'analyse de SQL Monitor.

Voici la sortie du fichier journal Ola sur le serveur SQL 2014, le CPU passe à 100% d'environ 2:10 à 2:45:

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  

Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

Voici la sortie du fichier journal Ola sur le SQL Server 2008 R2 pour les deux statistiques ci-dessus, mais le processeur atteint peut-être 15%:

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  

Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

Je ne peux pas les exécuter avec le serveur maxdop = 1 car cela élimine toute génération de plan parallèle et cela pourrait nuire à l'application. J'ai l'intention d'aller dans la direction opposée et de l'augmenter à 8 (il y a 16 cœurs sur la boîte) et de voir ce qui se passe. Peut aller plus vite pour réduire la durée d'ancrage du processeur. Ce travail s'exécute alors que la plupart des utilisateurs sont partis.

Les mises à jour des statistiques peuvent aller en parallèle sur la base de nombreuses options différentes dans SQL Server:

• Seuil de coût pour le parallélisme - une requête doit être aussi élevée pour parcourir le train du parallélisme. Vos deux serveurs peuvent avoir des paramètres CTFP différents qui provoquent la mise à jour 2008R2 à un seul thread, tandis que celui de 2014 peut devenir multi-thread.
• Degré maximal de parallélisme - dicte le nombre de cœurs qu'une requête peut utiliser, tout au plus, si SQL Server décide de la paralléliser aussi loin. La boîte 2008R2 peut avoir MAXDOP définie sur 1, tandis que la boîte 2014 pourrait avoir la valeur par défaut de 0 (illimité).
• Gouverneur de ressources - cette fonction Enterprise Edition vous permet de limiter différents groupes d'utilisateurs ou d'applications à différents MAXDOP.

Dans les versions ultérieures de SQL Server (2016 et versions ultérieures), cela devient encore plus compliqué:

• Options de portée au niveau de la base de données - vous pouvez cliquer avec le bouton droit sur une base de données, accéder aux propriétés et définir le niveau MAXDOP pour cette base de données.
• Conseils de parallélisme des statistiques - à partir de 2016 SP2, les instructions de création et de mise à jour des statistiques acceptent les conseils MAXDOP

Comme vous l'avez noté, celui de 2008R2 est à filetage unique, tandis que celui de 2014 est à filetage multiple (finissant ainsi plus rapidement, mais maximisant le processeur pendant son fonctionnement.)

Pour trouver le bon équilibre pour vos travaux de statistiques, pensez à:

• Quelles autres charges de travail se produisent dans la base de données en même temps? Pouvez-vous vous permettre de dominer la boîte pendant de brèves périodes? Par exemple, dans les entrepôts de données qui restent inactifs pendant la plupart des heures de week-end, j'ai vu des gens se concentrer sur les mises à jour des statistiques avec des analyses complètes quand ils savent que personne n'utilise le serveur de toute façon. Dans les environnements transactionnels lourds, vous devez commencer à utiliser moins d'impact pour les tâches de maintenance si les utilisateurs se plaignent même pendant les périodes de minuit.
• Le fullscan est-il vraiment nécessaire? Voyez-vous des requêtes qui n'obtiennent de bons plans que lorsque vous utilisez l'option d'analyse complète, ou le faites-vous simplement en tant que meilleure pratique? À mesure que votre base de données se développe, si vos investissements matériels ne suivent pas le rythme, vous devrez peut-être commencer à faire des compromis dans l'échantillonnage des statistiques plutôt que de faire des analyses complètes.
• Pouvez-vous mettre à jour les statistiques moins souvent? Par exemple, mettez à jour 1/4 de vos statistiques chaque week-end, puis chaque mois, tout recevra des mises à jour des statistiques?
• Pouvez-vous mettre à jour moins d'objets? Souvent, je vois des gens mettre à jour les statistiques même sur d'énormes tables d'audit ou d'archivage simplement parce que quelques dizaines de nouvelles insertions ont été effectuées, mais ces insertions n'affectent pas vraiment les statistiques sur la table (et personne ne l'interroge de toute façon.)

_{Réponse du wiki communautaire :}

Meilleure estimation: le plan choisi pour mettre à jour les statistiques est parallèle ou plus parallèle sur la box 2014 que sur la box 2008 R2.

Les statistiques de mise à jour parallèle pour existent fullscandepuis 2005, et pour les statistiques échantillonnées à partir de 2016, consultez Ajouts de l'optimiseur de requête dans SQL Server 2016 par Gjorgji Gjeorgjievski sur le blog du moteur de base de données SQL Server.

Si vous avez Enterprise Edition, vous pouvez utiliser le gouverneur de ressources pour limiter le processeur utilisé par votre tâche de maintenance.

Pensez également à voter pour le paramètre Ajouter à laMAXDOP suggestion Connect pour mettre à jour les statistiques de Javier Villegas.

Questions et réponses connexes: mise à jour des statistiques parallèles