タグ付けされた質問 「wait-types」

私はSLEEP_TASK前に待機タイプを見たことがありません、そして今日、私はそれらのトンを得ているようです。 私は公式のDBAではなく、DBAの知識があるSQL Server開発者です。先週末、サーバーを10.52.2500.0-R2SP1にアップグレードしました。 オンラインで見つけた情報はすべて、SLEEP_TASKサーバーが何らかの内部プロセスの完了を待っていることを示しています。チェックポイントやゴーストクリーンアップなどのブロッキングプロセスやバックグラウンドプロセスが実行されていないため、少し困惑しています。 この待機タイプを以前に見たことがありますか？

34 sql-server  sql-server-2008-r2  wait-types 

実行に長い時間がかかるストアドプロシージャのリストを見ると、待機時間が最も多いことが際立っています。ただし、その待機時間のほとんど（81％）はASYNC_NETWORK_IOであり、その理由はわかっています。ストアドプロシージャは約400 MBの情報を転送します。 ドキュメントでは、ASYNC_NETWORK_IOの原因は、クライアントがデータのフラッドに追いつくことができないことであり、それはおそらく真実であると述べています。クライアントがADO.NET経由でストアドプロシージャを呼び出してからデータセットを処理するだけなので、クライアントを維持する方法がわかりません。 したがって、この情報が与えられた場合、この手順のASYNC_NETWORK_IO待機タイプについて心配する必要がありますか？実際にサーバーのパフォーマンスに影響しますか？ 追加情報： SQL Server 2005のサービスパック2を使用しています。 クライアントアプリは、SQL Serverと同じボックス上にあります（私は知っています...知っていますが、それについては何もできません）。

16 sql-server  performance  sql-server-2005  stored-procedures  wait-types 

企業のERP（Dynamics AX 2012）を実行すると、実稼働環境が開発システムよりもはるかに遅いように見えました。 開発環境と実稼働環境の両方で同じアクティビティを実行し、トレースを実行した後、開発環境と比較して実稼働環境でのSQLクエリの実行が非常に遅いことを確認しました（平均で10〜50倍遅い）。 最初はこれをロードに起因すると考え、営業時間外に本番環境で同じアクティビティを再実行し、トレースで同じ結果を見つけました。 SQL Serverで待機統計をクリアし、しばらくの間、サーバーを通常の運用負荷で実行させた後、次のクエリを実行しました。 WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats …

14 sql-server  performance  sql-server-2012  wait-types 

私が取り組んでいるデータ処理システムのパフォーマンスに問題があります。大量のCXPACKETおよびLATCH_EX待機イベントを示す1時間のperoidから待機統計を収集しました。 システムは3つの処理SQL Serverで構成され、多数の数値計算と計算を実行してから、中央のクラスターサーバーにデータを供給します。処理サーバーでは、一度に最大6つのジョブを実行できます。これらの待機統計は、ボットネックを引き起こしていると思われる中央クラスターに関するものです。中央クラスタサーバーには、16コアと64GB RAMがあります。MAXDOPは0に設定されます。 CXPACKETは実行中の複数の並列クエリからのものであると思いますが、LATCH_EX待機イベントが何を示しているのかわかりません。私が読んだことから、これは非バッファ待機かもしれませんか？ これらの種類の待機統計の原因が何であるか、このパフォーマンス問題の根本原因を調査するために私が取るべき措置は何ですか？ 上位のクエリ結果は合計待機統計であり、下位のクエリ結果は1時間の統計です。

13 sql-server  performance  query-performance  parallelism  wait-types 

インベントリレポートを生成するプロセスがあります。クライアント側では、プロセスは構成可能な数のワーカースレッドを分割して、多数（潜在的に数千、通常は数十）のうちの1つのストアに対応するレポートのデータのチャンクを構築します。各ワーカースレッドは、ストアドプロシージャを実行するWebサービスを呼び出します。 各チャンクを処理するためのデータベースプロセスは、一連のデータを#Temporaryテーブルに収集します。各処理チャンクの最後に、データはtempdbの永続テーブルに書き込まれます。最後に、プロセスの最後に、クライアント側の1つのスレッドが永続的なtempdbテーブルにすべてのデータを要求します。 このレポートを実行するユーザーが多いほど、速度は低下します。データベース内のアクティビティを分析しました。ある時点で、プロセスのある時点で35の個別のリクエストがすべてブロックされているのがわかりました。これらのすべてのSPIDはLATCH_EX、リソースで約50ミリ秒待機していましたMETADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)。1つのSPIDにこのリソースがあり、他のすべてのSPIDがブロックしています。ウェブ検索でこの待機リソースについて何も見つかりませんでした。 使用しているtempdbのテーブルにはIDENTITY(1,1)列があります。これらのSPIDはIDENTITY列を待機していますか？ブロッキングを削減または排除するためにどのような方法を使用できますか？ サーバーはクラスターの一部です。サーバーは64ビットのWindows 2008 R2 Enterpriseで64ビットのSQL Server 2012 Standard Edition SP1を実行しています。サーバーには64 GBのRAMと48のプロセッサがありますが、データベースは標準エディションであるため、16しか使用できません。 （このすべてのデータを保持するためにtempdbの永続テーブルを使用する設計にわくわくしないことに注意してください。これを変更することは、技術的および政治的な興味深い課題になりますが、私は提案を受け入れます。） 2013年4月23日更新 マイクロソフトでサポートケースをオープンしました。詳細については、この質問を更新していきます。 2013年5月10日更新 SQL Serverのサポートエンジニアは、待機がIDENTITY列によって引き起こされたことに同意しました。IDENTITYを削除すると、待機がなくなりました。SQL 2008 R2では問題を再現できませんでした。SQL 2012でのみ発生しました。

