it-swarm-tr.com

Tam bir yedeklemeden sonra işlem günlüğü yedekleme boyutunu nasıl azaltabilirim?

Bir Sql Server 2005 örneğinde çalışacak şekilde 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 genellikle etkinlik düzeyine bağlı olarak birkaç yüz Kb ve 10Mb arasındadır, günlük diferansiyeller genellikle hafta sonunda 250Mb'ye kadar büyür ve haftalık yedekleme yaklaşık 3.5'tir. Gb.

Benim sorunum, tam yedeklemeden önce yapılan optimizasyonların bir sonraki işlem günlüğü yedeklemesinin normale dönmeden önce tam yedeklemenin, bu durumda 8Gb'nin boyutunun 2 katına çıkmasına neden olduğu görülüyor.

Ondan başka BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, söz konusu günlük yedeklemesinin boyutunu azaltmanın veya optimizasyonların işlem günlüğüne kaydedilmesini engellemenin bir yolu var mı?

38
Dave

Burada, günlük yedeklemelerinin nasıl çalıştığı hakkında yanlış anlaşılmalar gösteren bazı ilginç öneriler var. Bir günlük yedeklemesi, aradaki tam veya farklı yedeklemelerin ne olduğuna 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 yedeklemelerinin durdurulması veya günlük tam yedeklemelere geçmenin günlük yedekleme boyutlarını etkilemeyecektir. Günlük yedekleme zinciri başladıktan sonra işlem günlüğünü etkileyen tek şey günlük yedeklemesidir.

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

Orijinal sorunuzu cevaplamak için, BASİT kurtarma modeline girmeden, tüm işlem günlüğünü yedeklemeniz gerekecektir. Yaptığınız işlemlere bağlı olarak, boyutlarını azaltmak veya daha hedefli veritabanı yapmak için daha sık günlük yedekleri alabilirsiniz.

Yaptığınız bakım işlemleri hakkında bilgi gönderebiliyorsanız, bunları optimize etmenize yardımcı olabilirim. Herhangi bir şans eseri, indeks yeniden yapılanmalarının ardından bir daralma veritabanı izliyor musunuz?

Bakım yapılırken veritabanında başka bir etkinliğiniz yoksa, aşağıdakileri yapabilirsiniz:

  • kullanıcı etkinliğinin durdurulduğundan emin olun
  • son bir günlük yedeklemesi alın (bu, bakım başlangıç ​​noktasına kadar iyileşmenizi sağlar)
    • sIMPLE kurtarma modeline geç
    • bakım yapın - günlük her bir kontrol noktasında kesilecektir
    • tAM kurtarma modeline geçin ve tam bir yedek alın
    • normal olarak devam et

Umarım bu yardımcı olur - daha fazla bilgi için sabırsızlanıyoruz.

Teşekkürler

