T-SQL Tuesday #67 :Nouveaux événements étendus de sauvegarde et de restauration

Pour le mardi T-SQL du mois dernier, j'ai écrit sur certains indicateurs de trace non documentés qui vous aident à surveiller les opérations de sauvegarde et de restauration de longue durée. Ce mois-ci, le sujet de Jes Borland est les événements étendus, et j'ai pensé montrer de nouvelles fonctionnalités dans SQL Server 2016 qui rendent en grande partie ces indicateurs de trace obsolètes.

Si vous jouez avec CTP2 (vous pouvez le télécharger ici), vous remarquerez peut-être une nouvelle catégorie backup_restore et nouvel événement backup_restore_progress_trace :

Découverte d'un nouvel événement dans la boîte de dialogue Nouvelle session de CTP2

Voici une session XE rapide et sale pour capturer les données de cet événement (j'ai ajouté des commentaires pour filtrer uniquement les opérations de sauvegarde ou de restauration ; par défaut, les deux sont inclus) :

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

Maintenant, disons que j'exécute les opérations suivantes :créer une base de données, sauvegarder un peu de données, la supprimer et la restaurer :

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;

Maintenant, nous pouvons interroger les données du fichier cible de l'événement :

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

Pour une sauvegarde, l'indicateur de trace 3226 ne supprime aucune des sorties capturées par les événements étendus. J'ai omis les colonnes de sortie, en raison des filtres, par souci de brièveté :

Données d'événement pour une opération de sauvegarde

Pour une restauration, vous verrez ces lignes :

Données d'événement pour une opération de restauration

Si vous dépannez une opération de sauvegarde ou de restauration lente, vous pouvez facilement filtrer sur la durée, de sorte que vous ne voyez que les événements qui ont pris plus de n millisecondes, par exemple. La seule chose que je ne vois pas dans cette sortie est un moyen de savoir si l'initialisation instantanée du fichier était en vigueur lors de la restauration - vous aurez peut-être encore besoin de l'indicateur de trace 3004, comme décrit dans mon article du mardi T-SQL du mois dernier.

N'oubliez pas d'arrêter la session (mais n'hésitez pas à conserver la définition de la session sur le serveur, afin de pouvoir la réutiliser) :

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

Je n'ai effectué aucun test de performance ni analyse d'impact, mais en général, je dirais que - comme les indicateurs de trace - ce n'est pas quelque chose que vous voudriez exécuter tout le temps, mais uniquement lors du dépannage d'une opération spécifique. Il est un peu plus facile de configurer cette session et d'interroger les données, à mon humble avis, que d'activer les indicateurs de trace et d'analyser toute la sortie du journal des erreurs de SQL Server.