KB4338890 - CORRECTIF : erreur « Planificateur sans rendement » et SQL Server semblent ne pas répondre dans SQL Server 2014, 2016 et 2017

S’applique à
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Symptômes

Supposons que Microsoft SQL Server 2014, 2016 ou 2017 soit installé.  Vous pouvez rencontrer un ou plusieurs des problèmes suivants :

  • Le SQL Server instance ne répond pas et une erreur « Planificateur sans rendement » se produit. Vous devrez peut-être redémarrer le serveur pour récupérer.
  • La restauration d’une transaction peut prendre beaucoup de temps. Dans la plupart des cas, le redémarrage de la instance permet à la base de données de récupérer beaucoup plus rapidement que la restauration. Notez qu’il existe de nombreuses raisons pour lesquelles une restauration peut prendre beaucoup de temps. Consultez la section « Plus d’informations » ci-dessous pour plus d’informations sur la surveillance des restaurations avant de tenter de redémarrer.
  • Vous pouvez voir des attentes élevées sur les verrouillages tournants tels que SOS_OBJECT_STORE.

Résolution

Ce problème est résolu dans les mises à jour cumulatives suivantes pour SQL Server :

Mise à jour cumulative 9 pour SQL Server 2017

Mise à jour cumulative 2 pour SQL Server 2016 SP2

À propos des mises à jour cumulatives pour SQL Server :

Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :

Dernière mise à jour cumulative pour SQL Server 2017

Dernière mise à jour cumulative pour SQL Server 2016

Dernière mise à jour cumulative pour SQL Server 2014

Informations de Service Pack pour SQL Server

Cette mise à jour est corrigée dans le Service Pack suivant pour SQL Server :

Service Pack 3 pour SQL Server 2014

À propos des Service Packs pour SQL Server :

Les Service Packs sont cumulatifs. Chaque nouvelle version contient tous les correctifs fournis dans les Service Packs précédents et tous les nouveaux correctifs. Nous vous recommandons d’appliquer le dernier Service Pack et la dernière mise à jour cumulative pour ce Service Pack. Il n'est donc pas nécessaire d'installer la version antérieure d'un Service Pack avant d'installer la dernière version disponible. Utilisez le tableau 1 de l’article suivant pour obtenir plus d’informations sur le dernier Service Pack et la dernière mise à jour cumulative.

Comment déterminer la version, l’édition et le niveau de mise à jour de SQL Server et de ses composants

Plus d’informations

Il existe de nombreuses raisons pour lesquelles une restauration peut prendre beaucoup de temps, telles qu’une transaction de longue durée, un grand nombre de fichiers journaux virtuels dans le fichier journal des transactions, des E/S lentes, etc. Pour vérifier que le problème décrit dans cet article est la cause racine d’une restauration lente, nous vous suggérons d’utiliser les techniques suivantes pour surveiller la progression de l’opération de restauration :

  • À partir de sys.dm_exec_requests, identifiez les session_id dont la commande est définie sur « KILLED/ROLLBACK » et assurez-vous que la session accumule à la fois le temps d’E/S et le temps processeur indiquant la progression. Si les E/S ne changent pas, cela peut indiquer que vous rencontrez le problème décrit dans cet article.
  • Sys.dm_tran_database_transactions de requête pour identifier l’état actuel de la restauration à l’aide d’une requête comme celle-ci :

Remarque

  • SELECT getdate() comme CurrentTime, database_transaction_next_undo_lsn,database_transaction_begin_lsn,t.transaction_id,database_transaction_begin_time,database_transaction_log_record_count,db_name(t.database_id)
  • FROM sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Nom de la base de données') et s.session_id=<Session_id effectuant l’opération> de restauration

Remarque :

Dans la requête ci-dessus,

database_transaction_next_undo_lsn est le numéro DSN de l’enregistrement suivant à annuler. database_transaction_begin_lsn est le numéro LSN de l’enregistrement de début de la transaction dans le journal des transactions.

database_transaction_next_undo_lsn doit diminuer à chaque instantané de cette requête. La restauration se termine correctement lorsque le database_transaction_next_undo_lsn atteint database_transaction_begin_lsn.

L’objectif ici est de prendre quelques captures instantanées de la requête précédente dans un intervalle prédéterminé, puis d’utiliser le delta des LSN traités dans database_transaction_next_undo_lsn au cours de cet intervalle et d’extrapoler le temps nécessaire pour estimer le temps nécessaire à l’database_transaction_next_undo_lsn pour atteindre le database_transaction_begin_lsn.

Si la restauration progresse à un rythme correct entre chaque instantané, nous vous suggérons d’autoriser la restauration à se terminer seule sans redémarrer le SQL Server instance.

Pour plus d’informations sur la récupération longue, consultez les articles suivants :

État

Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».

Références

En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.