DIFF promus en FULL

Question

Nous utilisons la DatabaseBackupprocédure stockée d' Ola Hallengren pour sauvegarder une charge de bases de données SharePoint sur une instance SQL Server 2012 dans le stockage d'objets blob Azure. Nous faisons cela depuis un bon moment sans aucun problème. Cependant, au cours des 6 dernières semaines, nous avons DIFFsété promus au hasard FULLet nous ne pouvons pas savoir pourquoi.

Ceci est la sortie de l'étape d'agent

BACKUP DATABASE [Database] TO URL = N'https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak' 
WITH NO_CHECKSUM, COMPRESSION, CREDENTIAL = N'*storeageaccountname*'

Si vous regardez l'URL générée, vous remarquerez que les procédures sont stockées dans le répertoire DIFF, mais créent un fichier de sauvegarde COMPLET.

https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak
                                                                        --^           --^

DatabaseBackup (Ola proc) date du 14/06/2019, il a donc besoin d'une mise à niveau pour être juste, mais cela fonctionne bien depuis plus de 18 mois.

Nous n'appelons pas directement le code Ola car nous avons une petite procédure wrapper qui construit le nom du chemin virtuel pour Azure, mais c'est essentiellement ainsi que nous appelons le code d'Ola.

Il s'agit d'un problème où, pour une raison inconnue, les sauvegardes DIFF sont promues à FULL, ce qui entraîne des pétaoctets de sauvegardes d'objets blob Azure au lieu de gigaoctets - chaque jour.

EXECUTE dbo.DatabaseBackup
    @Database = @DatabaseName,
    @URL = @BackupPath,
    @Credential = @StorageAccount,
    @BackupType = @backupType,
    @Compress = @Compression,
    @LogToTable = 'Y',
    @ChangeBackupType = 'Y',
    @Updateability = @DatabaseReadOnlyState,
    @DirectoryStructure = NULL,
    @AvailabilityGroupDirectoryStructure = NULL

Avez-vous des idées à ce sujet?

Answer 1