[Düzenleme: tam bir yedekleme sonraki bir günlük yedeklemenin boyutunu değiştirip değiştiremeyeceği hakkında tartışma sonra (yapamaz) Ben arka plan malzeme ve kanıtlayan bir komut dosyası ile kapsamlı bir blog yazı koymak. Bunu kontrol edin https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

35
Paul Randal

Onları küçültebilirsiniz, ancak tekrar büyüyecek ve sonunda disk parçalanmasına neden olacaklardır. Endeks yeniden oluşturma ve dolandırmak çok büyük işlem günlükleri oluşturur. Zamanında kurtarılabilirliğe ihtiyacınız yoksa, Basit kurtarma moduna geçebilir ve işlem günlüğü yedeklemelerini tamamen ortadan kaldırabilirsiniz.

Optimizasyonlar için bir bakım planı kullandığınızı tahmin ediyorum, sadece belirli bir parçalanma seviyesine ulaşıldığında ve muhtemelen herhangi bir performans isabetine maruz kalmayacağınız zaman dizin defrags yapan bir komut dosyası kullanmak için değiştirebilirsiniz. Bu çok daha küçük günlükler üretecektir.

Günlük tam yedekleme BTW lehine günlük farklılıkları atlar.

5
SqlACID

Son sorunuz şuydu: "TRUNCATE_ONLY İLE YEDEKLEME GÜNLÜĞÜ dışında, söz konusu günlük yedeklemesinin boyutunu küçültmenin veya optimizasyonların kesinlikle hesaplanacağı gibi işlem günlüğüne kaydedilmesini önlemenin herhangi bir yolu var mı? çünkü tam yedeklemeden önce mi? "

Hayır, ama işte bir çözüm. Bu veritabanındaki o zamanki etkinliklerin yalnızca dizin bakım işleri olacağını biliyorsanız, dizin bakımı başlamadan önce işlem günlüğü yedeklemelerini durdurabilirsiniz. Örneğin, Cumartesi geceleri sunucularımdan bazıları, iş çizelgeleri şöyle:

  • 9:30 PM - işlem günlüğü yedeklemesi çalışıyor.
  • 9:45 PM - işlem günlüğü yedeklemesi son kez çalışır. Zamanlama 9:59 saatinde durur.
  • 10:00 PM - endeks bakım işi başlar ve saat 11: 30'dan önce bitirmek için yerleşik duraklara sahiptir.
  • 11:30 PM - tam yedekleme işi 30 dakikadan kısa sürede başlayıp bitiyor.
  • 12:00 - İşlem günlüğü yedeklemeleri her 15 dakikada bir yeniden başlar.

Bu, 9:45 ve 23:30 arasında zamanında noktaya kurtarılamadığım anlamına gelir, ancak getirisi daha hızlı performanstır.

3
Brent Ozar

Kolay cevap: Haftalık optimizasyon işinizi gece boyunca daha dengeli çalışacak şekilde değiştirin. Yani, Pazar gecesi a-e tablolarını yeniden indeksleyin, Pazartesi gecesi f-l vb. Tabii ki bu yerleşik ssis dizini bakım işini kullanmıyorsanız en iyi sonucu verir.

Bunun dezavantajı ve db deneyimlerinizin yüküne bağlı olarak önemli olduğunu optimize edici ve sorgu planlarının yeniden kullanımı ile tahribat wreaks olduğunu.

Ancak, umursadığınız tek şey t-log'unuzun haftalık olarak boyutu ise, günlük veya günlük saatlere ayırın ve aradaki t-log yedeklerini çalıştırın.

3
Jeremy Lowell

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

2
Steve Jones

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

Daha az işlem yaratıldığından daha fazla hedeflenen veritabanı optimizasyonu yapabilir misiniz (birisi bundan bahsetti, ancak sonuçların belirtildiğinden emin değilim). Belirli bir parçalanma veya bir süre boşa harcanan yeri tolere etmek gibi. Tablolarınızın% 40'ı yalnızca% 5'i parçalanmışsa, onlara dokunmamak biraz etkinlik tasarrufu sağlayabilir.

2
ErikE

Muhtemelen "optimizasyonlarınızın" dizin yeniden oluşturmalarını içerdiği varsayılabilir. Bu görevleri yalnızca haftalık olarak gerçekleştirmek, çok fazla güncelleme ve ek ile karşılaşmayan bir veritabanında kabul edilebilir, ancak verileriniz çok akıcıysa, 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 dizin bakım görevlerini gerçekleştirirken, yalnızca yeniden yapılandırmalar için% 30'un ötesinde ve yeniden yapılanmalar için% 15-30 aralığında parçalanan dizinleri hedefleyin.

  2. Bu görevler kaydedilmiş işlemlerdir, bu yüzden günlük büyümesi konusunda endişeleriniz varsa, Paul'ün önerisini savunurdum. Dizin bakımı öncesinde son işlem günlüğü yedeklemesi, Basit kurtarma'ya, ardından bakım işlemine geçin ve ardından Tam kurtarma'ya geçin ve ardından Tam veri yedekleme işlemi hile yapmalıdır.

Günlük dosyalarıma zen benzeri bir yaklaşım uyguluyorum: onlar olmak istedikleri boyutta. Yaşadığım mantra olan veritabanı etkinliğine kıyasla zayıf yedekleme uygulamaları nedeniyle yetersiz büyümeye dayanmadıkları sürece.

İsteğe bağlı dizin bakımını yapan komut dosyalarına gelince çevrimiçi görünün: orada bir ton var. Andrew Kelly yaklaşık bir yıl önce SQL Magazine'de iyi 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 de var. Önemli olan sizin için iyi çalışan bir tane bulmak ve minimal özelleştirmelerle kendiniz yapmaktır.

2
Tim Ford