10-20 SQL Server veritabanını senkronize bir duruma geri yükleme ve geri yükleme?


15

10-20 SQL Server 2008 R2 veritabanlarını 10-50 GB arasında boyutlarda yedeklemem gerekiyor, çevrimiçi olmaları ve aynı anda tek bir kurumsal uygulama tarafından kullanılmaları gerekiyor. Ayrıca tüm veritabanları arasında büyük ölçüde senkronize olan bir duruma geri yüklemem gerekiyor (veritabanları arasında birkaç saniye desync'e kadar para ödeyebilirim). Amaç KG / DEV ortamları için üretim verilerini yakalamaktır.

Veritabanlarının tam kurtarmada çalışmasını istemiyorum ve KG ortamları için veri yakalamaya adanmış ve kontrolüm altında olmayan bir ana yedekleme işleminden bağımsız kalan bir yedekleme yöntemi bulmak istiyorum.

Müşterilerim için, her biri ~ 30 GB'de 20 tam yedek yakalamak 1-2 saat sürecek. Bu, veritabanlarının basit kurtarma işleminde çalışırken çok zaman uyumsuz olacağından, tam yedeklemelerin ardışık olarak kabul edilemez olmasını sağlar.

Bunlardan daha iyi bir fikir arıyorum:

IDEA 1: VM disklerinin SAN düzeyinde anlık görüntüsü. anlık görüntüden MDF / LDF xcopy.

Kopyalanan dosyalar farklı bir sunucu örneğine eklendikten sonra, kurtarma işlemi aynı anda anlık görüntü olan tutarlı veritabanları üretmelidir.
Etrafta dolaşmak bu beni kötü bir fikir olduğuna inandırdı, çünkü en azından desync'e karşı master / msdb / etc alabilirim.

IDEA 2: Tüm veritabanlarında karmaşık bir yedekleme ve senkronizasyon geri yükleme düzenleme

Bu benim istemiyorum veritabanları tam kurtarma çalıştırmak talep zorlu gerektirir. Tüm veritabanları için son tarihten çok önce paralel yedeklemeler başlatın (T0). T0'a ulaşıldığında, tüm günlükleri yedekleyin (en fazla birkaç dakika sürmelidir). Ortaya çıkan sayısız yedeklemeyi alın ve veritabanlarında T0'a göre biraz tutarlı bir durum elde etmek için bunları geri yüklemeye ve günlükleri ileri / geri almaya çalışın.
Bu, güvenilir bir şekilde kullanılması için çok fazla planlama ve komut dosyası gerektirir, bu yüzden önlemek için büyük uzunluklara giderdim.

Başka bir çözümü özlüyor muyum?

PS1: Ben db anlık görüntüleri kullanmak isterdim . Fikir, her db üzerinde bir anlık görüntü başlatmak (saniyeler içinde sona ermesi), ardından her birini sonraki dakika / saat boyunca sırayla tamamen yedeklemektir. Ardından hepsini farklı bir sunucuya geri yükleyin ve her birini anlık görüntüye geri döndürün. AFAIK bu senaryo mümkün değildir çünkü anlık görüntüler veritabanı ile birlikte yedeklenemez. Yalnızca, oluşturuldukları sunucuda yerine geri alınabilirler. Ayrıca, tüm müşteriler için sahip olmadığım Enterprise Edition'a ihtiyaç duyuyorlar.

PS2: Cross-db senkronize yedekleri üretebilen bir 3. taraf çözümü biliyorsanız, lütfen belirtin.


Sürümü ile bu senaryo için SQL sunucusunun sürümü nedir? ve burada bahsettiğimiz veritabanlarının büyüklüğü nedir?
KASQLDBA

Yanıtlar:


12

Tek bir kurumsal uygulama tarafından eşzamanlı olarak kullanılan 10-20 SQL Server dbs'yi, çevrimiçi olarak, büyük ölçüde tüm dbs arasında senkronize edilmiş bir duruma geri yükleyecek şekilde yedeklemeliyim

Aradığınız şey, tüm müşteri veritabanlarınızda tutarlı bir yedeklemedir, TAM yedeklemeleri birlikte kullanmalısınız Marked Transactions(vurgu eklenmiştir):

İki veya daha fazla veritabanlarına ilgili güncellemeler yaptığınızda, ilgili veri tabanları , bir mantıksal olarak tutarlı bir noktaya onları kurtarmak için işlem işaretlerini kullanabilirsiniz . Ancak, bu kurtarma işlemi, kurtarma noktası olarak kullanılan işaretten sonra yapılan tüm işlemleri kaybeder. İşlemleri işaretleme yalnızca ilgili veritabanlarını test ederken veya yakın zamanda taahhüt edilen işlemleri kaybetmek istediğinizde uygundur.

resim açıklamasını buraya girin

Adhoc işlem günlüğü yedeklemesini aldığınızdan emin olun COPY_ONLY, aksi takdirde herhangi bir adhoc işlem günlüğü yedeklemesi COPY_ONLYgünlük zincirini kıracağından kurtarma işleminiz bir acı olacaktır. Önlem olarak, kullanıcıları yalnızca COPY_ONLY yedekleri kullanacak şekilde kısıtlayabilirsiniz .

SQL Server sürüm 2008 R2 ve sonrası için bir çözüme ihtiyacım var. Db boyutları db başına 50 GB'a kadardır ve hepsini yedekleme süresi 1-2 saatin üzerindedir.

İşaretli işlemler durumunuza uygun olacaktır. Paralel yedekleme yapmak için tek şey STRIPEonlara, ancak daha sonra yedekleme şeritlerinizi kaybetmediğinizden emin olursunuz. Onları daha hızlı yapmak için BUFFERCOUNTve ile oynayabilirsiniz MAXTRANSFERSIZE.

Anında dosya başlatmayı etkinleştirmenin yanı sıra yedekleme sıkıştırmasını kullanmalısınız .

Bakın


1
Sadece küçük bir not, not usingyedekleme sıkıştırması yedeklemeleri daha da hızlandırabilir ... bunun için depolama alanınız varsa.

4
Yavaş depolamada, I / O'da kaydedilen zaman CPU'da harcanan ekstra süreden daha ağır basacağından sıkıştırma yükünün haklı olduğundan daha fazla şüpheleniyorum. Daha hızlı depolamada, sıkıştırma avantajları depolama alanına çok daha fazla ağırlık verir.
Aaron Bertrand

@ShawnMelton Size katılıyorum, ancak yedekleri aktarırken, sıkıştırılmış yedeklerin aktarımı çok daha hızlı olacaktır. Yedekler sıkıştırma olmadan hızlı olacaktır (depolama altsistemine bağlı olarak), ancak sıkıştırmadan elde edilen kazançları düşünerek , çevremde AÇIK duruma getirme eğilimindeyim .
Kin Shah

@Kin, m-işlemlerinin burada bir çözüm olduğunu düşünmüyorum çünkü: A) Yedeklemelerin alındığı sunucudan farklı bir sunucuda çalışmak üzere tasarlanmamış gibi görünüyorlar. Bazıları satırları logmarkhistory'ye geri yükleyerek etrafta dolaştı ama belgelenmemiş davranışları kullanamıyorum. B) M-işlemleri için destek eklemek için uygulamamın kodunu değiştiremiyorum. Yedek betiklerimden özel m-işlemlerine başlamam gerekecek ve eğer doğru anladıysam , işaretten daha eski olanlar tamamlanana kadar tüm yeni işlemleri durduracaklar. Bu, önemli bir durdurucu olan uygulama kullanılabilirliğini etkiler.
bogdan

