当我们从旧的全闪存阵列迁移到新的全闪存阵列（不同但成熟的供应商）时，我们开始看到检查点期间 SQL Sentry 中的等待增加。
版本：SQL Server 2012 Sp4
在我们的旧存储上，我们的等待时间约为 2k，在检查点期间“峰值”达到 2500，而新存储的峰值通常为 10k，峰值接近 50k。Sentry 将我们更多地指向PAGEIOLATCHwatis。做我们自己的分析，这似乎是PAGEIOLATCH and PAGELATCH等待的组合。使用 Perfmon，我们通常可以说我们检查点的页面越多，我们得到的等待就越多，但我们在检查点期间只刷新了大约 125 mb。我们的工作量主要是写入（主要是插入/更新）。
存储供应商已向我们证明，在这些检查点事件期间，光纤通道直连阵列的响应时间不到 1 毫秒。HBA 还会确认阵列的编号。我们也不认为这是 HBA 队列问题，因为队列深度从未超过 8。我们还尝试了更新的 HBA，更改 ZIO、执行限制和队列深度设置无济于事。我们还将服务器的内存从 500 GB 增加到 1 TB，没有任何变化。在检查点过程中，我们确实看到 2 - 4 个独立内核（共 16 个）飙升至 100%，但整体 CPU 约为 20%。BIOS 也设置为高性能。有趣的是，我们确实看到 CPU 通常处于 C2 睡眠状态，即使我们已经禁用了它，所以我们仍在研究为什么睡眠状态会超过 C1。
我们可以看到几乎所有的等待都在数据页上，偶尔会有 DCM 页面类型的 PFS。等待在用户数据库中，而不是 tempdb。我们还看到等待跨越多个数据页，一些 SPID 在同一页上等待。数据库设计确实有几个插入热点，但旧存储采用了相同的设计。
运行这个查询的循环 100 次，我们能够捕捉到有多少 SPID 在磁盘与内存上等待
SELECT
[owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type] …我们有一个针对大型表的本地更新统计作业，它基本上发出 UPDATE STATS 命令。从历史上看，我们一直默认使用 FULL SCAN，但最近我们切换到 SAMPLE 50 PERCENT。奇怪的是，update stats 命令的运行时间要高得多。
举个例子，我们有表 1，它有 6 个统计信息（3 个索引，3 个自动生成）。聚集索引为 1.2 TB；NCI 1 为 2.7 GB；NCI 2 为 2.6 GB
1 个月前使用 FULL SCAN 更新了表上的统计信息，该命令耗时 96 分钟。昨晚更新了统计数据，SAMPLE 50 PERCENT，命令耗时 593 分钟！两次运行之间的表行数大致相同。
我可以从 sys.dm_db_stats_properties 看到聚集索引只占用了 4 分钟的时间。我的问题是，为什么将采样率降低 50% 会导致命令运行时间延长近 5 倍？
命令运行时没有发生任何阻塞（根据 SQL Sentry），也没有任何资源瓶颈（CPU < 40%，IO 延迟 < 10 by-in-large）。
我想知道的一件事是并行性是否在起作用 - 使用完整扫描，SQL 可以使用并行性，但使用示例 % 它是单线程的吗？
我们正在运行 SQL 2012 SP2 CU7