DIFF promossi a FULL

Question

Utilizziamo la DatabaseBackupstored procedure di Ola Hallengren per eseguire il backup di un carico di database di SharePoint su un'istanza di SQL Server 2012 nell'archivio BLOB di Azure. Lo facciamo da un po 'di tempo senza problemi. Tuttavia, nelle ultime 6 settimane i nostri DIFFssono stati promossi a caso FULLe non possiamo scoprire perché.

Questo è l'output del passaggio dell'agente

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

Se dai un'occhiata all'URL generato, noterai che le procedure vengono archiviate nella directory DIFF, ma creano un file di backup COMPLETO.

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

DatabaseBackup (Ola proc) è del 14/06/2019, quindi ha bisogno di un aggiornamento per essere equo, ma ha funzionato bene per oltre 18 mesi.

Non chiamiamo direttamente il codice Ola poiché abbiamo una piccola procedura wrapper che crea il nome del percorso virtuale per Azure, ma essenzialmente è così che chiamiamo il codice di Ola.

Questo è un problema per cui, per qualche motivo sconosciuto, i backup DIFF vengono promossi a FULL, ciò causa petabyte di backup BLOB di Azure invece di gigabyte, ogni giorno.

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

Hai qualche idea in merito?

Answer 1

Dici che questa promozione da DIFF a backup COMPLETI è "casuale" ma scommetto che puoi trovare una connessione tra questa attività e l'abbandono dei dati (o la manutenzione dell'indice) nel database stesso.

Poiché stai utilizzando ChangeBackupType='Y', il processo di backup sta guardando sys.dm_db_file_space_usage per vedere quanto del database è stato modificato ed esegue un backup COMPLETO se supera una soglia (ho difficoltà a distinguere la soglia predefinita dal codice sorgente ). È possibile modificare tale soglia regolando il ModificationLevelparametro, che è una percentuale. Dalla documentazione

ModificationLevel
Specificare una percentuale quando un backup differenziale verrà modificato in un backup completo. Questa opzione può essere utilizzata solo insieme a @ChangeBackupType = 'Y'. DatabaseBackup controlla allocato_extent_page_count e modified_extent_page_count in sys.dm_db_file_space_usage per calcolare la quantità di database che è stata modificata.

Answer 2

introduzione

Guardando il tuo codice, sembra che tu stia già utilizzando il @ChangeBackupTypeparametro Ola fornito nella sua SQL Server Maintenance Solution per la stored procedure DatabaseBackup . La documentazione di questo parametro fornisce le seguenti informazioni:

DatabaseBackup esegue il check- differential_base_lsnin sys.master_filesper determinare se è possibile eseguire un backup differenziale. Se un backup differenziale non è possibile, il database viene ignorato per impostazione predefinita. In alternativa, puoi impostare ChangeBackupType su Y per eseguire invece un backup completo.

^rilevanti ... e ...

DatabaseBackup esegue il check- last_log_backup_lsnin sys.database_recovery_statusper determinare se è possibile eseguire un backup del log delle transazioni nel modello di ripristino completo o con registrazione di massa. Se un backup del log delle transazioni non è possibile, il database viene ignorato per impostazione predefinita. In alternativa, puoi impostare ChangeBackupType su Y per eseguire invece un backup differenziale o completo.

^{non rilevante}

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

Assunzione

Visto che stai usando il parametro in questione e supponendo che i tuoi database siano tutti in esecuzione nel modello di recupero COMPLETO, mi aspetto che gli script di Ola facciano come gli è stato detto ed eseguano solo un backup differenziale, come stavi osservando in precedenza ... ..

tuttavia

... qualcosa sta alterando i database di SharePoint in modo tale che la procedura di Ola presuppone che il database richieda un backup COMPLETO. Ola verifica varie situazioni, una delle quali si basa sul parametro ....

ModificationLevel

C'è il parametro aggiuntivo @ModificationLevelche convertirà un backup DIFF in un backup COMPLETO se il primo parametro @ChangeBackupType = 'Y'è impostato. Guardando il codice di Ola ci fornisce questo:

  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

Ciò significa che se il parametro @ModifcationLevelè impostato su un valore ed @ChangeBackupTypeè impostato su Y, la procedura di backup convertirà il backup DIFF in un backup COMPLETO. Se la quantità di pagine modificate attiva il caso .

Poiché non l'hai impostato @ModificationLevel, rimane NULLcome si può vedere nel codice di Ola:

@ModificationLevel int = NULL,

Questo non sembra essere il caso nella tua situazione, a meno che, ovviamente, il valore del tuo parametro per @ModificationLevelnon lo sia NULL.

Soluzione 1

In tal caso, abbiamo trovato il colpevole. Cambia il valore per @ModificationLeveltorna a NULLe va tutto bene.

Ulteriori motivi per la conversione

Un altro motivo per cui il backup cambia da DIFFa FULLè il parametro @ChangeBackupTypestesso.

La descrizione (dall'alto) è stata scritta come:

DatabaseBackup (la procedura) esegue il check- differential_base_lsnin sys.master_filesper determinare se è possibile eseguire un backup differenziale. Se un backup differenziale non è possibile, il database viene ignorato per impostazione predefinita. In alternativa, puoi impostare ChangeBackupType su Y per eseguire invece un backup completo.

Controllo del codice

Ola ha scritto questo nel codice:

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

e questa parte qui:

   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;

Cosa significa questo?

Tradurre il codice di Ola

Beh, si legge un po 'così:

1. Ottieni il valore di differntial_base_lsnper il database corrente

2. Se il tipo di backup è DIFF, allora ...

   • Leggere la is_snapshotcolonna nella msdb.dbo.backupsettabella per il database corrente con @CurrentDifferentialBaseLSNe il backup typeè D(Backup database)
   • Se
     • @ChanageBackupType is Y` e
     • @CurrentBackupType è `DIFF e
     • @CurrentDifferentialBaseIsSnapshot è 1
   • Poi
     • Imposta @CurrentBackupTypesuFULL

Ecco una possibile situazione ...

Soluzione 2

... se il backup del database è stato eseguito da una soluzione di terze parti (CommVault, NetApp, et. al.), la soluzione di terze parti avrà creato un backup del database valido e coerente utilizzando il servizio SQL Server VSS Writer, che annoterà msdb.dbo.backupsetche è stata eseguita una copia istantanea del database, che imposta il is_snapshotparametro per quel database per il dato su differntial_base_lsncui si baserà il DIFF.

Per questo motivo, il backup DIFF che si sta tentando di eseguire non può più essere basato sul is_snapshotbackup e deve creare di nuovo un nuovo backup COMPLETO, per reimpostare is_snapshotil differntial_base_lsnvalore e e creare una nuova base per i backup DIFF futuri.

Trova l'altro backup

Dovrai determinare quale terza parte (o altra soluzione di backupb) sta interferendo con la soluzione implementata e assicurarti che siano ...

1. modificato per coesistere
2. ridotta a una soluzione di backup.