摘要
Microsoft SQL Server 2005 使用高分辨率 CPU 计数器提供微秒计时功能。 微秒是一次 millionth （或一毫秒的万分之一）。 但是，如果你使用更改 CPU 频率的技术，则 SQL Server 计时值可能不正确。 例如，当你使用以下任一技术时，可能会发生此问题：
-
CPU 步进
-
AMD Cool'n'Quiet 技术
-
各种电源方案
本文包含可帮助你解决此问题的方法和其他信息。
症状
使用 "设置统计" 时间语句显示服务器执行、分析和编译时间时，可能会获得不正确的值。 例如，你可能会注意到 SQL Server 执行时间的运行时间远超过 CPU 时间。 此问题可能会影响性能优化的准确性。 如果你使用的是服务器上 "摘要" 部分中列出的技术之一，则会出现此问题。
原因
出现此问题的原因是，使用这些技术时 CPU 频率会发生变化。 SQL Server 2005 使用高分辨率 CPU 计数器提供微秒计时功能。 如果 CPU 频率更改为节能并减少热量输出，则计算工期可能不正确。
解决方案
服务包信息
若要解决此问题，请获取最新的 SQL Server 2005 服务包。有关详细信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
913089 如何获取最新的 SQL Server 2005 服务包注意 在 SQL Server 2005 Service Pack 3 和更高版本的 service pack 中，不使用处理器时间戳。这些版本的 SQL Server 2005 使用更可靠的计时器，该计时器的最大精度为1毫秒。
状态
此问题首先在 SQL Server 2005 Service Pack 3 中更正。
解决方法
SQL Server 2005 需要已知的稳定数据点才能执行准确的性能优化。 如果在计算机上启用了动态 CPU 频率调整，则可以禁用它们，以便 Cpu 在开始监视和优化 SQL Server 性能之前保持稳定的频率。 若要执行此操作，请使用以下方法。
在计算机上配置电源方案以强制 Cpu 保持最大频率
为此，请按照下列步骤操作：
-
单击 " 开始"，单击 " 运行"，键入 " Powercfg"，然后单击 "确定"。
-
在 "电源选项属性" 对话框中，单击 "电源使用方案" 列表中的"始终打开"。
-
单击“确定”。
可能会发生偏差。 偏移是 CPU 频率值之间的分歧。 有关详细信息，请参阅 "偏差" 部分。 在这种情况下，你必须重新启动 Microsoft Windows，才能在更改电源方案后重新同步所有 Cpu 的频率。 如果无法重新启动计算机，请启用 SQL Server 处理器关系以防止 SQL Server 工作线程在 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毫秒。 SQL Server 查询经常在一位数的毫秒或微秒时间范围内完成。 此精度需要高分辨率的计时器。 因此，这些版本的 SQL Server 将某些查询的持续时间报告为0毫秒。 因此，很难在早期版本的 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
计划程序 id 2 上的 CPU 的时间戳计数器不与其他 Cpu 同步。
错误消息 2
CPU 时间戳频率已从191469更改为每毫秒1794177计时周期。 将使用新的频率
SQL Server 使用实时 Stamp Counter （RDTSC）指令获取64位 CPU 滴答计数。 你可以按 CPU 频率除以此值，将值转换为毫秒值。 当 CPU 频率发生变化或发生偏差时，可能会发生计时变体。
CPU 步进
CPU 步进被定义为 CPU 频率的有意更改。 CPU 步进也可能称为英特尔 SpeedStep 技术或 AMD PowerNow！ 技术协会. CPU 步进发生时，CPU 速度可能会以小至 50 MHz 的增量增加或减少，从而节省能源并减少热量输出。 位于同一非一致性内存访问（NUMA）节点内的 Cpu 不会单独调整频率。下表说明了 CPU 步进更改可能如何影响计时计算。
|
行为 |
RDTSC 计时周期 |
每毫秒的刻度（频率） |
时钟时间 |
|---|---|---|---|
|
开始批处理 |
1 |
200 |
0 |
|
频率步长 |
200 |
100 |
1ms |
|
结束批处理 |
500 |
3ms |
|
|
求和 |
500 |
4ms |
SQL Server 将在开始和结束 RDTSC 计时周期中捕获 RDTSC 计时周期。 然后，SQL Server 按 frequency 值划分刻度。 在此示例中，当你使用 frequency 值200或100时，将发生以下计时计算：
-
频率200： 500/200 = 2.5 ms
-
频率100： 500/100 = 5 毫秒
两种计时计算均不能与4毫秒的实际时钟时间相匹配。 如果在 RPC 中使用此计算 ：完成 的跟踪事件，将错误地报告 " 持续 时间" 和 " 结束时间 " 数据列。 RPC：已完成事件捕获起始墙时钟时间和 CPU 滴答计数。 若要获取比 SQL Server 2005 中的 Windows 提供更高的分辨率计时，SQL Server 跟踪中的 " 持续 时间" 和 " 结束时间 " 数据列使用已用 CPU 滴答计数进行计算。 " 结束时间 " 列通过将 " 工期 " 列添加到 " 开始时间 " 列计算得出。 在此示例中，通过错误地向开始时间添加2.5 毫秒或5毫秒来计算 结束时间 列。
光标
偏移是 CPU 时钟值的分歧。 具有多个 Cpu 的系统可以为同一时间点生成不同的 CPU 时钟值。 尽管这种情况不太常见，但 Cpu 可能会在一段时间内遇到时钟分隔。以下示例演示了偏差更改如何影响 SQL Server 跟踪中 duration 数据列的结果。 此示例假定 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 计时周期除以 frequency 值。 在此示例中，Windows 在两个不同的 Cpu 上计划了 SQL Server 工作线程。 服务批处理首先在第一个 CPU （CPU 1）上运行的 SQL Server 工作线程。 但是，批处理执行在某点中断，并且 SQL Server 已将批处理执行发送到挂起队列。 当 SQL Server 再次将向此批处理服务的 SQL Server 工作线程发送给可运行队列时，Windows 会将该线程调度为在第二个 CPU （CPU 2）上运行。 SQL Server 工作线程已在 CPU 2 上运行完毕。 由于 CPU 偏移，从 CPU 2 捕获的结束滴答值是1900而不是900。 如果启用 SQL Server 处理关系，则可以避免此行为。 此示例中使用以下计时计算：
-
不正确的、报告的值： （1900-100 = 1800）/200 = 9 毫秒
-
正确的值： （900-100 = 800）/200 = 4 毫秒
RPC：已完成事件的duration列的值将报告为9毫秒，而不是4毫秒。 此结果的精度超过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 不作任何默示或其他形式的保证。
