Accedi con Microsoft
Accedi o crea un account.
Salve,
Seleziona un altro account.
Hai più account
Scegli l'account con cui vuoi accedere.

Sintomi

Durante l'avvio di Microsoft SQL Server si noterà uno o più dei sintomi seguenti immediatamente dopo il completamento del ripristino del database e le connessioni client sono abilitate.

Sintomo 1

Vengono visualizzati messaggi di errore e asserzioni simili ai seguenti nel log degli errori di 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'. Questo errore può essere correlato alla temporizzazione. Se l'errore persiste dopo la rieseguire l'istruzione, usare DBCC CHECKDB per controllare il database per l'integrità strutturale oppure riavviare il server per verificare che le strutture di dati in memoria non siano danneggiate.

Sintomo 2

Vengono visualizzati messaggi di errore ed eccezioni simili alle seguenti nel log degli errori di SQL Server:

2014-12-13 12:38:30.25 spid51 con "dbghelp. dll" versione "4.0.5" 2014-12-13 12:38:30.25 spid51 * * * il dump dello stack viene inviato a C:\Programmi\Microsoft SQL Server \ MSSQL10_50. SQL2008R2\MSSQL\LOG\SQLDump0003.txt2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler: Process 51 ha generato l'eccezione fatale 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. La sessione viene terminata da SQL Server. Contattare il servizio di supporto tecnico prodotti con il dump prodotto nella directory log. La violazione di accesso avrà lo stack di chiamate seguente: sqlservr! TaskGhostCleanup:: Hashed + 0x8dsqlservr! TaskGhostCleanup:: accodare + 0x32sqlservr! IndexRowScanner:: MoveToRowOnNextPage + 0x9csqlservr! IndexDataSetSession:: GetNextRowValuesInternal + 0x11cb

Sintomo 3

Dopo aver ricevuto i messaggi menzionati nelle sezioni precedenti di sintomo, vengono visualizzati i messaggi seguenti nel log degli errori di SQL Server:

2014-12-13 08:04:53.37 Server Process 0:0:0 (0x23c8) 0x000000002880C1A0 Worker sembra non essere cedibile in Scheduler 23. Tempo di creazione del thread: 13062953007877. CPU del thread CA utilizzata: kernel 0 ms, utente 0 ms. Utilizzo processo 0%. Sistema inattivo 88%. Intervallo: 70013 ms. 2014-12-13 08:04:53.37 Server Process 0:0:0 (0x71d8) 0x000000002A8D21A0 Worker sembra non cedere in Scheduler 30. Tempo di creazione del thread: 13062953007891. CPU del thread CA utilizzata: kernel 0 ms, utente 0 ms. Utilizzo processo 0%. Sistema inattivo 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. Il processo di dump esterno non ha restituito errori. 2014-12-13 08:04:55.43 Server Process 0:0:0 (0x9358) 0x0000000081CE41A0 Worker sembra essere non cedente in Scheduler 4. Tempo di creazione del thread: 13062953009701. CPU del thread CA utilizzata: kernel 0 ms, utente 15 ms. Utilizzo processo 0%. Sistema inattivo 88%. Intervallo: 70011 ms.

A questo punto, SQL Server potrebbe non rispondere alle richieste degli utenti. In questo caso, devi riavviare il servizio per correggere la situazione.

Causa

Questo problema si verifica perché le query degli utenti provano a usare le code di pulizia fantasma prima che questo processo sia completamente inizializzato.

Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutti gli aggiornamenti della sicurezza inclusi nell'aggiornamento cumulativo precedente. Vedere gli ultimi aggiornamenti cumulativi per SQL Server:

Soluzione alternativa

Per risolvere il problema, eseguire le operazioni seguenti:

  1. Configura -T669 come parametro di avvio. Questi contrassegni di traccia impediscono alle query utente di accodare le richieste al processo di pulizia fantasma.

  2. Configurare un avviso di SQL Server Agent per attivare un processo in SQL msg 3408. Ad esempio, configurare l'avviso seguente:

    Il ripristino è completo. Si tratta solo di un messaggio informativo. Non è necessaria alcuna azione per l'utente.

  3. All'interno di questo processo eseguire uno script TSQL per attendere 5-10 minuti e quindi eseguire il comando DBCC TRACEOFF (669,-1) .

Questa procedura garantisce che il contrassegno di traccia sia attivo solo durante l'avvio di SQL Server. L'uso di questo flag di traccia non influisce sul funzionamento usuale del processo di pulizia dello sfondo di Ghost in background.

Stato

Microsoft ha confermato che si tratta di un problema con SQL Server e sta attualmente esaminando una correzione per questo problema. Questo articolo della Knowledge base verrà aggiornato con informazioni aggiuntive man mano che diventano disponibili.

Riferimenti

All'interno del motore di archiviazione: Ghost Cleanup in Depth Alerts sp_add_alert (Transact-SQL) DBCC TRACEOFF (Transact-SQL) Opzioni di avvio del motore di database diTrace Flags

Facebook LinkedIn Posta elettronica
SOTTOSCRIVI FEED RSS

Serve aiuto?

Vuoi altre opzioni?

Individua Community

Esplorare i vantaggi dell'abbonamento e i corsi di formazione, scoprire come proteggere il dispositivo e molto altro ancora.

Vantaggi dell'abbonamento a Microsoft 365

Formazione su Microsoft 365

Microsoft Security

Centro accessibilità

Le community aiutano a porre e a rispondere alle domande, a fornire feedback e ad ascoltare gli esperti con approfondite conoscenze.

Chiedi alla community Microsoft

Microsoft Tech Community

Partecipanti al Programma Windows Insider

Partecipanti al Programma Insider di Microsoft 365

Queste informazioni sono risultate utili?

Come valuti la qualità della lingua?
Cosa ha influito sulla tua esperienza?
Premendo Inviare, il tuo feedback verrà usato per migliorare i prodotti e i servizi Microsoft. L'amministratore IT potrà raccogliere questi dati. Informativa sulla privacy.

Grazie per il feedback!

×