T-SQL Tuesday #67:Nuevos eventos extendidos de copia de seguridad y restauración

Para el martes de T-SQL del mes pasado, escribí sobre algunos indicadores de seguimiento no documentados que lo ayudan a cuidar las operaciones de copia de seguridad y restauración de ejecución prolongada. Este mes, el tema de Jes Borland es Eventos extendidos, y pensé que mostraría nuevas capacidades en SQL Server 2016 que en gran medida hacen que estas marcas de seguimiento queden obsoletas.

Si está jugando con CTP2 (puede descargarlo aquí), puede notar una nueva categoría backup_restore y nuevo evento backup_restore_progress_trace :

Descubrimiento de un nuevo evento en el cuadro de diálogo Nueva sesión de CTP2

Aquí hay una sesión XE rápida y sucia para capturar los datos de este evento (he agregado comentarios para filtrar solo operaciones de copia de seguridad o solo restauración; de manera predeterminada, ambas están incluidas):

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

Ahora, supongamos que ejecuto las siguientes operaciones:crear una base de datos, hacer una copia de seguridad de algunos datos, soltarla y restaurarla:

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;

Ahora, podemos consultar los datos del archivo de destino del 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;

Para una copia de seguridad, el indicador de seguimiento 3226 no suprime ninguno de los resultados capturados por Extended Events. He dejado fuera las columnas de salida, debido a los filtros, por brevedad:

Datos de eventos para una operación de copia de seguridad

Para una restauración, verá estas filas:

Datos de eventos para una operación de restauración

Si está solucionando un problema de una operación de copia de seguridad o restauración lenta, puede filtrar fácilmente la duración, de modo que solo vea los eventos que tardaron más de n milisegundos, por ejemplo. Lo único que no veo en esta salida es alguna forma de saber si la inicialización instantánea del archivo estaba en efecto durante la restauración; es posible que aún necesite el indicador de seguimiento 3004, como se describe en mi publicación del martes de T-SQL del mes pasado.

No olvide detener la sesión (pero siéntase libre de mantener la definición de la sesión en el servidor, para que pueda usarla nuevamente):

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

No realicé ninguna prueba de rendimiento ni análisis de impacto, pero, en general, diría que, al igual que las marcas de rastreo, esto no es algo que desee ejecutar todo el tiempo, sino solo cuando soluciona problemas en una operación específica. Es un poco más fácil configurar esta sesión y consultar los datos, en mi humilde opinión, que activar los indicadores de seguimiento y analizar todos los resultados del registro de errores de SQL Server.