İşlem Günlüğü Yedekleri Seri mi Paralel mi?

SQL Server 2012 Standard Edition kullanıyoruz. Yedekleme ve bakım yapmak için daha kolay ve daha esnek bir çerçeve sağlamak amacıyla Ola Hallengren'in komut dosyalarını da kullanıyorum.

Bu soru Ola'nın senaryoları hakkında çok iyi değil, aynı zamanda en iyi uygulamalardır. Nihai cevabın "şirketinizin gereksinimlerine bağlı olduğunu" fark ettim. Ancak şirketimizin gereksinimleri hakkında bildiklerimi en iyi şekilde nasıl karşılayacağına dair topluluğun tavsiyesini almaya çalışıyorum.

Her 15 dakikada bir işlem günlüğü yedeklemeleri ayarlamak istiyorum. Bu şekilde umarız 15 dakikadan fazla veri kaybetmeziz. ALL_DATABASES kullanan bir iş mi ayarlamalıyım? ya da her veritabanı için bir iş kurmak ve hepsini paralel olarak başlatmak daha mı iyi? Soruyorum, çünkü Ola'nın senaryosunun yedeklemelerin seri olarak başlatıldığını nasıl gördüğümü temel aldığım hissine sahibim. Dizinin dezavantajı, birbirini izleyen her yedeklemenin diğeri tamamlanana kadar beklemesi olacaktır. Bu, yedeklemeler arasındaki süreyi artırabilir (yani 15 dakikadan fazla). Ayrıca endişem bir yedeklemede başarısız olmanın diğerlerinin gerçekleşmesini durdurması ve durumun böyle olmasını istemememdir. Diğerlerinin yedeklemeye devam etmesini isterdim.

Öyleyse Ola'nın komut dosyalarının seri olarak yürütüldüğü ve bir arızanın art arda yedeklemeleri durdurduğu doğru mu?

Ve her veritabanı için bir iş bulmak daha mı iyi? ya da hepsini yapan tek bir iş mi? Eğilimim ayrı işlere doğru, ancak SQL Server DBA'larının genel olarak ne yapma eğiliminde olduğunu anlamak istiyorum.

ALL_DATABASES kullanan bir iş mi ayarlamalıyım? ya da her veritabanı için bir iş kurmak ve hepsini paralel olarak başlatmak daha mı iyi?

İşlem günlüklerini (seri olarak) yedekleyecek bir iş kurmanızı öneririm. Bu, aynı zamanda veritabanı için yedeklemeyi bir seferde çalıştırdığınız için yedeklemenin G / Ç'ye çok fazla yardımcı olmadığından emin olur.

Paralel koşarken olası dezavantajlar neler olabilir

1. 50 veritabanınız olduğunu ve tüm veritabanlarının işlem günlüğü yedeklemesini planladığınızı ve hepsinin paralel olarak çalışmaya başladığını varsayalım, bu kesinlikle çok fazla G / Ç kullanacaktır. Ve dosyaları yedeklediği diskte başka veri dosyaları varsa yavaşlık görürsünüz. Yedekleme işi ile birlikte I / O çok talep isteyen kötü bir sorgu yedekleme yavaş oluyor gördük.

2. Yine 50 veritabanı varsayalım SQL Server ajan 50 iş yönetmek zor olmaz ve 100-200 veritabanları varsa ne olacağını olurdu SQL Server ajan açıp çok iş gördüğünüzde ben gibi olmaz, sadece basit tut. Aynı vakanın seninle olacağından eminim.

Dizinin dezavantajı, birbirini izleyen her yedeklemenin diğeri tamamlanana kadar beklemesi olacaktır. Bu, yedeklemeler arasındaki süreyi artırabilir (yani 15 dakikadan fazla).

İşlem günlüğü yedeklemeleri çoğunlukla küçüktür ve çok sayıda günlük kaydı üreten meşgul bir veritabanınız varsa, yedekleme sıklığını değiştirmeniz gerekebilir. Çoğunlukla frekans 15 dakika olduğunda işlem günlüğü yedeklemesinin tamamlandığını gördüm. Senin için endişe konusu olacağını düşünmüyorum.

Artı endişem bir yedeklemedeki bir başarısızlığın diğerlerinin gerçekleşmesini durdurması ve durumun böyle olmasını istememem

