SQL Server：如何跟踪 CREATE INDEX 命令的进度？

Question

SQL Server 2014，标准版

我已经读过 dm_exec_requests 中的 percent_complete 不适用于 CREATE INDEX，实际上，percent_complete 坚持为 0。所以这没有帮助。

我目前使用下面的方法，它至少显示了我的运动（索引创建没有被阻止）。但是我完全不知道我是 %10 还是 %99。

我尝试了这里描述的方法：https : //dba.stackexchange.com/a/102545/6229 但它显示了一个明显错误的 est 完成时间（它基本上显示了一个 60+ 分钟的过程的“现在”，我进入了 10 分钟)

我怎样才能得到线索？

SELECT percent_complete, estimated_completion_time, reads, writes, logical_reads, text_size, *
FROM
sys.dm_exec_requests AS r
WHERE
r.session_id <> @@SPID
AND r.session_id = 58

Answer 1

我认为以下查询至少会让您非常接近。它利用了 SQL Server 2014 中引入的 DMV：sys.dm_exec_query_profiles（感谢 Martin Smith 通过此相关的 DBA.StackExchange Answer: Progress of SELECT INTO statement向我介绍它：-）。

请注意：

• !! 您将需要添加SET STATISTICS PROFILE ON;或SET STATISTICS XML ON;在查询批次是做CREATE INDEX（和放在之前的CREATE INDEX说法，如果不明显），否则没有行会在这个DMV显示为SPID / session_id !!

• 该IN运算符用于过滤掉Index Insert如果包含将增加TotalRows值的行，这将使计算产生偏差，因为该行从不显示任何已处理的行。

• 此处显示的行数（即TotalRows）是表行数的两倍，因为该操作采取两个步骤，每个步骤都对所有行进行操作：第一个是“表扫描”或“聚集索引扫描”，第二个是“排序”。在堆上创建聚集索引或创建非聚集索引时，您将看到“表扫描”。在聚集索引上创建非聚集索引时，您将看到“聚集索引扫描”。

• 创建过滤索引时，此查询似乎不起作用。出于某种原因，过滤索引 a) 没有“排序”步骤，并且 b)row_count字段永远不会从 0 增加。
  不知道我在之前的测试，但我现在的测试表明，过滤索引是通过该查询捕获。甜的。虽然只是要注意行数可能会关闭（我会看看我是否能在某一天解决这个问题）。

• 在已经有非聚集索引的堆上创建聚集索引时，需要重建非聚集索引（将 RID -- RowID -- 换成聚集索引键），并且每个非聚集索引重建将是一个单独的操作，因此不会反映在创建聚集索引期间此查询返回的统计信息中。

• 此查询已针对：

  • 创建：
    • 堆上的非聚集索引
    • 聚集索引（不存在非聚集索引）
    • 聚集索引/表上的非聚集索引
    • 当非聚集索引已经存在时的聚集索引
    • 聚集索引/表上的唯一非聚集索引
  • 重建（具有聚集索引和一个非聚集索引的表；在 SQL Server 2014、2016、2017 和 2019 上测试）通过：
    • ALTER TABLE [schema_name].[table_name] REBUILD;（使用此方法时仅显示聚集索引）
    • ALTER INDEX ALL ON [schema_name].[table_name] REBUILD;
    • ALTER INDEX [index_name] ON [schema_name].[table_name] REBUILD;

DECLARE @SPID INT = 51;

