SQL Server2005/2008でテーブルの読み取りと書き込みの数に関する統計を見つける方法はありますか?
トリガーや監査を使用せずにDMVs/DMFs
を具体的に探しています。
ここでの目標は、の適切な曲線因子を見つけることです。 indexs-この記事からアイデアを得ました( Fill Factor Defined )。
[UPDATE]ServerFaultに関するフォローアップの質問があります
DMV/DMF統計から読み取り/書き込み集中テーブルを決定する方法
「テーブル」はクラスター化インデックスまたは「ヒープ」を意味することを忘れないでください。
次のクエリを使用して、データベース内のすべてのテーブルの読み取りと書き込みの数を見つけることができます。このクエリ結果はCSVファイルにエクスポートでき、Excelの数式を使用して読み取り/書き込み比率を簡単に計算できます。テーブルのインデックスを計画するときに非常に便利です
DECLARE @dbid int
SELECT @dbid = db_id('database_name')
SELECT TableName = object_name(s.object_id),
Reads = SUM(user_seeks + user_scans + user_lookups), Writes = SUM(user_updates)
FROM sys.dm_db_index_usage_stats AS s
INNER JOIN sys.indexes AS i
ON s.object_id = i.object_id
AND i.index_id = s.index_id
WHERE objectproperty(s.object_id,'IsUserTable') = 1
AND s.database_id = @dbid
GROUP BY object_name(s.object_id)
ORDER BY writes DESC
テーブルのインデックスに適切な曲線因子を決定するには、発生しているページ分割の数を調べる必要があります。これはsys.dm_db_index_operational_stats
に示されています。
リーフ割り当て数:インデックスのリーフレベルでのページ分割の総数。
非リーフ割り当てカウント:インデックスのリーフレベルを超えるページ分割の総数。
リーフページのマージ数:インデックスのリーフレベルでのページマージの総数。
少し掘り下げた後、DMVのページ分割数はそれほど有用ではないという投稿をいくつか見ました(私はこれを個人的に確認していません)が、パフォーマンスカウンター「ページ分割/秒」もあります(ただし、SQL Serverインスタンスレベルのみです)。
私は経験則を使用して、通常のテーブルはデフォルトの90%のフィルファクターを使用し、高挿入テーブルは70〜85%のどこかで使用します(行サイズによって異なります)。読み取り専用テーブルは、100%の曲線因子を利用できます
優れたクラスター化インデックス(つまり、増加し続ける、一意で狭い)がある場合、フィルファクターの実際の決定的な問題は、テーブルの更新方法と列のデータ型です。列がすべて固定サイズ(整数、10進数、浮動小数点、文字など)であり、null許容でない場合、更新によって行に必要なストレージを増やすことはできません。優れたクラスター化インデックスを考えると、ページ分割が発生しないため、100以上のフィルファクターを選択する必要があります。可変長の列がいくつかあり(たとえば、ユーザー名を保持するVarchar)、挿入後に列がほとんど更新されない場合でも、比較的高い曲線因子を維持できます。長さが大きく変動するデータ(UNCパス、コメントフィールド、XMLなど)がある場合は、フィルファクターを減らす必要があります。特に、列が頻繁に更新されて大きくなる場合(コメント列など)。非クラスター化インデックスは、インデックスキーがより問題になる可能性があることを除いて、一般的に同じです(一意ではない、おそらく増加しない)。 sys.dm_db_index_physical_statsがこれに最適なメトリックを提供すると思いますが、それは事後です。インデックススペースがどのように使用されているかを把握するために使用される平均/最小/最大レコードサイズ、平均フラグメントサイズ、平均ページスペースを確認します。 HTH。