İşlem günlüğünüzü yedeklemek neden bu kadar önemlidir?

Şu anda bir istemci için bir yedekleme çözümü uyguluyoruz ve ERP çözümü SQL Server kullanıyor.

ERP çözümü farklı bir şirket tarafından kuruldu. Ve onlar bunu yedeklemek ve işlem günlüğü kesilemiyor süper önemli olduğunu söylüyorlar.

Bu işlem günlüğünde biraz okudum ve zaten zaten tüm makineyi yedeklerken neden bu kadar önemli olduğunu anlamıyorum (SQL Server'ın farkında olan ve kullanan ArcServe UDP kullanıyoruz VSS). Anladığım kadarıyla SQL Server VM'deki temizleme görevleri zaten günlüğü kısaltmaya özen gösteriyor, ancak UDP aynı zamanda SQL Server günlük kesmesine de izin veriyor.

Anladığım kadarıyla işlem günlüğü bozuk veritabanlarını geri yüklemek için kullanılabilir, çünkü tüm işlemlerin bir günlüğüdür. Ama zaten tüm veritabanının saatlik bir yedek var, bu yüzden neden umurumda?

Bunu yalnızca DB Kurtarma Modunuz "tam" olarak ayarlanmışsa yapmanız gerekir. "Basit" olarak ayarlanmışsa, işlem günlüğünün yedeğini almanız gerekmez. Ancak bu iki seçenek arasındaki farka dikkat edin!

Her şeyden önce: DB'yi belirli bir zamana geri yükleyebilmek istiyorsanız, "tam" modunu kullanmanız gerekir. (Zamanlama o kadar doğru ayarlanabiliyor ki geri yükleme noktası için milisaniyeyi bile belirleyebilirsiniz) "Basit" modda yalnızca son tam yedeklemeye geri dönebilirsiniz .

İşlem günlüğünüzü yedeklemez / kesmezseniz, tüm zaman boyunca büyür (tam modda). .Trn dosyasının veritabanının kendisinden iki kat daha büyük olduğu veritabanlarını gördüm. Bu, DB'de ne sıklıkta değişiklik yapıldığına bağlıdır.

Başka bir nokta, bir günlük yedeklemesinin normalde tam bir yedeklemeden daha hızlı olmasıdır.

Bu yüzden her saat tam bir yedekleme yapmak için yedekleme planınızın uygun olmadığını düşünüyorum. Ancak durumunuza bağlıdır:

Eğer derseniz: DB'yi son tam saate geri yükleyebilirsem, her şey yolunda. -> Her saat tam yedeklemeyi tutmak istiyorsanız kurtarma modunu "basit" olarak ayarlamayı da düşünebilirsiniz.

Bence, sabahın erken saatlerinde tam bir yedekleme yapmak ve daha sonra her saatte bir işlem günlüğü yedeklemesi yapmak daha iyi bir fikir olacaktır. Çok daha hızlı olmalı ve istediğiniz herhangi bir zamana geri yükleyebilirsiniz. Ve ayrıca .trn dosyanız çok fazla büyümeyecek ...

Bu yardımcı olur umarım.

İyi. Kurtarma modelinizi tam olarak ayarladıysanız ve İşlem Günlüğünü SQL'in yedeklemesini (sunucu yedeklemesini değil) kullanarak yedeklemezseniz, işlem günlüğü kullanılabilir tüm disk alanını tüketene kadar büyümeye devam eder. (Bir keresinde küçük bir meslektaşımın sistem sürücüsüne SQL Server'ı yüklediğini ve işlem günlüğünü asla yedeklemediğini gördüm. Windows'u yedi .)

Evet, aynı zamanda belirli bir zaman dilimine de geri dönecektir. Dakika kadar. Twinkles'in dediği gibi, evet, insanlar masaları ve benzerlerini bırakırlar.

Tüm veritabanının saatlik yedeklenmesi için ne kullandığınızı ve tüm makine için kullandığınız ürünle aynı ürün olup olmadığını bilmiyorum. Öyleyse, SQL uyumlu olmayan bir yedekleme çözümü geri yüklemeler için desteklenmez. VSS'nin MDF ve LDF dosyalarını kopyalaması için geçen süre, örneğin dahili bir zaman damgası uyumsuzluğuna neden olabilir.

Birkaç ERP sistemini de yönetiyoruz. Ve sorun genellikle geceleri verileri diğer sistemlerle senkronize eden uzun süren toplu işlerin olmasıdır. Ve bazen bir saat veya daha fazla zaman alırlar. Dolayısıyla, bir çökme durumunda yapmak istediğiniz şey, tutarlı verilerinizin olduğu bir noktaya atlamaktır. (Bu, iki toplu iş arasında tam anlamıyla demektir.) Yalnızca saate bakarsanız, şu anda veri tabanının durumunun tam olarak ne olduğunu tam olarak bilemeyebilirsiniz.

Ama tabii ki duruma bağlı. Otomatik işleriniz vb. Yoksa, saatlik yedeklemeyle tamamen iyi olabilirsiniz.

Bunu yapmak istemenizin birkaç nedeni vardır:

1. Bir veritabanı sistemi genellikle meşgul, belki saniyede binlerce işlem yapıyor. Veriler, farklı dosya sistemlerindeki birkaç dosyaya dağıtılabilir. Geri yükledikten sonra veritabanının tutarlı (aka kullanılabilir) durumda olduğundan emin olmak önemsiz değildir. Yedekleme çözümünüz göreve hazırsa, harika, ancak işinizi üzerine bahis yapmadan önce bundan emin olmanız daha iyi olur.
2. Bir örnek: Birisi yanlışlıkla önemli veriler içeren bir tablo bırakır. Zamanında kurtarma özelliğine sahip bir veritabanı yedeklemeniz varsa, tüm sistemi geri yüklemek zorunda kalmadan verileri hızlı bir şekilde geri yükleyebilirsiniz.
3. Veritabanı tam kurtarma modundaysa, SQL Server'ın işlem günlüğü büyür. İşlem günlüğündeki depolama alanı yalnızca işlem günlüğü yedeklendiyse yeniden kullanılır. İşlem günlüğünü düzenli olarak yedeklemezseniz, boş alan kalmayıncaya kadar dosya sisteminiz dolar. Yeni bir işlem başlatılamayacağından, bu noktada her şey hemen durdurulacaktır .

Veritabanınız bir saat içinde yedekleyebileceğinizin ötesine geçtiğinde farklı bir modele ihtiyacınız vardır.

Veritabanınızın tam bir yedeği günlüklerinizi keser, ancak "SQL farkında" olması gerekir, çünkü bu senaryoda SQL sunucusuna neyi yedeklediğini ve neyi keseceğini söyleyen yedekleme yazılımıdır.

Diğerlerinin de belirttiği gibi, "Tam" kurtarma modelinde bir veritabanınız varsa, tam SQL uyumlu bir yedekleme yapana kadar işlem günlüğü süresiz olarak büyür.

Kurtarma , burada Yedekleme değil, gerçekten sorun. Ve bu teknik bir karar değil, bu bir ticari karar!

İşletme sahipleriniz, veritabanı işlemlerini bir saat veya daha fazla kaybetme konusunda sorun yaşıyorsa (yeniden yapmak çok zor veya imkansız olabilir!) Modeliniz çalışır. Tüm veritabanını yedeklemeden geri yüklerken sistem saatlerce çalışmıyorsa sorun olmazsa, modeliniz çalışır.

Ancak, işletmeniz ERP sistemini operasyonları için kritik bir varlık olarak görürse (hepsi değil mi?), Kritik hizmetleriniz için kabul edilebilir bir maksimum kurtarma süresi (RTO, Kurtarma Zamanı Hedefi olarak da bilinir) belirlemek bir iş kararı olacaktır.

Ayrıca, işletme sahiplerinin veya sistem paydaşlarının bir olayda ne kadar veri kaybetme riski taşıyacaklarını, yani RPO (Kurtarma Noktası Hedefi) tanımlamaları gerekir.

Onlara sorarsanız cevap "HİÇBİR veri kaybedilemez! ERP sistemi 24/7/365 mevcut olmalıdır!" Olabilir ... ki hepimizin bildiği gibi maliyet etkin olma olasılığı düşüktür. Onlara böyle tamamen gereksiz, kesintisiz bir sistem inşa etmenin maliyetini sunarsanız, daha makul bir rakam ortaya çıkarırlar;;)

