FULL'lere yükseltilen DIFF'ler

Question

DatabaseBackupBir SQL Server 2012 örneğindeki SharePoint veritabanlarının bir yükünü Azure blob depolamasına yedeklemek için Ola Hallengren'in saklı yordamını kullanıyoruz. Bunu uzun süredir sorunsuz bir şekilde yapıyoruz. Ancak, son 6 haftadır DIFFsrastgele terfi ediyoruz FULLve nedenini bulamıyoruz.

Bu, aracı adımının çıktısıdır

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

Oluşturulan URL'ye bir bakarsanız, prosedürlerin DIFF dizininde depolandığını, ancak bir TAM yedekleme dosyası oluşturduğunu göreceksiniz.

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

DatabaseBackup (Ola proc), 2019-06-14 tarihidir, bu nedenle adil olması için bir yükseltmeye ihtiyacı vardır, ancak 18 aydan fazla bir süredir iyi çalıştı.

Azure için sanal yol adını oluşturan küçük bir sarmalayıcı prosedürüne sahip olduğumuz için doğrudan Ola kodunu çağırmıyoruz, ancak esasen Ola'nın kodunu böyle adlandırıyoruz.

Bu, DIFF yedeklemelerinin TAM olarak yükseltilmesinin bilinmeyen bir nedenden ötürü bir sorundur; bu, her gün gigabayt yerine petabaytlarca Azure blob yedeklemesine neden olur.

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

Bunun hakkında herhangi bir fikrin var mı?

Answer 1

DIFF'den FULL yedeklemelere bu promosyonun "rastgele" olduğunu söylüyorsunuz, ancak bu aktivite ile veri karmaşası (veya indeks bakımı) arasında veritabanının kendisinde bir bağlantı bulabileceğinizi iddia ediyorum.

Kullandığınız Çünkü ChangeBackupType='Y', yedekleme işi bakıyor sys.dm_db_file_space_usage bir eşiği (ben kaynak kodundan varsayılan eşiği seçici zorluk yaşıyorum aşarsa nasıl değiştirildi veritabanının çok görmek ve yerine getirmekte olup TAM yedekleme ). ModificationLevelYüzde olan parametreyi ayarlayarak bu eşiği değiştirebilirsiniz . Gönderen dokümantasyon

ModificationLevel
Bir diferansiyel yedeklemenin tam yedeklemeye değiştirileceği zaman bir yüzde belirtin. Bu seçenek yalnızca @ChangeBackupType = 'Y' ile birlikte kullanılabilir. DatabaseBackup, bir veritabanının ne kadarının değiştirildiğini hesaplamak için, sys.dm_db_file_space_usage içindeki ayrılmış_uzuncu_sayfayı ve değiştirilmiş_uzuncu_sayfayı kontrol eder.

Answer 2

Giriş

Kodunuza baktığınızda , DatabaseBackup saklı yordamı için SQL Server Bakım Çözümünde@ChangeBackupType sağlanan Ola parametresini zaten kullandığınız görülüyor . Bu parametrenin dokümantasyonu aşağıdaki bilgileri sağlar:

DatabaseBackup differential_base_lsn, sys.master_filesbir diferansiyel yedeklemenin gerçekleştirilip gerçekleştirilemeyeceğini belirlemek için kontrol eder . Diferansiyel yedekleme mümkün değilse, veritabanı varsayılan olarak atlanır. Alternatif olarak, tam yedeklemenin gerçekleştirilmesi için ChangeBackupType değerini Y olarak ayarlayabilirsiniz.

^alakalı ... ve ...

DatabaseBackup kontroller last_log_backup_lsniçinde sys.database_recovery_statustam veya toplu günlük kurtarma modeli bir işlem günlük yedekleme yapılabilir olup olmadığını belirlemek için. İşlem günlüğü yedeklemesi mümkün değilse, veritabanı varsayılan olarak atlanır. Alternatif olarak, bunun yerine bir diferansiyel veya tam yedekleme gerçekleştirmek için ChangeBackupType'ı Y olarak ayarlayabilirsiniz.

^{ilgili değil}

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

Varsayım

Söz konusu parametreyi kullanırken ve veritabanlarınızın hepsinin TAM kurtarma modelinde çalıştığını varsayarsak, Ola'nın komut dosyalarının söylendiği gibi yapmasını ve daha önce gözlemlediğiniz gibi sadece bir diferansiyel yedekleme gerçekleştirmesini beklerim ... ..

