web-dev-qa-db-ja.com

クエリ待機時間が長い

以下のクエリは、定期的に非常に高い待機統計を持っていると見なされています。

このクエリは何に関連していますか？システムテーブル？待ち時間を短縮することはできますか？

ありがとう！

select @reservedpages = sum(a.total_pages),
@usedpages = sum(a.used_pages),
@pages = sum(
CASE
-- XML-Index and FT-Index-Docid is not considered "data", but is part of "index_size"

When it.internal_type IN (202,204) Then 0
When a.type <> 1 Then a.used_pages
When p.index_id < 2 Then a.data_pages
Else 0
END
)
from sys.partitions p join sys.allocation_units a on p.partition_id = a.container_id
left join sys.internal_tables it on p.object_id = it.object_id
sql-serverwaits
2
K09

これは、 sys.sp_spaceusedシステムストアドプロシージャ の定義からの抜粋のように見えます。

定期的に非常に高い待機統計を持っている

このストアドプロシージャの実行に関連する待機は何ですか？

sys.sp_spaceusedが頻繁に実行されているため、パフォーマンスに悪影響を及ぼしている理由を知りたいと思います。そのストアドプロシージャは通常、定期的に実行されることはなく、定期的に実行されることもありません。

使用しているSQLServerのバージョンに応じて、誰が（ホスト名、アプリケーション名など）このストアドプロシージャを開始しているかを確認する方法がいくつかあります。これを行うための私のお気に入りの方法は、拡張イベントを使用することです（SQL Server 2008以降のみの場合。現時点で質問でバージョンを指定していません）。

1
Thomas Stringer