DIFFs promovidos a FULLs

Nov 06 2020

Usamos o DatabaseBackupprocedimento armazenado de Ola Hallengren para fazer backup de uma carga de bancos de dados do SharePoint em uma instância do SQL Server 2012 no armazenamento de blob do Azure. Temos feito isso há um bom tempo sem problemas. No entanto, nas últimas 6 semanas, DIFFsestamos sendo promovidos aleatoriamente para FULLe não podemos descobrir o porquê.

Este é o resultado da etapa do 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 você der uma olhada na URL gerada, notará que o procedimento está sendo armazenado no diretório DIFF, mas criando um arquivo de backup COMPLETO.

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

DatabaseBackup (Ola proc) é de 14/06/2019, portanto, precisa de uma atualização para ser justo, mas tem funcionado bem por mais de 18 meses.

Não chamamos o código Ola diretamente, pois temos um pequeno procedimento de wrapper que cria o nome do caminho virtual para o Azure, mas essencialmente é assim que chamamos o código Ola.

Este é um problema em que, por algum motivo desconhecido, os backups DIFF estão sendo promovidos para FULL. Isso causa petabytes de backups de blob do Azure em vez de gigabytes - a cada dia.

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

você tem alguma opinião sobre isso?

Respostas

6 alroc Nov 09 2020 at 23:00

Você diz que a promoção de backups DIFF para FULL é "aleatória", mas aposto que pode encontrar uma conexão entre essa atividade e a rotatividade de dados (ou manutenção de índice) no próprio banco de dados.

Como você está usando ChangeBackupType='Y', o trabalho de backup está examinando sys.dm_db_file_space_usage para ver quanto do banco de dados foi alterado e executa um backup COMPLETO se exceder um limite (estou tendo dificuldade em discernir o limite padrão do código-fonte ) Você pode alterar esse limite ajustando o ModificationLevelparâmetro, que é uma porcentagem. Da documentação

ModificationLevel
Especifique uma porcentagem quando um backup diferencial será alterado para um backup completo. Esta opção só pode ser usada junto com @ChangeBackupType = 'Y'. DatabaseBackup verifica alocados_extent_pagina_conta e modificados_extent_pagina_conta em sys.dm_db_file_space_usage para calcular quanto de um banco de dados foi modificado.

3 JohnK.N. Nov 10 2020 at 00:32

Introdução

Olhando para o seu código, parece que você já está usando o @ChangeBackupTypeparâmetro Ola fornecido em sua solução de manutenção do SQL Server para o procedimento armazenado DatabaseBackup . A documentação deste parâmetro fornece as seguintes informações:

DatabaseBackup cheques differential_base_lsnem sys.master_filesdeterminar se um backup diferencial pode ser realizada. Se um backup diferencial não for possível, o banco de dados será ignorado por padrão. Como alternativa, você pode definir ChangeBackupType como Y para que um backup completo seja executado.

relevante ... e ...

DatabaseBackup cheques last_log_backup_lsnem sys.database_recovery_statusdeterminar se um backup do log de transações no modelo de recuperação completa ou bulk-logged pode ser realizada. Se um backup do log de transações não for possível, o banco de dados será ignorado por padrão. Como alternativa, você pode definir ChangeBackupType como Y para que um backup diferencial ou completo seja executado.

Não é relevante

Referência: DatabaseBackup (ola.hallengren.com)

Suposição

Vendo que você está usando o parâmetro em questão e assumindo que seus bancos de dados estão todos rodando no modelo de recuperação COMPLETA, então eu esperaria que os scripts do Ola fizessem como eles foram instruídos e apenas executassem um backup diferencial, como você estava observando anteriormente ... ..

Contudo

... algo está alterando os bancos de dados do SharePoint de tal forma, que o procedimento de Ola está assumindo que o banco de dados requer um backup COMPLETO. Ola verifica várias situações, uma das quais é baseada no parâmetro ....

ModificationLevel

Existe o parâmetro adicional @ModificationLevelque converteria um backup DIFF em um backup FULL se o primeiro parâmetro @ChangeBackupType = 'Y'fosse definido. Olhar para o código de Ola nos fornece isso:

  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

Isso significa que se o parâmetro @ModifcationLevelfor definido com um valor e @ChangeBackupTypefor definido como Y, o procedimento de backup converterá o backup DIFF em um backup COMPLETO se a quantidade de páginas alteradas acionar o caso .

Porque você não definiu @ModificationLevelpermanece NULLcomo pode ser visto no código de Ola:

@ModificationLevel int = NULL,

Este não parece ser o caso em sua situação, a menos que, é claro, o valor de seu parâmetro para @ModificationLevelnão seja NULL.

Solução 1

Nesse caso, encontramos o culpado. Altere o valor de @ModificationLevelvolta para NULLe tudo estará bem.

Outras razões para conversão

Outro motivo pelo qual o backup mudaria de DIFFpara FULLé o @ChangeBackupTypepróprio parâmetro .

A descrição (acima) foi escrita como:

DatabaseBackup (o procedimento) controlos differential_base_lsnem sys.master_filesdeterminar se uma cópia de segurança diferencial pode ser realizado. Se um backup diferencial não for possível, o banco de dados será ignorado por padrão. Como alternativa, você pode definir ChangeBackupType como Y para que um backup completo seja executado.

Verificar o Código

Ola escreveu isso no código:

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

e esta parte aqui:

   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;

O que isto significa?

Traduzindo o código de Ola

Bem, é um pouco assim:

  1. Obtenha o valor de differntial_base_lsnpara o banco de dados atual

  2. Se o tipo de backup for DIFF então ...

    • Leia a is_snapshotcoluna na msdb.dbo.backupsettabela para o banco de dados atual com o @CurrentDifferentialBaseLSNe o backup typeé D(backup do banco de dados)
    • E se
      • @ChanageBackupType is Y` e
      • @CurrentBackupType é `DIFF e
      • @CurrentDifferentialBaseIsSnapshot é 1
    • Então
      • Definir @CurrentBackupTypeparaFULL

Aqui você tem uma situação possível ...

Solução 2

... se o backup de seu banco de dados foi feito por uma solução de terceiros (CommVault, NetApp, et. al.), a solução de terceiros terá criado um backup de banco de dados válido e consistente usando o serviço SQL Server VSS Writer, que fará uma observação em msdb.dbo.backupsetque uma cópia instantânea do banco de dados foi feita, o que define o is_snapshotparâmetro para aquele banco de dados para o differntial_base_lsnqual seu DIFF seria baseado.

Por causa disso, o backup DIFF que você está tentando executar não pode mais ser baseado no is_snapshotbackup e deve criar um novo backup FULL novamente, para redefinir is_snapshoto differntial_base_lsnvalor e e criar uma nova base para backups DIFF futuros.

Encontre o outro backup

Você terá que determinar qual terceiro (ou outra solução de backupb) está interferindo na solução implementada e garantir que eles ...

  1. modificado para coexistir
  2. minimizado para uma solução de backup.