Erreur 17066 ou 17310 au démarrage de SQL Server

S’applique à
SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Express - duplicate (do not use) SQL Server 2014 Express - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use) SQL Server 2012 Enterprise SQL Server 2012 Developer SQL Server 2012 Express SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Datacenter SQL Server 2008 R2 Developer SQL Server 2008 R2 Express SQL Server 2008 Enterprise SQL Server 2008 Developer SQL Server 2008 Express Microsoft SQL Server 2005 Enterprise Edition Microsoft SQL Server 2005 Developer Edition Microsoft SQL Server 2005 Express Edition

Symptômes

Au démarrage de Microsoft SQL Server, vous remarquez un ou plusieurs des symptômes suivants immédiatement après la fin de la récupération de la base de données et l’activation des connexions client.

Symptôme 1

Vous recevez des messages d’erreur et des assertions semblables à ce qui suit dans votre journal des erreurs SQL Server :

Remarque

2014-12-13 08:03:34.85 spid24s Using 'dbghelp.dll' version '4.0.5'
2014-12-13 08:03:34.85 spid24s **Dump thread - spid = 0, EC = 0x0000000082274B20
2014-12-13 08:03:34.85 spid24s ***Stack Dump being sent to C :\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0001.txt
2014-12-13 08:03:34.85 spid24s * *******************************************************************************
2014-12-13 08:03:34.85 spid24s *
2014-12-13 08:03:34.85 spid24s * DÉBUT DU VIDAGE DE LA PILE :
2014-12-13 08:03:34.85 SPID24s * 12/13/14 08:03:34 SPID 24
2014-12-13 08:03:34.85 spid24s *
2014-12-13 08:03:34.85 spid24s * Emplacement : ghost.cpp :1742
2014-12-13 08:03:34.85 spid24s * Expression : tcln1 != NULL
2014-12-13 08:03:34.85 spid24s * SPID : 24
2014-12-13 08:03:34.85 spid24s * ID du processus : 35444
2014-12-13 08:03:34.85 spid24s *

2014-12-13 08:03:35.47 spid24s Error : 17066, Severity : 16, State : 1.
2014-12-13 08:03:35.47 spid24s SQL Server Assertion : File : <ghost.cpp>, line=1742 Échec de l’assertion = 'tcln1 != NULL'. Cette erreur peut être liée à la minutage. Si l’erreur persiste après la réexécution de l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de case activée ou redémarrez le serveur pour vous assurer que les structures de données en mémoire ne sont pas endommagées.

Symptôme 2

Vous recevez des messages d’erreur et des exceptions semblables aux suivants dans votre journal des erreurs SQL Server :

Remarque

2014-12-13 12:38:30.25 spid51 Using 'dbghelp.dll' version '4.0.5'
2014-12-13 12:38:30.25 spid51 ***Stack Dump being sent to C :\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0003.txt
2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler : Le processus 51 a généré une exception irrécupérable c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server met fin à ce processus.
2014-12-13 12:38:30.25 spid51 * *******************************************************************************
2014-12-13 12:38:30.25 spid51 *
2014-12-13 12:38:30.25 spid51 * DÉBUT DU VIDAGE DE LA PILE :
2014-12-13 12:38:30.25 spid51 * 12/13/14 12:38:30 spid 51
2014-12-13 12:38:30.25 spid51 *
2014-12-13 12:38:30.25 spid51 *
2014-12-13 12:38:30.25 spid51 * Adresse d’exception = 000000000030D47C module(sqlservr+0000000000FD47C)
2014-12-13 12:38:30.25 spid51 * Code d’exception = c0000005 EXCEPTION_ACCESS_VIOLATION
2014-12-13 12:38:30.25 spid51 * Une violation d’accès s’est produite reading address FFFFFFFFFFFFFF
2014-12-13 12:38:30.25 spid51 * Mémoire tampon d’entrée 54 octets -
2014-12-13 12:38:30.25 spid51 * exec usp_select1

2014-12-13 12:38:30.77 Server error : 17310, Severity : 20, State : 1.
2014-12-13 12:38:30.77 Serveur Une demande utilisateur provenant de la session avec SPID 51 a généré une exception irrécupérable. SQL Server met fin à cette session. Contactez les services de support produit avec le vidage produit dans le répertoire des journaux.

La violation d’accès aura la pile d’appels suivante :

sqlservr ! TaskGhostCleanup ::IsHashed+0x8d
sqlservr ! TaskGhostCleanup ::Enqueue+0x32
sqlservr ! IndexRowScanner ::MoveToRowOnNextPage+0x9c
sqlservr ! IndexDataSetSession ::GetNextRowValuesInternal+0x11cb

Symptôme 3

Après avoir reçu les messages mentionnés dans les sections précédentes sur les symptômes, vous recevez les messages suivants dans le journal des erreurs SQL Server :

Remarque

