DIFFs promovidos a FULLs
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
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.
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_lsnemsys.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_lsnemsys.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_lsnemsys.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:
Obtenha o valor de
differntial_base_lsnpara o banco de dados atualSe o tipo de backup for DIFF então ...
- Leia a
is_snapshotcoluna namsdb.dbo.backupsettabela para o banco de dados atual com o@CurrentDifferentialBaseLSNe o backuptypeéD(backup do banco de dados) - E se
@ChanageBackupType isY` e@CurrentBackupTypeé `DIFF e@CurrentDifferentialBaseIsSnapshoté1
- Então
- Definir
@CurrentBackupTypeparaFULL
- Definir
- Leia a
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 ...
- modificado para coexistir
- minimizado para uma solução de backup.