SQL Server Distributed Replay

S’applique à :yesSQL Server 2016 (13.x), yesSQL Server 2017 (14.x) et yesSQL Server 2019 (15.x)

Important

SQL Server Distributed Replay n’est pas disponible avec la préversion SQL Server 2022 (16.x).

La fonctionnalité Microsoft SQL Server Distributed Replay vous aide à évaluer l’impact de futures mises à niveau de SQL Server. Vous pouvez également l’utiliser pour évaluer l’impact des mises à niveau du matériel et du système d’exploitation, ainsi que des paramétrages de SQL Server .

Avantages de Distributed Replay

Comme SQL Server Profiler, vous pouvez utiliser Distributed Replay pour relire une trace capturée sur un environnement de test mis à niveau. À l’inverse de SQL Server Profiler, Distributed Replay n’est pas limité à la relecture de la charge de travail d’un seul ordinateur.

Distributed Replay offre une solution plus scalable que SQL Server Profiler. Avec Distributed Replay, vous pouvez relire des charges de travail de plusieurs ordinateurs et mieux simuler une charge de travail critique.

La fonctionnalité Microsoft SQL Server Distributed Replay peut utiliser plusieurs ordinateurs pour relire les données de trace et simuler les charges de travail critiques. Utilisez Distributed Replay pour tester la compatibilité des applications, tester les performances ou planifier la capacité.

Quand utiliser Distributed Replay

Les fonctionnalités de SQL Server Profiler et de Distributed Replay se chevauchent quelque peu.

Vous pouvez utiliser SQL Server Profiler pour relire une trace capturée sur un environnement de test mis à niveau. Vous pouvez également analyser les résultats de la relecture pour rechercher d'éventuelles incompatibilités de fonctions et de performances. Cependant, SQL Server Profiler ne peut relire une charge de travail que d’un seul ordinateur. Pendant la relecture d’une application OLTP intensive présentant de nombreuses connexions simultanées actives ou un débit élevé, SQL Server Profiler peut devenir un goulot d’étranglement des ressources.

Distributed Replay offre une solution plus scalable que SQL Server Profiler. Utilisez-le pour relire une charge de travail depuis plusieurs ordinateurs et mieux simuler des charges de travail critiques.

Le tableau suivant explique à quel moment utiliser chacun des outils.

Outil Utilisation quand...
SQL Server Profiler Vous souhaitez utiliser le mécanisme de relecture classique sur un ordinateur unique. En particulier, vous avez besoin de fonctions de débogage ligne par ligne, telles que les commandes Étape, Exécuter jusqu’au curseuret Basculer le point d’arrêt .

Vous souhaitez relire une trace Analysis Services .
Distributed Replay Vous souhaitez évaluer la compatibilité des applications. Par exemple, vous souhaitez tester des scénarios de mise à niveau de SQL Server et du système d'exploitation, des mises à niveau du matériel ou des paramétrages d'index.

La concurrence dans la trace capturée est si élevée qu’un seul client de relecture ne suffit pas à la simuler.

Concepts de Distributed Replay

Les composants suivants constituent l'environnement de Distributed Replay :

  • Outil d'administration Distributed Replay : une application console, DReplay.exe, utilisée pour communiquer avec le contrôleur de relecture distribuée. Utilisez l'outil d'administration pour contrôler la relecture distribuée.

  • Contrôleur Distributed Replay : un ordinateur exécutant le service Windows nommé contrôleur Distributed Replay SQL Server . Le contrôleur Distributed Replay orchestre les actions des clients de relecture distribuée. Chaque environnement Distributed Replay ne doit contenir qu'une seule instance de contrôleur.

  • Clients Distributed Replay : un ou plusieurs ordinateurs (physiques ou virtuels) qui exécutent le service Windows nommé client Distributed Replay SQL Server . Les clients Distributed Replay fonctionnent ensemble pour simuler des charges de travail sur une instance de SQL Server. Chaque environnement Distributed Replay peut contenir un ou plusieurs clients.

  • Serveur cible : une instance de SQL Server que les clients Distributed Replay peuvent utiliser pour relire les données de trace. Nous conseillons de placer le serveur cible dans un environnement de test.

