Bir diferansiyel yedekleme neden tabanını belirleyemiyor?

Bu benim ilk DBA.SE yazım, bu yüzden lütfen herhangi bir hata hakkında bana bilgi verin, teşekkürler!

Ben yeni bir DBA (BT uzmanı değil, şirkette bunu yapacak başka kimse yok), bu yüzden açıklama ne kadar basitse o kadar iyi olur. Ben veritabanı yedekleme stratejileri hakkında okuyorum (ya da, onları "geri yükleme stratejileri" olarak adlandırmayı öğrendim gibi). Ben Tam Diferansiyel ve İşlem Günlüğü yedekleri ne anlıyorum, ama bilmek istiyorum neden bir değişiklik yedeği yalnızca en son tam yedekten dayandırılabilir.

Bir diferansiyel yedekleme son tam yedeklemeden bu yana değişen her şeyse, neden diferansiyel seçimimin herhangi bir yedeğine dayanamıyor? Daha açık olmak gerekirse , geri yükleme sırasında değil , yedekleme alındığında temel belirtmek istiyorum . Geri yüklerken, geri yüklemeyi gerçekleştirmek için doğru tabanı ve karşılık gelen diferansiyeli seçeceğinizi varsayıyorum (A tabanından geri yüklemek için B tabanından yapılmış bir diferansiyel kullanmamak).

Bu işlevselliğin mümkün olmasını engelleyen neden nedir? Bir sebep olması gerektiğini anlıyorum, sadece ne olduğunu bilmiyorum.

Not: Bazın belirtilemediğini anlıyorum, ama sorum neden olmasın ? ("Neden yaptın?" Konusundaki tartışmalarla da ilgilenmiyorum.)

analoji

İşte diferansiyel yedeklemeyi nasıl anladığımın bir benzetmesi:

Hücrelerde bazı veriler içeren bir Excel dosyası var.

1. günde bu dosyanın bir kopyasını alıp başka bir yerde saklıyorum ("tam yedekleme").

2. günde, dosyaya bakıyorum ve 1. günde yaptığım yedek kopyayla karşılaştırıyorum ve değişen tüm hücreleri ve yeni değerlerinin ne olduğunu not ediyorum ("diferansiyel yedekleme"). Bir hücrede yapılan her değişikliği değil , yalnızca son değerinin ne olduğunu not ediyorum . A1 hücresi "Alfred" olarak başladıysa, "Betty", "Charlie", sonra "Dave" olarak değiştirildiyse, sadece "A1 artık Dave" olarak dikkat çekerdim.

3. günde, geçerli dosyayı yedekleme dosyasıyla tekrar karşılaştırırım ve değişiklikleri not ediyorum (2. günle aynı tabanla başka bir "diferansiyel yedekleme"). Yine, gözlemlenen zamanda sadece hücre başına son değerleri not etmek, hücrenin gün boyunca sahip olduğu tüm değerleri değil.

4. günde tekrar karşılaştırırım ve değişiklikleri tekrar not ederim. A1 hücresiyle devam ederken, gün boyunca 10 başka isim olsa bile şimdi "Sarah" yazıyor ve tek not ettiğim "Şimdi A1 Sarah'dır".

5. günde dosyam dağılıyor; bu yüzden, 1. günde yaptığım yedek kopyaya bakıyorum, sonra 4. günde belirtilen son durumlar ve yedek kopyaya not edilen değişiklikleri uyguluyorum ve şimdi dosyayı 4. günde olduğu gibi "geri yükledim" Böylece, 1. günde yapılan yedeklemeye bakıyorum, 4. günde A1 hücresinin "Sarah" olarak sona erdiğini görüyorum ve yedek hücreyi A1 "Sarah" olarak değiştirdim.

2. günde dosyanın başka bir yedek kopyasını ("dolu") yapsaydım neden önemli olurdu? 3. veya 4. günde dosyayı 1. günde yapılan kopyayla karşılaştırmak (okumak, "farklı bir yedeğini almak") neden hala mümkün olmaz? Anladığım kadarıyla, SQL Server (başka bir yedek alındığında) 2. günde yapılan tam bir yedekleme ile karşılaştırmamı gerektirir (eğer yapılmışsa) - başka bir seçenek yok.

