T-SQL Wtorek #67:Nowe rozszerzone zdarzenia tworzenia kopii zapasowych i przywracania

We wtorek w T-SQL w zeszłym miesiącu pisałem o kilku nieudokumentowanych flagach śledzenia, które pomagają nadzorować długotrwałe operacje tworzenia kopii zapasowych i przywracania. W tym miesiącu tematem Jesa Borlanda są zdarzenia rozszerzone i pomyślałem, że pokażę nowe możliwości w SQL Server 2016, które w dużej mierze sprawią, że te flagi śledzenia staną się przestarzałe.

Jeśli grasz z CTP2 (możesz go pobrać tutaj), możesz zauważyć nową kategorię backup_restore i nowe wydarzenie backup_restore_progress_trace :

Odkrywanie nowego zdarzenia w oknie dialogowym Nowa sesja CTP2

Oto szybka i brudna sesja XE do przechwytywania danych dla tego zdarzenia (dodałem komentarze dotyczące filtrowania tylko do operacji tworzenia kopii zapasowych lub tylko przywracania; domyślnie obie są uwzględnione):

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

Teraz powiedzmy, że uruchamiam następujące operacje – tworzenie bazy danych, tworzenie kopii zapasowej danych, upuszczanie i przywracanie:

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;

Teraz możemy zapytać o dane z pliku docelowego zdarzenia:

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

W przypadku kopii zapasowej flaga śledzenia 3226 nie pomija żadnych danych wyjściowych przechwyconych przez zdarzenia rozszerzone. Pominąłem kolumny wyjściowe, ze względu na filtry, dla zwięzłości:

Dane zdarzeń dla operacji tworzenia kopii zapasowej

W przypadku przywrócenia zobaczysz te wiersze:

Dane zdarzeń dla operacji przywracania

Jeśli rozwiązujesz problemy z powolną operacją tworzenia kopii zapasowej lub przywracania, możesz łatwo filtrować według czasu trwania, aby na przykład widzieć tylko zdarzenia trwające dłużej niż n milisekund. Jedyną rzeczą, której nie widzę w tych danych wyjściowych, jest jakikolwiek sposób na stwierdzenie, czy podczas przywracania działało natychmiastowe inicjowanie pliku — nadal możesz potrzebować flagi śledzenia 3004, jak opisano w moim poście na wtorek z T-SQL z zeszłego miesiąca.

Nie zapomnij zatrzymać sesji (ale możesz zachować definicję sesji na serwerze, aby móc jej ponownie użyć):

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

Nie przeprowadziłem żadnych testów wydajności ani analizy wpływu, ale ogólnie powiedziałbym, że – podobnie jak flagi śledzenia – nie jest to coś, co chciałbyś uruchamiać przez cały czas, ale tylko podczas rozwiązywania problemów z określoną operacją. Nieco łatwiej jest skonfigurować tę sesję i zapytać o dane, IMHO, niż włączać flagi śledzenia i analizować wszystkie dane wyjściowe z dziennika błędów SQL Server.