Reporting Server Ekleme Maliyeti

Raporlama Sunucusu Eklemenin Maliyeti

“Raporlama sorgularımızı ayrı bir SQL Server’a aktarmak istiyoruz.”

İlk maliyetler oldukça açıktır.

Donanım ve depolama – sanal bir makinede çalıştırıyor olsanız bile, örneğin 4 çekirdek ve 32 GB RAM maliyetlerini hesaba katmanız gerekir. Yalnızca veritabanları için depolama alanına ihtiyacınız olmayacak, aynı zamanda bu sunucunun yedeklenip yedeklenmeyeceğine ve bir felaket kurtarma veri merkezine kopyalanıp kopyalanmayacağına da karar vermeniz gerekecek.

Yazılım lisanslama – Standard Edition çekirdek başına ~2 bin dolar, Enterprise Edition ise çekirdek başına ~7 bin dolar. Windows’u (özellikle artık çekirdek başına lisanslandığı için), yönetim/yedekleme/antivirüs araçlarınızı ve izleme yazılımınızı da ekleyin.

Proje planlama – Always On Availability Groups, log shipping ya da transactional replication gibi yöntemlerle verileri üretimden raporlama sunucusuna nasıl aktaracağınızı tasarlamanız gerekecektir.

Uygulama değişiklikleri – raporlama sorgularını çalıştıran uygulamanın yeni bir connection string’e ihtiyacı olacaktır.  SQL Server’dan yalnızca okuma yapacağınız durumda aşağıda belirtilen kodu connection string parametresinde kullanmanız gerekir. Hem okuma hem de yazma yapan tek bir uygulamanız varsa ve yalnızca bazı sorguları devre dışı bırakmak istiyorsanız, bu sorguları yeni connection string’e geçirmek için kodu gözden geçirmeniz gerekecektir.

ApplicationIntent = ReadOnly

Bir sorun giderme süreci eklemek – er ya da geç veri replikasyon süreci bozulacaktır. Yönteme (AGs, log shipping, replication) ve hata türüne bağlı olarak, farklı şekillerde başarısız olacaktır – belki tüm veriler eskidir, belki sadece bir kısmı eskidir veya belki raporlara hiç erişilemez. Arıza yöntemlerini listelemek ve belirtilerin neye benzeyeceğini açıklamak isteyeceksiniz. Bu, iş kullanıcılarının raporlarının ne zaman yanlış olduğunu anlamalarına ve uygun şekilde tepki vermelerine yardımcı olur. Bu adımı atmazsanız, ilk başarısızlıktan sonra insanlar her zaman rapor verilerinde bir hata olduğunu düşüneceklerdir.

Başarısızlığa hazırlanın – bu başarısızlık yöntemlerinin her biri için nasıl tepki vereceğinize karar verin. Örneğin, AG replikasyonu bozulursa ve raporlar güncelliğini yitirirse, sorun çözülene kadar raporları primary sisteme mi yönlendireceksiniz yoksa siz sorun giderirken veya replikaları yeniden senkronize ederken kullanıcılar kullanılamayan raporlarla mı uğraşmak zorunda kalacak? Bu adımı atmazsanız, her seferinde boşa kürek çekmiş olursunuz ve raporlar hatalı veya çalışmaz durumdayken hazırlıksız görünürsünüz.

RPO ve RTO için gerçekçi beklentiler belirleyin – sürecinize ve hazırlığınıza bağlı olarak, iş kullanıcılarının işler bozulduğunda raporlarının ne kadar süre kapalı kalacağını anladıklarından emin olun.

Replikasyonun ek yükünü ölçün – AG’ler ve transactional replication, eskiden raporların maliyetinin ötesinde performans yavaşlamaları ekleyebilir. Örneğin, saatte yalnızca birkaç rapor çalıştırıyorsanız ve yalnızca verilerin bir alt kümesine ulaşıyorsanız, aniden her bir silme/güncelleme/ekleme işlemini çoğaltmak büyük bir ek yük getirebilir.

Monitoring ekleyin – raporlama sunucusunun ne kadar geride olduğunu ve her ikisinde de performansın nasıl gittiğini izlemeye başlamanız gerekir. Performans sorunlarını gidermek de çok daha zor hale gelir – örneğin, dizin ayarlaması yaparken, doğru dizin karışımını bulmak için hem birincil hem de raporlama sunucularındaki verileri birleştirmeniz gerekir.

Raporlamayı gerçekten yapmanız gerektiğinden emin misiniz?

Bu pahalı projeye başlamadan önce şunu sorun:

– Karşılaştığımız primary wait type nedir?

– Bu wait type’ı azaltmanın en ucuz/kolay yolu nedir?

Zaman zaman PAGEIOLATCH beklemeleriyle (bir veri dosyasından veri sayfalarını okumak için beklemek anlamına gelir) karşılaşan insanlar görüyorum ve 16-32GB RAM ile 1TB’lık bir veritabanıyla uğraşıyorlar. Bu sorunu çözmek için on binlerce dolar harcamayın – 1.000 dolarlık RAM satın alın ve dizin ayarlaması yapmak için biraz zaman harcayın.