Bir diferansiyel yedekleme , son tam yedeklemeden bu yana değiştirilen sayfaların listesini oluşturmak için diferansiyel değişiklik haritası olarak adlandırılanı kullanır . Bu liste bir "diferansiyel" listedir, bu nedenle yedekleme türünün adı ve yedeklemenin yalnızca ilişkili tam yedeklemenin üzerine geri yüklenmesinin nedeni.

Tam yedekleme yapılması diferansiyel değişiklik haritasını sıfırlar. Bu noktadan sonra, değiştirilen tüm sayfalar haritaya kaydedilir. Daha sonra bir diferansiyel alırsanız, bu yedekleme yalnızca son tam yedeklemeden bu yana değiştirilen ve haritaya kaydedilen sayfaları içerir.

Analojinizde, tüm geri yükleme işlemi için bir temel görevi gören iki tam yedek muhtemelen farklı içeriklere ve dolayısıyla farklı diferansiyel haritalara sahip olacaktır. Farkı ikinci yedeklemedeki ilk yedeklemeye göre geri yüklerseniz, veritabanı büyük olasılıkla bozulur. Aslında, SQL Server, dayalı bir tam yedeklemenin temel aldığı orijinal tam yedeklemenin dışında bir şey üzerine geri yüklemeyi engeller.

SQL Server'dan bir diferansiyel yedekleme almasını istediğinizde, diferansiyel için tek "temel", diferansiyel yedeklemenin başladığı anda veritabanında bulunan tek diferansiyel değişiklik haritasıdır. Bu nedenle, diferansiyel yedeklemenin tabanını belirleyemezsiniz.

@MartinSmith bir yorumuna cevaben - Kullanmak mümkün olabilir COPY_ONLYyedekleri tam yedeklemeler bir dizi üzerinde farklı bir yedekleme geri yükleme. Aşağıdaki senaryoyu düşünün:

1. BACKUP DATABASE xyz TO DISK = 'path_to_backup.bak';
2. BACKUP DATABASE xyz TO DISK = 'path_to_backup_2.bak' WITH COPY_ONLY;
3. BACKUP DATABASE xyz TO DISK = 'path_to_backup_3.bak' WITH COPY_ONLY;
4. BACKUP DATABASE xyz TO DISK = 'path_to_backup_4.bak' WITH COPY_ONLY;
5. BACKUP DATABASE xyz TO DISK = 'path_to_backup_diff.bak' WITH DIFFERENTIAL;

5. adımdaki diferansiyel yedekleme, 1. ila 4. adımlarda alınan yedeklerden herhangi biri üzerine geri yüklenebilmelidir, çünkü diferansiyel değişim haritası yalnızca 1. adımdaki tam yedekleme gerçekleştiğinde temizlenir. COPY_ONLYAdım 2, 3 ve 4'te yedeklemeler, do not değişikliği harita sıfırlayın. Diferansiyel değişiklik haritası tam yedeklemeden bu yana yapılan değişiklikleri biriktirdiğinden , birbirini izleyen COPY_ONLYyedeklemelerin her biri, önceki yedeklemelerin herhangi birine karşı çalışması için diferansiyel yedeklemenin yeterli bilgisi içerir .

Çalışması gerektiği gibi görünse de, pratikte, bir copy_only yedeklemesinin üzerine bir diferansiyelin geri yüklenmesi aşağıdaki hataya neden olur:

Msg 3136, Seviye 16, Durum 1, Hat 1
Veritabanı doğru önceki durumuna geri yüklenmediği için bu diferansiyel yedekleme geri yüklenemez.
Msg 3013, Seviye 16, Durum 1, Satır 1
VERİTABANI GERİ YÜKLE anormal olarak sona eriyor.

Diferansiyel ve copy_only geri yüklemelerini test etmek için bir SQL Server 2012 platform repro oluşturdum ve dosyayı gist.github.com'a kaydettim - UYARI komut dosyası RestoreTest, ilk adımı olarak adlandırılan herhangi bir veritabanını bırakacaktır .

