SQL Server 起動時のエラー 17066 または 17310

どこにいても、どのデバイスからでも、 Microsoft 365

Microsoft 365 にアップグレードして、最新の機能と更新プログラムを利用できます。

今すぐアップグレード

現象

Microsoft SQL Server 起動時に、データベースの回復が完了し、クライアント接続が有効になると、すぐに以下の現象が 1 つまたは複数発生します。

現象 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 を指定して 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 * 12/13/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 * プロセス ID: 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 アサーション: ファイル: < ghost.cpp > は、行 = 1742 失敗したアサーション = ' 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 を指定して SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0003.txt に送信されるスタックのダンプ。
2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler: プロセス 51 に致命的な例外が生成される c0000005 を参照します。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 * 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 * 例外アドレス = 000000000030D47C Module(sqlservr+00000000000FD47C)
2014-12-13 12:38:30.25 spid51 * 例外コード = c0000005 参照
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 * exec usp_select1

2014-12-13 12:38:30.77 サーバー エラー: 17310、レベル: 20、状態: 1 です。
SPID 51 がセッションから 2014-12-13 12:38:30.77 サーバー A のユーザー要求には、致命的な例外が生成されます。SQL Server はこのプロセスを終了しています。ログ ディレクトリに生成されるダンプを使用して、Product Support Services までお問い合わせください。

アクセス違反は、以下の呼び出しスタックを作成します。

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 です。概算のスレッドの CPU 使用率はカーネル 0 ms、ユーザー 0 ms、プロセス使用率は 0% です。システムの 88% がアイドル状態です。間隔は 70013 ms です。
2014-12-13 08:04:53.37 サーバー プロセス 0:0:0 (0x71d8) ワーカー 0x000000002A8D21A0 が解放されていないスケジューラの 30 のように見えます。スレッドの作成時刻は 13062953007891 です。概算のスレッドの CPU 使用率はカーネル 0 ms、ユーザー 0 ms、プロセス使用率は 0% です。システムの 88% がアイドル状態です。間隔は 70013 ms です。
2014-12-13 08:04:53.38 サーバー。 0 の spid のスレッドのコンテキストを取得できませんでした。
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 サーバー * 12/13/14 08時 04分: 53 spid 29488
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 Server * *******************************************************************************
ダンプの 2014-12-13 08:04:53.38 サーバー スタックの署名は、0x0000000000000341 です。
2014-12-13 08:04:55.43 サーバーの外部のダンプ プロセスはリターン コード 0x20000001 です。外部ダンプ プロセスは、エラーを返しませんでした。
2014-12-13 08:04:55.43 サーバー プロセス 0:0:0 (0x9358) ワーカー 0x0000000081CE41A0 が解放されていないスケジューラ 4 のように見えます。スレッドの作成時刻は 13062953009701 です。概算のスレッドの CPU の使用率はカーネル 0 ms、ユーザー 15 ms、プロセス使用率は 0% です。システムの 88% がアイドル状態です。間隔は 70011 ms です。


この時点で、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 の問題であることと、この問題の修正プログラムが現在調査中であることを確認済みです。このサポート技術情報資料は、利用可能になった追加情報を更新します。

関連情報

ストレージ エンジン内: ゴースト クリーンアップの深さ

アラート

sp_add_alert (Transact-SQL)

DBCC TRACEOFF (Transact-SQL)

トレース フラグ

データベース エンジンのスタートアップ オプション

ヘルプを表示

スキルを磨く
トレーニングの探索
新機能を最初に入手
Microsoft Insider に参加する

この情報は役に立ちましたか?

フィードバックをお送りいただきありがとうございます!

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×