T-SQL вторник #67 :Ново архивиране и възстановяване на разширени събития

За T-SQL вторник от миналия месец написах за някои недокументирани флагове за проследяване, които ви помагат да гледате продължителни операции за архивиране и възстановяване. Този месец темата на Джес Борланд е Разширени събития и реших да покажа нови възможности в SQL Server 2016, които до голяма степен правят тези флагове за проследяване остарели.

Ако играете с CTP2 (можете да го изтеглите тук), може да забележите нова категория backup_restore и ново събитие backup_restore_progress_trace :

Откриване на ново събитие в диалоговия прозорец Нова сесия на CTP2

Ето бърза и мръсна XE сесия за улавяне на данните за това събитие (добавих коментари за филтриране само за операции за архивиране или само за възстановяване; по подразбиране и двете са включени):

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

Сега, да кажем, че изпълнявам следните операции – създавам база данни, поставям малко данни в нея, пускам я и я възстановявам:

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;

Сега можем да потърсим данните от целевия файл за събитие:

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

За резервно копие флагът за проследяване 3226 не потиска нито един от изходните данни, уловени от разширени събития. Пропуснах изходните колони, поради филтрите, за краткост:

Данни за събитие за операция за архивиране

За възстановяване ще видите тези редове:

Данни за събитие за операция по възстановяване

Ако отстранявате неизправности при бавно архивиране или възстановяване, можете лесно да филтрирате продължителността, така че да виждате само събития, които са отнели повече от n милисекунди, например. Единственото нещо, което не виждам в този изход, е някакъв начин да разбера дали мигновената инициализация на файл е била в сила по време на възстановяването – все още може да се нуждаете от флаг за проследяване 3004, както е описано в публикацията ми за T-SQL вторник от миналия месец.

Не забравяйте да спрете сесията (но не се колебайте да запазите дефиницията на сесията на сървъра, за да можете да я използвате отново):

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

Не извърших никакви тестове за производителност или анализ на въздействието, но като цяло бих казал, че – подобно на флаговете за проследяване – това не е нещо, което бихте искали да работите през цялото време, а само при отстраняване на неизправности при конкретна операция. Малко по-лесно е да настроите тази сесия и да направите заявка за данните, IMHO, отколкото да включите флаговете за проследяване и да анализирате целия изход от регистъра за грешки на SQL Server.