2014-12-13 08:04:53.37 Server Process 0:0:0 (0x23c8) Worker 0x000000002880C1A0 semble ne pas céder sur Scheduler 23. Heure de création du thread : 13062953007877. Processeur de thread approx utilisé : noyau 0 ms, utilisateur 0 ms. Utilisation du processus 0 %. Système inactif 88 %. Intervalle : 70013 ms.
2014-12-13 08:04:53.37 Server Process 0:0:0 (0x71d8) Worker 0x000000002A8D21A0 semble ne pas céder sur Scheduler 30. Heure de création du thread : 13062953007891. Processeur de thread approx utilisé : noyau 0 ms, utilisateur 0 ms. Utilisation du processus 0 %. Système inactif 88 %. Intervalle : 70013 ms.
2014-12-13 08:04:53.38 Server ***Impossible d’obtenir le contexte des threads pour spid 0
2014-12-13 08:04:53.38 Server * *******************************************************************************
2014-12-13 08:04:53.38 Server *
2014-12-13 08:04:53.38 Serveur * DÉBUT DU VIDAGE DE LA PILE :
2014-12-13 08:04:53.38 Server * 12/13/14 08:04:53 SPID 29488
2014-12-13 08:04:53.38 Server *
2014-12-13 08:04:53.38 Serveur * Planificateur non productif
2014-12-13 08:04:53.38 Server *
2014-12-13 08:04:53.38 Server * *******************************************************************************
2014-12-13 08:04:53.38 Server Stack Signature for the dump is 0x0000000000000341
2014-12-13 08:04:55.43 Code de retour du processus de vidage externe serveur 0x20000001. Le processus de vidage externe n’a renvoyé aucune erreur.
2014-12-13 08:04:55.43 Server Process 0:0:0 (0x9358) Worker 0x0000000081CE41A0 semble ne pas céder sur Scheduler 4. Heure de création du thread : 13062953009701. Processeur de thread approx utilisé : noyau 0 ms, utilisateur 15 ms. Utilisation du processus 0 %. Système inactif 88 %. Intervalle : 70011 ms.

SQL Server peut ne pas répondre aux demandes des utilisateurs à ce stade. Si tel est le cas, vous devez redémarrer le service pour corriger la situation.

Cause

Ce problème se produit, car les requêtes utilisateur tentent d’utiliser les files d’attente de nettoyage fantôme avant que ce processus ne soit entièrement initialisé.

Résolution

Informations sur les Service Packs

Pour résoudre ce problème, procurez-vous le Service Pack 1 pour SQL Server 2014.

Pour plus d’informations sur SQL Server 2014 Service Pack 1 (SP1), consultez la section Bugs that are fixed in SQL Server 2014 Service Pack 1 .

Correctif logiciel pour SQL Server 2008 SP4

Pour résoudre ce problème, appliquez l'3034373 de la Base de connaissances : Un package de mise à jour de correctif logiciel à la demande est disponible pour SQL Server 2008 SP4.

Correctif logiciel pour SQL Server 2008 R2 SP3

Pour résoudre ce problème, appliquez l'3033860 de la Base de connaissances : Un package de mise à jour de correctif logiciel à la demande est disponible pour SQL Server 2008 R2 SP3.

Informations sur les mises à jour cumulatives

L’amélioration des fonctionnalités a été introduite dans la mise à jour cumulative suivante de SQL Server.

Mise à jour cumulative 6 pour SQL Server 2014 /en-us/help/3031047

Mise à jour cumulative 4 pour SQL Server 2012 SP2 /en-us/help/3007556

Mise à jour cumulative 14 pour SQL Server 2012 SP1 /en-us/help/3023636

À 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 :

      

Solution de contournement

Pour résoudre ce problème, procédez comme suit :

  1. Configurez -T669 comme paramètre de démarrage. Cet indicateur de trace empêche les requêtes des utilisateurs de mettre en file d’attente les demandes au processus de nettoyage fantôme.
  2. Configurez une alerte de l’SQL Server Agent pour déclencher un travail sur le message SQL 3408. Par exemple, configurez l’alerte suivante :
    La récupération est terminée. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
  3. À l’intérieur de cette tâche, exécutez un script TSQL pour attendre 5 à 10 minutes, puis exécutez la commande DBCC TRACEOFF (669,-1).

Cette procédure garantit que cet indicateur de trace est actif uniquement au démarrage de SQL Server. L’utilisation de cet indicateur de trace n’affecte pas le fonctionnement habituel du processus de nettoyage des fantômes d’arrière-plan.

État

Microsoft a confirmé qu’il s’agissait d’un problème avec SQL Server et cherche actuellement un correctif pour ce problème. Cet article de la Base de connaissances sera mis à jour avec des informations supplémentaires dès qu’elles seront disponibles.

Références

À l’intérieur du moteur de stockage : nettoyage fantôme en profondeur
        
         Alertes
        
         sp_add_alert (Transact-SQL)
        
         DBCC TRACEOFF (Transact-SQL)
        
         Indicateurs de trace
        
         Options de démarrage du moteur de base de données