SQL Server の compile ロックが発生したブロックの説明

文書翻訳 文書翻訳
文書番号: 263889
すべて展開する | すべて折りたたむ

目次

概要

Microsoft SQL Server では、ストアド プロシージャ プランの 1 つだけのコピーは同時にキャッシュに通常です。これを強制する、コンパイル プロセスの一部のシリアル化をする必要があります、一部で compile ロックを使用して同期が行われます。同じストアド プロシージャを同時に多数の接続を実行しているし、コンパイル ロックそのストアド プロシージャを実行するたびに取得が必要の場合は、システム プロセス Id (Spid) が各オブジェクトは排他コンパイル ロックを取得しようとお互いにブロックを開始します。

詳細

ストアド プロシージャの再コンパイルは、ストアド プロシージャ、またはトリガーにコンパイル ロックの詳細については 1 つです。ソリューションは、小さくか、再コンパイルを回避するのにはここでです。ストアド プロシージャを再コンパイルする必要がありますは、最も一般的な原因の詳細については、再コンパイルの頻度を減らすことにいくつかの有用な情報は、次の Microsoft Knowledge Base の資料を参照してください。
243586 ストアド プロシージャの再コンパイルのトラブルシューティング
次の条件に該当する場合にコンパイル ロックが発生することもできます。
  • ストアド プロシージャを実行するユーザーは、プロシージャの所有者ではありません。
  • ストアド プロシージャ名は、オブジェクト所有者名で完全修飾ではありません。
たとえば、ユーザーの"dbo"がオブジェクトを所有している場合 dbo.mystoredproc 「ハリー、」別のユーザー、所有者で修飾されたオブジェクトではないため、コマンド"exec mystoredproc、"オブジェクト名が失敗して初期キャッシュ ルックアップを使用してこのストアド プロシージャを実行します。(これは Harry.mystoredproc という別のストアド プロシージャが存在するかどうか不明です。したがって、SQL Server dbo.mystoredproc のキャッシュされたプランの実行に適切なものであることを確認してすることはできません。)SQL Server は排他コンパイル ロックの手を取得し、プロシージャをコンパイルする準備ができます。これは、オブジェクト ID にオブジェクト名を解決するが含まれていますSQL Server プランをコンパイルする前に、SQL Server このオブジェクト ID を使用して、プロシージャ キャッシュのより正確な検索を実行するのには、所有者限定なしでも以前コンパイルされたプランを見つけることができます。

既存のプランが見つかれば、SQL Server、キャッシュされたプランを再利用して、ストアド プロシージャは、実際にはコンパイルされません。ただし、所有者-限定がないため、2 番目のキャッシュ検索を実行し、既存のキャッシュされた実行プランを再利用できるように、プログラムを決定する前に、コンパイルの排他ロックを取得するのには、SQL サーバー必要があります。ロックを取得し、参照し、このポイントに到達するために必要なその他の作業を実行する、ブロックにつながる、コンパイル ロックの遅延を導入できます。これは、所有者名を指定せず、プロシージャを同時に実行するストアド プロシージャの所有者でないユーザー多くの場合は特にそうです。コンパイル ロックを待機している Spid が表示されない場合でも、所有者-限定がないはストアド プロシージャの実行の遅延を紹介し、不必要に高い CPU 使用率が発生することに注意します。

この問題が発生すると、SQL Server プロファイラー トレースに、次の一連のイベントが記録されます。(キャッシュに関連するイベントをトレースするには、高度なイベント使用する必要があります。これを行うをクリックしてください。オプション で、 ツール メニューのしを選択 すべてのイベント クラス。)

元に戻す全体を表示する
イベント クラステキスト
RPC: 開始mystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: 開始mystoredproc
......

SP:CacheMiss名前によってキャッシュ ルックアップが失敗した場合に発生します。次に、 SP:ExecContextHit あいまいなオブジェクト名、オブジェクト ID に解決すると、対応するキャッシュされたプラン最終的にキャッシュに見つからなかったことを示します状況によっては、 SP:CacheHit代わりに表示される可能性があります。SP:ExecContextHit.

コンパイル ロックの場合は、この問題を解決するは、ストアド プロシージャへの参照を所有者で修飾されたであるかどうかを確認することです。ではなく exec mystoredproc、exec を使用します。 dbo.mystoredproc.)所有者-限定がパフォーマンス上の理由が重要ですが、ストアド プロシージャの追加キャッシュ参照を防ぐために、データベース名を修飾する必要はありません。

