Un instantané de base de données fournit une vue en lecture seule d'une base de données SQL Server qui est cohérente sur le plan transactionnel avec l'état de la base de données source au moment de la création de l'instantané de base de données. Un certain nombre de raisons existent pour l'utilisation d'instantanés de base de données, par exemple la création de rapports sur une base de données en miroir, et DBCC CHECKDB utilise également des instantanés de base de données internes à partir de SQL Server 2005.
Les instantanés de base de données offrent également la possibilité d'annuler toutes les modifications apportées à une base de données depuis la création de l'instantané de base de données, mais avec un effet secondaire désagréable sur le journal des transactions de la base de données dont Paul a parlé ici.
L'impact sur les performances de l'instantané pour la charge de travail d'écriture de la base de données est l'un des éléments qui n'est généralement pas pris en compte ou affiché autour des instantanés de base de données. L'équipe SQLCAT a publié un livre blanc pour SQL Server 2005, Database Snapshot Performance Considerations under I/O-Intensive Workloads, qui a étudié les impacts sur les performances des instantanés de base de données, et après avoir travaillé récemment avec un client où les instantanés de base de données entraînaient des problèmes de performances, je voulais testez SQL Server 2012 et déterminez s'il y a eu des changements dans la surcharge des instantanés de base de données sept ans et trois versions de SQL Server plus tard.
Tester la configuration
Pour tester l'effet des instantanés de base de données sur les performances de la charge de travail en écriture, j'ai utilisé notre Dell R720 en effectuant une insertion de 1 000 000 lignes dans une nouvelle table dans une version agrandie de la base de données AdventureWorks2012. La base de données AdventureWorks2012 a été créée avec 8 fichiers de données répartis sur deux SSD Fusion-io ioDrive Duo 640 Go qui ont chacun été configurés comme deux disques individuels de 320 Go sous Windows, présentant un total de 4 disques. Pour simplifier l'explication de la configuration, la disposition du stockage utilisée pour ces tests est indiquée dans le tableau ci-dessous :
| Disque | Configuration | Utilisation |
|---|---|---|
| K | 15K RAID 5 – 6 Disque | Instantané |
| L | Fusion-io Card2 – Face B | Fichier journal |
| M | Fusion-io Card2 – Face A | 4 fichiers de données |
| N | Fusion-io Card1 – Face A | 4 fichiers de données |
| Q | Fusion-io Card1 – Face B | Tempdb |
| R | LSI Nytro BLP4-1600 | Instantané |
Tableau 1 – Disposition et utilisation du disque du serveur
Le stockage de l'instantané de la base de données était soit une matrice RAID-5 de six disques SAS 15 000 tr/min connectés via iSCSI, soit une carte PCI-E LSI Nytro BLP4-1600.
La charge de travail de test a utilisé l'instruction SELECT INTO suivante pour générer une table de 1 000 000 lignes qui a été supprimée entre chacun des tests.
SELECT TOP 1000000 * INTO tmp_SalesOrderHeader FROM Sales.SalesOrderHeaderEnlarged;
Les tests ont été chronométrés pour mesurer la durée sans instantané de la base de données, puis la durée avec un instantané de la base de données créé sur chacun des périphériques de stockage pour mesurer la dégradation des performances causée par l'écriture des changements de page dans le fichier fragmenté de l'instantané de la base de données. Les tests ont également été exécutés à l'aide de deux instantanés de base de données sur le même périphérique de stockage afin de déterminer quelle pourrait être la surcharge d'avoir des instantanés de base de données supplémentaires pour les opérations d'écriture dupliquées qui doivent potentiellement être effectuées.
Résultats
Chaque configuration de test a été exécutée dix fois et la durée moyenne, convertie de millisecondes en secondes pour faciliter la visualisation, est illustrée à la figure 1, pour 0, 1 ou 2 instantanés de base de données.
Figure 1 – Durée de l'instantané
Les tests de référence sans instantanés de base de données exécutés en moyenne en 1,8 seconde, et même lorsque le stockage des fichiers d'instantané de base de données était équivalent en termes de performances, l'existence d'un seul instantané de base de données imposait une surcharge aux performances d'écriture de la base de données. La surcharge du deuxième instantané de base de données est inférieure à celle du premier instantané de base de données dans chacun des tests, bien que les disques à 15 000 tr/min aient eu beaucoup plus de mal à suivre la charge de travail d'écriture supplémentaire du deuxième instantané de base de données pour la base de données.
Les performances de la carte LSI Nytro m'ont initialement surpris car il s'agissait également d'un SSD PCI-X. Cependant, après avoir discuté des résultats avec Glenn, il a mentionné que la compression du contrôleur Sandforce et les performances d'écriture plus lentes pour les données aléatoires à faible compression de ses tests passés sur le lecteur. Cependant, il surclassait toujours facilement les médias tournants.
Avant d'exécuter les tests, j'étais intéressé de savoir quels types d'attente se produiraient pendant les tests, donc dans le cadre de la configuration de test, j'ai effacé sys.dm_os_wait_stats avec DBCC SQLPERF et capturé la sortie du DMV pour chaque test exécuté dans une table. Les attentes les plus fréquentes pour les configurations d'instantané unique étaient PREEMPTIVE_OS_WRITEFILE et WRITE_COMPLETION, comme illustré à la figure 2, pour 1 ou 2 instantanés de base de données.
Figure 2 – Instantané Top Waits
L'un des éléments intéressants était l'ajout des attentes FCB_REPLICA_WRITE lors de la création d'un deuxième instantané. Après avoir examiné les résultats d'attente de l'instantané de base de données unique et réexécuté quelques séries de tests, cette attente ne se produit jamais pour un seul instantané et se produit uniquement lorsque plusieurs instantanés existent et sont associés à la copie des pages dans les fichiers d'instantané de la base de données. Les temps d'attente pour les attentes PREEMPTIVE_OS_WRITEFILE évoluent étroitement avec l'augmentation de la durée d'exécution pour chacune des configurations.
Avec ces résultats à l'esprit, lors de l'examen d'un système utilisant la méthodologie des attentes et des files d'attente, voir ce type d'attente avec des valeurs plus élevées peut valoir la peine de rechercher si des instantanés de base de données existent ou non pour l'une des bases de données sur le serveur.
Conclusion
Lors de l'utilisation d'instantanés de base de données, même dans SQL Server 2012, il existe une surcharge associée aux écritures supplémentaires requises pour copier les pages de données dans les fichiers fragmentés pour les instantanés. Si l'utilisation d'instantanés de base de données fait partie de votre configuration générale, je ferais très attention à la planification du sous-système d'E/S pour répondre aux exigences de charge de travail pour l'activité d'E/S simultanée vers les fichiers fragmentés d'instantané de base de données.
D'après les résultats de ces tests, j'envisagerais même de placer des instantanés de base de données sur des SSD avant tempdb pour les performances d'écriture, ainsi que pour un impact moindre sur les performances de la maintenance des instantanés.
Comme toujours, votre kilométrage peut varier et vous voudrez certainement tester les performances de n'importe quelle configuration avant de la mettre en production.
