Problem tanımı

Kullanıcılarımızın çoğunlukla güncel olan bir veritabanını sorgulama yeteneğine ihtiyacı vardır. Veriler 24 saate kadar eski olabilir ve bu kabul edilebilir. Üretim kopyasında ikinci bir veritabanını almak ve güncel tutmak için en düşük maliyetli yaklaşım hangisidir? Düşünmediğim bir yaklaşım var mı?

İş yoğunluğu

Hisse senedi alım satım faaliyetini izlemek için kullandığımız üçüncü taraf bir uygulamamız var. Gün boyunca, çeşitli iş akışlarının bir parçası olarak birçok küçük değişiklik meydana geldi (evet, bu ticaret geçerliydi. Hayır, bu şüpheli, vb.). Geceleri büyük set bazlı işlemler yapıyoruz (önceki günün işlemlerini yükle).

Güncel çözüm ve problem

Biz faydalanmak veritabanı anlık . Saat 10: 00'da, enstantane fotoğrafını düşürüp yeniden yaratıyoruz. ETL işlemi daha sonra başlar. Bu açıkça diskimize vergi veriyor ancak kullanıcılarımızın veritabanını kilitlemeden veritabanını sorgulamalarını sağlıyor (bir Access front end kullanıyorlar). Gecenin geç saatlerinde ve sabahın erken saatlerinde kullanırlar, böylece aksama sürelerini fark ederler.

Bu yaklaşımla ilgili sorun iki katlıdır. Birincisi, gece işlemenin başarısız olması ve bu durumun nadiren gerçekleşmemesi durumunda, anlık görüntünün düşürülmesine neden olan veritabanını geri kazanmamızdır. Diğer bir problem ise işlem sürelerimizin SLA'dan geçmesidir. Bunu, yetersiz yazılı soruları ve endeksleme eksikliğini belirledikten sonra satıcı ile çalışarak çözmeye çalışıyoruz. Veritabanı anlık görüntüsü de bu yavaşlamada, şok edici değil, şok edici değil, mevcut olduğunda hız farkının gösterdiği gibi bir suçlu.

Yaklaşılan yaklaşımlar

Kümeleme

Veri tabanı kümelemesini açtık ancak bu, verileri kullanılabilir hale getirme gereksinimlerini karşılamadı ve yöneticinin yaşamını genel olarak karmaşık hale getirdi. O zamandan beri kapalı.

SQL Server Çoğaltma

Geçen hafta replikasyona bakmaya başladık . Teorimiz, ikinci bir kataloğu ayağa kaldırarak üretim veritabanıyla senkronize edilebileceğimizdir. ETL başlamadan önce, bağlantıyı keseceğiz ve yalnızca ETL işlemi tamamlandıktan sonra yeniden etkinleştireceğiz.

Yönetici Anlık Görüntü Çoğaltma ile başladı, ancak anlık görüntüyü ve gereken disk tüketimini oluşturmak için birkaç gün boyunca yüksek CPU kullanımı gerektiğinden endişe duyuyor. Abone göndermeden önce tüm verileri fiziksel dosyalara yazdığını, böylece .6TB veritabanımızın depolama maliyetlerinde 1.8 TB'a mal olacağını belirtti. Ayrıca, bir çırpıda üretmek için birkaç gün sürecekse, istenen SLA'ya sığmaz.

İnce makaleyi okuduktan sonra, Snapshot aboneleri başlatmak için bir yol gibi görünebilir ancak daha sonra senkronizasyonda kalmasını sağlamak için Transaction Replication'a geçmek isteriz. İşlemsel çoğaltmayı açıp kapatmanın tam yeniden başlatma işlemini zorlamayacağını varsayıyorum? Aksi takdirde, zaman penceremizi uçuracağız

Veritabanı Aynalama

Veritabanımız TAM kurtarma modunda olduğundan veritabanı yansıtma bir seçenektir, ancak bu konuda Çoğaltma'dan daha az şey biliyorum. "Veritabanı yansıtma doğrudan verilere erişilmesini önler, yansıtılmış verilere yalnızca bir veritabanı anlık görüntüsü yoluyla erişilebilir" olarak belirtilen SO yanıtını buldum .

Günlük Gönderimi

Kütük nakliyesi de bir seçenek olabilir gibi gözüküyor ama bu, hakkında hiçbir şey bilmediğim şeylerden bir diğeri. Her şeyden daha düşük maliyetli bir çözüm (uygulama ve bakım) olur mu? Remus'un yorumuna göre, "Günlük gönderimi, kopya kopyasına salt okunur erişime izin veriyor, ancak alınan bir sonraki yedekleme günlüğünü uygularken tüm kullanıcıların bağlantısını kesecek (ör. Her 15-30 dakikada bir)." Bu aksama süresinin ne kadar süre için çevrileceğinden emin değilim, bu nedenle kullanıcıların bir miktar endişelenmesine neden olabilir.

MS Senkronizasyonu

Sadece geçen hafta sonu Sync'i kullanmayı duydum ve henüz araştırmadım. Bu sorunun olduğu gibi görünürlüğü yüksek olan bir şey için yeni bir teknoloji sunmaktan nefret ediyorum ama en iyi yaklaşım buysa, öyle olsun.

