KB4338890 - 修正: 2014 年、2016 年、2017 年SQL Serverに "非生成スケジューラ" エラーとSQL Serverが応答しなくなります

適用先
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

現象

Microsoft SQL Server 2014、2016、または 2017 がインストールされていることを前提としています。  次の 1 つ以上の問題が発生する可能性があります。

  • SQL Server インスタンスが応答しなくなったように見え、"生成されないスケジューラ" エラーが発生します。 回復するには、サーバーを再起動する必要がある場合があります。
  • トランザクションのロールバックが完了するまでに長い時間がかかる場合があります。 ほとんどの場合、インスタンスを再起動すると、データベースはロールバックよりもはるかに高速に復旧できます。 ロールバックが完了するまでに長い時間がかかる理由は数多くあることに注意してください。再起動を試みる前のロールバックの監視の詳細については、以下の「詳細情報」セクションを参照してください。
  • SOS_OBJECT_STOREなどのスピンロックに対して高い待機が表示される場合があります。

解決策

この問題は、SQL Serverの次の累積的な更新プログラムで修正されています。

SQL Server 2017 の累積的な更新プログラム 9

SQL Server 2016 SP2 の累積的な更新プログラム 2

SQL Serverの累積的な更新プログラムについて:

SQL Serverの各新しい累積的な更新プログラムには、すべての修正プログラムと、以前の累積的な更新プログラムに含まれていたすべてのセキュリティ修正プログラムが含まれています。 SQL Serverの最新の累積的な更新プログラムを確認してください。

SQL Server 2017 の最新の累積的な更新プログラム

SQL Server 2016 の最新の累積的な更新プログラム

SQL Server 2014 の最新の累積的な更新プログラム

SQL Serverのサービス パック情報

この更新プログラムは、SQL Serverの次の Service Pack で修正されています。

SQL Server 2014 用 Service Pack 3

SQL Serverのサービス パックについて:

Service Pack は累積的であり、 最新の Service Pack には新しい修正プログラムと共に、それ以前の Service Pack に含まれていたすべての修正プログラムが含まれています。 このサービス パックの最新の Service Pack と最新の累積的な更新プログラムを適用することをお勧めします。 最新の Service Pack をインストールする前に、以前の Service Pack をインストールする必要はありません。 最新の Service Pack と最新の累積的な更新プログラムの詳細については、次の記事の表 1 を参照してください。

SQL Server とそのコンポーネントのバージョン、エディション、および更新プログラムのレベルを確認する方法

詳細情報

実行時間の長いトランザクション、トランザクション ログ ファイル内の多数の VDF、低速 I/O など、ロールバックに時間がかかる理由は多数あります。この記事で説明されている問題がロールバック速度の低下の根本原因であることを確認するために、ロールバック操作の進行状況を監視するには、次の手法を使用することをお勧めします。

  • sys.dm_exec_requestsから、コマンドが "KILLED/ROLLBACK" に設定されているsession_idを特定し、セッションが進行状況を示す IO 時間と CPU 時間の両方を累積していることを確認します。 IO が変更されていない場合は、この記事で説明されている問題が発生していることを示している可能性があります。
  • クエリ sys.dm_tran_database_transactions 、次のようなクエリを使用してロールバックの現在の状態を識別します。

注

  • getdate() を CurrentTime、database_transaction_next_undo_lsn、database_transaction_begin_lsn、t.transaction_id、database_transaction_begin_time、database_transaction_log_record_count、db_name(t.database_id) として選択します
  • FROM sys.dm_tran_database_transactions t
  • join sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Database Name') と s.session_id=<Session_idロールバック操作を実行します>

注:

上記のクエリでは、

database_transaction_next_undo_lsn は、元に戻す次のレコードの LSN です。 database_transaction_begin_lsn は、トランザクション ログ内のトランザクションの開始レコードの LSN です。

database_transaction_next_undo_lsnは、このクエリの各スナップショットで減少しているはずです。 ロールバックは、 database_transaction_next_undo_lsnがdatabase_transaction_begin_lsn に達すると正常に完了します。

ここでの目標は、前のクエリのスナップショットをいくつか所定の間隔で取得し、その間隔内の database_transaction_next_undo_lsn で処理された LSN の差分を使用し、 database_transaction_next_undo_lsn が database_transaction_begin_lsnに到達するまでにかかる時間を見積もるためにかかる時間を推定することです。

各スナップショット間で適切な速度でロールバックが進行している場合は、SQL Server インスタンスを再起動せずに、ロールバックを単独で完了できるようにすることをお勧めします。

実行時間の長い復旧の詳細については、次の記事を参照してください。

状態

Microsoft は、これが "適用対象" セクションに記載されている Microsoft 製品の問題であることを確認しました。

参考資料

マイクロソフトでソフトウェア更新プログラムの説明に使用する用語集を参照してください。