Große Löschabfrage scheint eingefroren zu sein

Wir haben eine Löschabfrage für eine Datenbank mit 1,8 Mrd. Zeilen ausgeführt. Dieses Löschen würde 1,2 Milliarden Zeilen löschen.

Im Nachhinein hätten wir diese Abfrage in jeweils 100 m aufgeteilt, aber wir befinden uns in einer Position, in der sie 24 Stunden lang ausgeführt wurde und die Protokolldatei 2 TB groß ist. Dies scheint die maximal zulässige Größe für eine Protokolldatei zu sein.

Die Datenbank befindet sich im EINFACHEN Wiederherstellungsmodus.

Gibt es eine Speicherung dieser Abfrage? Oder müssen wir nur den SQL Server neu starten und sehen, was passiert? Wird die Datenbank unbrauchbar? Können wir irgendetwas tun, um dies so sauber wie möglich abzutöten?

Überprüfen Sie zunächst das SQL-Fehlerprotokoll, um festzustellen, ob es tatsächlich eine maximale Größe für das Protokoll erreicht hat. Wenn dies der Fall ist, hat die Abfrage keine Hoffnung auf Abschluss. Sie befindet sich wahrscheinlich bereits in einem Rollback-Status.

Selbst wenn es so ist, ziehe ich es immer vor, die Spid manuell zu töten (benutze sp_who2oder sp_WhoIsActivefinde die Spid, dann mache eine kill 59oder was auch immer). Sie können den Rollback-Status auch nur überprüfen, wenn Sie einen expliziten KILL ausführen. Weitere Informationen finden Sie in diesem verwandten Thread .

Da dies ein Löschen und kein Aktualisieren oder Einfügen ist, haben Sie möglicherweise großes Glück und stellen fest, dass es sofort zurückgesetzt wird. Wenn nicht, kann das Zurücksetzen genauso lange (oder länger) dauern wie bis zu diesem Punkt.

Verwenden Sie, um den Rollback-Status anzuzeigen

kill 59 with statusonly

Leider habe ich festgestellt, dass dies häufig nichts Nützliches anzeigt, nur eine "0% vollständig". In diesem Fall müssen Sie sp_who2die E / A und die CPU verwenden und beobachten, um festzustellen, ob sie noch etwas tun.

In Bezug auf den Neustart ist dies ein ernstes Risiko. Wenn das Spid aktiv zurückgesetzt wird (CPU und E / A ändern sich), wird beim Neustart von SQL die Datenbank nur vollständig offline geschaltet, bis das Rollback vollständig abgeschlossen ist (Stunden und Stunden). Aber , wenn die CPU und IO sind nicht bewegt, dann kann es in der Tat ist es sofort klar. In jedem Fall ist es ein Risiko.

Eine letzte Option, wenn die Dinge besonders schlimm sind: Wenn Sie ein Backup von kurz vor dem Start des Löschvorgangs haben (und es keine anderen Updates für die Datenbank gab) , besteht der schnellste Weg zur Wiederherstellung möglicherweise darin, die Datenbank einfach zu löschen und neu zu starten SQL und Wiederherstellung aus dem Backup.

Wenn Sie die Datenbank nicht löschen können (oder wenn Sie die Instanz bereits neu gestartet haben und das SQL-Fehlerprotokoll eine Wiederherstellungszeit von 24 Stunden vorhersagt), fahren Sie die SQL-Dienste herunter, löschen Sie die MDF- und LDF-Dateien von der Festplatte, starten Sie SQL und löschen Sie sie die (Geister-) Datenbank und Wiederherstellung aus dem Backup.

Natürlich würden Sie dies nur versuchen, wenn dies eine Back-End-Verarbeitungsdatenbank wäre, mit der Benutzer nicht interagiert haben.

Starten Sie den SQL Server nicht neu. Dies verlängert nur Ihre Qual, da eine Wiederherstellung stattfindet, die alle nicht abgeschlossenen Transaktionen, einschließlich Ihres Löschvorgangs, rückgängig macht oder wiederholt.

Wenn Sie die Sitzung beenden, in der der Löschvorgang ausgeführt wird, tritt ein Rollback auf, dessen Abschluss ebenfalls lange dauert.

Sie möchten sich die folgende Abfrage ansehen, um den Status der Operation anzuzeigen:

SELECT des.session_id 
    , des.host_name
    , des.login_name
    , der.command
    , der.estimated_completion_time
    , der.blocking_session_id
    , der.last_wait_type
    , der.percent_complete
    , der.start_time
    , der.status
    , der.wait_resource
    , der.wait_type
    , der.wait_time
FROM sys.dm_exec_sessions des
    INNER JOIN sys.dm_exec_requests der ON des.session_id = der.session_id
WHERE des.session_id <> @@SPID
    AND des.is_user_process = 1
ORDER BY des.session_id;

Die percent_completeSpalte und diejenigen, die darauf angewiesen sind, z. B. estimated_completion_time, werden nur für die folgenden Vorgänge ausgefüllt:

ALTER INDEX REORGANIZE
AUTO_SHRINK option with ALTER DATABASE
BACKUP DATABASE
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKTABLE
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
RECOVERY
RESTORE DATABASE
ROLLBACK
TDE ENCRYPTION

Daher wird diese Spalte nur dann von Bedeutung sein, wenn Sie die Löschanweisung bereits abgebrochen haben und sie zurückgesetzt wird oder wenn Sie den SQL Server bereits neu gestartet haben und sich in der Wiederherstellung befinden.

Wenn die blocking_session_idSpalte eine Nummer enthält, bedeutet dies, dass eine andere Sitzung den Löschvorgang blockiert. Wenn diese Sitzung den Löschvorgang seit dem Start blockiert hat, können Sie den Vorgang möglicherweise abbrechen, ohne dass ein Rollback erforderlich ist.