Partager via

Compression de sauvegarde (SQL Server)

Cette rubrique décrit la compression des sauvegardes SQL Server, notamment les restrictions, le compromis des performances de compression des sauvegardes, la configuration de la compression de sauvegarde et le ratio de compression.

Remarque

Pour plus d’informations sur les éditions de SQL Server 2014 prenant 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 versions ultérieures peut restaurer une sauvegarde compressée.

Avantages

  • Étant donné qu’une sauvegarde compressée est inférieure à une sauvegarde non compressée des mêmes données, la compression d’une sauvegarde nécessite généralement moins d’E/S d’appareil et augmente généralement considérablement la vitesse de 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 coexister dans un jeu de supports.

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

  • Les NTbackups ne peuvent pas partager une bande avec des 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. Par conséquent, vous pouvez créer des sauvegardes compressées de faible priorité dans une session dont l’utilisation du processeur est limitée parResource 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 des performances de vos E/S de sauvegarde, vous pouvez isoler les E/S de sauvegarde vers ou depuis les appareils en évaluant les types de compteurs de performances suivants :

  • Compteurs de performances d’E/S Windows, tels que les compteurs de disque physique

  • Compteur du Débit d'octets de l'appareil/seconde de l’objet SQLServer: Backup Device

  • Compteur de débit de sauvegarde/restauration par seconde de l’objet SQLServer:Databases

Pour plus d’informations sur les compteurs Windows, consultez l’aide de Windows. Pour plus d’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 ratio de compression d’une sauvegarde, utilisez les valeurs associées à la sauvegarde dans les colonnes backup_size et compressed_backup_size de la table d'historique backupset, comme suit :

backup_size :compressed_backup_size

Par exemple, un taux de compression de 3:1 indique que vous enregistrez environ 66% sur l’espace disque. Pour interroger 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 qui ont été compressées. Divers facteurs peuvent avoir un impact sur le ratio de compression obtenu. Les principaux facteurs sont les suivants :

  • Type de données.

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

  • Cohérence des données entre les lignes d’une page.

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

  • Indique si les données sont chiffrées.

    Les données chiffrées compressent considérablement moins que les données non chiffrées équivalentes. Si le chiffrement transparent des données est utilisé pour chiffrer une base de données entière, la compression des sauvegardes risque de ne pas réduire la taille de la base de données entière, le cas échéant.

  • Indique si la base de données est compressée.

    Si la base de données est compressée, la compression des sauvegardes risque de ne pas réduire la taille de la base de données, le cas échéant.

Allocation d’espace pour le fichier de sauvegarde

Pour les sauvegardes compressées, la taille du fichier de sauvegarde final dépend de la compression des données, et cela est inconnu 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 à l’aide de la compression, le moteur de base de données utilise un algorithme de pré-allocation pour le fichier de sauvegarde. Cet 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 nécessaire pendant l’opération de sauvegarde, le moteur de base de données augmente le 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 uniquement si nécessaire pour atteindre sa taille finale, utilisez l’indicateur de trace 3042. L’indicateur de trace 3042 entraîne l’opération de sauvegarde à contourner l’algorithme de pré-allocation de 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, l’utilisation de cet indicateur de trace peut entraîner une légère pénalité de performances (augmentation possible de la durée de l’opération de sauvegarde).

Tâches associées

Voir aussi

Vue d’ensemble de la sauvegarde (SQL Server)
Indicateurs de trace (Transact-SQL)

  • Last updated on