11 sql-server  sql-server-2012  concurrency  wait-types 

編集：セッションレポートがブロックされているがPAGELATCH_*、LCK_M_関連する待機タイプではなく、で待機しているのはなぜですか？ 以前は、SQLサーバーはブロッキングセッションのみをblocking_session_Id列で報告すると想定していました。ブロックされたセッションが論理ロックを待機していて、などのほかのものがなかった場合PAGELATCH_*。

9 sql-server  sql-server-2014  optimization  locking  wait-types 

次のような状況です。 私はRACを持っています。両方のノードにロックがあります。 最初のノード SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS 1 102 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFA958 5f4bzdg49fdxq ACTIVE 2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFAC98 5f4bzdg49fdxq ACTIVE セッション情報をブロックしています SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID …

9 oracle  locking  wait-types 

運用中のSQL Serverの1つで発生している断続的なCPUスパイクのトラブルシューティングを試みています。28 GBのRAMと4つのCPUコアを備えたSQL Server 2008 R2 Standard Editionを実行しています。これが発生すると、RESOURCE_SEMAPHORE_QUERY_COMPILERの待機が多数あることに気づきます。これは約1〜2分続き、その後停止して、CPU使用率は通常に戻ります。 これを調査した結果、これは通常、再利用できない多数の実行プランをコンパイルしたことが原因であると理解しています。 この動作は、メモリプレッシャーによるプランキャッシュの削除によってもトリガーされますか？もしそうなら、私はこれをどのようにチェックしますか？アプリケーションの修正を展開するまで、サーバーRAMのアップグレードなどの短期的な解決策があるかどうかを確認しようとしています。私が考えることができる他の唯一の短期間のオプションは、最も忙しいデータベースのいくつかを別のサーバーに移動することです。

8 sql-server  wait-types 

昨日、SQL ServerのCPU使用率が高いことについて不満を言っていた顧客から電話がありました。SQL Server 2012 64ビットSEを使用しています。サーバーはWindows Server 2008 R2 Standard、2.20 GHz Intel Xeon（4コア）、16 GB RAMを実行しています。 犯人が実際にSQL Serverであることを確認した後、ここで DMVクエリを使用してインスタンスの上位の待機を調べました。上位2つの待機は（1）PREEMPTIVE_OS_DELETESECURITYCONTEXTと（2）SOS_SCHEDULER_YIELDでした。 編集：「トップ待機クエリ」の結果を次に示します（誰かが私の希望に反して今朝サーバーを再起動しましたが）。 私たちは多くの激しい計算/変換を行うので、私は理解できますSOS_SCHEDULER_YIELD。しかし、私はPREEMPTIVE_OS_DELETESECURITYCONTEXT待機タイプとそれが最も高い理由について非常に興味があります。 この待機タイプについて私が見つけることができる最良の説明/ディスカッションは、ここにあります。それは言及しています： PREEMPTIVE_OS_待機タイプは、データベースエンジン（通常はWin32 API）を離れ、さまざまなタスクのためにSQL Serverの外部でコードを実行する呼び出しです。この場合、以前にリモートリソースアクセスに使用されていたセキュリティコンテキストが削除されています。関連するAPIは、実際にはDeleteSecurityContext（）という名前です 私の知る限り、リンクサーバーやファイルテーブルなどの外部リソースはありません。また、なりすましなどは一切行いません。バックアップが原因でスパイクが発生したり、ドメインコントローラに障害が発生したりする可能性はありますか？ これが主な待機タイプになる原因は何ですか？この待機タイプをさらに追跡するにはどうすればよいですか？ 編集2： Windowsセキュリティログの内容を確認しました。興味のあるエントリがいくつかありますが、これらが正常かどうかはわかりません。 Special privileges assigned to new logon. Subject: Security ID: NT SERVICE\MSSQLServerOLAPService Account Name: MSSQLServerOLAPService Account Domain: NT Service Logon ID: 0x3143c Privileges: SeImpersonatePrivilege …

8 sql-server  sql-server-2012  dmv  extended-events  wait-types