1°) Database Experimentation Assistant : Introduction

Développé par Microsoft, Database Experimentation Assistant (DEA) est un outil de testing destiné à mesurer les impacts de performances liés à des modifications dans SQL Server. Cet outil peut être utilisé dans les cas suivants :
– Un changement de version de SQL Server.
– La modification d’un code applicatif.
– L’ajout, la modification ou la supression d’un index.
– La modification de l’infrastructure (changement physique de serveur, VM).
– L’activation d’une feature SQL.

DEA va comparer les différences de comportement entre l’activité capturée sur une base source et cette même activité rejouée sur une base cible, puis afficher ses analyses sous forme de rapports.

Depuis la version 2.6 (dernière version de DEA) , Microsoft a inclus la possibilité de capturer et de rejouer l’activité sur de nouvelles plateformes telles que Azure SQL Database, Azure SQL Managed Instance et SQL Server sur Linux. Cela s’avère bien pratique lorsque l’on souhaite vérifier la performance d’une nouvelle architecture dans Azure.

 

2°) L’installation

Database Experimentation Assistant 2.6 est téléchargeable depuis le lien suivant : https://www.microsoft.com/en-us/download/confirmation.aspx?id=54090

L’installation est vraiment très simple : L’outil fonctionne sur un simple poste de travail. Il n’est donc pas nécessaire de l’installer sur un serveur hébergeant une instance MSSQL.

L’installation s’effectue en lançant le fichier DatabaseExperimentationAssistantV2.6.exe.

Depuis les dernières versions, il n’est plus nécessaire d’installer des composants additionnels (SQL Server Data Tools, R for Windows, R Interop) pour générer les rapports d’analyse. Toute la solution de reporting est désormais intégrée à l’outil.

 

3°) Le principe

DEA opère en trois étapes :

• LA CAPTURE : L’opération consiste à capturer une trace de l’activité du serveur SQL source. Concrètement, l’activité des requêtes va être tracée dans des fichiers au format trace ou au format XEvent.
• LE REPLAY : L’activité SQL, tracée dans les fichiers générés lors de la capture, va être rejouée sur la base cible. De nouvelles traces, dédiées au replay, vont être générées pour capturer l’activité du serveur cible.
• L’ANALYSE : Les différents fichiers de trace (serveur source et serveur cible) vont ensuite servir pour l’analyse qui produira des rapports de performance comparatifs entre les serveurs.

 

4°) Démarrage d’un test

Lançons un test pour étudier le comportement d’une base de données en version SQL 2012 sur une nouvelle instance en version SQL 2016.

Pour réaliser ce test, nous disposons :

• D’une instance SQL Server 2012 dans laquelle fonctionne une base de données (ici, AdventureWorks2012). Cette base de données sera notre base source.
• D’une instance SQL Server 2016. Cette instance sera notre instance cible.

DEA étant installé, nous sommes prêts à démarrer. Lançons l’outil.

La toute première opération va consister ici à mettre en place la capture de l’activité de la base de données AdventureWorks2012.

 

LA CAPTURE

Voici, ci-dessous, l’écran de configuration de la capture de l’activité.

Certaines informations sont à saisir pour configurer la capture :

1. Le nom de la trace de la capture.
2. Le choix du format des traces (Trace ou Xevents).
3. La durée de la capture.
4. Le répertoire où seront stockés les fichiers traces. Ce répertoire doit être sur le serveur sur lequel tourne l’instance SQL. L’instance SQL doit avoir les permissions pour écrire des fichiers dans ce répertoire.
5. Un backup de la base de données est nécessaire avant la capture. En effet, c’est ce backup qui va servir à restaurer la base sur l’instance cible.
6. Le type de serveur (SqlServer, AzureSqlDb,AzureSqlManagedInstance).
7. Le nom de l’instance SQL.
8. Le type de connexion (SqlAuthentication, Windows).
9. Le nom de la base de données.
10. Les logins et mots de passe.

Important : Petites mises en garde avant de lancer la capture.

• Selon l’activité tracée, les fichiers peuvent être volumineux et générer de l’activité disque. Il faut veiller à avoir suffisamment d’espace pour héberger les fichiers de traces et positionner ces traces dans un répertoire qui ne gênera pas le moteur SQL.
• Il est également conseillé de faire un test sur un environnement de test avant de générer des traces en Production.

Après avoir saisi les différentes informations de configuration, la capture se lance en cliquant sur le bouton « Start » (voir ci-dessous).

Une fois la période de capture terminée, les fichiers de traces sont générés dans le répertoire prévu. Comme ces fichiers sont nécessaires au mécanisme de Replay, il va falloir les recopier manuellement sur le serveur où est hébergée l’instance cible.

 

LE REPLAY

Voici l’écran de configuration du Replay

Tout comme l’écran de capture, un certain nombre d’éléments sont à renseigner :

1. Le nom du Replay
2. Le format des traces de la capture (Trace ou Xevents).
3. La source des traces de la capture (Local ou Blob Storage sur Azure).
4. Le chemin complet de la trace de la capture.
5. Le choix de l’outil de Replay (InBuilt par défaut).
6. Le répertoire où vont être générées les traces du Replay.
7. La confirmation que la restauration du backup a été effectuée sur l’instance cible.
8. Le type de server cible (SqlServer, AzureSqlDb,AzureSqlManagedInstance).
9. Le nom de l’instance SQL cible (ici, notre instance SQL 2016).
10. Le type de connexion (SqlAuthentication, Windows).
11. Le nom de la base de données.
12. Les logins et mots de passe.

Une fois les paramètres renseignés, lançons le replay de notre capture sur l’instance SQL 2016.

Une fois l’intégralité des traces rejouée sur la base cible, nous pouvons procéder à l’analyse comparative des performances entre notre instance source (2012) et notre instance cible (2016).

 

L’ANALYSE

L’un des pré-requis pour générer le rapport d’analyse est de se connecter à une instance SQL qui servira à héberger la base de report. En effet, pour comparer les données des traces de capture et de replay, il est nécessaire de charger celles-ci dans une base de données de reporting. Il faut donc choisir ici une instance SQL (l’instance cible par exemple).

Une fois ce « serveur de report » défini, il faut configurer l’analyse de performance en spécifiant les emplacements des fichiers de traces de capture et de replay. Bien évidemment, notre serveur de report devra avoir accès à ces différentes traces d’où la nécessité de les recopier sur ce serveur.

Une fois cette configuration effectuée, l’analyse se lance. Les résultats arrivent rapidement et s’affichent de manière graphique, mettant en avant les différences de performances constatées sur les requêtes entre les deux instances SQL.

L’écran principal nous propose une synthèse des différences constatées entre les deux plateformes. Il est possible d’accéder à des informations plus détaillées pour chacune des requêtes SQL (Statistiques d’exécution, charge CPU, I/O, plan d’exécution) comme dans l’écran ci-dessous.

 

4°) Conclusion

DEA se révèle vraiment être un outil pratique : sa facilité d’installation et d’utilisation en font un bon candidat pour l’analyse de performance notamment dans le cadre d’un upgrade de version SQL ou d’une migration sur Azure. Les informations disponibles sont bien détaillées et permettent vraiment d’identifier les problèmes de performance qui pourraient s’avérer bloquants dans le cadre d’une migration.