Mesele şu ki, herhangi bir işlemi kaybetmekten kaçınabilirseniz, işinizi potansiyel olarak yüzlerce veya binlerce çalışma saatinden tasarruf edersiniz. Herhangi bir şirkette BÜYÜK tasarruf anlamına gelir ve şirketinizin büyüklüğü ile büyür ...

Herkesin buna büyük tepkileri vardı, ama bir veya daha önemli bir not daha eklemek istiyorum.

SQL Server kurtarma modellerinin ayrıntılarını ve veri kaybı için iş gereksinimlerinizi bilmek çok önemlidir; ancak, bu durumda, yedek ürününüzün SQL Server ile nasıl çalıştığını anlamanız zorunludur. (Yukarıdaki yorumlara dayanarak, disk birimlerini VSS kopyası ile yedekliyorsunuz gibi görünüyor, bu da SQL Server yedeklemelerinin ek olarak gerekli olup olmayabileceği anlamına geliyor.)

Son zamanlarda benzer bir ürünü değerlendirdikten sonra, sormanız gerekebilecek bazı önemli noktalar şunlardır:

• Tam kurtarma bir veritabanı için zaman içinde bir noktaya geri yükleme nasıl yapılır?
• Tam kurtarmada yeni bir veritabanı için ilk yedekleme nasıl ele alınır?
• Yedekleme ürünü, belirli bir zamana geri yüklemek için SQL Server günlük yedekleri gerektiriyor mu? (Benim durumumda, cevap evetti.)
• Depolama altyapınız, normal SQL yüküne ek olarak VSS kopyaları / diferansiyelleri (belirli bir aralıkta) için veri hacmini işleyebilir mi?

Umarım bu yardımcı olur.

