Bei Microsoft anmelden
Melden Sie sich an, oder erstellen Sie ein Konto.
Hallo,
Wählen Sie ein anderes Konto aus.
Sie haben mehrere Konten.
Wählen Sie das Konto aus, mit dem Sie sich anmelden möchten.

Problembeschreibung

Während des Microsoft SQL Server-Starts bemerken Sie unmittelbar nach Abschluss der Datenbankwiederherstellung eines oder mehrere der folgenden Symptome, und Clientverbindungen sind aktiviert.

Symptom 1

Sie erhalten Fehlermeldungen und Assertionen, die in Ihrem SQL Server-Fehlerprotokoll wie folgt aussehen:

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'. Dieser Fehler kann Zeit bezogen sein. Wenn der Fehler nach erneuter Ausführung der Anweisung weiterhin auftritt, verwenden Sie DBCC CHECKDB, um die Datenbank auf strukturelle Integrität zu überprüfen, oder starten Sie den Server neu, um sicherzustellen, dass die Datenstrukturen im Arbeitsspeicher nicht beschädigt sind.

Symptom 2

Sie erhalten Fehlermeldungen und Ausnahmen, die in Ihrem SQL Server-Fehlerprotokoll wie folgt aussehen:

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 wird an c:\Programme\Microsoft SQL Server \ MSSQL10_50. SQL2008R2\MSSQL\LOG\SQLDump0003.txt2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler: Process 51 generiert schwerwiegende Ausnahme 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 beendet diese Sitzung. Wenden Sie sich an den Product Support Services mit dem im Protokollverzeichnis erstellten Dump. Die Zugriffsverletzung hat den folgenden Aufruf Stapel: sqlservr! TaskGhostCleanup:: ishashed + 0x8dsqlservr! TaskGhostCleanup:: Enqueue + 0x32sqlservr! IndexRowScanner:: MoveToRowOnNextPage + 0x9csqlservr! IndexDataSetSession:: GetNextRowValuesInternal + 0x11cb

Symptom 3

Nachdem Sie die Nachrichten erhalten haben, die in den vorherigen Symptom Abschnitten erwähnt wurden, erhalten Sie im SQL Server-Fehlerprotokoll die folgenden Nachrichten:

2014-12-13 08:04:53.37 Server Process 0:0:0 (0x23c8) Worker 0x000000002880C1A0 scheint im Scheduler 23 nicht zu sein. Thread Erstellungszeit: 13062953007877. Ca. Thread-CPU verwendet: Kernel 0 ms, Benutzer 0 ms. Prozessnutzung 0%. System Idle 88%. Intervall: 70013 ms. 2014-12-13 08:04:53.37-Server Prozess 0:0:0 (0x71d8) Worker-0x000000002A8D21A0 scheint im Scheduler 30 nicht zu sein. Thread Erstellungszeit: 13062953007891. Ca. Thread-CPU verwendet: Kernel 0 ms, Benutzer 0 ms. Prozessnutzung 0%. System Idle 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. Der externe dumpprozess hat keine Fehler zurückgegeben. 2014-12-13 08:04:55.43-Server Prozess 0:0:0 (0x9358) Worker 0x0000000081CE41A0 scheint in Scheduler 4 nicht zu sein. Thread Erstellungszeit: 13062953009701. Ca. Thread-CPU verwendet: Kernel 0 ms, Benutzer 15 ms. Prozessnutzung 0%. System Idle 88%. Intervall: 70011 ms.

SQL Server reagiert zu diesem Zeitpunkt möglicherweise nicht auf Benutzeranforderungen. In diesem Fall müssen Sie den Dienst neu starten, um die Situation zu beheben.

Ursache

Dieses Problem tritt auf, weil Benutzer Abfragen versuchen, die Ghost Cleanup-Warteschlangen zu verwenden, bevor dieser Prozess vollständig initialisiert wird.

Jedes neue kumulative Update für SQL Server enthält alle Hotfixes und alle Sicherheitsupdates, die im vorherigen kumulativen Update enthalten waren. Schauen Sie sich die neuesten kumulativen Updates für SQL Server an:

Problemumgehung

Führen Sie die folgenden Schritte aus, um dieses Problem zu umgehen:

  1. Configure -T669 as Startup Parameter. Diese Ablaufverfolgungsflags verhindern, dass Benutzer Abfragen aus Warteschlangenanforderungen an den Ghost-Cleanupprozess durchführen.

  2. Richten Sie eine SQL Server-Agent-Benachrichtigung ein, um einen Auftrag in SQL msg 3408 auszulösen. Richten Sie beispielsweise die folgende Warnung ein:

    Die Wiederherstellung ist abgeschlossen. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.

  3. Führen Sie innerhalb dieses Auftrags ein TSQL-Skript aus, um 5 bis 10 Minuten zu warten, und führen Sie dann den Befehl DBCC TRACEOFF (669,-1) aus.

Dieses Verfahren stellt sicher, dass dieses Ablaufverfolgungsflag nur während des SQL Server-Starts aktiviert ist. Die Verwendung dieses Ablaufverfolgungsflags hat keinen Einfluss auf die übliche Funktion des Ghost Cleanup-Hintergrundprozesses.

Status

Microsoft hat bestätigt, dass es sich um ein Problem mit SQL Server handelt, und untersucht derzeit eine Lösung für dieses Problem. Dieser Knowledge Base-Artikel wird mit zusätzlichen Informationen aktualisiert, sobald er verfügbar ist.

Informationsquellen

Innerhalb des Speichermoduls: Ghost Cleanup in Depth Alerts Sp_add_alert (Transact-SQL) DBCC TRACEOFF (Transact-SQL) Trace Flags Datenbankmodul-Startoptionen

Benötigen Sie weitere Hilfe?

Möchten Sie weitere Optionen?

Erkunden Sie die Abonnementvorteile, durchsuchen Sie Trainingskurse, erfahren Sie, wie Sie Ihr Gerät schützen und vieles mehr.

In den Communities können Sie Fragen stellen und beantworten, Feedback geben und von Experten mit umfassendem Wissen hören.

War diese Information hilfreich?

Wie zufrieden sind Sie mit der Sprachqualität?
Was hat Ihre Erfahrung beeinflusst?
Wenn Sie auf "Absenden" klicken, wird Ihr Feedback zur Verbesserung von Produkten und Diensten von Microsoft verwendet. Ihr IT-Administrator kann diese Daten sammeln. Datenschutzbestimmungen.

Vielen Dank für Ihr Feedback!

×