SSIS

Burada bolca SSIS yapıyoruz, bu yüzden ikincil senkronize tutmak için birkaç yüz SSIS paketi üretmek bizim için çirkin olsa da bir seçenek . Bunu yapan bir taraftar değilim, çünkü bu çok fazla bakım yükü, ekibimin üstlenmemesini tercih ederim.

SAN "sihirli" enstantane

Geçmişte, tüm disklerin anında yedeklerini almak için yöneticimizin bazı SAN teknolojilerini kullandığını duydum. Belki de mdf / ldf’nin kopyalarını kopyalamak için kullanılabilecek bazı EMC sihirleri var ve hedef veritabanını çıkarabilir / ekleyebiliriz.

Yedekleme ve geri yükleme

Bence haftada bir kez tam yedeklemeler alıyoruz, geceleri farklılıklar yapıyoruz ve her 15 dakikada bir tolog yapıyoruz. Kullanıcılar tam geri yükleme için 3-4 saatlik bir kesinti ile yaşayabilirlerse, bunun bir yaklaşım olabileceğini düşünüyorum.

Kısıtlamalar

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, vmdk dosyalarına eşlenen sürücülerle birlikte EMC SAN depolama, kaynak kataloğunda commvault işleme yedekleme ve .6TB veri. Bu, şirket içinde barındırdığımız üçüncü taraf bir uygulamadır. Yapılarını değiştirmek genellikle üzerine kaşlarını çattı. Kullanıcılar veritabanını sorgulamadan gidemezler ve çalışmalarını yapmak için izledikleri tabloları proaktif olarak tanımlayarak kısıtlanmayı reddederler.

DBA'larımız şu anda tamamen yüklenicilerdir. Tam zamanlı çalışanlar yelken açtılar ve biz onları henüz değiştirmedik. Uygulama yöneticileri SQL Server konularında tam anlamıyla bilgili değiller ve bu çabayı engelleyebilecek / engelleyebilecek bir Depolama / VM yöneticileri ekibimiz var. Geliştirme ekipleri şu anda yer almamaktadır, ancak yaklaşıma dayalı olarak listelenebilmektedir. Bu nedenle, çözümü uygulamak ve sürdürmek daha basit olacaktır.

Ben, rehinenin gelişim tarafındayım, bu yüzden sadece yaklaşım önerebilirim ve işlerin yönetim tarafı ile uğraşmak zorunda kalmam. Bu yüzden yönetici yüreğinde hiç zaman kalmadan, bir yaklaşımın diğerinden üstün olacağını söylemekte tereddüt ediyorum --- hepsi gazetelere göre harika görünüyor. Hepinizin önerdiği herhangi bir yöne koşmaya tamamen istekliyim, çünkü gördüğüm gibi, beni sadece bir DB uzmanı olarak daha değerli hale getirecek. Bir el arabası var ama hiçbir holocaust pelerin yok .

İlgili sorular

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Düzenlemeler

@ Onpnt'ın sorularını yanıtlamak için

Veri gecikme kabulü

Kullanıcılar şu anda 24 saate kadar olan verileri görüntülüyor. Veriler sadece 2200 itibariyle geçerlidir.

Veri miktarı belirli bir dakika, saat ve gün içinde değişir. Bunu nasıl ölçeceğinizden emin değilsiniz. İş saatleri, belki saat başına yüzlerce değişiklik. Gecelik işlem, iş günü başına milyonlarca satır

İkincil bağlantı

Dahili ağ, ayrı sanal konak ve özel depolama

İkincil örneğe ilişkin gereksinimleri okuyun

Windows grubunun tüm tablolara ikincil okuma erişimi olacak

İkincil vakanın çalışma süresi

Bir up-time gereksinimin güçlü bir tanımı yoktur. Kullanıcılar her zaman kullanılabilir olmasını ister, ancak bunun için para ödemeye razı olurlar, muhtemelen fazla değil. Gerçekçi olarak, günün 23 saatinin yeterli olacağını söyleyebilirim.

Mevcut şema ve tüm nesnelerde değişiklikler

Seyrek değişiklikler, belki de her üç ayda bir masa objeleri için. Belki kod nesneleri için ayda bir kez.

Güvenlik

Özel güvenlik gerekmez. Üretim izinleri, kopya izinleriyle eşleşir. Düşündüğüm kadarıyla, kullanıcıları prod'a okuma erişimini iptal edebiliriz ve sadece kopyalarını okumalarına izin verdik ... Gerçi bir zorunluluk değil.

@darin Boğazı

Anlık görüntüye geri dönmek bir seçenek olabilir, ancak peşinden koşmalarının bir nedeni olduğunu düşünüyorum. Yönetici ile kontrol edeceğim

@cfradenburg

