Tam bir yedeklemeden sonra işlem günlüğü yedeklemesini nasıl azaltırım?

Sql Server 2005 örneğinde çalışmak üzere ayarlanmış üç bakım planım var:

• Haftalık veritabanı optimizasyonları ve ardından tam yedekleme
• Günlük diferansiyel yedekleme
• Saatlik işlem günlüğü yedekleri

Saatlik günlük yedeklemeleri, aktivite seviyesine bağlı olarak genellikle birkaç yüz Kb ile 10Mb arasındadır, günlük farklılıklar genellikle hafta sonuna kadar 250Mb'ye çıkar ve haftalık yedekleme yaklaşık 3.5Gb olur.

Karşılaştığım sorun, tam yedeklemeden önceki optimizasyonların bir sonraki işlem günlüğü yedeklemesinin tam yedeklemenin 2 katından fazla büyümesine neden olması, bu durumda 8Gb, normale dönmeden önce ortaya çıkması.

Bunun dışında BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, o günlük yedeklemesinin boyutunu küçültmenin ya da optimizasyonların işlem günlüğüne kaydedilmesini engellemenin bir yolu var mıdır, zira önceleri tam yedeklemede hesaba katılacaklardır.

Buradaki bazı ilginç öneriler, hepsi de log yedeklemelerinin nasıl çalıştığı hakkında yanlış anlaşıldığını gösteriyor. Bir günlük yedeklemesi, aradaki hangi tam veya yedeklemelerin alındığına bakılmaksızın önceki günlük yedeklemesinden bu yana oluşturulan TÜM işlem günlüğünü içerir. Günlük yedeklemelerini durdurmak veya günlük tam yedeklemeye geçmek günlük yedekleme boyutlarını etkilemez. İşlem günlüğünü etkileyen tek şey, günlük yedekleme zinciri başladıktan sonra günlük yedeklemesidir.

Bu kuralın tek istisnası, log yedekleme zincirinin kırılmış olmasıdır (örneğin, SIMPLE kurtarma modeline giderek, bir veritabanı anlık görüntüsünden geri dönerek, NO_LOG / TRUNCATE_ONLY YEDEKLEME KAYDI kullanarak günlüğü keserek), bu durumda ilk günlük yedeklemesidir. En son tam yedeklemeden bu yana tüm işlem günlüğünü içerecektir - bu da günlük yedekleme zincirini yeniden başlatır; veya log yedekleme zinciri başlatılmadıysa - ilk kez FULL'a geçtiğinizde, ilk tam yedekleme alınana kadar bir tür sahte SIMPLE kurtarma modelinde çalışırsınız.

Asıl sorunuzu yanıtlamak için, SIMPLE kurtarma modeline girmeden tüm işlem günlüğünü yedeklemeniz gerekir. Yaptığınız işlemlere bağlı olarak, boyutlarını azaltmak için daha fazla günlük kaydı alabilir veya daha fazla hedefli veritabanı yapabilirsiniz.

Yaptığınız bakım işlemleri hakkında biraz bilgi gönderirseniz, onları optimize etmenize yardımcı olabilirim. Siz, indeks yeniden yapılandırmaları tarafından kullanılan alanı geri kazanmak için shrink veri tabanının ardından endeks yeniden yapılandırmaları yapıyor musunuz?

Bakım gerçekleşirken veritabanında başka bir etkinlik yoksa, aşağıdakileri yapabilirsiniz:

• kullanıcı etkinliğinin durdurulduğundan emin olun
• son bir günlük yedeği alın (bu, bakım başlangıç ​​noktasına kadar kurtarmanıza olanak sağlar)
  • SIMPLE kurtarma modeline geçme
  • bakım gerçekleştirin - günlük her kontrol noktasında kesilecektir
  • TAM kurtarma modeline geçin ve tam yedekleme yapın
  • normal olarak devam et

Umarım bu yardımcı olur - daha fazla bilgi için bekliyorum.

Teşekkürler

[Düzenleme: tam yedeklemenin sonraki bir günlük yedeklemesinin boyutunu değiştirip değiştiremeyeceği hakkındaki tüm tartışmalardan sonra (yapamam) Kapsamlı bir blog gönderisini arka plan materyali ve kanıtlayan bir komut dosyası ile bir araya getirdim. Https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/] adresinden kontrol edin.

Onları küçültebilirsin, ama sadece yeniden büyüyecekler, sonunda disk parçalanmasına neden olacaklar. Endeks yeniden oluşturma ve birleştirme işlemleri çok büyük işlem günlükleri oluşturuyor. Zamanında kurtarılabilirliğe ihtiyacınız yoksa, Basit kurtarma moduna geçebilir ve işlem günlüğü yedeklemelerini tamamen kaldırabilirsiniz.

İyileştirmeler için bir bakım planı kullandığınızı tahmin ediyorum, yalnızca belirli bir parçalanma seviyesine ulaşıldığında ve herhangi bir performansa maruz kalmayacağınız zaman, indeks birleştirmeleri yapan bir betiği kullanmak için değiştirebilirsiniz. Bu daha küçük kütükler üretecektir.

BTW'nin günlük yedeklemelerinin lehine günlük farkları atlardım.

