Symptômes
Supposez que vous avez installé Microsoft SQL Server 2014, 2016 ou 2017. Vous risquez de voir un ou plusieurs des problèmes suivants :
-
L’instance SQL Server semble sans réponse et un message d’erreur « programmateur sans yield » s’affiche. Il est possible que vous deviez redémarrer le serveur pour le récupérer.
-
La restauration d’une transaction risque de prendre un certain temps. Dans la plupart des cas, le redémarrage de l’instance permettra une récupération plus rapide de la base de données que la restauration. Notez qu’il existe de nombreuses raisons pour lesquelles la restauration peut prendre un certain temps, voir la section « informations supplémentaires » ci-dessous pour plus d’informations sur l’analyse des restaurations avant d’essayer de redémarrer.
-
Il est possible que vous voyiez des attentes élevées sur les verrouillages spinlock, par exemple les SOS_OBJECT_STORE.
Résolution
Ce problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et 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
Informations sur le Service Pack pour SQL Server
Cette mise à jour est corrigée dans le Service Pack SQL Server suivant :
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 de 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 trouver plus d’informations sur le dernier Service Pack et la dernière mise à jour cumulative.
Déterminer le niveau de version, d’édition et de mise à jour de SQL Server et ses composants
Informations supplémentaires
Il existe de nombreuses raisons pour lesquelles un ROLLBACK peut prendre un certain temps, par exemple une transaction longue, un grand nombre de VLFs dans le fichier du journal des transactions, des e/s lentes, etc. Pour vérifier que le problème décrit dans cet article est la cause profonde 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 le session_id dont la commande est définie sur « tués/Rollback » et assurez-vous que la session accumule à la fois les paramètres IO et Time CPU indiquant la progression. Si les e/s ne changent pas, il peut s’agir d’une indication que vous rencontrez le problème décrit dans cet article.
-
Sys.dm_tran_database_transactions d’interrogation pour identifier l’état actuel de la restauration à l’aide d’une requête semblable à ce qui suit :
Sélectionnez GETDATE () en tant que 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 ()
À partir de sys.dm_tran_database_transactions t
JOINDRE sys.dm_exec_requests s T.transaction_id = s.transaction_id
OÙ 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 LSN de l’enregistrement suivant à annuler. database_transaction_begin_lsn est le LSN de l’enregistrement Begin pour la transaction dans le journal des transactions.
database_transaction_next_undo_lsn doit être décroissante de chaque instantané de cette requête. La restauration s’effectue correctement lorsque le database_transaction_next_undo_lsn atteint database_transaction_begin_lsn.
Dans le cadre d’un intervalle prédéterminé, l’objectif est de prendre quelques instantanés de la requête précédente, puis d’utiliser le delta du LSNs traité database_transaction_next_undo_lsn dans le cadre de cet intervalle et de procéder à une extrapolation du temps écoulé pour évaluer la durée nécessaire à l' database_transaction_next_undo_lsn pour atteindre le database_transaction_begin_lsn.
Si la restauration progresse à un tarif valide entre chaque instantané, nous vous suggérons d’effectuer le Rollback en tant que tel, sans redémarrage de l’instance SQL Server.
Pour plus d’informations sur la récupération du temps prolongé, voir les articles suivants :
-
Présentation des performances de récupération dans SQL Server
-
SQL Server (2000, 2005, 2008) : récupération/restauration plus longue que prévue
-
Suivi de l’avancement de la restauration de la base de données à l’aide des informations
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.
Références
Apprenez-en davantage sur la terminologieutilisée par Microsoft pour décrire les mises à jour logicielles.
