Symptômes

Lors du démarrage de Microsoft SQL Server, vous remarquez un ou plusieurs des problèmes suivants immédiatement après la récupération de la base de données et les connexions client.

Symptôme 1

Vous recevez des messages d’erreur et des affirmations similaires à ce qui suit dans le journal des erreurs SQL Server :

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 = 0x0000000082274B202014-12-13 08:03:34.85 spid24s ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0001.txt2014-12-13 08:03:34.85 spid24s * *******************************************************************************2014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * BEGIN STACK DUMP:2014-12-13 08:03:34.85 spid24s * 12/13/14 08:03:34 spid 242014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * Location: ghost.cpp:17422014-12-13 08:03:34.85 spid24s * Expression: tcln1 != NULL2014-12-13 08:03:34.85 spid24s * SPID: 242014-12-13 08:03:34.85 spid24s * Process ID: 354442014-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 Failed Assertion = 'tcln1 != NULL'. Cette erreur est éventuellement liée au minutage. Si l’erreur persiste après avoir reexécuté l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de données, ou redémarrez le serveur pour vérifier 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 à ce qui suit dans le journal des erreurs SQL Server :

2014-12-13 12:38:30.25 spid51 en utilisant’dbghelp. dll’version' 4.0.5 ' 2014-12-13 12:38:30.25 spid51 * * * vidage de la pile envoyé à C:\Program Files\Microsoft SQL Server \ MSSQL10_50. SQL2008R2\MSSQL\LOG\SQLDump0003.txt2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler : le processus 51 a généré une erreur irrécupérable c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.2014-12-13 12:38:30.25 spid51 * *******************************************************************************2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * BEGIN STACK DUMP:2014-12-13 12:38:30.25 spid51 * 12/13/14 12:38:30 spid 512014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * Exception Address = 000000000030D47C Module(sqlservr+00000000000FD47C)2014-12-13 12:38:30.25 spid51 * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION2014-12-13 12:38:30.25 spid51 * Access Violation occurred reading address FFFFFFFFFFFFFFFF2014-12-13 12:38:30.25 spid51 * Input Buffer 54 bytes -2014-12-13 12:38:30.25 spid51 * exec usp_select12014-12-13 12:38:30.77 Server Error: 17310, Severity: 20, State: 1.2014-12-13 12:38:30.77 Server A user request from the session with SPID 51 generated a fatal exception. SQL Server met fin à cette session. Contactez les services de support technique en utilisant le vidage produit dans le répertoire du journal. La violation d’accès aura la pile d’appels suivante : sqlservr. TaskGhostCleanup :: IsHashed + 0x8dsqlservr ! TaskGhostCleanup :: enqueue + 0x32sqlservr. IndexRowScanner :: MoveToRowOnNextPage + 0x9csqlservr ! IndexDataSetSession :: GetNextRowValuesInternal + 0x11cb

Symptôme 3

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

2014-12-13 08:04:53.37 Server Process 0:0:0 (0x23c8) Worker 0x000000002880C1A0 semble non-yield on Scheduler 23. Heure de création du thread : 13062953007877. Approx. processeur utilisée : 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 apparaît comme non-yield on Scheduler 30. Heure de création du thread : 13062953007891. Approx. processeur utilisée : noyau 0 ms, utilisateur 0 ms. Utilisation du processus 0%. Système inactif 88%. Interval: 70013 ms.2014-12-13 08:04:53.38 Server ***Unable to get thread context for spid 02014-12-13 08:04:53.38 Server * *******************************************************************************2014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * BEGIN STACK DUMP:2014-12-13 08:04:53.38 Server * 12/13/14 08:04:53 spid 294882014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * Non-yielding Scheduler2014-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 0x00000000000003412014-12-13 08:04:55.43 Server External dump process return code 0x20000001. Le processus de vidage externe n’a pas renvoyé d’erreur. 2014-12-13 08:04:55.43 Server Process 0:0:0 (0x9358) Worker 0x0000000081CE41A0 semble non-revenuable sur le programmateur 4. Heure de création du thread : 13062953009701. Approx. processeur utilisée : noyau 0 ms, utilisateur 15 ms. Utilisation du processus 0%. Système inactif 88%. Intervalle : 70011 ms.

SQL Server ne répond pas aux demandes des utilisateurs à ce stade. Si tel est le cas, vous devez redémarrer le service pour résoudre ce problème.

Cause

Ce problème survient parce que les requêtes de l’utilisateur essaient d’utiliser les files d’attente de nettoyage de Ghost avant que ce processus ne soit complètement initialisé.

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 :

Solution de contournement

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

  1. Configurez -T669 en tant que paramètre de démarrage. Cet indicateur de suivi empêche les requêtes de l’utilisateur de traiter les demandes en file d’attente au processus de nettoyage de fantôme.

  2. Définissez une alerte d’agent SQL Server pour déclencher une tâche sur le message SQL MSG 3408. Par exemple, configurez l’alerte suivante :

    La récupération est terminée. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise.

  3. Dans cette tâche, exécutez un script TSQL pour attendre de 5 à 10 minutes, puis exécutez la commande DBCC TRACEOFF (669,-1) .

Cette procédure vérifie que cet indicateur de suivi est actif uniquement lors du démarrage de SQL Server. L’utilisation de cet indicateur de suivi n’a pas d’incidence sur le fonctionnement habituel du processus de nettoyage de fantôme en arrière-plan.

Statut

Microsoft a confirmé qu’il s’agit d’un problème lié à SQL Server et qu’il étudie actuellement un correctif pour résoudre ce problème. Cet article de la base de connaissances sera mis à jour avec des informations supplémentaires dès qu’il sera disponible.

Références

À l’intérieur du moteur de stockage : des alertes de nettoyage de profondeur sp_add_alert (Transact-SQL) DBCC TRACEOFF (Transact-SQL)

Besoin d’aide ?

Développez vos compétences

Découvrez des formations >

Accédez aux nouvelles fonctionnalités en avant-première

Rejoindre Microsoft Insider >

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la langue ?
Qu’est-ce qui a affecté votre expérience ?

Nous vous remercions de vos commentaires.

×