Benim varsayım, bu yaklaşımlardan sadece birini kullanmamızdı ama bu, restorasyonların "diğer" senkronizasyon teknolojilerini kıracağı iyi bir noktaydı. EMC enstantane büyüsünü kullanarak araştırma yapıyorlar. Yöneticinin tarif ettiği gibi, 1900'de bir anlık görüntü alacaklar ve görüntüyü ikincil bölgeye geçireceklerdi. Bu 2200 yılına kadar tamamlanmalı ve ardından ikincil veritabanının bir kopyasını çıkarıp yeniden bağlayacaklar.

Sarmak

2012-10-29 EMC anlık görüntüsünü ve diğer bazı çoğaltma seçeneklerini değerlendirdik, ancak DBA'lar Yansıtma'yı en iyi şekilde anlayabileceklerine karar verdi. Cevapları iptal ettiler çünkü hepsi yardım ettiler ve bana araştırmam gereken "ev ödevleri" nin yanı sıra birçok seçenek verdiler.

Yapılarını değiştirmek genellikle üzerine kaşlarını çatıyor

Çoğaltma olasılığı çok fazla ve ben bundan önce Sync'i atacağım. (Eşitleme Çerçevesinde gerçek hayattaki yüksek işlem testlerinden)

Veri gecikme istisna durumunuz 3-4 saatse, günlük gönderimi büyük olasılıkla burada salt okunur bir kopyaya oynanan en iyi bahis olacaktır. Fakat kütükte ne kadar değişiklik oluyor? Bunu ne kadar çabuk ve ne kadar itmeniz gerektiğini görmek için izliyor olun.

Mirroring'e gidemiyorsanız veya 2012 kuruluşuna geçemiyorsanız, bunun için Enterprise'a gidebilirsiniz.

SSIS sadece veri dökümü yapmıyor, fakat bunu yapabiliyor. Arama dönüşümleri açısından çok fazla bakıyorsunuz ve görev zaman ve kaynaklar açısından pahalı olacak. Yine de dediğim gibi yapabilir.

Gerçekten, birkaç soruyu yanıtlamaya dayalı seçimlerin belirgin bir daralması olacaktır.

• Veri gecikme kabulü
• Belirli bir dakika, saat ve günde veri miktarı değişmesi İkincil bağlantı
• İkincil örneğe ilişkin gereksinimleri okuyun
• İkincil vakanın çalışma süresi
• Mevcut şema ve tüm nesnelerde değişiklikler
• Güvenlik

Bu, en iyi olanı bulmak için kendiniz için denemeniz gereken şeylerden biri olacak. Çoğaltma zor olabilir, bu nedenle doğrudan parasal bir maliyet olmasa da, bunu idare eden genel giderler olacaktır.

Günlük Gönderiyi genişletmek için, günlükleri her 15-30 dakikada bir geri yüklemeniz gerekmez. İsterseniz, her dört saatte bir veya günde bir kez yapabilirsiniz. Uyguladığım buna benzer bir çözüm, haftalık tam bir yedekleme yapıyor ve raporlama yapan bir DB'ye geri yüklüyor (bu biraz zaman alabilir ve hafta sonları olabilir). Hafta boyunca diferansiyel yedekleri alınır ve bunlar gece raporlama veritabanına geri yüklenir. Kullanıcıların geri yüklemeden önce önyükleme yapması gerekir, ancak raporlama DB iş saatleri uygulaması olduğundan, bununla ilgili bir sorun yoktur. Veriler, ihtiyaçlarınızı temel alan bir sorun olmaması gereken bir günlüktir.

Bunun için veritabanı yansıtma kullanmak için, Enterprise kullanmıyorsanız anlık görüntüleri kullanabilmek için Enterprise satın almanız gerekir. Anlık görüntünün kaldırılması gerektiğinden (tüm kullanıcıların çıkarılması gerektiği anlamına gelir) ve ardından yeni verileri almak için yeniden yaratıldığından, verileri% 100 güncel tutmaz. Bununla birlikte, bu, log geri yüklemelerinden veya yukarıda açıkladığım yöntemden daha az zaman olacaktır.

SQL 2012'ye yükseltmek bir seçenek ise, birincil veritabanıyla güncel tutulacak salt okunur bir ikincil ayarlamak mümkündür. Ben sadece bundan bahsediyorum çünkü en sorunsuz çözüm bu olabilir.

İnsanlar işlem çoğaltması için paçavra olduğu kadar, durumunuza uygun bir ses gibi geliyor. Birkaç not:

1. Aboneyi anlık görüntüyle başlatmanız gerekmez. Yayıncının yedeğini alabilir ve bununla başlayabilirsiniz.
2. Komutların iletimini aboneye yalnızca dağıtım işini durdurarak durdurabilirsiniz (sırasıyla, bir push veya pull aboneliği olarak ayarladığınıza bağlı olarak, yalnızca dağıtıcıda veya abonedeki normal bir SQL Agent işidir). Sadece distribütörde tutulduğunuza dikkat edin, böylece yeteri kadar geçmişi saklayabilmenizi sağlar.
3. İsterseniz, yayıncınızdan (muhtemelen OLTP türü) dizin oluşturmayı kabul etmek yerine, orada yapılacak iş yüklerini (muhtemelen raporlama türü) yerleştirmek için abonedeki endekslemeyi değiştirebilirsiniz.