Compression de sauvegardes (SQL Server)

Cette rubrique décrit la compression des sauvegardes SQL Server , notamment les restrictions, les compromis en termes de performances pour la compression des sauvegardes, la configuration pour la compression des sauvegardes et le taux de compression.

Notes

Pour plus d’informations sur les éditions de SQL Server 2014 qui prennent en charge la compression de sauvegarde, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2014. Chaque édition de SQL Server 2008 et ultérieure peut restaurer une sauvegarde compressée.

Avantages

  • Une sauvegarde compressée étant plus petite qu'une sauvegarde non compressée des mêmes données, la compression d'une sauvegarde requiert en général moins d'E/S de périphérique et, par conséquent, augmente souvent considérablement la vitesse de la sauvegarde.

    Pour plus d'informations, consultez Impact sur les performances de la compression des sauvegardes, plus loin dans cette rubrique.

Restrictions

Les restrictions suivantes s'appliquent aux sauvegardes compressées :

  • Les sauvegardes compressées et non compressées ne peuvent pas co-exister dans un support de sauvegardes.

  • Toutefois, les versions précédentes de SQL Server ne peuvent pas lire les sauvegardes compressées.

  • NTbackups ne peut pas partager de bande avec les sauvegardes SQL Server compressées.

Impact sur les performances de la compression des sauvegardes

Par défaut, la compression augmente considérablement l'utilisation de l'UC et l'UC supplémentaire consommée par le processus de compression peut avoir un impact néfaste sur les opérations simultanées. Ainsi, dans une session où l’utilisation de l’UC est limitée, il peut être préférable de créer une sauvegarde compressée de priorité basse à l’aide deResource Governor. Pour plus d’informations, consultez Utiliser Resource Governor pour limiter l’utilisation de processeur avec la compression de sauvegarde (Transact-SQL).

Pour obtenir une bonne image de vos performances d'E/S de sauvegarde, vous pouvez isoler l'E/S de sauvegarde en direction ou depuis des unités en évaluant les types suivants de compteurs de performance :

  • Compteurs de performance d'E/S Windows, tels que les compteurs de disque physique

  • Compteur Débit d’unité en octets/s de l’objet SQLServer:Backup Device

  • Compteur Débit de sauvegarde/restauration/s de l’objet SQLServer:Databases

Pour des informations sur les compteurs Windows, consultez l'aide de Windows. Pour obtenir des informations sur l’utilisation des compteurs SQL Server, consultez Utiliser des objets SQL Server.

Calculer le taux de compression d'une sauvegarde compressée

Pour calculer le taux de compression d’une sauvegarde, utilisez les valeurs pour la sauvegarde dans les colonnes backup_size et compressed_backup_size de la table de l’historique backupset , comme suit :

backup_size:compressed_backup_size

Par exemple, un taux de compression 3:1 indique que vous économisez environ 66 % de l'espace disque. Pour effectuer une requête sur ces colonnes, vous pouvez utiliser l'instruction Transact-SQL suivante :

SELECT backup_size/compressed_backup_size FROM msdb..backupset;  

Le taux de compression d'une sauvegarde compressée dépend des données compressées. Divers facteurs peuvent avoir une incidence sur le taux de compression obtenu. Les facteurs majeurs sont :

  • Le type des données.

    Les données caractères se compressent plus que d'autres types de données.

  • La cohérence des données dans les lignes sur une page.

    En général, si une page contient plusieurs lignes dans lesquelles un champ contient la même valeur, une compression importante peut se produire pour cette valeur. En revanche, pour une base de données qui contient des données aléatoires ou qui contient une seule grande ligne par page, une sauvegarde compressée serait presque aussi importante qu'une sauvegarde non compressée.

  • Si les données sont chiffrées.

    Le taux de compression des données chiffrées est beaucoup moins élevé que celui des données non chiffrées correspondantes. Si le chiffrement transparent des données est utilisé pour chiffrer une base de données entière, la compression des sauvegardes ne réduit pas leur taille de manière significative, voire pas du tout.

  • Si la base de données est compressée.

    Si la base de données est compressée, compresser des sauvegardes peut réduire faiblement leur taille, voire pas du tout.

Allocation d'espace pour le fichier de sauvegarde

Pour les sauvegardes compressées, la taille du fichier de sauvegarde final dépend de la capacité de compression des données. Or, celle-ci n'est pas connue avant la fin de l'opération de sauvegarde. Par conséquent, par défaut, lors de la sauvegarde d'une base de données faisant appel à la compression, le moteur de base de données utilise un algorithme de préallocation pour le fichier de sauvegarde. Cette algorithme préalloue un pourcentage prédéfini de la taille de la base de données pour le fichier de sauvegarde. Si davantage d'espace est requis au cours de l'opération de sauvegarde, le moteur de base de données augmente la taille du fichier. Si la taille finale est inférieure à l'espace alloué, à la fin de l'opération de sauvegarde, le moteur de base de données réduit le fichier à la taille finale réelle de la sauvegarde.

Pour permettre au fichier de sauvegarde de croître autant que nécessaire uniquement afin d'atteindre sa taille définitive, utilisez l'indicateur de trace 3042. L'indicateur de trace 3042 permet à l'opération de sauvegarde de contourner l'algorithme de préallocation de la compression de sauvegarde par défaut. Cet indicateur de trace est utile si vous devez économiser de l'espace en allouant uniquement la taille réelle requise pour la sauvegarde compressée. Toutefois, le recours à cet indicateur de trace peut entraîner une légère baisse des performances (augmentation possible de la durée de l'opération de sauvegarde).

Tâches associées

Voir aussi

Backup Overview (SQL Server)
Indicateurs de trace (Transact-SQL)