Hangi nesnel faktörler SQL Server çoğaltması uygulama zamanı olduğunu gösterir?

Veritabanımızın yüksek performansı ile bakım kolaylığı arasında bir denge kurmaya çalışıyorum. SSRS raporlarımızı işlem veritabanımızdan fiziksel olarak ayrı bir veritabanına kopyalayarak performansı artırmak için çoğaltmayı kullanmayı düşünüyoruz. Ancak, çoğaltmanın etkinleştirilmesinin geliştirici bakış açısından bir takım dezavantajları vardır:

• Şema değişikliklerini zorlaştırır
• Otomatik entegrasyon / derleme sunucumuza engel olur
• SQL kaynak kontrolünün uygulanmasını zorlaştırıyor gibi görünüyor

Sorum şu : Ne zaman bu dezavantajlar ışığında çoğaltma ile gitme zamanının geldiğini biliyor musunuz? Ek karmaşıklığın kazanımları haklı gösterip göstermediğine nasıl karar veriyorsunuz?

Daha önce kullandık, bu yüzden kurmak sorun değil. Bu daha çok, kararın verilmesine ya da etkinleştirilmemesine bağlıdır. Başkalarının çoğaltma ile gözlemlediği bazı nesne performansı metriklerini arıyorum.

Tabii ki en iyi şey, kendi sunucularımızda bazı simüle edilmiş yük testleri yapmak ve bunu kendimiz çözmektir, ancak orada bazı genel kurallar olduğunu umuyorum.

Çoğaltma, uygulamanın tasarım aşamasında dikkate alınmalıdır. Coğrafi olarak dağıtılmış bir iş gücünüz / kullanıcı tabanınız varsa, bölgesel veritabanlarına ve merkezi veritabanlarına sahip olmak mantıklı olabilir. Dizüstü bilgisayarlardaki bağlantısı kesilmiş veritabanları, nihayet ağa yeniden bağlandıklarında "senkronize edilebilir" (yoldaki satış personelini düşünün).

Raporlama amaçları için çoğaltma cevap DEĞİLDİR. Raporlama ortamındaki performans sorunlarının çoğu, raporların çevrimiçi işlem işleme (OLTP) için yapılandırılmış bir sisteme karşı yazılmasından kaynaklanmaktadır.

Raporlama amacıyla çoğaltma, OLTP verilerinizi başka bir sunucuya taşımak, ancak aynı rapor dostu olmayan yapıyı korumaktır. Temelde, soruna daha fazla donanım atıyorsunuz ve bakım maliyetlerinizi artırıyorsunuz, ancak marjinal kazançlar için.

Bakmanız gereken, raporlarınızın ihtiyaç duyduğu belirli verileri nasıl elde edeceğiniz ve bunları daha kullanışlı bir biçime nasıl dönüştüreceğinizdir. Üretim veritabanınızdan yeni işlemler alan ve bunu tercihen ayrı bir sunucuda bulunan bir raporlama veritabanında depolayan bir feed oluşturun. Feed her çalıştığında, en son yayınlandığından daha yeni olan tüm verileri almalı, bu verileri dönüştürmeli ve depolamalıdır. Şu anda çalıştırdığınız raporlar, gerekli dönüşüm türleri hakkında size iyi bir fikir verecektir.

Bu yaklaşımı izleyerek, büyük performans avantajlarından yararlanacaksınız.

Değer için, rapor yazarları çoğaltılan veritabanındaki dizinlere "sahip" olabileceğinden çoğaltmanın benzer bir durumda yardımcı olduğunu gördük. Bu bize, uygulama geliştiricilerin INSERTS ve UPDATES üzerindeki olumsuz etkileri nedeniyle üretimde hiçbir zaman onaylamayacakları dizinler ekleyerek sorgu performansını iyileştirme olanağı sağlamıştır.

Belki de kullanım durumunuzun bir kısmı, bazı işlem tablolarını kopyalamak, bazı endekslemeyi değiştirmek ve buna değip değmeyeceğini görmek mi?

Bu yardımcı olur umarım!