Vous dites que cette promotion des sauvegardes DIFF vers les sauvegardes FULL est "aléatoire" mais je parie que vous pouvez trouver un lien entre cette activité et le désabonnement des données (ou la maintenance de l'index) dans la base de données elle-même.

Parce que vous utilisez ChangeBackupType='Y', le travail de sauvegarde regarde sys.dm_db_file_space_usage pour voir combien de la base de données a été modifiée et effectue une sauvegarde complète si elle dépasse un seuil (j'ai du mal à discerner le seuil par défaut à partir du code source ). Vous pouvez modifier ce seuil en ajustant le ModificationLevelparamètre, qui est un pourcentage. De la documentation

ModificationLevel
Spécifiez un pourcentage lorsqu'une sauvegarde différentielle sera remplacée par une sauvegarde complète. Cette option ne peut être utilisée qu'avec @ChangeBackupType = 'Y'. DatabaseBackup vérifie alloué_extent_page_count et modified_extent_page_count dans sys.dm_db_file_space_usage pour calculer la part d'une base de données qui a été modifiée.

Answer 2

introduction

En regardant votre code, il semble que vous utilisez déjà le @ChangeBackupTypeparamètre Ola fourni dans sa solution de maintenance SQL Server pour la procédure stockée DatabaseBackup . La documentation de ce paramètre fournit les informations suivantes:

DatabaseBackup chèques differential_base_lsnen sys.master_filespour déterminer si une sauvegarde différentielle peut être effectuée. Si une sauvegarde différentielle n'est pas possible, la base de données est ignorée par défaut. Vous pouvez également définir ChangeBackupType sur Y pour qu'une sauvegarde complète soit effectuée à la place.

^pertinent ... et ...

DatabaseBackup contrôles last_log_backup_lsndans sys.database_recovery_statusafin de déterminer si une sauvegarde du journal des transactions dans le modèle de récupération complète ou enregistré en bloc peut être effectué. Si une sauvegarde du journal des transactions n'est pas possible, la base de données est ignorée par défaut. Vous pouvez également définir ChangeBackupType sur Y pour qu'une sauvegarde différentielle ou complète soit effectuée à la place.

^{non pertinent}

^{Référence: DatabaseBackup (ola.hallengren.com)}

supposition

Étant donné que vous utilisez le paramètre en question et en supposant que vos bases de données fonctionnent toutes dans le modèle de récupération FULL, je m'attendrais à ce que les scripts Ola fassent ce qu'ils ont été dit et effectuent simplement une sauvegarde différentielle, comme vous le faisiez précédemment ... ..

pourtant

... quelque chose modifie les bases de données SharePoint de telle manière que la procédure d'Ola suppose que la base de données nécessite une sauvegarde complète. Ola vérifie différentes situations, dont l'une est basée sur le paramètre ...

ModificationLevel

Il existe un paramètre supplémentaire @ModificationLevelqui convertirait une sauvegarde DIFF en sauvegarde FULL si le premier paramètre @ChangeBackupType = 'Y'est défini. Regarder le code d'Ola nous fournit ceci:

  IF @ModificationLevel IS NOT NULL AND @BackupType <> 'DIFF'
  BEGIN
    INSERT INTO @Errors ([Message], Severity, [State])
    SELECT 'The value for the parameter @ModificationLevel is not supported.', 16, 3
  END

Cela signifie que si le paramètre @ModifcationLevelest défini sur une valeur et @ChangeBackupTypeest défini sur Y, la procédure de sauvegarde convertira la sauvegarde DIFF en sauvegarde FULL Si le nombre de pages modifiées déclenche le cas .

Parce que vous ne l'avez pas défini, @ModificationLevelil reste NULLcomme on peut le voir dans le code d'Ola:

@ModificationLevel int = NULL,

Cela ne semble pas être le cas dans votre situation, à moins bien sûr que la valeur de votre paramètre pour @ModificationLevelne l'est pas NULL.

Solution 1

Dans ce cas, nous avons trouvé le coupable. Changez la valeur de @ModificationLevelretour à NULLet tout va bien.

Autres raisons de conversion

Une autre raison pour laquelle la sauvegarde passerait de DIFFà FULLest le paramètre @ChangeBackupTypelui-même.

La description (ci-dessus) a été écrite comme suit:

DatabaseBackup (la procédure) vérifie differential_base_lsnà sys.master_filesdéterminer si une sauvegarde différentielle peut être effectuée. Si une sauvegarde différentielle n'est pas possible, la base de données est ignorée par défaut. Vous pouvez également définir ChangeBackupType sur Y pour qu'une sauvegarde complète soit effectuée à la place.

Vérifier le code

Ola a écrit ceci dans le code:

SELECT @CurrentDifferentialBaseLSN = differential_base_lsn
FROM sys.master_files
WHERE database_id = DB_ID(@CurrentDatabaseName)
AND [type] = 0
AND [file_id] = 1

et cette partie ici:

   IF @CurrentBackupType = 'DIFF'
    BEGIN
      SELECT @CurrentDifferentialBaseIsSnapshot = is_snapshot
      FROM msdb.dbo.backupset
      WHERE database_name = @CurrentDatabaseName
      AND [type] = 'D'
      AND checkpoint_lsn = @CurrentDifferentialBaseLSN
    END

    IF @ChangeBackupType = 'Y'
    BEGIN
      IF @CurrentBackupType = 'DIFF' AND @CurrentDifferentialBaseIsSnapshot = 1
      BEGIN
        SET @CurrentBackupType = 'FULL'
      END
    END;

Qu'est-ce que ça veut dire?

Traduire le code d'Ola

Eh bien, ça se lit un peu comme ça:

1. Obtenir la valeur de differntial_base_lsnpour la base de données actuelle

2. Si le type de sauvegarde est DIFF, alors ...

   • Lisez la is_snapshotcolonne du msdb.dbo.backupsettableau de la base de données actuelle avec @CurrentDifferentialBaseLSNet la sauvegarde typeest D(Sauvegarde de la base de données)
   • Si
     • @ChanageBackupType is Y` et
     • @CurrentBackupType est `DIFF et
     • @CurrentDifferentialBaseIsSnapshot est 1
   • ensuite
     • Régler @CurrentBackupTypesurFULL

Ici vous avez une situation possible ...

Solution 2

... si votre base de données a été sauvegardée par une solution tierce (CommVault, NetApp, et. al.), la solution tierce aura créé une sauvegarde de base de données valide et cohérente à l'aide du service SQL Server VSS Writer, qui notera dans le msdb.dbo.backupsetqu'une copie instantanée de la base de données a été prise, ce qui définit le is_snapshotparamètre de cette base de données pour la donnée sur differntial_base_lsnlaquelle votre DIFF serait basé.

Pour cette raison, la sauvegarde DIFF que vous essayez d'effectuer ne peut plus être basée sur la is_snapshotsauvegarde et doit créer à nouveau une nouvelle sauvegarde FULL, pour réinitialiser is_snapshotla differntial_base_lsnvaleur et et créer une nouvelle base pour les futures sauvegardes DIFF.

Trouvez l'autre sauvegarde

Vous devrez déterminer quelle tierce partie (ou autre solution de sauvegardeb) se mêle de votre solution implémentée et vous assurer qu'elle est soit ...

1. modifié pour coexister
2. réduit à une solution de sauvegarde.