L'outil d'administration Distributed Replay, le contrôleur et le client peuvent être installés sur différents ordinateurs ou sur le même ordinateur. Il ne peut exister qu'une instance du contrôleur Distributed Replay ou du service client en cours d'exécution sur le même ordinateur.

L'illustration suivante montre l'architecture physique Distributed Replay de SQL Server :

Distributed Replay Architecture

Tâches relatives à Distributed Replay

Description de la tâche Rubrique
Explique comment configurer Distributed Replay. Configurer Distributed Replay
Explique comment préparer les données de trace d'entrée. Préparer les données de trace d’entrée
Explique comment relire les données de trace. Relire les données de trace
Décrit comment examiner les résultats des données de trace de Distributed Replay. Examiner les résultats de la relecture
Décrit comment utiliser l’outil d’administration pour lancer, surveiller et annuler des opérations sur le contrôleur. Options de ligne de commande de l'outil d'administration (Distributed Replay Utility)

Spécifications

Avant d’utiliser la fonctionnalité Microsoft SQL Server Distributed Replay, prenez connaissance des spécifications du produit présentées dans cette rubrique.

Spécifications des données de trace d'entrée

Pour que les données de trace puissent être correctement relues, elles doivent répondre à des spécifications de version et de format et contenir des événements et des colonnes obligatoires.

Versions de trace d'entrée

Distributed Replay prend en charge les données de trace d'entrée recueillies dans les versions suivantes de SQL Server:

  • SQL Server 2017 (14.x) Mise à jour cumulative 1 et versions ultérieures. Consultez : SQL Server 2017, mises à jour cumulatives.
  • SQL Server 2016 (13.x)
  • SQL Server 2014 (12.x)
  • SQL Server 2012 (11.x)
  • SQL Server 2008 R2
  • SQL Server 2008
  • SQL Server 2005 (9.x)

Formats de trace d'entrée

Les données de trace d'entrée peuvent se présenter sous l'un des formats suivants :

  • Un fichier de trace unique ayant l'extension .trc .

  • Un jeu de fichiers de trace de substitution qui suivent la convention d’affectation des noms de substitution de fichier, par exemple : <TraceFile>.trc, <TraceFile>_1.trc, <TraceFile>_2.trc, <TraceFile>_3.trc, ... <TraceFile>_n.trc.

Événements et colonnes de trace d'entrée

Les données de trace d'entrée doivent contenir des événements et des colonnes spécifiques pour pouvoir être relues par Distributed Replay. Le modèle TSQL_Replay , dans SQL Server Profiler , contient tous les événements et toutes les colonnes obligatoires, ainsi que des informations supplémentaires. Pour plus d’informations sur ce modèle, consultez Conditions préalables à la relecture.

Avertissement

Si vous n’utilisez pas le modèle TSQL_Replay pour capturer les données de trace d’entrée, ou si les conditions d’entrée de trace ne sont pas satisfaites, vous pouvez recevoir des résultats de relecture inattendus.

Vous pouvez également créer un modèle de trace personnalisé et l'utiliser pour relire des événements avec Distributed Replay, à condition que ce modèle contienne les événements suivants :

  • Audit Login

  • Audit Logout

  • ExistingConnection

  • RPC Output Parameter

  • RPC:Completed

  • RPC:Starting

  • SQL:BatchCompleted

  • SQL:BatchStarting

Si vous relisez des curseurs côté serveur, les événements suivants sont également obligatoires :

  • CursorClose

  • CursorExecute

  • CursorOpen

  • CursorPrepare

  • CursorUnprepare

Si vous relisez des instructions SQL préparées côté serveur, les événements suivants sont également obligatoires :

  • Exec Prepared SQL

  • Prepare SQL

Toutes les données de trace d'entrée doivent contenir les colonnes suivantes :

  • Classe d'événements

  • EventSequence

  • TextData

  • Nom de l’application

  • LoginName

  • nom_base_de_données

  • ID de base de données

  • HostName

  • Binary Data

  • SPID

  • Heure de Début

  • EndTime

  • IsSystem

