DIFFs wurden zu FULLs befördert

Question

Wir verwenden die DatabaseBackupgespeicherte Prozedur von Ola Hallengren , um eine Last von SharePoint-Datenbanken auf einer SQL Server 2012-Instanz im Azure-Blob-Speicher zu sichern. Wir machen das schon eine ganze Weile ohne Probleme. In den letzten 6 Wochen werden wir DIFFsjedoch nach dem Zufallsprinzip befördert FULLund wir können nicht herausfinden, warum.

Dies ist die Ausgabe des Agentenschritts

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*'

Wenn Sie sich die generierte URL ansehen, werden Sie feststellen, dass die Prozeduren im DIFF-Verzeichnis gespeichert werden, aber eine VOLLSTÄNDIGE Sicherungsdatei erstellen.

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

DatabaseBackup (Ola proc) ist vom 14.06.2019, daher muss ein Upgrade durchgeführt werden, um fair zu sein, aber es funktioniert seit über 18 Monaten gut.

Wir rufen Ola-Code nicht direkt auf, da wir eine kleine Wrapper-Prozedur haben, die den virtuellen Pfadnamen für Azure erstellt, aber im Wesentlichen nennen wir Ola-Code auf diese Weise.

Dies ist ein Problem, wenn aus einem unbekannten Grund DIFF-Sicherungen auf VOLL hochgestuft werden. Dies führt täglich zu Petabytes an Azure-Blob-Sicherungen anstelle von Gigabyte.

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

Hast du irgendwelche Gedanken dazu?

Answer 1

Sie sagen, dass diese Heraufstufung von DIFF zu VOLLSTÄNDIGEN Sicherungen "zufällig" ist, aber ich würde wetten, dass Sie eine Verbindung zwischen dieser Aktivität und der Datenabwanderung (oder Indexpflege) in der Datenbank selbst finden können.

Da Sie verwenden ChangeBackupType='Y', überprüft der Sicherungsjob sys.dm_db_file_space_usage , um festzustellen , wie viel von der Datenbank geändert wurde, und führt eine vollständige Sicherung durch, wenn sie einen Schwellenwert überschreitet (ich habe Schwierigkeiten, den Standardschwellenwert aus dem Quellcode zu erkennen ). Sie können diesen Schwellenwert ändern, indem Sie den ModificationLevelParameter anpassen , der ein Prozentsatz ist. Aus der Dokumentation

ModificationLevel
Geben Sie einen Prozentsatz an, zu dem eine differenzielle Sicherung in eine vollständige Sicherung geändert wird. Diese Option kann nur zusammen mit @ChangeBackupType = 'Y' verwendet werden. DatabaseBackup überprüft in sys.dm_db_file_space_usage die zugewiesene_extent_page_count und die geänderte_extent_page_count, um zu berechnen, wie viel von einer Datenbank geändert wurde.

Answer 2

Einführung

Wenn Sie sich Ihren Code ansehen, scheint es, dass Sie bereits den @ChangeBackupTypeParameter Ola verwenden, der in seiner SQL Server-Wartungslösung für die gespeicherte Prozedur DatabaseBackup angegeben ist. Die Dokumentation dieses Parameters enthält die folgenden Informationen:

DatabaseBackup checkt differential_base_lsnein, sys.master_filesum festzustellen, ob eine differenzielle Sicherung durchgeführt werden kann. Wenn eine differenzielle Sicherung nicht möglich ist, wird die Datenbank standardmäßig übersprungen. Alternativ können Sie ChangeBackupType auf Y setzen, um stattdessen eine vollständige Sicherung durchzuführen.

^relevant ... und ...

DatabaseBackup checkt last_log_backup_lsnein, sys.database_recovery_statusum festzustellen, ob eine Transaktionsprotokollsicherung im vollständigen oder massenprotokollierten Wiederherstellungsmodell durchgeführt werden kann. Wenn eine Transaktionsprotokollsicherung nicht möglich ist, wird die Datenbank standardmäßig übersprungen. Alternativ können Sie ChangeBackupType auf Y setzen, damit stattdessen eine differenzielle oder vollständige Sicherung durchgeführt wird.

^{nicht relevant}

^{Referenz: DatabaseBackup (ola.hallengren.com)}

Annahme

Angesichts der Tatsache, dass Sie den fraglichen Parameter verwenden und davon ausgehen, dass Ihre Datenbanken alle im vollständigen Wiederherstellungsmodell ausgeführt werden, würde ich erwarten, dass Ola-Skripte das tun, was ihnen gesagt wurde, und nur eine differenzielle Sicherung durchführen, wie Sie zuvor beobachtet haben ... ..

