forwarded_fetch_count 和forwarded_record_count 之间的区别

Question

我一直在挠头，重新阅读MSFT帮助，但我仍然无法理解sys.dm_db_index_operational_stats和sys.dm_db_index_physical_stats中的forwarded_fetch_count和forwarded_record_count之间的区别。让我用下面的例子来说明我理解观点的问题。

\n

我运行了以下查询：

\n

;with heaps as ( \nselect \n    DB_NAME(DB_ID()) dbname, object_name ( p.object_id ) objname, sum(row_count) row_count,\n    DB_ID() database_id, p.object_id objectid\nfrom \n    sys.dm_db_partition_stats p\n    join sys.objects o on o.object_id = p.object_id \nWHERE \n    index_id = 0 and o.is_ms_shipped = 0 --and row_count > 0\n    group by p.object_id ) \nselect \n    h.*, \n    forwarded_fetch_count\nfrom heaps h\n    cross apply sys.dm_db_index_operational_stats(database_id, objectid, 0, null) ps\n    WHERE forwarded_fetch_count > 0 ORDER BY forwarded_fetch_count DESC\xc2\xa8\n

\n

和

\n

SELECT page_count, OBJECT_NAME(ps.object_id)\n,avg_record_size_in_bytes\n,avg_page_space_used_in_percent\n,forwarded_record_count \nFROM sys.dm_db_index_physical_stats(db_id('your_db_name'), NULL,NULL, NULL, 'DETAILED') AS ps\nWHERE forwarded_record_count IS NOT NULL AND forwarded_record_count > 0\nGO\n

\n

这两个查询都返回了我正在调整的单个数据库中的不同表列表。第一个查询返回的表中每个表有 1000 到 100 000 条转发提取，第二个查询返回其他表集的 10 - 60 000 条转发记录计数。

\n

作为管道胶带修复，我重建了有问题的表格。然而，在 Windows 的性能监视器中，我仍然看到大量的转发记录/秒（图表通常飙升至 100）。运行 sp_blitzfirst @seconds = 30 时，我会收到每秒大量转发的提取的警报。一旦警报是一般警报（意味着与任何数据库无关），同一语句的其他 9 个警报就会提到：“Forwarded Fetches/Sec High：TempDB Object”。根据转发的提取计数，TempDB 中的转发提取数量比 TempDB 中的转发提取数量多十倍或一百倍。

\n

最后但并非最不重要的一点是，ISV 大量实施了触发器（我将其与 TempDB 转发提取相关）。

\n

我的问题：

\n

\n
• 两个视图中的两列有什么区别？
\n
• 当处理由于堆上转发记录而导致数据库缓慢时，我应该使用哪一个？（我知道MSFT的帮助提到了dm_db_index_physical_stats中与堆相关的forwarded_record_count，但仍然没有让我更清楚）。
\n
• 我可以确定 TempDB 中的什么原因导致这些转发的提取吗？
\n

\n

Answer 1

物理统计视图返回有关索引或表的物理结构的信息。

转发记录计数显示堆中有多少行已转发记录。当堆行更新到不再适合页面的大小时，就会创建这些行。该行被移动到具有足够空间的不同页面，并且转发指针留在原始行中。

对于具有 123 个此类转发记录的堆表，转发记录计数也将为 123。

操作统计视图从存储引擎的角度记录堆（或索引）上的操作计数。

当执行计划需要已转发的堆行时，就会发生转发提取。每次跟随前向指针来定位查询或语句所需的数据时，它都会递增。

完全扫描具有 123 条转发记录的堆表将使转发的提取计数增加 123。运行该查询 5 次将使计数增加 5 x 123 = 615。

多次扫描堆的单个查询（和执行计划）还可以将 123 的倍数添加到计数中，或者在仅部分扫描堆的情况下添加任何其他数字（可能是因为查询有一个子句TOP）。

要点是，每当执行计划中的任何用户、任何查询和任何计划运算符需要堆中的一行并发现它已被转发时，转发的获取计数都会增加。

换句话说，操作统计数据为您提供有关查询如何访问数据的累积指标。物理统计数据告诉您堆在特定时刻的物理状态。

如果您对查询性能感兴趣，您很可能会关注操作统计信息。

如果您对物理结构的状态感兴趣，您将查看物理统计数据。

一旦您确定转发的记录确实导致了真正的性能问题，您就可以通过不使用堆、重建堆或更改表结构或查询来修复它们，以便减少导致转发的行的更新。