Combinaisons de traces d'entrée et de serveurs cibles prises en charge

Le tableau suivant répertorie les versions de données de trace prises en charge et, pour chacune d'entre elles, les versions de SQL Server prises en charge avec lesquelles les données peuvent être relues.

Version de données de trace d'entrée Versions de SQL Server prises en charge pour l'instance de serveur cible
SQL Server 2005 (9.x) SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2008 SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2008 R2 SQL Server 2008 R2, SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2012 (11.x) SQL Server 2012 (11.x), SQL Server 2014 (12.x),SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2014 (12.x) SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2016 (13.x) SQL Server 2016 (13.x), SQL Server 2017 (14.x)
SQL Server 2017 (14.x) SQL Server 2017 (14.x)

Systèmes d'exploitation requis

Les systèmes d'exploitation pris en charge pour exécuter l'outil d'administration et les services contrôleur et clients sont les mêmes que dans votre instance SQL Server . Pour plus d’informations sur les systèmes d’exploitation pris en charge pour votre instance SQL Server , consultez Configurations matérielle et logicielle requises pour l’installation de SQL Server 2016.

Les fonctionnalités Distributed Replay sont prises en charge à la fois sur les systèmes d'exploitation basés sur des processeurs x86 et ceux basés sur des processeurs x64. Pour les systèmes d'exploitation basés sur des processeurs x64, seul le mode Windows on Windows (WOW) est pris en charge.

Limitations d'installation

Un ordinateur ne peut avoir qu'une seule instance de chaque fonctionnalité Distributed Replay installée. Le tableau suivant indique le nombre d'installations autorisées pour chaque fonctionnalité dans un même environnement Distributed Replay.

Fonctionnalité de Distributed Replay Nombre maximal d'installations par environnement de relecture
SQL Server Service Distributed Replay Controller 1
SQL Server Service Distributed Replay Client 16 (ordinateurs physiques ou virtuels)
Outil d'administration Illimité

Notes

Bien qu'une seule instance de l'outil d'administration puisse être installée sur un même ordinateur, vous pouvez en démarrer plusieurs instances. Les commandes émises depuis plusieurs outils d'administration sont résolues dans l'ordre de leur réception.

Fournisseur d'accès aux données

Distributed Replay ne prend en charge que le fournisseur d'accès aux données SQL Server ODBC Native Client.

Spécifications requises pour la préparation du serveur cible

Nous conseillons de placer le serveur cible dans un environnement de test. Pour relire les données de trace avec une instance de SQL Server différente de celle qui a servi à les enregistrer, assurez-vous que les opérations suivantes ont été effectuées sur le serveur cible :

  • Toutes les connexions et tous les utilisateurs contenus dans les données de trace doivent être présents dans la même base de données sur le serveur cible.

  • Toutes les connexions et tous les utilisateurs présents sur le serveur cible doivent avoir les mêmes autorisations que sur le serveur d'origine.

  • Les ID de base de données sur la cible doivent idéalement être identiques à ceux qui sont sur la source. Si ce n’est pas le cas, la mise en correspondance peut être effectuée sur la base du DatabaseName s’il est présent dans la trace.

  • La base de données par défaut de chaque connexion contenue dans les données de trace doit être définie (sur le serveur cible) en tant que base de données cible relative à la connexion. Par exemple, les données de trace à relire contiennent les activités de la connexion Freddans la base de données Fred_Db située sur l’instance d’origine de SQL Server. Par conséquent, sur le serveur cible, la base de données par défaut de la connexion Freddoit être la base de données correspondant à Fred_Db (même si le nom de la base de données est différent). Pour définir la base de données par défaut de la connexion, utilisez la procédure stockée système sp_defaultdb .

La relecture d'événements associés à des connexions manquantes ou incorrectes va entraîner des erreurs de relecture, mais l'opération de relecture va se poursuivre.

Voir aussi