DIFF повышены до FULL

Question

Мы используем DatabaseBackupхранимую процедуру Олы Халленгрена для резервного копирования нагрузки баз данных SharePoint на экземпляре SQL Server 2012 в хранилище BLOB-объектов Azure. Мы занимаемся этим довольно давно без каких-либо проблем. Однако в течение последних 6 недель нас DIFFsслучайным образом продвигают на должности, FULLи мы не можем понять, почему.

Это результат действия агента.

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

Если вы посмотрите на сгенерированный URL, вы заметите, что процедуры сохраняются в каталоге DIFF, но создают ПОЛНЫЙ файл резервной копии.

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

DatabaseBackup (Ola proc) выпущен 14.06.2019, поэтому, честно говоря, его нужно обновить, но он хорошо работает уже более 18 месяцев.

Мы не вызываем код Ola напрямую, поскольку у нас есть небольшая процедура-оболочка, которая создает имя виртуального пути для Azure, но по сути именно так мы вызываем код Ola.

Это проблема, из-за которой по неизвестной причине резервные копии DIFF переводятся в ПОЛНОЕ, что приводит к петабайтам резервных копий BLOB-объектов Azure вместо гигабайт - каждый день.

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

Есть ли у вас какие-нибудь мысли по этому поводу?

Answer 1

Вы говорите, что преобразование DIFF в ПОЛНОЕ резервное копирование является «случайным», но я готов поспорить, что вы можете найти связь между этим действием и оттоком данных (или обслуживанием индекса) в самой базе данных.

Поскольку вы используете ChangeBackupType='Y', задание резервного копирования смотрит на sys.dm_db_file_space_usage, чтобы узнать, какая часть базы данных была изменена, и выполняет ПОЛНОЕ резервное копирование, если оно превышает пороговое значение (мне трудно определить порог по умолчанию из исходного кода. ). Вы можете изменить этот порог, настроив ModificationLevelпараметр в процентах. Из документации

ModificationLevel
Укажите процент, в котором разностная резервная копия будет изменена на полную. Этот параметр можно использовать только вместе с @ChangeBackupType = 'Y'. DatabaseBackup проверяет selected_extent_page_count и modified_extent_page_count в sys.dm_db_file_space_usage, чтобы вычислить, какая часть базы данных была изменена.

Answer 2

Введение

Глядя на ваш код, кажется, что вы уже используете @ChangeBackupTypeпараметр Ola, предоставленный в его решении для обслуживания SQL Server для хранимой процедуры DatabaseBackup . Документация по этому параметру предоставляет следующую информацию:

DatabaseBackup проверяет differential_base_lsnв , sys.master_filesчтобы определить , может ли быть выполнено дифференциальное резервное копирование. Если разностное резервное копирование невозможно, база данных по умолчанию пропускается. Кроме того, вы можете установить для ChangeBackupType значение Y, чтобы вместо этого выполнялось полное резервное копирование.

^{актуально} ... и ...

DatabaseBackup проверяет last_log_backup_lsnв , sys.database_recovery_statusчтобы определить , может ли быть выполнено резервное копирование журнала транзакций в полной или неполном протоколировании модели восстановления. Если резервное копирование журнала транзакций невозможно, база данных по умолчанию пропускается. Кроме того, вы можете установить для ChangeBackupType значение Y, чтобы вместо этого выполнялось дифференциальное или полное резервное копирование.

^{не имеет значения}

^{Ссылка: DatabaseBackup (ola.hallengren.com)}

Предположение

Видя, как вы используете рассматриваемый параметр, и предполагая, что все ваши базы данных работают в модели ПОЛНОГО восстановления, я бы ожидал, что сценарии Ola будут действовать так, как им было сказано, и просто выполнят дифференциальное резервное копирование, как вы ранее наблюдали ... ..

Однако

... что-то изменяет базы данных SharePoint таким образом, что процедура Олы предполагает, что база данных требует ПОЛНОЙ резервной копии. Ола проверяет различные ситуации, одна из которых основана на параметре ....

ModificationLevel

Существует дополнительный параметр @ModificationLevel, который преобразует резервную копию DIFF в ПОЛНУЮ резервную копию, если установлен первый параметр @ChangeBackupType = 'Y'. Глядя на код Олы, мы получаем следующее:

  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

Это означает, что если для параметра @ModifcationLevelзадано значение и @ChangeBackupTypeустановлено значение Y, то процедура резервного копирования преобразует резервную копию DIFF в ПОЛНУЮ резервную копию. Если количество измененных страниц запускает случай .

Поскольку вы не установили, @ModificationLevelон остается, NULLкак видно в коде Олы:

@ModificationLevel int = NULL,

Похоже, что в вашей ситуации это не так, если, конечно, значение вашего параметра для @ModificationLevelне так NULL.

Решение 1

В этом случае мы нашли виновного. Измените значение на " @ModificationLevelНазад", NULLи все будет хорошо.

Дальнейшие причины обращения

Другая причина, по которой резервная копия изменится с DIFFна, FULL- это @ChangeBackupTypeсам параметр .

Описание (сверху) было записано как:

DatabaseBackup (процедура) проверяет , differential_base_lsnв , sys.master_filesчтобы определить , может ли быть выполнено дифференциальное резервное копирование. Если разностное резервное копирование невозможно, база данных по умолчанию пропускается. Кроме того, вы можете установить для ChangeBackupType значение Y, чтобы вместо этого выполнялось полное резервное копирование.

Проверка кода

Ола написал это в коде:

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

и эта часть здесь:

   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;

Что это значит?

Перевод кода Олы

Читается это примерно так:

1. Получить значение differntial_base_lsnдля текущей базы данных

2. Если тип резервной копии - DIFF, то ...

   • Прочитайте is_snapshotстолбец в msdb.dbo.backupsetтаблице для текущей базы данных @CurrentDifferentialBaseLSNи резервное копирование typeявляется D(резервным копированием базы данных)
   • Если
     • @ChanageBackupType is Y` и
     • @CurrentBackupType это `DIFF и
     • @CurrentDifferentialBaseIsSnapshot является 1
   • потом
     • Установить @CurrentBackupTypeнаFULL

Вот вам возможная ситуация ...

Решение 2

... если ваша база данных была создана сторонним решением (CommVault, NetApp и др.), то стороннее решение создаст действительную и согласованную резервную копию базы данных с помощью службы SQL Server VSS Writer, которая сделает отметку в том, msdb.dbo.backupsetчто была сделана моментальная копия базы данных, которая устанавливает is_snapshotпараметр для этой базы данных, на differntial_base_lsnкотором будет основан ваш DIFF.

Из - за этого резервное копирование DIFF вы пытаетесь выполнить больше не может быть основан на is_snapshotподпорках и должны создать новую полную резервную копию снова, чтобы сбросить is_snapshotи на differntial_base_lsnзначение, и создать новую базу для будущего DIFF резервного копирования.

Найдите другую резервную копию

Вам нужно будет определить, какая сторонняя сторона (или другое решение для резервного копированияb) вмешивается в ваше реализованное решение, и убедиться, что они либо ...

1. изменен, чтобы сосуществовать
2. сведено к минимуму до одного решения для резервного копирования.