Son sorunuz şuydu: "TRUNCATE_ONLY'DEN YEDEKLEME KAYDI dışında, bu günlük yedeklemesinin boyutunu küçültmenin veya optimizasyonların işlem günlüğüne kaydedilmesini engellemenin herhangi bir yolu var; yedekleme onlar önce?

Hayır, ama işte geçici bir çözüm. O zamanki veritabanındaki tek aktivitenin indeks bakım işi olacağını biliyorsanız, indeks bakımı başlamadan önce işlem günlüğü yedeklemelerini durdurabilirsiniz. Örneğin, cumartesi geceleri sunucularımdan bazıları, iş programları şöyle görünüyor:

• 9:30 PM - işlem günlüğü yedeklemesi çalışır.
• 9:45 PM - işlem günlüğü yedeklemesi son kez çalışır. Program 9: 59'da duruyor.
• 22:00 - Dizin bakım işi başlar ve saat 11: 30'dan önce bitirmek için yerleşik durdurucuları vardır.
• 23:30 - tam yedekleme işi başlar ve 30 dakikadan daha kısa bir sürede tamamlanır.
• 12:00 AM - işlem günlüğü yedeklemeleri her 15 dakikada bir yeniden başlar.

Bu, saat 9:45 - 23:30 arasında zamanında geri kazanılabilirliğe sahip olmadığım anlamına geliyor, ancak geri ödeme daha hızlı performans gösteriyor.

Kolay cevap: Haftalık optimizasyon işinizi gece bazında daha dengeli çalışacak şekilde değiştirin. yani, pazar gecesi tabloları yeniden indeksleyin, pazartesi gecesi f - l'yi iyice ayarlayın ... iyi bir denge bulunsun, kütüğünüz ortalama olarak büyüklüğünün 1 / 6'sı kadar olacaktır. Tabii bu en iyi şekilde yerleşik ssis index bakım işini kullanmıyorsanız işe yarar.

Bunun dezavantajı db'nizin yaşadığı yüke bağlı olarak önemli olması, optimize edici ve sorgu planlarının yeniden kullanılması ile zarar vermesidir.

Ancak tek önemsediğiniz şey, haftalık T-log'unuzun büyüklüğü haftalıksa, günden güne veya saatten saate bölün ve aradaki t-log yedeklerini çalıştırın.

Ayrıca, yedeklemelerin ve kayıtların boyutlarını azaltmak için üçüncü taraf bir araca da bakabilirsiniz (Quest'ten Litespeed, Red Gate'ten SQL Yedekleme, Hyperbac). Kaset tasarrufunda kendileri için hızlı bir şekilde ödeme yapabilirler.

Muhtemelen "optimizasyonlarınızın" indeks yeniden yapılandırmaları içerdiği varsayılabilir. Bu görevleri yalnızca haftalık olarak gerçekleştirmek, çok fazla güncelleme ve ekleme yapılmayan bir veritabanında kabul edilebilir, ancak verileriniz çok akışkansa, birkaç şey yapmak isteyebilirsiniz:

1. Programınız izin veriyorsa ve etki kabul edilebilirse, dizinlerinizi her gece yeniden oluşturun veya yeniden düzenleyin. Bu gecelik indeks bakım görevlerini yerine getirirken, yalnızca yeniden yapılanmalar için% 30, yeniden yapılanmalar için% 15-30 aralığında bir bölüme ayrılmış olan indeksleri hedef alır.

2. Bu görevler günlüğe kaydedilmiş işlemlerdir, bu nedenle günlük büyümesiyle ilgileniyorsanız, Paul'ün önerdiği şeyi savunurum. Endeks bakımı öncesi son işlem günlüğü yedeklemesi, Basit kurtarma işlemine ve ardından bakım işlemine ve ardından Tam kurtarma işlemine geri dönme işleminin ardından Tam veri yedeklemesine geçme işlemini yapmanız gerekir.

Günlük dosyalarıma zen benzeri bir yaklaşımla yaklaşıyorum: onlar olmak istedikleri boyutta. Yaşadığım mantra olan veritabanı etkinliği ile karşılaştırıldığında, zayıf yedekleme uygulamaları nedeniyle aşırı büyümeye katlanmadıkları sürece.

İsteğe bağlı indeks bakımı yapan senaryolara gelince çevrimiçi görünün: orada bir ton var. Andrew Kelly, bir yıl önce SQL Dergisi'nde nezih bir tane yayınladı. SQLServerPedia’nın Michelle Ufford’dan bazı senaryoları var ve SQL Magazine’in son sayısında (Temmuz 2009’a inanıyorum) konuyla ilgili tam bir makale var. Önemli olan sizin için en uygun olanı bulmak ve en az özelleştirmeyle kendiniz yapmaktır.

Veritabanı optimizasyonunuz sırasında işlem günlüğünüzü çeşitli noktalarda özel olarak yedekleyebilir misiniz? T-logların toplam büyüklüğü aynı olacaktır, ancak her biri daha küçük olacaktır ve muhtemelen bir şekilde size yardımcı olacaktır.

Daha fazla hedefli veritabanı optimizasyonu yapabilir misiniz? Bir süre için belirli miktarda parçalanma veya boşa alanın tolere edilmesi gibi. Masalarınızın% 40'ı sadece% 5 oranında parçalanmışsa, onlara dokunmamak oldukça fazla etkinlik kazandırabilir.