T-SQL Dienstag Nr. 67:Neue erweiterte Sicherungs- und Wiederherstellungsereignisse

Für den T-SQL-Dienstag des letzten Monats habe ich über einige undokumentierte Trace-Flags geschrieben, die Ihnen helfen, lang andauernde Sicherungs- und Wiederherstellungsvorgänge zu babysitten. In diesem Monat lautet das Thema von Jes Borland Erweiterte Ereignisse, und ich dachte, ich würde neue Funktionen in SQL Server 2016 zeigen, die diese Ablaufverfolgungsflags weitgehend überflüssig machen.

Wenn Sie mit CTP2 spielen (Sie können es hier herunterladen), bemerken Sie möglicherweise eine neue Kategorie backup_restore und neues Ereignis backup_restore_progress_trace :

Erkennen eines neuen Ereignisses im Dialogfeld „Neue Sitzung“ von CTP2

Hier ist eine schnelle und schmutzige XE-Sitzung zum Erfassen der Daten für dieses Ereignis (ich habe Kommentare zum Filtern nur nach Sicherungs- oder nur Wiederherstellungsvorgängen hinzugefügt; standardmäßig sind beide enthalten):

CREATE EVENT SESSION [Backup progress] ON SERVER 
ADD EVENT sqlserver.backup_restore_progress_trace
(
    ACTION(package0.event_sequence)
 
    -- to only capture backup operations:
    --WHERE [operation_type] = 0
 
    -- to only capture restore operations:
    --WHERE [operation_type] = 1 
)
ADD TARGET package0.event_file 
(
  SET filename = N'C:\temp\BackupProgress.xel'
); -- default options are probably ok
GO
 
ALTER EVENT SESSION [Backup progress] ON SERVER STATE = START;
GO

Nehmen wir nun an, ich führe die folgenden Operationen aus – erstelle eine Datenbank, speichere ein paar Daten, lösche sie und stelle sie wieder her:

USE [master];
GO
CREATE DATABASE floob;
GO
SELECT s1.* INTO floob.dbo.what 
  FROM sys.all_objects AS s1 
  CROSS JOIN sys.all_objects;
GO
BACKUP DATABASE floob TO DISK = 'c:\temp\floob.bak' 
  WITH INIT, COMPRESSION, STATS = 30;
GO
DROP DATABASE floob;
GO
RESTORE DATABASE floob FROM DISK = 'c:\temp\floob.bak' 
  WITH REPLACE, RECOVERY;

Jetzt können wir die Daten aus der Ereigniszieldatei abfragen:

;WITH x AS 
(
  SELECT ts,op,db,msg,es
  FROM 
  (
   SELECT 
    ts  = x.value(N'(event/@timestamp)[1]', N'datetime2'),
    op  = x.value(N'(event/data[@name="operation_type"]/text)[1]', N'nvarchar(32)'),
    db  = x.value(N'(event/data[@name="database_name"])[1]', N'nvarchar(128)'),
    msg = x.value(N'(event/data[@name="trace_message"])[1]', N'nvarchar(max)'),
    es  = x.value(N'(event/action[@name="event_sequence"])[1]', N'int')
   FROM 
   (
    SELECT x = CONVERT(XML, event_data) 
     FROM sys.fn_xe_file_target_read_file
          (N'c:\temp\Backup--Progress*.xel', NULL, NULL, NULL)
   ) AS y
  ) AS x 
  WHERE op = N'Backup' -- N'Restore'
  AND db = N'floob'
  AND ts > CONVERT(DATE, SYSUTCDATETIME())
)
SELECT /* x.db, x.op, x.ts, */ 
  [Message] = x.msg, 
  Duration = COALESCE(DATEDIFF(MILLISECOND, x.ts, 
             LEAD(x.ts, 1) OVER(ORDER BY es)),0)
FROM x
ORDER BY es;

Bei einer Sicherung unterdrückt das Ablaufverfolgungsflag 3226 keine der von Extended Events erfassten Ausgaben. Ich habe die Ausgabespalten aufgrund der Filter der Kürze halber weggelassen:

Ereignisdaten für einen Sicherungsvorgang

Bei einer Wiederherstellung sehen Sie diese Zeilen:

Ereignisdaten für einen Wiederherstellungsvorgang

Wenn Sie einen langsamen Sicherungs- oder Wiederherstellungsvorgang beheben, können Sie einfach nach der Dauer filtern, sodass Sie beispielsweise nur Ereignisse sehen, die länger als n Millisekunden gedauert haben. Das einzige, was ich in dieser Ausgabe nicht sehe, ist eine Möglichkeit festzustellen, ob die sofortige Dateiinitialisierung während der Wiederherstellung wirksam war – möglicherweise benötigen Sie dennoch das Ablaufverfolgungsflag 3004, wie in meinem Post für den T-SQL-Dienstag des letzten Monats beschrieben. P>

Vergessen Sie nicht, die Sitzung zu beenden (aber Sie können die Sitzungsdefinition gerne auf dem Server behalten, damit Sie sie erneut verwenden können):

ALTER EVENT SESSION [Backup progress] ON SERVER STATE = STOP;

Ich habe keine Leistungstests oder Auswirkungsanalysen durchgeführt, aber im Allgemeinen würde ich sagen, dass dies – wie die Trace-Flags – nicht ständig ausgeführt werden sollte, sondern nur bei der Fehlerbehebung bei einem bestimmten Vorgang. Es ist meiner Meinung nach etwas einfacher, diese Sitzung einzurichten und die Daten abzufragen, als die Trace-Flags einzuschalten und die gesamte Ausgabe des Fehlerprotokolls von SQL Server zu parsen.