T-SQL Tuesday #67:Nieuwe back-up en herstel van uitgebreide gebeurtenissen

Voor de T-SQL-dinsdag van vorige maand schreef ik over enkele niet-gedocumenteerde traceringsvlaggen die u helpen om langlopende back-up- en herstelbewerkingen te verzorgen. Deze maand is het onderwerp van Jes Borland Extended Events, en ik dacht dat ik nieuwe mogelijkheden in SQL Server 2016 zou laten zien die deze traceringsvlaggen grotendeels overbodig maken.

Als je met CTP2 speelt (je kunt het hier downloaden), zie je misschien een nieuwe categorie backup_restore en nieuwe gebeurtenis backup_restore_progress_trace :

Een nieuwe gebeurtenis ontdekken in het dialoogvenster Nieuwe sessie van CTP2

Hier is een snelle en vuile XE-sessie voor het vastleggen van de gegevens voor deze gebeurtenis (ik heb opmerkingen voor filteren toegevoegd aan alleen back-up- of herstelbewerkingen; standaard zijn beide inbegrepen):

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

Laten we nu zeggen dat ik de volgende bewerkingen uitvoer:maak een database, maak een back-up van een beetje gegevens, laat het vallen en herstel het:

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;

Nu kunnen we de gegevens van het gebeurtenisdoelbestand opvragen:

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

Voor een back-up onderdrukt traceringsvlag 3226 geen van de uitvoer die is vastgelegd door Extended Events. Ik heb uitvoerkolommen weggelaten vanwege de filters, voor de beknoptheid:

Gebeurtenisgegevens voor een back-upbewerking

Voor een herstel ziet u deze rijen:

Gebeurtenisgegevens voor een herstelbewerking

Als u een trage back-up- of herstelbewerking wilt oplossen, kunt u eenvoudig filteren op de duur, zodat u alleen gebeurtenissen ziet die langer duren dan bijvoorbeeld n milliseconden. Het enige dat ik in deze uitvoer niet zie, is een manier om te zien of directe bestandsinitialisatie van kracht was tijdens het terugzetten - je hebt misschien nog steeds traceringsvlag 3004 nodig, zoals beschreven in mijn bericht voor de T-SQL-dinsdag van vorige maand.

Vergeet niet de sessie te stoppen (maar bewaar de sessiedefinitie gerust op de server, zodat u deze opnieuw kunt gebruiken):

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

Ik heb geen prestatietests of impactanalyse uitgevoerd, maar in het algemeen zou ik zeggen dat - net als de traceringsvlaggen - dit niet iets is dat je altijd wilt laten lopen, maar alleen bij het oplossen van problemen met een specifieke bewerking. Het is een beetje eenvoudiger om deze sessie op te zetten en de gegevens op te vragen, IMHO, dan om de traceervlaggen in te schakelen en alle uitvoer uit het foutenlogboek van SQL Server te ontleden.