1

さまざまなテーブル定義がSQLServerの行挿入速度にどのように影響するかをベンチマークしたい場合、トランザクションをBEGINからCOMMITまでの時間だけで十分ではないと思います。これは、INSERTを（シーケンシャル）ログに追加するために費やした時間を測定するだけです。右？

ただし、実際のI / Oヒットは、INSERTが実際に実際のテーブル（INSERTの後にわずかに再編成される可能性のあるクラスター化されたインデックス）に適用されたときに発生します。使用された合計時間をすべて包括的に測定するにはどうすればよいですか？つまり、すべてのINSERT（ログに書き込まれる）の時間+「実際の」データ構造の更新に使用される時間ですか？タイマーを停止する前に「チェックポイント」を実行するだけで十分ですか？

4

2 に答える 2

1

返答がないので、私はこれに自分で答えます。

さまざまなドキュメントで確認できる限り、。all related disk activityを発行することでクエリによって誘導されますCHECKPOINT。これにより、すべてのダーティページが強制的にディスクに書き込まれます。

測定対象のクエリのみが実行された場合、ダーティページはクエリによってタッチされたページのみになります。実行された実験は、この「理論」をサポートしているようです。

于 2011-08-08T10:53:11.900 に答える
0

SET STATISTICS TIME ON設定後に実行する各ステートメントのMSでの実行時間とCPU時間を提供します

編集：以下のクエリを使用して、実行時にバッファプールでダーティになっているページの正確な数、MB単位のサイズ、サーバー上の構成済みの最大/最小メモリと合計を確認できます。

SELECT
ISNULL((CASE WHEN ([database_id] = 32767) THEN 'Resource Database' ELSE DB_NAME (database_id) END),'Total Pages') AS [Database Name],
SUM(CASE WHEN ([is_modified] = 1) THEN 1 ELSE 0 END)  AS [Dirty Page Count],
SUM(CASE WHEN ([is_modified] = 1) THEN 0 ELSE 1 END)  AS [Clean Page Count],
COUNT(*) * 8.0 / 1024.0 [Size in MB], a.value_in_use [Min Server Memory], 
b.value_in_use [Max Server Memory]
FROM sys.dm_os_buffer_descriptors
INNER JOIN sys.configurations a on a.configuration_id = 1543
INNER JOIN sys.configurations b on b.configuration_id = 1544
GROUP BY [database_id],a.value_in_use,b.value_in_use WITH CUBE
HAVING A.value_in_use IS NOT NULL AND B.value_in_use IS NOT NULL
ORDER BY 1;
于 2011-08-03T22:11:39.990 に答える