SQL Server に新しく追加された同時実行およびスケジューリングの診断機能

文書翻訳 文書翻訳
文書番号: 319892 - 対象製品
BUG #: 102179 (SQLBUG_70)
BUG #: 356317 (SQLBUG_80)
すべて展開する | すべて折りたたむ

目次

概要

さまざまな動的な処理に対応できるように、SQL Server には、安定性を確保するためのいくつかの内部プロセスが含まれています。一例として、ロック モニタが挙げられます。ロック モニタを使用することにより、デッドロック状態を検出し、解決できます。

SQL Server 7.0 Service Pack 4 (SP4) および SQL Server 2000 Service Pack 3 (SP3) には、高度なプロセスのヘルス モニタが追加されています。以下の対象に関して、ヘルス モニタの強化が行われました。
  • ブロッキング
  • ネットワークの問題
  • 入出力 (IO)
  • メモリ
  • CPU
SQL Server で稼動状態に関する問題が検出されると、以下のような一連の新しいエラー メッセージが SQL Server エラー ログに出力されます。これらのエラー メッセージの詳細については、この資料の「詳細」を参照してください。

SQL Server 7.0

エラー 1223 : プロセス ID %d:%d はロック "%s" をリソース %s で獲得できませんでした。リソースのスケジューラ %d でデッドロックが発生している可能性があるためです。プロセス ID %d:%d がこのリソースでロック "%h" を保持しています。

SQL Server 2000

エラー 1229 : プロセス ID %d:%d が、スケジューラ %d でプロセスをブロックしているリソースを所有しています。
新しいエラー メッセージには、以下のものがあります。

ロック検出の強化 : 1223、1229
スケジューラのハングの検出 : 17881、17883
すべてのスケジューラのハングの検出 : 17882、17884
警告 : 稼動状態に関連する問題は、多くの場合、それ以前に発生した現象が原因です。SQL Server エラー ログおよびシステム イベント ログを慎重に調査して、実際の根本的な原因を特定する必要があります。

たとえば、スケジューラの問題を示す 17883 エラー メッセージが出力されることがあります。しかし、エラー ログを確認すると、それ以前に発生した例外により SQL Server プロセスがリソース不足のまま停止している場合や、アプリケーションで深刻なブロック状態が発生している場合があります。
: マイクロソフトは、17883 エラー メッセージが発生する条件に関して、すべてのコンテンツを最新の状態にするように努めています。ただし、17883 エラー メッセージはヘルス モニタの検出メッセージであり、発生する原因は多岐にわたります。マイクロソフトは、SQL Server ソフトウェア製品に関する既知の問題を修正しましたが、SQL Server ソフトウェアとは関係のないさまざまな状況でも 17883 エラーが発生することを確認しました。たとえば、外部アプリケーションの CPU 消費やハードウェア障害で、このエラーが発生した事例があります。望ましくないエラーの再発を回避するには、17883 エラー メッセージの根本的な原因を特定する必要があります。

詳細

ここでは、ヘルス モニタの強化および SQL Server エラー ログに出力される可能性のある関連エラー メッセージについて説明します。

UMS

追加されたヘルス モニタの診断のいくつかをよりよく理解するためには、まず SQL Server で UMS (User Mode Scheduler) の Ums.dll ヘルパ ファイルがどのように使用されているかを理解する必要があります。

SQL Server 7.0 および Microsoft SQL Server 2000 では共に、論理的なスケジューラが使用されます。これらのスケジューラは、キー データベース アクションのパスに関して、SQL Server でオペレーティング システムのリソース使用量を最大限に活用するのに役立ちます。UMS 層は、SQL Server が Win32 イベントを正しく使用して、オペレーティング システムから参照可能なスレッドまたはファイバ (またはこれら両方) のスケジューリングを厳密に制御することを保証します。SQL Server では、実行可能なスレッドまたはファイバを厳密に制御することにより、ロックなどのデータベース要素の処理に必要な CPU の使用効率を最大限に高めます。

たとえば、論理的なスケジューリングにより、ロックの所有者がロックを解放し、ロックの待ち状態にあるオブジェクトに休止状態から復帰するようにシグナルを通知する (SetEvent を実行する) まで、ロック待ちのオブジェクトを休止状態にしておくことができます (Win32 イベントで WaitForSingleObject を実行します)。

ロック検出の強化

ロック モニタは、(ワーカー スレッドの) リソース レベルのブロッキングの状態を検出できるように強化されています。ロックを所有する SPID が現在スケジューラのキューに挿入されている場合、割り当てられたワーカー スレッドはすべて作成されていて、どのワーカー スレッドも解決不可能な待ち状態になるため、次のエラー メッセージが SQL Server エラー ログに出力されます。

SQL Server 7.0

プロセス ID %d:%d はロック "%s" をリソース %s で獲得できませんでした。リソースのスケジューラ %d でデッドロックが発生している可能性があるためです。プロセス ID %d:%d がこのリソースでロック "%h" を保持しています。
パラメータの説明 :
  1. 待機している SPID
  2. 待機している ECID (サブ プロセス実行 ID)
  3. ロック モード名
  4. リソース名
  5. 論理的な UMS スケジューラ ID
  6. 所有している SPID
  7. 所有している ECID
  8. 所有しているリソース名