Sadece endişelenme derim. İşlem günlüğü yedeklemeleri, hata yapmadığınız sürece başarısız olamaz. Hatalar olabilir

1. İşi çalıştıran sahip AD'den kaldırıldı

2. Birisi veritabanının kurtarma modelini değiştirdi.

3. Yetersiz disk alanı

Yukarıdakilerin dışında işlem günlüğü yedeklemesinin başarısız olması için herhangi bir neden görmedim. Güvenebileceğiniz çok sağlam.

Genel olarak, T-log yedeklerinizi daima seri olarak çalıştırın; örneklerimin çoğunda birkaç düzine veritabanı var ve bunların birçoğu çok aktif ve işlem günlüğü yedeklemeleri toplamda sadece birkaç saniye sürüyor; özellikle meşgul olduğunda yarım dakika kadar.

Yedekleri paralel olarak çalıştırmak, aşağıdaki koşulların tümü doğru olduğunda gerçekten yararlı olacaktır:

• Veritabanlarınız ve günlük dosyalarınızın tümü benzersiz bağımsız iğlerde (veya herhangi bir kombinasyonda yarıiletken disklerde)

  • Yalnızca T-log yedeklemeleri için, yalnızca günlük dosyalarının bu gereksinimi karşılaması gerekir.

• Her veritabanı için yedekleme hedefleriniz ayrı iğlerde bulunur.

• SQL Server örneği ve medya arasında paylaşılan SAN HBA veya iSCSI veya başka bir bant genişliği kullanmıyorsunuz.

• yani Veritabanı A'yı okumak ve Yedekleme A yazmaktan gelen IOPS Veritabanı B'yi okumak ve Yedekleme B yazmakla aynı diskleri KULLANMAYIN .

Tüm bunlar doğruysa, bir miktar paralellik toplam takvim süresinin miktarını azaltabilir. Tüm bunlar doğru değilse, büyük olasılıkla bir veya daha fazla disk kümesinin çöpe neden olmasına neden olur ve paralel yedeklemelerinizin her ikisi de aslında diziden daha fazla takvim süresi alır, ancak aynı zamanda işletim sistemi dosya sistemi veya depolama düzeyi parçalanmasına neden olabilir. Yedekleme A ve Yedekleme B'yi aynı anda yazıyorsunuz!

Bir yedeklemenin başarısız olduğu ve geri kalanının başarılı olduğu konusunda endişelenmeyin - herhangi bir başarısızlık varsa, yine de her şeyi kontrol etmeniz gerekir ve yedeklemelerin başarısız olduğunu gördüğüm zamanların nedeni:

• Disk hatası

• Hyperbac / Litespeed / üçüncü taraf sıkıştırma yazılımı hatası (SQL ile başarısız olan disk arasında yazılımınız varsa)

  • Uyarı olarak, hata hiç bitmeyen bir yedekleme işi biçiminde olabilir, bu nedenle uyarı gönderen "beklenenden daha uzun süre çalışan işler" için bazı kontroller yapmak değerlidir.

• Şifreleme ürünü hatası (SQL ile başarısız olan disk arasında yazılımınız varsa)

• Ağ hatası (veritabanı dosyaları veya büyük olasılıkla yedekleme dosyaları ağ üzerindeyse)

• İzinler

  • yeni yüklemelerde en yaygın olanı

  • veya yepyeni yedekleme konumları

  • SQL Server Service kullanıcısını değiştirme (normal yedekleme izinlerine ihtiyaç duyulan şeydir)

  • birden fazla SQL Server örneği tarafından kullanıldığı için SQL Server hizmet kullanıcısını kilitleme

• Yapılandırma hataları

• Güç kesintisi

• İşletim sistemi çökmesi

Yukarıdaki koşullar da karşılanmadığı sürece bunların çoğu birini etkilemez ve diğerlerini etkilemez.

Eklemek gerekirse, Ola komut dosyalarını bir veritabanı yedeklemesi hangi nedenle olursa olsun yedeklemezse, bir sonrakini dener. Daha önce de belirtildiği gibi, tüm veritabanlarını yalnızca bir veritabanı yedeklemesi başarısız olsa bile, tüm veritabanlarını yedeklediğiniz varsayılarak (bir tanesi) herkes için iş).