FULLにプロモートされたDIFF

Nov 06 2020

Ola HallengrenのDatabaseBackupストアドプロシージャを使用して、SQL Server2012インスタンス上のSharePointデータベースの負荷をAzureBLOBストレージにバックアップします。私たちはこれをかなり長い間問題なく行ってきました。ただし、過去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）は2019-06-14からのものであるため、公平にアップグレードする必要がありますが、18か月以上にわたって正常に機能しています。

Azureの仮想パス名を構築する小さなラッパープロシージャがあるため、Olaコードを直接呼び出すことはありませんが、基本的にはこれがOlaのコードの呼び出し方法です。

これは、何らかの理由でDIFFバックアップがFULLにプロモートされている場合の問題です。これにより、毎日ギガバイトではなくペタバイトのAzureBLOBバックアップが発生します。

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

それについて何か考えはありますか？

回答

6 alroc Nov 09 2020 at 23:00

このDIFFのフルバックアップへの昇格は「ランダム」であるとおっしゃっていますが、このアクティビティとデータベース自体のデータチャーン（またはインデックスのメンテナンス）との関係を見つけることができると思います。

を使用しているためChangeBackupType='Y'、バックアップジョブはsys.dm_db_file_space_usageを調べてデータベースの変更量を確認し、しきい値を超えた場合は完全バックアップを実行します（ソースコードからデフォルトのしきい値を識別するのが困難です））。ModificationLevelパーセンテージであるパラメーターを調整することにより、そのしきい値を変更できます。ドキュメントから

ModifiedLevel
差分バックアップが完全バックアップに変更される割合を指定します。このオプションは、@ ChangeBackupType = 'Y'と一緒にのみ使用できます。DatabaseBackupは、sys.dm_db_file_space_usageのallocated_extent_page_countとmodified_extent_page_countをチェックして、変更されたデータベースの量を計算します。

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

前書き

コードを見ると、DatabaseBackupストアドプロシージャのSQLServerメンテナンスソリューションで@ChangeBackupType提供されているパラメータOlaをすでに使用しているようです。このパラメーターのドキュメントには、次の情報が記載されています。

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データベースをそのような方法で変更しているため、Olaの手順では、データベースに完全バックアップが必要であると想定しています。Olaはさまざまな状況をチェックしますが、そのうちの1つはパラメーターに基づいています。

モディフィケーションレベル

@ModificationLevel最初のパラメーター@ChangeBackupType = 'Y'が設定されている場合、DIFFバックアップをFULLバックアップに変換する追加のパラメーターがあります。Olaのコードを見ると、次のことがわかります。

  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、その後、バックアップ手順はFULLバックアップに差分バックアップを変換するページの量がトリガにケースを変更した場合。

設定@ModificationLevelしていないのでNULL、Olaのコードに見られるように残ります。

@ModificationLevel int = NULL,

もちろん、パラメータの値が@ModificationLevelでない限り、これはあなたの状況には当てはまらないようですNULL。

解決策1

その場合、私たちは犯人を見つけました。の値をに変更@ModificationLevelするNULLと、すべて問題ありません。

変換のさらなる理由

バックアップがからDIFFに変わるもう1つの理由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;

これは何を意味するのでしょうか？

オラのコードの翻訳

まあそれはこのように少し読みます：

differntial_base_lsn現在のデータベースのの値を取得します
バックアップタイプがDIFFの場合、...
- を使用して現在のデータベースの表のis_snapshot列を読み取り、バックアップは（データベースバックアップ）です。msdb.dbo.backupset@CurrentDifferentialBaseLSNtypeD
- 場合
  - @ChanageBackupType is Y`と
  - @CurrentBackupType `DIFFと
  - @CurrentDifferentialBaseIsSnapshot です 1
- 次に
  - 設定する@CurrentBackupTypeにはFULL

ここにあなたは可能な状況があります...

解決策2

...データベースがサードパーティのソリューション（CommVault、NetAppなど）によってバックアップされている場合、サードパーティのソリューションは、SQL Server VSSWriterサービスを使用して有効で一貫性のあるデータベースバックアップを作成します。msdb.dbo.backupsetデータベースのスナップショットコピーが作成されたことをメモします。これにより、DIFFの基になるis_snapshot特定のデータベースのパラメータが設定されdifferntial_base_lsnます。

このため、実行しようとしているDIFFバックアップはis_snapshotバックアップに基づくことができなくなり、新しいFULLバックアップを再度作成し、is_snapshotとのdifferntial_base_lsn値をリセットし、将来のDIFFバックアップ用の新しいベースを作成する必要があります。

他のバックアップを探す

どのサードパーティ（または他のバックアップソリューションb）が実装されたソリューションに干渉しているかを判断し、それらがいずれかであることを確認する必要があります...