T-SQL Martedì #67:Nuovi eventi estesi di backup e ripristino

Per il martedì di T-SQL del mese scorso, ho scritto di alcuni flag di traccia non documentati che ti aiutano a fare da babysitter a operazioni di backup e ripristino di lunga durata. Questo mese, l'argomento di Jes Borland è Eventi estesi e ho pensato di mostrare nuove funzionalità in SQL Server 2016 che rendono ampiamente obsoleti questi flag di traccia.

Se stai giocando con CTP2 (puoi scaricarlo qui), potresti notare una nuova categoria backup_restore e il nuovo evento backup_restore_progress_trace :

Scoperta di un nuovo evento nella finestra di dialogo Nuova sessione di CTP2

Ecco una sessione XE rapida e sporca per acquisire i dati per questo evento (ho aggiunto commenti per filtrare solo le operazioni di backup o di ripristino; per impostazione predefinita, sono inclusi entrambi):

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

Ora, supponiamo che io esegua le seguenti operazioni:creare un database, eseguirne il backup di alcuni dati, rilasciarlo e ripristinarlo:

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;

Ora possiamo interrogare i dati dal file di destinazione dell'evento:

;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;

Per un backup, il flag di traccia 3226 non sopprime l'output acquisito dagli eventi estesi. Ho tralasciato le colonne di output, a causa dei filtri, per brevità:

Dati evento per un'operazione di backup

Per un ripristino, vedrai queste righe:

Dati evento per un'operazione di ripristino

Se stai risolvendo un'operazione di backup o ripristino lenta, puoi facilmente filtrare in base alla durata, in modo da visualizzare solo gli eventi che hanno richiesto più di n millisecondi, ad esempio. L'unica cosa che non vedo in questo output è un modo per sapere se l'inizializzazione del file istantanea era attiva durante il ripristino:potresti comunque aver bisogno del flag di traccia 3004, come descritto nel mio post per il martedì di T-SQL del mese scorso.

Non dimenticare di interrompere la sessione (ma sentiti libero di mantenere la definizione della sessione sul server, in modo da poterla riutilizzare):

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

Non ho eseguito alcun test delle prestazioni o analisi dell'impatto, ma in generale, direi che, come i flag di traccia, questo non è qualcosa che vorresti eseguire tutto il tempo, ma solo durante la risoluzione dei problemi di un'operazione specifica. È un po' più semplice impostare questa sessione e interrogare i dati, IMHO, piuttosto che attivare i flag di traccia e analizzare tutto l'output dal log degli errori di SQL Server.