;WITH agg AS
(
     SELECT SUM(qp.[row_count]) AS [RowsProcessed],
            SUM(qp.[estimate_row_count]) AS [TotalRows],
            MAX(qp.last_active_time) - MIN(qp.first_active_time) AS [ElapsedMS],
            MAX(IIF(qp.[close_time] = 0 AND qp.[first_row_time] > 0,
                    [physical_operator_name],
                    N'<Transition>')) AS [CurrentStep]
     FROM sys.dm_exec_query_profiles qp
     WHERE qp.[physical_operator_name] IN (N'Table Scan', N'Clustered Index Scan',
                                           N'Index Scan',  N'Sort')
     AND   qp.[session_id] = @SPID
), comp AS
(
     SELECT *,
            ([TotalRows] - [RowsProcessed]) AS [RowsLeft],
            ([ElapsedMS] / 1000.0) AS [ElapsedSeconds]
     FROM   agg
)
SELECT [CurrentStep],
       [TotalRows],
       [RowsProcessed],
       [RowsLeft],
       CONVERT(DECIMAL(5, 2),
               (([RowsProcessed] * 1.0) / [TotalRows]) * 100) AS [PercentComplete],
       [ElapsedSeconds],
       (([ElapsedSeconds] / [RowsProcessed]) * [RowsLeft]) AS [EstimatedSecondsLeft],
       DATEADD(SECOND,
               (([ElapsedSeconds] / [RowsProcessed]) * [RowsLeft]),
               GETDATE()) AS [EstimatedCompletionTime]
FROM   comp;

示例输出：

                        Rows                 Percent   Elapsed  Estimated    Estimated
CurrentStep  TotalRows  Processed  RowsLeft  Complete  Seconds  SecondsLeft  CompletionTime
-----------  ---------  ---------  --------  --------  -------  -----------  --------------
Clustered    11248640   4786937    6461703   42.56     4.89400  6.606223     2016-05-23
Index Scan                                                                   14:32:40.547

Answer 2

我认为我们可以通过引用 sys.dm_exec_requests 来删除 @SPID 变量：

;WITH agg AS
(
     SELECT SUM(qp.[row_count]) AS [RowsProcessed],
            SUM(qp.[estimate_row_count]) AS [TotalRows],
            MAX(qp.last_active_time) - MIN(qp.first_active_time) AS [ElapsedMS],
            MAX(IIF(qp.[close_time] = 0 AND qp.[first_row_time] > 0,
                    [physical_operator_name],
                    N'<Transition>')) AS [CurrentStep]
     FROM sys.dm_exec_query_profiles qp
     WHERE qp.[physical_operator_name] IN (N'Table Scan', N'Clustered Index Scan',
                                           N'Index Scan',  N'Sort')
     AND   qp.[session_id] IN (SELECT session_id from sys.dm_exec_requests where command IN ( 'CREATE INDEX','ALTER INDEX','ALTER TABLE') )
), comp AS
(
     SELECT *,
            ([TotalRows] - [RowsProcessed]) AS [RowsLeft],
            ([ElapsedMS] / 1000.0) AS [ElapsedSeconds]
     FROM   agg
)
SELECT [CurrentStep],
       [TotalRows],
       [RowsProcessed],
       [RowsLeft],
       CONVERT(DECIMAL(5, 2),
               (([RowsProcessed] * 1.0) / [TotalRows]) * 100) AS [PercentComplete],
       [ElapsedSeconds],
       (([ElapsedSeconds] / [RowsProcessed]) * [RowsLeft]) AS [EstimatedSecondsLeft],
       DATEADD(SECOND,
               (([ElapsedSeconds] / [RowsProcessed]) * [RowsLeft]),
               GETDATE()) AS [EstimatedCompletionTime]
FROM   comp;

Answer 3

由于这个话题似乎仍然很活跃，我认为值得注意的是，在 SQL Server 2019 和 Azure SQL DB（在 150 兼容模式下）中使用新的可恢复索引操作提供了此功能。目录视图sys.index_resumable_operations有一个percent_complete列指示进度。

除了能够监视索引创建和重建之外，可恢复的索引操作还有助于将操作分解为随着操作进行而提交的小块。这有助于保持事务日志较小，并且还可以帮助诸如可用性组之类的事情，因为操作可以复制到任何辅助服务器。使用可恢复的索引操作，您可以在故障转移后在新的主服务器上恢复索引创建或重建而不会丢失进度，并且由于事务是在此过程中提交的，因此在长时间的索引操作期间不会出现同步备份的问题.