SQL Server ではダンプが出力されるエラーの種類としては、[A15] SQL Server Trouble Shooting Tips from Support Team by Takashi Honma で解説されている次のような種類があります。
- Access Violation
- Assertion
- Latch Timeout
- Non-yielding Scheduler
- Deadllock Schedulers
- Non-yielding Resource Monitor
- Non-yielding IOCP Listener
この中で Assertion (アサーション) のダンプについてまとめておきたいと思います。
Assertion はどのような時に発生するのか？
Assertion は SQL Server のコード上のチェックにより明示的に発生する例外となります。
SQL Server のコード内には次のような Assertion のコードが含まれており、特定の条件に合致した (または合致しなかった) 場合には、Assertion が呼び出され SQL Server はダンプが出力されます。
上記の内容の場合は「RESTORE VERIFYONLY」の処理の中に実装されている Assertion となるのですが、このステートメントの中ではいくつかのチェックが行われています。
RESTORE VERIFYONLY ではこれらのチェックをパスできないと最終的には Assertion のコードが呼ばれているようでした。
今回は強制的に Assertion を呼び出すため上記の処理にパッチを当て「je」時のジャンプ先を Assertion のコードに変えています。
(ジャンプ先を sqlmin!MediaReadInterface::Wait+0xee から 0x76 に変更しています)
そうすると上記のコードが呼ばれた際には、ジャンプ先が、Assertion をコールされるコードとなっていますので、処理を進めると Assertion が発生します。
RESTORE VERIFY を実行したクエリウィンドウが以下になるのですが、Assertion が発生していることがメッセージから確認できますね。
Assertion 発生時のダンプ
Assertion はダンプが出力されますので、ERRORLOG を確認すると、次のようにダンプが出力されていることが確認できます。ダンプ出力時には、DBCC INPUTBUFFER で Assertion が発生したステートメントの情報が確認できるようになっています。 
今回の Assertion であれば、ERRORLOG には次のような情報も出力されていますので、どのような処理でダンプが出力されたのかを想定をすることが可能です。
SQL Server Assertion: File: <mediaRead.cpp>, line=437 Failed Assertion = ‘ReadPipelineIsInProgress ()’. This error may be timing-related. If the error persists after rerunning the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.
Assertion のダンプについては「!analyze -v」である程度の情報を確認することができるようになっていますので Windbg で確認をしてみるもの方法として考えられます。
Assertion 発生時の対応について
Assertion の根本原因については、特定タイミングの予期せぬ処理により、メモリ上のデータ破損の可能性もあります。
発生時の回避をユーザー側で実現することは困難であり、次のいずれかの方法による解決が一般的な方法となります。
- 最新の累積修正プログラムで該当の Assertion に対する修正が行われていないか
- Microsoft の有償サポートを使用して根本原因の解決を行う
- 有償サポートがプロフェッショナルサポートの場合は、最新の累積修正プログラムを導入してからでないと、根本的な問題解決が困難なケースがあるかもしれません。