3
Burada gerçekten ne istediğini biraz belirsizleştiriyor. İlk önce tam kurtarma ortamınız var, sonra her biri kendi yedekleme stratejisine sahip birkaç müşteriniz var. Uygulama katmanını değiştirmek istemezsiniz, herhangi bir sql yedeklemesi almak istemezsiniz ve blok düzeyinde çoğaltma istemezsiniz, ancak bir çözüm beklersiniz. Gereksinimler, gerçek 'iş' içeren her şeyi değiştirmeye devam ediyor. Ne yazık ki bir magic.stackexchange.com web sitemiz yok.
Tom V - topanswers.xyz'yi deneyin

7

İşlem günlüğü yedeklemelerinin yanı sıra tam yedeklemeler de çalıştırıyorsanız (ve bu verilerin önemli olduğunu düşünüyorsanız) yedekleri ve işlem günlüğü yedeklerini test sistemine kopyalayabilir ve veritabanlarını geri yüklemek için zamanında geri yükleme yapabilirsiniz. + - aynı zamanda.

Tüm veritabanlarının aynı SQL Server makinesinde bulunup bulunmadığına veya sunucu saatlerinin ne kadar iyi senkronize edildiğine bağlı olarak, 'birkaç saniyelik senkronizasyon' hedefini eşleştirebilmeniz gerekir.