Ekibimin son değerlendirmemizdeki deneyimi, yukarıdaki sorulara çok ilginç cevaplar verdi. Kesin olan bir şey, VSS yedek ürünüyle yedeklemelerin bizim için daha karmaşık olmasıdır.

Diğerlerinin söylediği gibi, VM'yi veya depolamayı yedeklemek / anlık görüntü almak için üçüncü taraf bir araç kullanıyorsanız, geçerli bir yedek almama riskiyle karşı karşıya kalırsınız. SQL Server yedeklemelerini yöneten tüm üçüncü taraf araçları, VSS kullanarak SQL Server'ı uygulayacak ve bağlanacaktır. Bu, SQL Server'ın tüm I / O'yu veri dosyalarına sınamasını istemek için yapar, böylece tutarlı bir anlık görüntü alınabilir. Değilse, çeşitli eyaletlerde birçok işlem yapabilirsiniz ve geri yükleme, bu işlemlerin ileri veya geri alınabileceğini bilemez.

Orada her üçüncü taraf VM / Depolama anlık görüntü aracı ile çalışmadım, ancak birlikte çalıştığım olanlar Sistem Veritabanlarının bulunduğu yerde anlık görüntü yakalayamadı - SQL Server bu veritabanlarını sorgulayamıyor. TÜMÜNÜ bu veritabanlarını akışlı bir şekilde yedeklediler - yani ... YEDEKLEME VERİTABANI komutlarını vermek ve ardından yedekleme dosyasının kendisini yapıştırmak.

Hepsinden önemlisi, birçoğunun da söylediği gibi, TAM kurtarma modelindeyseniz ve BACKUP LOG deyimlerini düzenli olarak yayınlamıyorsanız, diskte yer kalmayıncaya kadar işlem günlüğü büyümeye devam edecektir.

Sorulması gereken gerçek soru, ve yukarıda kaçırmış olabilirim ... Bu yedeklemelerden birkaç kez başarıyla geri yüklediniz mi ve bu geri yüklemelerdeki verilerin tutarlılığından memnun musunuz? Kişisel olarak, bu benim için yeterli olmayacak olsa da, hala bir zar gibi hissediyor ve bu iyi bir DBA'nın yedekleme ve kurtarma söz konusu olduğunda asla almadığı bir şey.

İşlem günlüklerinin yalnızca bir kurtarma mekanizması olmadığını unutmayın. Uygun günlük bakımı, genel veritabanı performansında da önemli bir rol oynayabilir (yani, işlem hacmi).

Günlük dosyalarınızı sık sık yedeklemek birkaç şey yapar:

1. Performans için iyi olan fiziksel günlük dosyalarındaki VLF sayısını azaltır.
2. Bir veritabanını kurtarmanız gerektiğinde günlük yedeklerini kullanmaya daha hazırsınız demektir.
3. Tam bir yedeklemeden biraz daha hızlı

Saatte bir tam yedekleme yapmaktan kurtulabilirseniz, daha sık günlük yedeklemelerinden ne kadar faydalanacağınızdan emin değilsiniz. Sonuçta anladığım kadarıyla tam bir yedekleme, tam bir geri yükleme sağlamak için gerektiği kadar günlük yedekleyecektir.

Öte yandan, uygulamanız saatlik tam yedeklemeler arasında tonlarca işlem oluşturuyorsa, orijinal geliştiricilerin neden daha ayrıntılı günlük bakımı önerdiğini açıklayabilir. Birçok işlem, günlüklerinizdeki VLF sayısını artırabilir ve bu da günlük kesilene kadar performans cezasına neden olabilir. Bu bir uygulama içinde bir 'sorgu zaman aşımı süresi doldu' hatası olarak ifade gördüm (kısa bir süre önce asılı).

İşlem günlüğü bakımı ile ilgili öneriler bu makalede çok iyi açıklanmıştır. 8 Daha İyi İşlem Günlüğü Çıkışı Adımları . Ayrıca, bu makalede Etkili Veritabanı Bakımı için En İyi İpuçları , benim için çok iyi çalışan (<200) için biraz keyfi bir VLF sayımından bahsetmektedir.

Diğer insanlar bir translog yedekleme vb. Nedenlerinin çoğunu zaten vermişlerdir. Sunucuyu zaten yedeklediğinizde bunun neden iyi bir strateji olduğu konusunda bazı şüpheler var gibi görünüyor.

Benim için yukarıda olmayan birkaç iyi neden ortaya çıktı. 3. taraf uygulamanız geri yükleyebileceğiniz bir yedek almazsa ne olur? Yedeklemenizi geri yüklemeye çalıştınız mı? Şablonlarınızdan yeni oluşturduğunuz yeni bir sunucuya ne dersiniz (DR düşünün)? Alan adınızdaki farklı harmanlama içeren başka bir sunucuya ne dersiniz? veya SQL örneği?

Bazen üçüncü taraf uygulamanızın en hızlı geri yükleme yolu olmadığı için gereksiz yedekler alıyorum. Bazen 3. taraf uygulamanızın kaydettiği depolama alanı da etkilenir veya kendi nedenleriyle bozulur.