SQL Server で XEvent セッションと sqlos.wait_info イベントを使用する場合のアクセス違反とメモリ ダンプ ファイル

この記事は、SQL Server で sqlos.wait_info イベントがある XEvent セッションを使用するときに発生する問題を解決するのに役立ちます。

元の製品バージョン: SQL Server
元の KB 番号: 4033835

現象

以下のシナリオについて考えてみます。

  • Microsoft SQL Server でsqlos.wait_infoイベントを含む XEvent セッションを作成します。

  • このセッションでは、次のパターンでフィルター (述語) を定義します。

    [sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%< **Query Text** >')
    

このシナリオでは、次のいずれかの問題が発生する可能性があります。

  • SQL Server は、アクセス違反またはスタック オーバーフロー メモリ ダンプ ファイルを生成します。

  • SQL Server は、生成されていないスケジューラ メモリ ダンプ ファイルを生成します。

  • クエリは結果を返さないか、クエリを取り消したり強制終了したりすることはできません。

  • SQL Server が SQL Server エラー ログにEXCEPTION_ACCESS_VIOLATION例外とスタック オーバーフロー メモリ ダンプ ファイルを生成すると次のいずれかのメッセージのようなエラー メッセージが生成されます。

    <タイムスタンプ> spid52 *
    <タイム スタンプ> spid52 * BEGIN STACK DUMP:
    <タイム スタンプ> spid52 *<Time Stamp> spid 52
    <タイムスタンプ> spid52 *
    <タイムスタンプ> spid52 *
    <Time Stamp> spid52 * Exception Address = 00007FFA414ED763 Module(sqlmin+0000000000D763)
    <タイムスタンプ> spid52 * 例外コード = c0000005 EXCEPTION_ACCESS_VIOLATION
    <タイム スタンプ> spid52 * アクセス違反がアドレス 0000000000000008の書き込み中に発生しました
    <タイム スタンプ> spid55 スタック不足のためスタック ダンプ ファイルを作成できません (場所: scheduler.cpp:2090
    式: !pWorker->WorkerQueueElem::IsInList ()
    SPID: 55
    プロセス ID: 8548)
    <タイムスタンプ> ダンプの spid55 スタック署名が0x0000000000000000
    <Time Stamp> spid55 <Time Stamp> Stack Overflow Dump not possible - Exception c00000fd EXCEPTION_STACK_OVERFLOW at 0x00007FFA4EF85F35
    <Time Stamp> spid55 SqlDumpExceptionHandler: Address=0x00007FFA4EF85F35 Exception Code = c00000fd
    <タイムスタンプ> spid55 Rax=000000000000044c Rbx=0000000002612320 Rcx=0000000002612050 Rdx=00000000662baf59
    <タイムスタンプ> spid55 Rsi=000000004b04f848 Rdi=0000000004b000270 Rip=000000004ef85f35 Rsp=00000000002611fd0
    <Time Stamp> spid55 Rbp=000000000000000000 EFlags=0000000000010202
    <タイム スタンプ> spid55 cs=0000000000000033 ss=000000000000002b ds=000000000000002b
    es=000000000000002b fs=0000000000000053 gs=000000000000002b
    <タイムスタンプ> spid55 1: フレーム 000000000000000000 リターン アドレス 00007FFA4EF85F35

回避策

この問題を回避するには、 wait_info イベントと共に複雑なフィルター条件を使用しないようにします。 これは、 wait_info イベントがリソースを大量に消費し、クエリの速度が大幅に低下する可能性があるためです。

このような状況で <Query Text> を追跡する場合は、フィルター述語パターンを次のように変更します。

([sqlserver].[equal_i_sql_unicode_string]([sqlserver].[sql_text],N'<Query Text>')