Biraz yara bandı çözümü olabilir, ancak gereksinimleri karşılar ve oldukça basit ve ucuzdur.

Önemli veritabanlarınızdan (ve tamamen kurtarma aşamasında olan) tam yedeklemeleriniz ve işlem günlüğü yedeklemeleriniz yoksa, gerçekten yedekleme stratejinizi gözden geçirmeniz gerekir. SAN düzeyinde anlık görüntüler, zaten geri yükleme zamanında bir nokta yapamayacağınız için tam kurtarma modunda bir veritabanına sahip olma noktasını gerçekten tartışıyor.

Lütfen MrDenny'nin bu konuda söylediklerini okuyun



1

Belirttiğiniz koşullar altında, VSS yedeklemelerine 3. taraf veya Microsoft tabanlı bir VSS sağlayıcısı aracılığıyla baktınız mı? Üretim kurtarma zincirinizi kırmayacak bir COPY_ONLY yedeklemesi gerçekleştirebilirsiniz ve daha sonra makul marjlarınız dahilinde başka bir yerde kurtarabileceğiniz tüm veritabanlarının yedeğini almalısınız. Çok etkin bir veritabanının kullanılan seyrek dosyalar nedeniyle bir disk alanı sorununa neden olabileceğinden, VSS yedeklemesinin veritabanı anlık görüntüleri ile aynı mekanizmalara ve düşüşlere sahip olduğunu unutmayın. SQL yazıcısı hizmeti TechNet kaynaklara göz atın burada ve SQL Server VSS yedeklemeler burada .

Bunu Windows Server Yedekleme ile yapmak için, VSS Ayarları altındaki özel yapılandırma ayarlarında VSS kopya yedeklemesini seçtiğinizden emin olmak için manuel yedekleme sihirbazı adımlarını izleyeceksiniz. Bu, Windows Server yedeklemenizin sunucuda alınan diğer yedeklemelere müdahale etmemesini sağlar. Ayrıntılar için Windows Server Yedekleme başvurusuna bakın.


VSS'yi hipervizör / SAN düzeyinde disk anlık görüntüleri çekmeye alternatif olarak gördüm. Bu durumları basit kurtarma kullanan müşteriler için (şimdi ek bir yanıt olarak gönderildi) çözümüme dahil ettim.
bogdan

1

@ Kin'in cevabı olarak oy kullanacağım çünkü sorunun sorduğu ilk soru oldu. Ek bir cevap buldum ve aşağıda açıklayacağım.

Basit kurtarma modeli kullanan müşteriler için, hipervizör veya SAN düzeyinde T0'da alınan geçici bir disk anlık görüntüsünden çıkarılan MDF'lerin ve LDF'lerin bir kopyasına ihtiyacım olacak. Bunları devletteki dbs'yi T0'dan kurtarmak için kullanabilirim.

Tam kurtarma modelini kullanan müşteriler için şunlardan birini isteyeceğim:

  • T0'dan önce tamamlanan en son tam yedeklemenin ANA yedekleme işlemlerinden kopyalar + T0'ı kapsayan sonraki işlem günlüğü yedeklemeleri zincirinden en az. Sonra T0 zaman kurtarma bir nokta yapabilirsiniz.

  • Kendi COPY_ONLYyedeklerimi gerçekleştirme erişimi . Hepsini T0'da paralel olarak başlatacağım, ki bu birkaç saniyeden fazla sürmemeli ve asıl 1 numaralı endişemdi. Ardından, geri yükleme sırasında , her yedeklemeden FirstLSN'e bir zaman kurtarma gerçekleştireceğim . Bunun güzelliği, benim diğer endişem olan ANA yedekleme işlemi ile etkileşime girmemi gerektirmemesidir, COPY_ONLYyedeklerim tutarlılıklarını etkilemeden çalışırken günlükleri bile kesebilirler .


0

Bunu yılda birkaç kez KG ve üretim kopyası olan diğer ortamlar için yapıyorum. Geri yüklemeler için tam kurtarma modu gerçekten gereklidir ve zaman içinde bir noktaya geri yükleme iyi çalışır. Ayrıca çok fazla çoğaltma vardır ve zaman içinde bir noktaya geri yükledikten sonra 'satır bulunamadı' hatalarımız olması nadirdir. Ayrıca, üretimin coğrafi olarak uzak bir kopyası için SAN klon / anlık görüntü yöntemini kullanıyoruz ve bu da veritabanlarının senkronize edilmesi için iyi çalışıyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.