it-swarm.com.de

SQL Server: Wie kann der Fortschritt des Befehls CREATE INDEX verfolgt werden?

SQL Server 2014, Std Ed

Ich habe gelesen, dass Prozent_Komplett in dm_exec_requests für CREATE INDEX nicht funktioniert, und in der Praxis bleibt Prozent_Komplett bei 0. Das hilft also nicht.

Ich verwende derzeit die folgende Methode, die mir zumindest die Bewegung zeigt (dass die Indexerstellung nicht blockiert ist). Aber ich habe keine Ahnung, ob ich durch den Prozess% 10 oder% 99 bin.

Ich habe die hier beschriebene Methode ausprobiert: https://dba.stackexchange.com/a/102545/6229 , aber es wird eine eindeutig falsche est-Fertigstellungszeit angezeigt (im Grunde wird "jetzt" für mehr als 60 Minuten angezeigt Prozess, in dem ich 10 min bin)

Wie kann ich einen Hinweis bekommen?

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

Ich denke, die folgende Abfrage wird Sie zumindest ganz nah bringen. Es verwendet eine DMV, die in SQL Server 2014 eingeführt wurde: sys.dm_exec_query_profiles (und danke an Martin Smith für die Einführung über diese verwandte DBA.StackExchange-Antwort: Fortschritt von SELECT) INTO-Anweisung :-).

Bitte beachten Sie:

  • !! Sie müssen SET STATISTICS PROFILE ON; Oder SET STATISTICS XML ON; In den Abfragebatch einfügen, der den CREATE INDEX (und platzierte vor die CREATE INDEX - Anweisung, wenn dies nicht offensichtlich war), sonst werden in dieser DMV keine Zeilen für diese SPID/session_id !!

  • Der Operator IN wird verwendet, um die Zeile Index Insert Herauszufiltern, die, falls enthalten, die Werte für TotalRows erhöht, wodurch die Berechnungen verzerrt werden, da in dieser Zeile niemals verarbeitete Zeilen angezeigt werden .

  • Die hier angezeigte Zeilenanzahl (dh TotalRows) ist doppelt so hoch wie die Zeilenanzahl der Tabelle, da der Vorgang zwei Schritte umfasst, von denen jeder alle Zeilen bearbeitet: Der erste ist ein "Tabellenscan" oder ein "Clustered Index" Scannen "und zweitens" Sortieren ". Beim Erstellen eines Clustered-Index oder eines NonClustered-Index auf einem Heap wird "Tabellenscan" angezeigt. Sie sehen "Clustered Index Scan", wenn Sie einen NonClustered Index für einen Clustered Index erstellen.

  • Diese Abfrage scheint beim Erstellen gefilterter Indizes nicht zu funktionieren. Aus irgendeinem Grund haben gefilterte Indizes a) nicht den Schritt "Sortieren" und b) das Feld row_count Erhöht sich niemals von 0.
    Ich bin mir nicht sicher, was ich zuvor getestet habe, aber meine Tests zeigen jetzt, dass gefilterte Indizes sind von dieser Abfrage erfasst wurden. Süss. Beachten Sie jedoch, dass die Anzahl der Zeilen möglicherweise deaktiviert ist (ich werde sehen, ob ich das eines Tages beheben kann).

  • Wenn Sie einen Clustered-Index auf einem Heap erstellen, auf dem sich bereits NonClustered-Indizes befinden, müssen die NonClustered-Indizes neu erstellt werden (um die RID - RowID - gegen die Clustered-Index-Schlüssel auszutauschen), und jeder NonClustered-Index wird neu erstellt eine separate Operation sein und sich daher nicht in den Statistiken widerspiegeln, die von dieser Abfrage während der Erstellung des Clustered Index zurückgegeben werden.

  • Diese Abfrage wurde getestet gegen:

    • Erstellen:
      • Nicht gruppierte Indizes auf einem Heap
      • ein Clustered-Index (es sind keine NonClustered-Indizes vorhanden)
      • Nicht gruppierte Indizes für den gruppierten Index/die gruppierte Tabelle
      • ein Clustered-Index, wenn bereits NonClustered-Indizes vorhanden sind
      • Eindeutige NonClustered-Indizes für den Clustered-Index/die Clustered-Tabelle
    • Neuerstellung (Tabelle mit Clustered-Index und einem NonClustered-Index; getestet auf SQL Server 2014, 2016, 2017 und 2019) über:
      • ALTER TABLE [schema_name].[table_name] REBUILD; ( bei Verwendung dieser Methode wird nur der Clustered Index angezeigt)
      • 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;

Beispielausgabe:

                        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
69
Solomon Rutzky

Da dieses Thema noch aktiv zu sein scheint, sollte ich beachten, dass die Verwendung des neuen wiederaufnehmbare Indexoperationen in SQL Server 2019 und Azure SQL DB (im Kompatibilitätsmodus 150) diese Funktionalität bietet. Die Katalogansicht sys.index_resumable_operations enthält eine prozentuale unvollständige Spalte, die den Fortschritt anzeigt.

Wiederaufnehmbare Indexoperationen können nicht nur die Erstellung und Wiederherstellung von Indizes überwachen, sondern auch dazu beitragen, die Operation in kleine Teile aufzuteilen, die im Verlauf der Operation festgeschrieben werden. Dies hilft, das Transaktionsprotokoll klein zu halten, und kann auch bei Dingen wie Verfügbarkeitsgruppen hilfreich sein, da der Vorgang auf alle sekundären Server repliziert werden kann. Mit wiederaufnehmbaren Indexvorgängen können Sie die Indexerstellung oder -wiederherstellung auf dem neuen Primärserver nach einem Failover fortsetzen, ohne den Fortschritt zu verlieren. Da die Transaktionen auf dem Weg festgeschrieben werden, besteht bei langen Indexvorgängen kein Problem mit der Sicherung der Synchronisierung .

2
Pam Lahoud