Ошибка 17066 или 17310 во время запуска SQL Server

Применяется к
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

Проблема

Во время запуска Microsoft SQL Server вы заметите одно или несколько из следующих симптомов сразу после завершения восстановления базы данных и включения клиентских подключений.

Симптом 1

В журнале ошибок SQL Server появляются сообщения об ошибках и утверждения, похожие на следующие:

Примечание

2014-12-13 08:03:34.85 spid24s Использование 'dbghelp.dll' версии '4.0.5'
2014-12-13 08:03:34.85 spid24s **Поток дампа - spid = 0, EC = 0x0000000082274B20
2014-12-13 08:03:34.85 spid24s ***Стековый дамп, отправляемый в 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 * НАЧАЛО ДАМПА СТЕКА:
2014-12-13 08:03:34.85 spid24s * 13.12.14 08:03:34 spid 24
2014-12-13 08:03:34.85 spid24s *
2014-12-13 08:03:34.85 spid24s * Местоположение: ghost.cpp:1742
2014-12-13 08:03:34.85 spid24s * Выражение: tcln1 != NULL
2014-12-13 08:03:34.85 spid24s * SPID: 24
2014-12-13 08:03:34.85 spid24s * Идентификатор процесса: 35444
2014-12-13 08:03:34.85 spid24s *

2014-12-13 08:03:35.47 spid24s Ошибка: 17066, Серьезность: 16, Состояние: 1.
2014-12-13 08:03:35.47 spid24s SQL Server Assertion: File: <ghost.cpp>, line=1742 Failed Assertion = 'tcln1 != NULL'. Эта ошибка может быть связана со временем. Если ошибка сохраняется после повторного запуска инструкции, используйте DBCC CHECKDB для проверки базы данных на предмет структурной целостности или перезапустите сервер, чтобы убедиться, что структуры данных в памяти не повреждены.

Симптом 2

В журнале ошибок SQL Server появляются сообщения об ошибках и исключения, похожие на следующие:

Примечание

2014-12-13 12:38:30.25 spid51 Использование 'dbghelp.dll' версии '4.0.5'
2014-12-13 12:38:30.25 spid51 ***Стековый дамп отправляется в C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0003.txt
2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler: процесс 51 создал неустранимое исключение c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server завершает этот процесс.
2014-12-13 12:38:30.25 spid51 * *******************************************************************************
2014-12-13 12:38:30.25 spid51 *
2014-12-13 12:38:30.25 spid51 * НАЧАЛО ДАМПА СТЕКА:
2014-12-13 12:38:30.25 spid51 * 13.12.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 * Адрес исключения = 00000000030D47C Module(sqlservr+000000000000FD47C)
2014-12-13 12:38:30.25 spid51 * Код исключения = c0000005 EXCEPTION_ACCESS_VIOLATION
2014-12-13 12:38:30.25 spid51 * Произошло нарушение прав доступа при чтении адреса FFFFFFFFFFFFFFFF
2014-12-13 12:38:30.25 spid51 * Входной буфер 54 байт -
2014-12-13 12:38:30.25 spid51 * исполнительный usp_select1

2014-12-13 12:38:30.77 Server Error: 17310, Severity: 20, State: 1.
2014-12-13 12:38:30.77 Server Запрос пользователя из сеанса со SPID 51 создал неустранимое исключение. SQL Server завершает этот сеанс. Обратитесь в службу поддержки продукта с дампом, созданным в каталоге журнала.

Нарушение прав доступа будет иметь следующий стек вызовов:

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

Симптом 3

После получения сообщений, упомянутых в предыдущих разделах симптомов, в журнале ошибок SQL Server появятся следующие сообщения:

Примечание