ブロック ロックを検出するには、以下の技術文書で定義されているものなどのブロッキング スクリプトを使用してコンパイルが原因で発生します。
251004 [INF] SQL Server 7.0 ブロッキングを監視する方法
271509 INF: SQL Server 2000年のブロッキングを監視する方法
ブロッキング スクリプトの出力で確認できますコンパイル ブロックのある代表的な特性を以下に示します。
  • lastwaittype ブロックとは、通常のブロッキング Spid の LCK_M_X (排他) には、 waitresource 形式は"タブ: dbid。object_id [、「Object_id」を、ストアド プロシージャのオブジェクト ID がコンパイル]]"。
  • ブロックにあります。 waittype 0x0000、実行可能な状態を指定します。Blockees があります。 waittype 0x000e (排他的ロック) のステータスが休止します。
  • ブロッキングの発生の時間が長くなる可能性がありますが、長年にわたり、他の Spid をブロックしている SPID を 1 つはありません。ローリングをブロックがします。1 回のコンパイルが完了したとき、他の SPID をヘッド ブロックを数秒以内のロールを引き継ぎ。
次の情報はスナップショットからです。 sysprocesses このような時のブロック。
   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
で、 waitresource6 列 (「6:834102」)、データベース ID、834102 はオブジェクト ID です。このオブジェクトの ID (にもかかわらず、「タブ」ロックの種類) テーブルに、ストアド プロシージャに属していることに注意します。

メモ
  • SQL Server 2005 を使用している場合は、SQL Server 2000 のシステム テーブルの多くは、一連のビューとして実装されています。これらのビューは互換性ビューとしては、知られています、旧バージョンとの互換性のみを目的としています。互換性ビューに SQL Server 2000 には、同じメタデータを公開します。SQL Server 2000年のシステム テーブルと、SQL Server 2005 のシステム ビューとの間のマッピングの詳細については、SQL Server 2005 Books online の「マップ SQL Server 2000年システム テーブルに SQL Server 2005 システム ビュー」トピックを参照してください。
  • ストアド プロシージャの名前が「sp _」のプレフィックスで始まる、master データベースにではない場合を参照してください。SP:CacheMissキャッシュ ヒットの各実行場合でもをする前に、所有者のストアド プロシージャを限定します。SQL サーバーのシステム ストアド プロシージャであることをストアド プロシージャをおよびシステム ストアド プロシージャを別の名前解決規則がある sp _ プレフィックスを通知するためです。(、「希望」の場所で master データベースです)。ユーザーが作成したストアド プロシージャの名前を「sp _」で始めることはできません。
  • 所有者限定プロシージャとして作成されたときは、所有者限定プロシージャは、大文字と小文字を実行すると、所有者限定プロシージャが取得できます、CacheMiss コンパイル ロック要求しますが、最終的に、キャッシュされたプランを使用します。したがって、実際には、プロシージャの再コンパイルとしないと、オーバーヘッドの多くは発生しません。しかし、プロシージャとして作成されたときと同じ手順では、大文字と小文字を実行しようとして多くの Spid がある場合特定の状況では、コンパイル ロックの要求、「チェーン ブロック」のような状況可能性があります。これは、サーバーまたはデータベースで使用されている照合順序と並べ替え順序にかかわらず当てはまります。この現象の原因は、大文字と小文字が異なる場合、変更できるハッシュ値を (パフォーマンス上の理由) は、プロシージャ キャッシュ内を検索するために使用されるアルゴリズムが基づいていることです。

    この回避策を削除し、プロシージャ プロシージャとして同じ大文字と小文字を作成するのには、アプリケーションによって実行されるです。さらに、同じ大文字と小文字を使用するすべてのアプリケーションから、プロシージャを実行することを確認することもできます。
  • 代わりに言語イベントとしては RPC としてストアド プロシージャを実行しようとした場合、SQL Server する必要があります解析し言語イベント クエリのコンパイル、特定のプロシージャを実行して、キャッシュ内でそのプロシージャのプランを検索するクエリを行っていることを確認します。SQL Server する必要がありますを解析し、言語イベントをコンパイルするのには、この問題を回避するには、SQL としては RPC にクエリが送信されることを確認します。

    詳細については、「ストアド プロシージャを作成する」の記事、「システム ストアド プロシージャ」セクション、Books online を参照してください。


既知の問題

プランのキャッシュを防ぐことができますいくつか既知の問題は次のとおりです。
  • ストアド プロシージャのパラメーターとして BLOB 変数を使用します。詳細については、Knowledge Base の資料を参照するのには、次の資料番号をクリックしてください。
    2380435 FIX ストアド プロシージャのクエリ プランが BLOB 変数をストアド プロシージャを使用して文字列関数では、Microsoft SQL Server 2008年では、変数を使用するとキャッシュされていません。
  • ストアド プロシージャまたはクエリ バッチを開いている対称キーを使用します。詳細については、次の MSDN ブログ記事を参照してください。
    http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx

プロパティ

文書番号: 263889 - 最終更新日: 2011年7月13日 - リビジョン: 3.0
キーワード:?
kbinfo kbmt KB263889 KbMtja
機械翻訳の免責
重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。
英語版 KB:263889
Microsoft Knowledge Base の免責: Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com