2011-07-17 100 views
1

如果我想測試不同的表定義如何影響SQL Server中的行插入速度,我想僅僅將事務從BEGIN定時到COMMIT是不夠的:這僅測量將追加INSERT添加到(順序)日誌的時間花費。對?基準INSERT的最佳方式 - 全包?

但是,實際的I/O命中是在INSERT實際應用於真正的表(聚集索引可能在INSERT之後稍微重組)時出現的。我如何衡量所用的總時間,全包?也就是說,所有INSERT(寫入日誌)的時間+用於更新「真實」數據結構的時間?在停止定時器之前執行「CHECKPOINT」是否足夠?

回答

1

由於缺乏反應,我會自己回答。

據我在各種文檔中可以看到的,我將通過發出CHECKPOINT來達到all related disk activity。這將強制將所有髒頁面寫入磁盤。

如果只是要測量的查詢被執行,唯一的髒頁面將是查詢所觸及的頁面。所做的實驗似乎支持這一「理論」。

+0

+1有用的信息,thx。 –

+0

但是這是一個錯誤,因爲這個數字是人爲低的 - 除非你長時間保持較高的插入/更新,檢查點不會過多地減慢數據庫的速度。遠遠低於你的測試。 – TomTom

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; 
+0

這是不夠的。我需要全部的執行時間,也就是說,包括將髒緩衝區頁面稍後寫入磁盤。 – someName

+0

將髒頁面寫入磁盤可能隨時發生,而不是**在運行查詢之後。如果你真的想剖析檢查點,你可以在插入後立即發出一個'CHECKPOINT',並且STATISTICS TIME也會給你時間。 如果你不想自己添加時間,你可以用探查器來捕獲這個,分析批量完成的事件,但你仍然需要自己發出CHECKPOINT –