摘要
Microsoft SQL Server 2005 使用高解析度的 CPU 計數器來提供微秒的時間功能。 微秒是一 millionth，也就是1毫秒的一次。 不過，如果您使用的是變更 CPU 頻率的技術，則 SQL Server 的時間值可能不正確。 例如，當您使用下列任何一種技術時，可能會發生這個問題：
-
CPU 步進
-
AMD Cool'n'Quiet 技術
-
各種電源配置
本文包含可協助您解決這個問題的方法及其他資訊。
徵狀
當您使用 [設定統計時間] 語句來顯示伺服器執行、分析及編譯時間時，您可能會得到不正確的值。 例如，您可能會發現 SQL Server 執行時間的時間已過多，而超出 CPU 的時間。 這個問題可能會影響效能調整的準確度。 如果您使用的是伺服器 [摘要] 區段中所列的其中一個技術，就會發生此問題。
原因
發生這個問題的原因是，當您使用這些技術時，CPU 頻率有所變更。 SQL Server 2005 使用高解析度的 CPU 計數器來提供微秒的時間功能。 如果 CPU 頻率變更為省電並減少熱量輸出，則計算出的期間可能不正確。
解決方案
Service pack 資訊
若要解決此問題，請取得最新的 SQL Server 2005 service pack。如需詳細資訊，請按一下下列文章編號，以查看 Microsoft 知識庫中的文章：
913089 如何取得 SQL Server 2005 的最新 Service Pack記事 在 SQL Server 2005 Service Pack 3 和更新版本的 service pack 中，不會使用處理器時間戳記。這些版本的 SQL Server 2005 使用較可靠的計時器，其最大精度為1毫秒。
狀態
這個問題首先是在 SQL Server 2005 Service Pack 3 中修正。
因應措施
SQL Server 2005 需要已知和穩定的資料點，才能執行精確的效能調整。 如果在電腦上啟用動態 CPU 頻率調整，您可以停用它們，以便在開始監視及調整 SQL Server 效能前，Cpu 會維持穩定的頻率比率。 若要執行這項操作，請使用下列方法。
在電腦上設定 [電源配置]，強制 Cpu 保持在最大頻率
若要執行這項操作，請依照下列步驟執行：
-
按一下 [ 開始]，按一下 [ 執行]，輸入 Powercfg，然後按一下 [確定]。
-
在 [電源選項屬性] 對話方塊中，按一下 [電源配置] 清單中的 [永不開啟]。
-
按一下 [確定]。
可能會發生偏移。 [偏移] 是 [CPU 頻率] 值之間的差異。 如需詳細資訊，請參閱「漂移」一節。 在這種情況下，您必須重新開機 Microsoft Windows，才能在變更電源配置後重新同步所有 Cpu 的頻率。 如果您無法重新開機電腦，請啟用 SQL Server 處理器關聯，避免 SQL Server worker 執行緒在 Cpu 間移動。 當您這麼做時，即使發生 CPU 頻率值之間的分歧，也不需要重新開機電腦。 若要針對伺服器上的所有 Cpu 啟用 SQL Server 處理器關聯，您必須使用不同的遮罩，視伺服器上的邏輯處理器數目而定。 下表列出範例案例。
|
CPU 編號 |
啟用處理器關聯的語句 |
|---|---|
|
02 Cpu |
exec sp_configure 「關連遮罩」，0x00000003GOreconfigureGO |
|
04 Cpu |
exec sp_configure 「關連遮罩」，0x0000000FGOreconfigureGO |
|
08 Cpu |
exec sp_configure 「關連遮罩」，0x000000FFGOreconfigureGO |
|
16個 Cpu |
exec sp_configure 「關連遮罩」，0x0000FFFFGOreconfigureGO |
|
32 Cpu |
exec sp_configure 「關連遮罩」，0xFFFFFFFFGOreconfigureGO |
注意： 在 BIOS 層級停用 CPU 頻率變化功能可能是不夠的。 各種協力廠商公用程式都可以變更 CPU 頻率。 某些實現甚至會在 Cpu 低於最大電源配置設定的情況下啟用頻率調整。 在這種情況下，當您在 SQL Server 2005 執行效能調整時，必須停用這些協力廠商實用程式。
使用協力廠商的實用程式和驅動程式來同步處理 CPU 頻率和 CPU 時鐘計數器
在極少數的情況下，系統可能需要來自製造商的更新，才能修正 CPU 頻率問題。 如果您懷疑系統可能有問題，最好的做法是檢查系統是否有最新的 BIOS、微碼及固件更新。
其他相關資訊
Microsoft SQL Server 2000 及舊版的 SQL Server 都使用 Windows 計時機制。 計時機制會使用毫秒精確度值。 通常，此精度是10到15毫秒。 不過，精確度可能會相當大，就是 55 ms。 SQL Server 查詢經常在一位數的毫秒或微秒時間範圍內完成。 這個精確度需要高解析度的計時器。 因此，這些版本的 SQL Server 會將部分查詢的持續時間報告為 0 ms。 因此，在舊版的 SQL Server 中監視效能並調整 SQL Server 效能很困難。 SQL Server 2005 可使用高解析度的 CPU 計數器來提供微秒的時間功能，以改善精確度。 當您使用 [摘要] 區段中所列的技術時，報告的計時值可能不正確。 這個問題可能會影響下列物件與功能：
-
追蹤事件：
-
[ 注意 ] 事件
-
[儲存程式] 節點中的事件
-
TSQL 節點中的事件
-
[物件] 節點中的事件
-
[事務] 節點中的事件
-
-
動態管理檢視：
-
sys.dm_exec_query_stats
-
sys.dm_exec_requests
-
sys.dm_exec_sessions
-
sys.dm_io_pending_io_requests
-
sys.dm_os_ring_buffers
-
sys.dm_os_sys_info
-
sys.dm_io_virtual_file_stats
-
sys.dm_os_wait_stats
-
-
[設定統計時間] 語句
-
Sysprocesses系統資料表
安裝 SQL Server 2005 Service Pack 2 （SP2）後，當 SQL server 檢測到高解析度計時器在 Cpu 之間不同步時，SQL Server 會在錯誤記錄中記錄錯誤訊息。 錯誤訊息指出效能計時可能不准確，且使用者應該謹慎使用效能資料。錯誤訊息的文字會類似下列其中一個錯誤訊息：
錯誤訊息 1
計畫程式識別碼2上的 CPU 時間戳計數器不會與其他 Cpu 同步處理。
錯誤訊息 2
CPU 時間戳頻率已從191469變更為每毫秒1794177刻度。 新的頻率將會使用
SQL Server 會使用即時戳記計數器（RDTSC）指示來取得64位的 CPU 滴答計數。 您可以將這個值除以 CPU 頻率，將值轉換成毫秒值。 當 CPU 頻率變更或發生偏差時，可能會發生時間變化。
CPU 步進
CPU 步進是在 CPU 頻率中定義為有意變更。 CPU 步進可能也稱為英特爾 SpeedStep 技術或 AMD PowerNow！ 技術. 當 CPU 步進發生時，CPU 速度可能會以小至 50 MHz 的步長增加或減少，以節省能量並減少熱量輸出。 相同非一致性記憶體存取（NUMA）節點內的 Cpu 不會獨立調整頻率。下表說明 CPU 步進變更可能會如何影響計時計算。
|
執行 |
RDTSC 刻度 |
每毫秒的刻度（頻率） |
時鐘時間 |
|---|---|---|---|
|
啟動批次 |
1 |
200 |
0 |
|
Frequency 階向下 |
200 |
100 |
1ms |
|
結束批次處理 |
500 |
3ms |
|
|
本壘 |
500 |
4ms |
SQL Server 會在開始和結束 RDTSC 刻度上捕獲 RDTSC 的刻度。 然後，SQL Server 會依據頻率值來分割刻度。 在這個範例中，當您使用的 frequency 值200或100時，會發生下列計時計算：
-
Frequency 200： 500/200 = 2.5 ms
-
Frequency 100： 500/100 = 5 毫秒
兩種時間計算都不符合 4 ms 的實際時鐘時間。 如果在 RPC 中使用此計算 ：已完成 的追蹤事件，則 [ 持續 時間] 和 [ 結束時間 ] 資料欄位的報告會不正確。 RPC：已完成的事件會捕獲開始牆的時鐘時間和 CPU 滴答計數。 若要取得比 SQL Server 2005 中的 Windows 供應品更高的解析度，請使用已過的 CPU 滴答計數來計算 SQL Server 追蹤中的 [ 持續 時間] 和 [ 結束時間 ] 資料行。 [ 結束時間 ] 資料行是透過將 [ 工期 ] 資料行新增至 [ 開始時間 ] 資料行來計算。 在這個範例中，會將 2.5 ms 或5毫秒錯誤地新增至開始時間，計算出 [ 結束時間 ] 資料行。
游標
[偏移] 是 CPU 時鐘值的分歧。 具有多個 Cpu 的系統會在相同的時間點產生不同的 CPU 時鐘值。 雖然不常見，但是 Cpu 可能會在一段時間內遇到時鐘分隔問題。下列範例示範在 SQL Server 追蹤中，偏差變更會如何影響 持續時間 資料行的結果。 此範例假設 CPU 頻率在每毫秒200刻度上保持穩定。 下表說明此案例中的事件。
|
執行 |
Windows 排程的 CPU |
CPU 1 RDTSC |
CPU 2 RDTSC |
時鐘時間 |
|---|---|---|---|---|
|
啟動批次 |
1 |
100 |
1100 |
0 |
|
結束批次處理 |
2 |
900 |
1900 |
4毫秒 |
|
本壘 |
4毫秒 |
SQL Server 會在起點和終點捕獲 RDTSC 的刻度。 然後，SQL Server 會將 RDTSC 的滴答數除以頻率值。 在這個範例中，Windows 在兩個不同的 Cpu 上排程了 SQL Server worker 執行緒。 服務批次的 SQL Server worker 執行緒會在第一個 CPU （CPU 1）上執行。 不過，批次執行已中斷于某個時間點，而 SQL Server 將批執行傳送到擱置中的佇列。 當 SQL Server 將將此批次傳送到可執行佇列的 SQL Server worker 執行緒再次傳送給該執行緒時，Windows 會在第二個 CPU （CPU 2）上分派要執行的執行緒。 SQL Server worker 執行緒已在 CPU 2 上執行完畢。 由於 CPU 偏移，從 CPU 2 捕獲的結束刻度值是1900，而不是900。 如果您啟用 SQL Server 的關聯性，就可以避免此行為。 在這個範例中，會用到下列計時計算：
-
不正確但報告的值： （1900-100 = 1800）/200 = 9 ms
-
正確的值： （900– 100 = 800）/200 = 4 ms
RPC：已完成事件的 [持續時間] 資料行的值會報告為9毫秒，而不是 4 ms。 此結果的值大於4毫秒的正確值。您可以在 SQL Server 2005 中新增一些 [警告] 訊息，以指出先前提及的效能輸出可能不可靠。 在某些未發現的情況下，SQL Server 2005 SP2 可能會報告下列有關的警告訊息：
-
誤報警告訊息
-
漂移可能會變得數毫秒，而不會引起明顯的系統效果
當您評估效能相關的輸出，以及將效能相關的輸出與時鐘時鐘計時進行比較時，必須小心。 如果沒有任何其他效能問題的跡象，您通常可以忽略警告訊息。 例如，您通常可以在下列情況中忽略警告訊息：
-
進程正如預期方式執行。
-
SQL Server 查詢未在奇怪的 durational 模式中執行。
-
您看不到其他瓶頸的跡象。
不過，在略過警告訊息之前，建議您與製造商聯繫，以確認沒有已知的 RDTSC 問題。 您可以使用追蹤標記8033（– T8033），返回原始發行版本本的 SQL Server 2005 以及 SQL Server 2005 SP1 中的報告行為。 最初發行版本本的 SQL Server 2005 與 SQL Server 2005 SP1 不會報告警告訊息。 如果您執行的是原始發行版本本的 SQL Server 2005 或 SQL Server 2005 SP1 （沒有問題），您通常可以忽略這些訊息。
為什麼 WAITFOR DELAY 語句能正常運作？ 週期性的系統處理常式是什麼？
超時機制不會受到高解析度設計的影響。 SQL Server 不會針對以計時器為基礎的活動使用高解析度計時器。 某些超時活動是以使用 GetTickCount 函數的減少解析度計時器為基礎。 這些超時活動包括封鎖超時、WAITFOR DELAY 語句，以及鎖死偵測。
如需詳細資訊，請按一下下面的文章編號，檢視「Microsoft 知識庫」中的文章：
938448 如果伺服器使用雙核 AMD 皓龍處理器或多處理器 AMD 皓龍處理器，則 Windows Server 2003 的伺服器可能會遇到時間戳記計數器偏移
895980 使用 QueryPerformanceCounter 函數的程式在 Windows Server 2003 和 Windows XP 中的執行效果可能不佳本文討論的協力廠商產品是由與 Microsoft 無關的公司所生產。Microsoft 不會對這些產品的效能或可靠性作出任何暗示或其他保證。