İstediğiniz özellik prensipte var olabilir . Mevcut veritabanı yapıları ile verimli olmazdı (Max Vernon'un cevabına bakınız). SQL Server, bir dizi farklı eşleme bulundurmalı veya geçerli DB içeriğini temel olarak belirttiğiniz tam yedeklemeyle karşılaştırmalıdır.

Büyük dosyaları tekilleştiren uygulamalar vardır. İki tam yedekleme yapabilirsiniz ve yalnızca değiştirilen veriler saklanacaktır. Bu, özel tabana sahip bir fark gibidir. exdupeörneğin bunu yapabilir.

Bununla ilgili güzel bir şey, herhangi bir yedekleme dosyası kümesiyle birlikte çalışmasıdır. Aslında 3. tam yedekleme dosyası ile başlayarak sadece artımlı (fark değil) alan kullanımı ödersiniz . Alan kullanımı, önceki yedekleme dosyası (ilk dosya ile değil) arasındaki farktır . Veri tekilleştirmenin depolanması benzer davranışa sahiptir.

Açıkladığınız özellik neden mevcut değil? Her özellik bütçeyi tüketir ve diğer özelliklerin bulunmamasına neden olur. Görünüşe göre bu öncelik listesinde yeterince uzağa gitmedi. Ne için iyi olacağından emin değilim. Özel üsleri kullanmak için oldukça ezoterik bir gereklilik gibi görünüyor.

İşlem günlüğü yedeklemelerini farklı yedeklerle karıştırmayın, farklı amaçları vardır! "Hücrelerde yapılan tüm değişiklikleri not ettiğiniz" gibi bir "diferansiyel yedekleme" olarak adlandırdığınız şey aslında bir işlem günlüğüdür .

Farklı bir yedeklemenin amacı, yalnızca son tam yedeklemeden bu yana değişen bilgileri kaydederek elde edilen yedekleme dosyasının boyutunu küçük tutmak ve geri yükleme süresini kurtarma süresi hedefiniz (RTO) içinde tutmaktır.

Bir işlem günlüğü yedeklemesinin amacı, işlemleri keyfi bir noktaya kadar tekrar oynatmanıza izin vermektir - genellikle, ancak mutlaka "en son gerçekleşen her şeyi " yapmak zorunda değildir .

Bahsettiğiniz şey aslında mümkündür - ancak tam yedeklemeyi geri yüklemeniz ve ardından işlem günlüklerini geri yüklemeniz gerekir.

1. gün tam yedeklemenize ve 1. ve 5. gün arasında tüm işlem günlüğü yedeklemelerine sahipseniz, 1. gün yedeklemesini geri yüklemenizi ve 4. günde olduğu gibi verileri elde edene kadar işlem günlüğünü yeniden oynatmanızı engelleyen hiçbir şey yoktur. Ayrıca, daha az sayıda işlemi yeniden oynatacağınız için geri yüklemenin biraz daha hızlı olacağı 2. gün yedeklemesinden başlayabilir. Ayrıca 1. gün tam yedeklemesini, 3. gün diferansiyel yedeklemesini geri yükleyebilir ve ardından işlem günlüklerini 4. güne geri yükleyebilirsiniz.

Düzenleme: Tamam, düzenlenmiş benzetmeniz biraz daha mantıklı. O zaman cevap "işlem günlüğü yedeklemeleri ile istediğinizi zaten başarabildiğiniz için" dir. Bir diferansiyel yedekleme, bir dizi işlem günlüğü etkinliğini kaydetmenin sadece ucuz ve kullanışlı bir yoludur. Bir işlem günlüğü yedeklemesinin sunmadığı herhangi bir veri kurtarma ayrıntı düzeyi sunmaz. Bir ürün haline getiren "sadece kolaylık" sağlayan çok fazla özellik var.

Excel ile benzetme yapmak elma ve portakalları karşılaştırmaktır. Neden ? Veri bütünlüğü olmadığından Excel bir veritabanı değildir. Excel oldukça güzel bir elektronik tablo uygulamasıdır ve veritabanını tamamlayabilir.

SQL Server, tüm verilerinizi saklamanızı ve bunları sorgulamak için bir mekanizma sağlayan ilişkisel bir veritabanı sistemidir. Veri bütünlüğü (ACID özellikleri) ile birlikte veri ilişkisi önemli olduğundan, önemli kısım "İlişkisel" dir.

Temel Bilgiler:

Veritabanındaki veriler, kullanıcı tarafından görülebilen mantıksal bileşenler (tablolar, görünümler, procs, tetikleyiciler vb.) Şeklinde düzenlenmiştir. Bir veritabanı en azından fiziksel olarak diskte iki (veri ve günlük dosyası) veya daha fazla (ikincil veri dosyası) dosyası olarak uygulanır.

• Bir veritabanı, kayıtları saklamak için kullanılan temel veri depolama birimi olan sayfa içerir .
• Bir veritabanı sayfası, bir veritabanı veri dosyasının 8192 baytlık (8KB) ​​bir parçasıdır.
• Bir veritabanı dosyasındaki 8 fiziksel bitişik sayfa (8 * 8KB = 64KB) bir kapsam oluşturur .
• Bir IAM (Dizin Atama Haritası) sayfası, tek bir dosyada 4 GB sınırına hizalanmış yaklaşık 4 GB değerinde alanı izler. Bu 4 GB'lık parçalara GAM aralıkları denir .

neden bir diferansiyel yedeklemenin yalnızca en son tam yedeklemeye dayandırılabileceği. - veya - Bir diferansiyel yedekleme son tam yedeklemeden bu yana değişen her şeyse, neden diferansiyel seçimimin herhangi bir yedeğine dayanamıyor?

Excel hakkındaki benzetmenize dayanarak, yaptığınız şey öncekine değişenleri uygulamaktır. Bu işlem günlüğünden taahhüt edilen tüm işlemleri uyguluyor with STOP AT(not: 5. günde dosya bozulur ve 4. günde durursunuz)

Her veri dosyasının her 4 GB bölümünde (GAM aralığı olarak adlandırılır), son 4 yedeklemeden bu bölümün hangi bölümlerinin (uzantılar olarak adlandırılır) değiştiğini izleyen ve değişen verileri gösteren farklı bitmap adı verilen özel bir veritabanı sayfası vardır. veritabanına eklendi.

Farklı bir yedekleme, bu bitmap'leri tarar ve yalnızca değiştirilmiş olarak işaretlenen veri dosyası uzantılarını yedekler. Bitmap'ler bir sonraki tam yedeklemeyle sıfırlanır (bu nedenle, farklı bir yedekleme yalnızca en son tam yedeklemeye dayanabilir ) , böylece veritabanının gittikçe daha fazla değiştikçe, daha fazlasının diferansiyel bitmaplerde işaretleneceğini görebilirsiniz. ve ardışık diferansiyel yedeklemeleri daha büyük ve daha büyük olacaktır.

Bu komut dosyasını, son tam yedeklemeden bu yana veritabanının ne kadar değiştiğini bulmak için de kullanabilirsiniz. .

Diferansiyel taban bilgisi masterveritabanında saklanır - sys.database_fileveya ( sys.master_files- veritabanı salt okunur veya çevrimdışı olduğunda faydalıdır).

Diferansiyel tabanla ilgili bilgileri depolayan 3 önemli sütun vardır .

• differential_base_lsnDiferansiyel yedeklemeler için bir başlangıç noktasıdır. Daha sonra değiştirilen veri uzantıları differential_base_lsn, diferansiyel yedeklemeye dahil edilir.
• Bu differential_base_guid, farklı bir yedeklemenin dayandığı temel yedeklemenin benzersiz tanımlayıcısıdır .
• Karşılık differential_base_timegelen zamandırdifferential_base_lsn

Farklı veritabanları ya da işlem günlüğü yedeklemelerinin geri yüklenmesi hacminin büyük olması nedeniyle daha sık tam yedeklemeler yerine, RTO'yu (Kurtarma Süresi Hedefi = Veritabanınızı kurtarmak için gereken süre) hızlandırmak için farklı bir yedekleme yararlıdır. zaman dilimi içinde.

Not: COPY_ONLY tam yedekleme diferansiyel tabanını sıfırlamaz, bu nedenle COPY_ONLY yedekleme diferansiyel taban işlevi göremez.

Referanslar :

• Bir sayfanın anatomisi
• Bir kaydın anatomisi
• SQL Server Yedeklemelerini Anlama