ancak

... bir şey SharePoint veritabanlarını öyle bir şekilde değiştiriyor ki, Ola'nın prosedürü veritabanının TAM yedekleme gerektirdiğini varsayıyor. Ola, biri parametreye dayalı olan çeşitli durumları kontrol eder ...

ModificationLevel

@ModificationLevelİlk parametre @ChangeBackupType = 'Y'ayarlanırsa , DIFF yedeklemesini TAM yedeklemeye dönüştürecek ek parametre vardır . Ola'nın koduna bakmak bize şunu sağlar:

  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

Bu, parametre @ModifcationLevelbir değere @ChangeBackupTypeayarlanmışsa ve olarak ayarlanmışsa Y, yedekleme prosedürünün DIFF yedeklemesini TAM yedeklemeye dönüştüğü anlamına gelir . Değiştirilen sayfa sayısı durumu tetiklerse .

Ayarlamadığınız @ModificationLeveliçin NULL, Ola'nın kodunda görüldüğü gibi kalır :

@ModificationLevel int = NULL,

Bu kurs sizin parametrenin değeri sürece, senin durumundaki durum görünmüyor @ModificationLeveldeğil NULL.

1.Çözüm

Bu durumda suçluyu bulduk. Değeri @ModificationLevelgeri olarak değiştirin NULLve her şey yolunda.

Dönüşüm için Diğer Nedenler

Yedek gelen değiştirecek bir diğer nedeni DIFFile FULLparametredir @ChangeBackupTypekendisi.

Açıklama (yukarıdan) şu şekilde yazılmıştır:

DatabaseBackup (prosedür) differential_base_lsn, sys.master_filesbir diferansiyel yedeklemenin gerçekleştirilip gerçekleştirilemeyeceğini belirlemek için kontrol eder . Diferansiyel yedekleme mümkün değilse, veritabanı varsayılan olarak atlanır. Alternatif olarak, tam yedeklemenin gerçekleştirilmesi için ChangeBackupType değerini Y olarak ayarlayabilirsiniz.

Kodu Kontrol Etmek

Ola bunu kodda yazdı:

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

ve buradaki bölüm:

   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;

Ne anlama geliyor?

Ola'nın Kodunu Çevirme

Biraz şöyle okur:

1. differntial_base_lsnMevcut veritabanı için değerini alın

2. Yedekleme türü DIFF ise, o zaman ...

   • Oku is_snapshotsütunu msdb.dbo.backupsetile geçerli veritabanı için masaya @CurrentDifferentialBaseLSNve yedekleme typeolduğu D(Veritabanı yedekleme)
   • Eğer
     • @ChanageBackupType is Y` ve
     • @CurrentBackupType FARKLI ve
     • @CurrentDifferentialBaseIsSnapshot dır-dir 1
   • Sonra
     • Set @CurrentBackupTypeiçinFULL

Burada olası bir durum var ...

2.Çözüm

... veritabanınız üçüncü taraf bir çözüm (CommVault, NetApp, vb.) tarafından yedeklendiyse, üçüncü taraf çözüm SQL Server VSS Writer hizmetini kullanarak geçerli ve tutarlı bir veritabanı yedeklemesi oluşturacaktır. msdb.dbo.backupsetVeritabanının anlık bir kopyasının alındığına dair bir not alacaktır , bu, DIFF'inizin temel alacağı is_snapshotverilen için o veritabanı için parametreyi ayarlar differntial_base_lsn.

Bu nedenle, gerçekleştirmeye çalıştığınız DIFF yedeklemesi artık is_snapshotyedeklemeye dayalı olamaz is_snapshotve ve differntial_base_lsndeğerini sıfırlamak ve gelecekteki DIFF yedeklemeleri için yeni bir temel oluşturmak için yeniden yeni bir TAM yedekleme oluşturmalıdır.

Diğer Yedeği Bulun

Hangi üçüncü tarafın (veya başka bir yedekleme çözümününb) uygulanan çözümünüze karıştığını belirlemeniz ve bunların ikisinden birinin ...

1. birlikte var olmak için değiştirildi
2. tek bir yedekleme çözümüne indirgenmiştir.