2014-12-13 08:04:53.37 Серверный процесс 0:0:0 (0x23c8) Рабочий 0x000000002880C1A0 не уступает в планировщике 23. Время создания цепочки: 13062953007877. Приблизительно ЦП потока Используется: ядро 0 мс, пользователь 0 мс. Использование процесса 0%. Система простаивает 88%. Интервал: 70013 мс.
2014-12-13 08:04:53.37 Server Process 0:0:0 (0x71d8) Worker 0x000000002A8D21A0 не уступает в планировщике 30. Время создания цепочки: 13062953007891. Приблизительно ЦП потока Используется: ядро 0 мс, пользователь 0 мс. Использование процесса 0%. Система простаивает 88%. Интервал: 70013 мс.
2014-12-13 08:04:53.38 Сервер ***Не удалось получить контекст потока для spid 0
2014-12-13 08:04:53.38 Сервер * *******************************************************************************
2014-12-13 08:04:53.38 Сервер *
2014-12-13 08:04:53.38 Сервер * НАЧАЛО ДАМПА СТЕКА:
2014-12-13 08:04:53.38 Сервер * 13.12.14 08:04:53 spid 29488
2014-12-13 08:04:53.38 Сервер *
2014-12-13 08:04:53.38 Server * Планировщик неуступчивости
2014-12-13 08:04:53.38 Сервер *
2014-12-13 08:04:53.38 Сервер * *******************************************************************************
2014-12-13 08:04:53.38 Подпись стека серверов для дампа 0x0000000000000341
2014-12-13 08:04:55.43 Сервер Внешний дамп кода возврата 0x20000001. Внешний процесс дампа не вернул ошибок.
2014-12-13 08:04:55.43 Server Process 0:0:0 (0x9358) Worker 0x0000000081CE41A0, по-видимому, не уступает в планировщике 4. Время создания цепочки: 13062953009701. Приблизительно ЦП потока Используется: ядро 0 мс, пользователь 15 мс. Использование процесса 0%. Система простаивает 88%. Интервал: 70011 мс.

В этот момент SQL Server может не отвечать на запросы пользователей. В этом случае для исправления ситуации необходимо перезапустить службу.

Причина

Эта проблема возникает из-за того, что запросы пользователей пытаются использовать очереди фантомной очистки до того, как этот процесс будет полностью инициализирован.

Решение

Сведения о пакете обновления

Чтобы устранить эту проблему, приобретите пакет обновления 1 для SQL Server 2014.

Дополнительные сведения о SQL Server 2014 с пакетом обновления 1 (SP1) см. в статье об ошибках, исправленных в SQL Server 2014 с пакетом обновления 1.

Исправление для SQL Server 2008 с пакетом обновления 4 (SP4)

Чтобы устранить эту проблему, примените 3034373 KB. Доступен пакет исправлений по запросу для SQL Server 2008 SP4.

Исправление для SQL Server 2008 R2 с пакетом обновления 3 (SP3)

Чтобы устранить эту проблему, примените 3033860 KB: Доступен пакет исправлений по запросу для SQL Server 2008 R2 SP3.

Сведения о накопительном пакете обновления

Улучшение функций представлено в следующем накопительном пакете обновления SQL Server.

Накопительный пакет обновления 6 для SQL Server 2014 г. /ru-us/help/3031047

Накопительный пакет обновления 4 для SQL Server 2012 с пакетом обновления 2 (SP2) /en-us/help/3007556

Накопительный пакет обновления 14 для SQL Server 2012 с пакетом обновления 1 (SP1) /en-us/help/3023636

Сведения о накопительных обновлениях для SQL Server

Каждый новый накопительный пакет обновления для SQL Server содержит все исправления и исправления безопасности, которые входили в состав предыдущего накопительного пакета обновления. Ознакомьтесь с последними накопительными пакетами обновления для SQL Server:

      

Временное решение

Чтобы обойти эту проблему, выполните следующие действия.

  1. Настройте -T669 в качестве параметра запуска. Эти флаги трассировки не позволяют пользовательским запросам ставить запросы в очередь процесса фантомной очистки.
  2. Настройте оповещение агента SQL Server для запуска задания в SQL MSG 3408. Например, настройте следующее оповещение:
    Восстановление завершено. Это информационное сообщение. Никаких действий со стороны пользователя не требуется.
  3. В этом задании запустите сценарий TSQL, чтобы подождать 5–10 минут, а затем выполните команду DBCC TRACEOFF (669,-1).

Эта процедура гарантирует, что этот флаг трассировки будет активен только во время запуска SQL Server. Использование этого флага трассировки не влияет на обычное функционирование процесса фоновой фантомной очистки.

Состояние

Корпорация Майкрософт подтвердила, что это проблема с SQL Server, и в настоящее время изучает решение этой проблемы. Эта статья базы знаний будет обновляться дополнительными сведениями по мере их поступления.

Ссылки

Внутри Storage Engine: Ghost cleanup в подробностях
        
         Оповещения
        
         sp_add_alert (Transact-SQL)
        
         DBCC TRACEOFF (Transact-SQL)
        
         Флаги трассировки
        
         Параметры запуска ядра СУБД