SQL Server 2000

エラー 1229 : プロセス ID %d:%d が、スケジューラ %d でプロセスをブロックしているリソースを所有しています。
パラメータの説明 :
  1. 所有している SPID
  2. 所有している ECID (サブ プロセス実行 ID)
  3. 所有している論理的な UMS スケジューラ ID

トレース フラグ

SQL Server には、このヘルス モニタのレポートを無効にするためのトレース フラグが含まれています。

レポート処理を無効にするには、次のいずれかの方法を使用します。
  • 以下に示す起動時のパラメータ (-T###) を設定します。
  • DBCC TRACEON (###) を使用します。
SQL Server 7.0 の場合 : -T1216

SQL Server 2000 の場合 : -T1261

: これは記述の誤りではありません。SQL Server 2000 では、-T1216 はデッドロック出力用のトレース フラグとして既に使用されています。そのため、1261 を代わりに使用します。

現象発生の例

クライアント 1 が SQL Server に接続します。

クライアント 1 は、トランザクションを開始してデータの変更を行う Transact-SQL コマンドを実行します。

次に例を示します。
begin tran
update authors set au_lname = 'test'
クライアント 1 はアイドル状態になり、sysprocesses システム テーブルに、休止状態、およびトランザクションが開いたままでコマンドの受信待ちの状態であることが示されます。

クライアント 2 〜 255 の約 254 のクライアントが SQL Server にログオンし、Authors テーブルの SELECT ステートメントを発行します。これらのクライアントはすべて、元のテーブルの更新処理でブロックされます。

クライアント 1 はトランザクションのコミットを試行しますが、すべてのワーカー スレッドがクライアント 2 〜 255 によって使用されているため、クライアント 1 はキューに挿入されます。

ブロッキング

このエラー メッセージは通常、拡張されたブロッキングの状態を示しています。ロック モニタを実行するたびに、約 5 秒おきにメッセージが SQL Server エラー ログに追加されることがあります。

: メッセージは、リソースの問題が発生する SPID または ECID ごとにログに出力されます。そのため、同じロック モニタが繰り返し実行されている間は、複数のメッセージがログに出力されることがあります。

SQL Server では、この問題は自動的に解決されません。ただし、それぞれ 1223 または 1229 のエラー メッセージが表示され、問題が発生したことが示されます。この問題が発生した場合、多くの解決方法があります。

ロックまたはクエリのタイムアウト

クエリでロックまたはクエリのタイムアウトが使用される場合、タイムアウトが発生すると、通常は自然に問題が解消します。ただし、この現象は、アプリケーションにより同時実行のパフォーマンスが低下していることを示しているため、調査する必要があります。

Transact-SQL KILL

管理者が sysprocesses システム テーブルに対してクエリを実行できる場合、Transact-SQL KILL コマンドを使用することで、BLOCKING SPID および適切な BLOCKED SPIDS を強制終了してワーカー スレッドを解放し、システムを正常な状態に戻すことができます。
251004 [INF] SQL Server 7.0 のブロッキングを監視する方法
271509 SQL Server 2000 のブロッキングを監視する方法
263889 コンパイル ロックによる SQL ブロッキング

サポート

sysprocesses システム テーブルの情報を取得できない場合は、(Sqlservr.exe) プロセスのプロセス ダンプを取得し、Microsoft SQL Server サポートに追加調査を依頼してください。

並列クエリ

まれなケースですが、不十分な並列クエリ プランを選択したことが原因で、このエラー メッセージが表示されることがあります。並列クエリで、非常に多くの SQL Server ワーカーを使用してクエリが実行されると、SQL Server ワーカー プールが枯渇することがあります。sysprocesses システム テーブルにある ECID 列は、個々の SPID に使用されているワーカーの数を示しています。一般に、コンピュータの物理 CPU に対して ECID 値が高い場合は、クエリが適切にチューニングされていません。クエリ プランおよび MAXDOP (max degree of parallelism) クエリ オプションの設定を確認し、問題のクエリを適切にチューニングします。

スケジューラの問題

論理的なスケジューラの数に問題があります。SQL Server を起動すると、論理的なスケジューラに対して max worker thread の設定値が均等に分配されます。SQL Server で使用可能な CPU の数が多いほど、ワーカー キューはさらに分割されます。アプリケーションで、望ましくないトランザクション スコープの処理が発生している場合、CPU の必要量が増えると、短時間でリソース不足に陥ることがあります。このような場合には、アプリケーションのトランザクション スコープは即座に修正されます。

次の表は、sp_configure ストアド プロシージャの max worker thread の設定が 255 の場合の、CPU の数に基づいたワーカー プールの割り当てを示しています。
元に戻す全体を表示する
CPU のブロッキングチェーンの長さ
1 255
2 128
4 64
8 32
16 16
マイクロソフトは、max worker thread の設定値をデフォルトの 255 のままにしておくことをお勧めします。 関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
319942 [HOWTO] SQL Server の適切な環境設定を確認する方法

UMS の状態

60 秒ごとに論理的なスケジューラの状態を確認するために、新しい内部ルーチンが追加されました。スケジューラの処理が停滞している場合、またはスケジューラが応答を停止した場合、対応するエラー メッセージが SQL Server エラー ログに出力されます。エラーは、問題が解決されるまで 60 秒ごとにログに出力されます。

既に説明したように、多くの場合、これらのメッセージはそれ以前に発生したイベントが原因です。SQL Server エラー ログおよびアプリケーション イベント ログを注意深く調査して、問題の根本的な原因の特定に役立ててください。

: スナップショットが作成されるのは 60 秒ごとです。そのため、状態が最初に検出されるまで 120 秒かかることがあります。

SQL Server 7.0

エラー 17881 : スケジューラ %1!ld! が応答を停止しているようです。SPID %2!ld!、ECID %3!ld!、UMS Context 0x%4!p!
エラー 17882 : すべてのスケジューラでデッドロックが生じている可能性があります

トレース フラグ

-T1217 という起動時のパラメータを使用して SQL Server 7.0 を起動する場合、上記の 2 つのチェックを無効にできます。

SQL Server 2000 SP3

8.00.760 (SP3)
エラー: 17883 - スケジューラ %1!ld! が応答を停止しているようです。SPID %2!ld!、ECID %3! ld!、UMS コンテキスト 0x%4!p!

8.00.765

8.00.765 以降の修正プログラムでは、より明解なメッセージに変更されています。
エラー 17883 : プロセス %1!ld!:%2!ld! (%3!lx!) UMS コンテキスト 0x%4!p! が Scheduler %5!ld! では起動されていないようです


2003-03-21 08:22:20.27 server エラー : 17883、レベル : 1、状態 : 0。
2003-03-21 08:22:20.27 server プロセス 51:0 (dbc) UMS コンテキスト 0x018DA930 が Scheduler 0 では起動されていないようです
2003-03-21 08:22:22.45 server Stack Signature for the dump is 0x00000000
エラー 17884 : すべてのスケジューラでデッドロックが生じている可能性があります

トレース フラグ

-T1260 という起動時のパラメータを使用して SQL Server を起動すると、これら 2 つのチェックを無効にできます。

SQL Server 2000 ミニダンプ ファイル

SQL Server 2000 SP3 以降では、ミニダンプ ファイルを生成する機能が実装されています。ビルド 8.00.765 以降では、停止しているスケジューラが初めて検出されたときにミニダンプ ファイルが生成されます。

これらのエラー メッセージ (17883 および 17884) に対してミニダンプ ファイルが繰り返し生成されないように、デフォルトの動作では、SQL Server プロセスの実行中に一度だけミニダンプ ファイルが生成されます。メッセージが表示されるたびにミニダンプ ファイルを生成するには、トレース フラグ -T1262 を有効にします。

ミニダンプ ファイルは、LOG フォルダに SQLDmpr###.mdmp という名前で生成されます。このミニダンプ ファイルは、Microsoft Support で問題の根本的な原因を特定する際に役立ちます。

エラー 17881 およびエラー 17883

これらのメッセージは、1 つの UMS スケジューラで問題が発生したことを示します。スケジューラに、他のワーカー スレッドの処理の実行を妨げているワーカー スレッドがあり、スケジューラが応答を停止しているというフラグが設定されたことが、ヘルス モニタで検出されました。スケジューラの応答が停止するのは、通常、SQL Server 製品または外部コンポーネント (XProc、COM オブジェクトなど) の不具合が原因です。

17833 の発生条件として既知のものを以下に示します。関連する資料については、「サポート技術情報」 (Microsoft Knowledge Base) を検索してください。更新された修正プログラムをシステムにインストールする必要がある場合は、適宜その修正プログラムを適用してください。
815056 [FIX] チェックポイント処理により SQL Server データベースの処理に遅延が生じ、スケジューラからエラー 17883 の発生原因が正しく返されない
810885 ハイエンド ディスク サブシステムでエラー 17883 が発生する
すぐに根本的な原因を特定できない場合は、エラー ログで問題の箇所を探し、詳細なサポートを行ってください。

スケジューラが正常に応答していない場合、SQL Server 全体の同時実行のパフォーマンスが低下することがあります。また、SQL Server の処理が停滞することや、応答が停止することがあります。

エラー 17882 および 17884

これらのメッセージは、すべての UMS スケジューラで問題が発生したことを示しています。これは、SQL Server システム全体に及ぶ問題であることを示すもので、SQL Server の応答が停滞します。17881 メッセージおよび 17883 メッセージと同様、詳細については、エラー ログおよび「サポート技術情報」 (Microsoft Knowledge Base) を参照してください。必要に応じて、詳細なサポートを行ってください。

プロパティ

文書番号: 319892 - 最終更新日: 2005年11月21日 - リビジョン: 8.1
この資料は以下の製品について記述したものです。
  • Microsoft SQL Server 2000 Service Pack 3
  • Microsoft SQL Server 7.0 Service Pack 4
キーワード:?
kbsample kberrmsg kbbug kbfix kbinfo KB319892
"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