jedoch

... etwas die SharePoint-Datenbanken so verändert, dass Olas Verfahren davon ausgeht, dass für die Datenbank eine vollständige Sicherung erforderlich ist. Ola prüft verschiedene Situationen, von denen eine auf dem Parameter basiert ....

ModificationLevel

Es gibt den zusätzlichen Parameter @ModificationLevel, der eine DIFF-Sicherung in eine VOLLSTÄNDIGE Sicherung konvertieren würde, wenn der erste Parameter @ChangeBackupType = 'Y'festgelegt wird. Wenn wir uns Olas Code ansehen, erhalten wir Folgendes:

  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

Das heißt, wenn der Parameter @ModifcationLevelauf einen Wert und auf gesetzt @ChangeBackupTypeist Y, konvertiert die Sicherungsprozedur die DIFF-Sicherung in eine VOLLSTÄNDIGE Sicherung. Wenn die Anzahl der geänderten Seiten den Fall auslöst .

Da Sie es nicht festgelegt @ModificationLevelhaben, bleibt es NULLwie in Olas Code zu sehen:

@ModificationLevel int = NULL,

Dies scheint in Ihrer Situation nicht der Fall zu sein, es sei denn, der Wert Ihres Parameters für @ModificationLevelist dies natürlich nicht NULL.

Lösung 1

In diesem Fall haben wir den Schuldigen gefunden. Ändern Sie den Wert für @ModificationLevelzurück zu NULLund alles ist gut.

Weitere Gründe für die Umstellung

Ein weiterer Grund, warum sich die Sicherung von DIFFnach ändern würde , FULList der Parameter @ChangeBackupTypeselbst.

Die Beschreibung (von oben) wurde geschrieben als:

Databasebackup (das Verfahren) überprüft , differential_base_lsnin , sys.master_filesum zu bestimmen , ob eine Änderungssicherung durchgeführt werden kann. Wenn eine differenzielle Sicherung nicht möglich ist, wird die Datenbank standardmäßig übersprungen. Alternativ können Sie ChangeBackupType auf Y setzen, um stattdessen eine vollständige Sicherung durchzuführen.

Den Code überprüfen

Ola schrieb dies in den Code:

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

und dieser Teil hier:

   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;

Was bedeutet das?

Übersetzen von Olas Code

Nun, es liest sich ein bisschen so:

1. Ruft den Wert von differntial_base_lsnfür die aktuelle Datenbank ab

2. Wenn der Sicherungstyp DIFF ist, dann ...

   • Lesen Sie die is_snapshotSpalte in der msdb.dbo.backupsetTabelle für die aktuelle Datenbank mit der @CurrentDifferentialBaseLSNund die Sicherung typeist D(Datenbanksicherung)
   • Wenn
     • @ChanageBackupType is Y` und
     • @CurrentBackupType ist `DIFF und
     • @CurrentDifferentialBaseIsSnapshot ist 1
   • Dann
     • Set @CurrentBackupTypezuFULL

Hier haben Sie eine mögliche Situation ...

Lösung 2

... wenn Ihre Datenbank von einer Drittanbieterlösung (CommVault, NetApp, et al.) gesichert wurde, hat die Drittanbieterlösung eine gültige und konsistente Datenbanksicherung mit dem SQL Server VSS Writer-Dienst erstellt wird in der Notiz msdb.dbo.backupsetvermerkt, dass eine Snapshot-Kopie der Datenbank erstellt wurde, die den is_snapshotParameter für diese Datenbank für die gegebene festlegt , auf der differntial_base_lsnIhr DIFF basieren würde.

Aus diesem Grund kann die DIFF-Sicherung, die Sie durchführen möchten, nicht mehr auf der is_snapshotSicherung basieren und muss erneut eine neue VOLLSTÄNDIGE Sicherung erstellen, um is_snapshotden differntial_base_lsnWert und zurückzusetzen und eine neue Basis für zukünftige DIFF-Sicherungen zu erstellen.

Suchen Sie das andere Backup

Sie müssen feststellen, welcher Drittanbieter (oder eine andere Sicherungslösung) sich in Ihre implementierte Lösung einmischt, und sicherstellen, dass es sich entweder um ...

1. modifiziert, um nebeneinander zu existieren
2. minimiert auf eine Backup-Lösung.