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.

En Fazla Karşılaştığımız 2 Büyük SQL Server Sorunu

Şirketler bizi performans veya yüksek kullanılabilirlik sorunları için arıyor, ancak tekrar tekrar bulduğumuz ilk iki şey şunlar oluyor:

1. İşletmenin RPO (recovery point objective) ve RTO’suna (recovery time objective) uyacak şekilde yedekleme yapmıyorlar.
2. CHECKDB’yi haftalık olarak ya da hiç yapmıyorlar ve bunun neden bir sorun olduğunu anlamıyorlar

Şimdi basit bir senaryo üzerinden gidelim ve nasıl yapacağınızı görelim.

Perşembe sabahı saat 11 ve bir e-posta alıyorsunuz: kullanıcılar kritik bir tabloda SELECT çalıştırdıklarında corruption hataları bildiriyorlar. Sorguyu çalıştırıyorsunuz ve tablodaki kümelenmiş dizinde corruption olduğu ortaya çıkıyor.

İşte bakım programınız:

• Gece 11:00 Full Backup
• Her 15 dakika da bir Transaction Log backup
• İki günden eski günlük yedeklerini silin (çünkü yalnızca yakın zaman noktaları için zaman içinde geri yükleme özelliğine ihtiyacınız var, değil mi?)
• CHECKDB haftalık cumartesi günleri saat sabah 09:00

Corruption gerçekleştiğinde onaramazsınız (bu bir clustered index ve tüm sütunları kapsayacak kadar non-cluster index yok) ve işletmenin bu verilere geri ihtiyacı vardır. Sıra sizde: bu soruları yanıtlayın:

1. Sırayla hangi yedekleri geri yüklüyorsunuz?
2. Bunlar bozulma içermeyecek mi?
3. Ne kadar veri kaybetmiş olacaksınız?
4. Bu süreç ne kadar sürecek?
5. Buna göre, etkili RPO ve RTO’nuz nedir?
6. İşletme bunun yeterince iyi olmadığını söylerse, para harcamadan bu rakamları iyileştirmek için hangi özel adımları atabilirsiniz?