SQL Server’a Raporlama Sunucusu Eklemenin Gerçek Maliyeti: Lisans, Mimari ve Alternatifler

Raporlar üretim veritabanını yavaşlatmaya başladığında en sık gelen öneri, raporlamayı ayrı bir sunucuya taşımaktır. Kâğıt üzerinde basit görünür: veri başka bir yere kopyalanır ve raporlar oraya yönlendirilir. Pratikte ise raporlama sunucusu kendi lisansları, donanımı, veri aktarımı, izlemesi ve arıza senaryolarıyla birlikte yeni bir üretim sistemidir ve toplam maliyeti çoğu zaman ilk tahminin oldukça üzerinde çıkar.

Bu yazıda bir SQL Server raporlama sunucusunun gerçek maliyetini, seçeneklerin lisans ve operasyon açısından nasıl ayrıştığını, SQL Server 2025 ile nelerin değiştiğini ve ayrı bir sunucu kurmadan önce denenmesi gereken adımları ele alıyoruz.

Raporlamayı Ayırmanın Yolları

Raporlara verinin ayrı bir kopyasını sağlamanın dört yaygın yolu vardır. Her biri verinin güncelliği, gerektirdiği sürüm ve çalışır durumda tutmak için gereken emek açısından farklıdır.

Herkesin Öngördüğü Maliyetler

Lisans

Raporlama sunucusu üretim kullanıcılarına hizmet verdiği için pasif bir replika değildir ve tam olarak lisanslanmalıdır. Microsoft’un SQL Server 2025 liste fiyatlarıyla 8 core’lu bir raporlama sunucusunun maliyeti şöyledir:

• Enterprise (okunabilir availability group secondary için zorunlu): 4 × 15.123 $ = 60.492 $
• Standard (log shipping, replication veya gece kopyası): 4 × 3.945 $ = 15.780 $

Primary sunucu bugün Standard ile çalışıyorsa ve okunabilir secondary seçilirse, primary’nin de Enterprise’a geçmesi gerekir. Aynı 8 core için bu, 4 × (15.123 $ − 3.945 $) = 44.712 $ ek maliyet demektir. Windows Server lisansları, Software Assurance ve yeni sunucudaki yedekleme, izleme ve güvenlik araçlarının lisansları bunlara eklenir. Bu kuralları SQL Server 2025 lisanslama rehberimizde ayrıntılı olarak ele aldık.

Donanım ve depolama

Raporlama sunucusunun ağır sorguları kaldıracak kadar işlemci ve belleğe, verinin tam bir kopyası için de yeterli depolamaya ihtiyacı vardır. Bu sunucunun yedeklenip yedeklenmeyeceğine ve felaket kurtarma planına dahil edilip edilmeyeceğine de karar vermek gerekir; bir kesinti sırasında duran raporlar çoğu zaman kendi başına bir iş sorununa dönüşür.

Rapor sunucusu yazılımı

SQL Server 2025 ile birlikte şirket içi raporlama Power BI Report Server altında birleştirildi ve bu ürün artık hem Enterprise hem de Standard müşterilerine sunuluyor. SQL Server 2022 ve öncesinde Power BI Report Server hakkı yalnızca aktif Software Assurance’a sahip Enterprise core lisanslarına tanınıyordu; SQL Server Reporting Services 2022 ise 11 Ocak 2033’e kadar destekleniyor. Microsoft’un genel lisans kuralına göre SQL Server bileşeni kurulan her işletim sistemi ortamının lisanslanması gerektiğinden, Power BI Report Server’ı ayrı bir sunucuya kurmak o sunucunun core’larını da maliyete ekler; ayrıntıları kendi sözleşmenizle doğrulayın.

Sonradan Ortaya Çıkan Maliyetler

• Uygulama değişiklikleri. Raporların yeni connection string’lere ihtiyacı vardır. Availability group’larda okumalar yalnızca bağlantıda ApplicationIntent=ReadOnly belirtildiğinde ve read-only routing yapılandırıldığında secondary’ye gider. Okuma ve yazmayı aynı anda yapan bir uygulamada kodun sorgu sorgu gözden geçirilmesi gerekir.
• İki iş yükü için indeksler. Raporlama sorguları genellikle işlemsel iş yükünden farklı indekslere ihtiyaç duyar. Okunabilir bir secondary üzerinde primary’de olmayan bir indeks oluşturulamaz; bu nedenle raporlama indeksleri üretimde de yazma yükü yaratır.
• Replikasyon yükü. Availability group’lar ve transactional replication her insert, update ve delete işlemini taşır. Raporlar saatte birkaç kez verinin küçük bir bölümünü okuyorduysa, her değişikliğin replike edilmesi raporların kendisinden daha maliyetli olabilir.
• Arıza yönetimi. Veri aktarımı er ya da geç bozulur veya geride kalır. Kullanıcıların eski veri gösteren raporları nasıl fark edeceğini bilmesi, ekibin de her arıza türü için yazılı bir kararı olması gerekir: raporları geçici olarak primary’ye yönlendirmek, raporların kullanılamamasını kabul etmek ya da yeniden senkronize etmek.
• İzleme. Artık replikasyon gecikmesini, raporlama sunucusunun kendi performansını ve primary üzerindeki etkisini izlemeniz gerekir. İş yükü iki sunucuya bölündüğü için performans analizi de zorlaşır.
• Beklenti yönetimi. İş birimlerinin rapor verisinin ne kadar güncel olduğunu ve bir arızada raporların ne kadar süre kullanılamayabileceğini bilmesi gerekir; bu, raporlama için RPO ve RTO’nun karşılığıdır.

Ağ İzolasyonu: Rapor Sunucusunu Veritabanı Sunucusundan Ayırmak

Raporlamayı ayırmanın performans ve lisans dışında, en az bunlar kadar önemli bir nedeni daha vardır: güvenlik. Reporting Services ya da Power BI Report Server veritabanı sunucusuna kurulduğunda, kullanıcıların raporlara erişebilmesi için o sunucuya HTTP (80) ve HTTPS (443) trafiğinin açılması gerekir. Bu, veritabanı sunucusunun web trafiği alan bir sunucuya dönüşmesi demektir: Sunucu kullanıcı ağından doğrudan erişilebilir hâle gelir, web servisinde ortaya çıkabilecek bir açık doğrudan verinin bulunduğu makineyi etkiler ve güvenlik duvarı kuralları bu trafik için gevşetilmek zorunda kalır.

Rapor sunucusu ayrı bir makineye taşındığında katmanlı bir yapı kurulabilir:

• Kullanıcılar yalnızca rapor sunucusuna erişir. 80 ve 443 portlarındaki trafik uygulama katmanındaki rapor sunucusunda sonlanır; veritabanı sunucusuna hiçbir web trafiği yönlendirilmez.
• Veritabanı sunucusu izole bir ağ segmentinde kalır. Gelen bağlantılar yalnızca rapor sunucusundan ve uygulama sunucularından, SQL Server portu (varsayılan olarak 1433) üzerinden kabul edilir. Rapor kataloğunu tutan ReportServer veritabanı yine veritabanı sunucusunda barındırılabilir.
• Veritabanı sunucusunun internet erişimi kapatılır. Bir veritabanı sunucusunun dışarıya bağlantı kurmasına ihtiyaç yoktur; işletim sistemi ve SQL Server güncellemeleri WSUS gibi iç bir kaynaktan alınabilir. Dışarıya kapalı bir sunucu, ele geçirilse bile verinin dışarı aktarılmasını ve zararlı yazılımın dış dünyayla iletişim kurmasını önemli ölçüde zorlaştırır.

Bu ayrım saldırı yüzeyini daraltır ve kurumsal güvenlik politikalarının ve denetimlerin genellikle beklediği katmanlı ağ mimarisiyle de uyumludur. Bedeli ise ayrı rapor sunucusunun core’larının lisanslanmasıdır; ancak veritabanı sunucusunu web trafiğine ve internete tamamen kapatabilmenin sağladığı güvenlik kazanımı, birçok kurum için bu maliyeti tek başına haklı çıkarır. Güvenlik duvarı ve port kısıtlamalarının ayrıntılarını SQL Server güvenlik sıkılaştırma rehberimizde, internete kapalı sunucularda güncellemelerin nasıl yönetileceğini ise Windows güncellemeleri yazımızda ele aldık.

Gerçekten Raporlama Sunucusuna İhtiyacınız Var mı?

Bu maliyete girmeden önce raporların neden yavaş olduğunu bulun. Birçok ortamda sorun, maliyetin küçük bir kısmıyla mevcut sunucu üzerinde çözülebilir.

1. Bekleme istatistiklerine bakın

Baskın bekleme türü, sunucunun neyin eksikliğini çektiğini gösterir. Yoğun PAGEIOLATCH_* beklemeleri sorguların diskten sayfa okumayı beklediği anlamına gelir ve genellikle çalışma kümesine yetmeyen belleğe ya da eksik indekslere işaret eder. Yüzlerce gigabaytlık bir veritabanının 32 GB belleğe sahip bir sunucuda çalışması bir bellek sorunudur ve bellek eklemek sunucu eklemekten çok daha ucuzdur.

SELECT TOP (10)
    wait_type,
    wait_time_ms / 1000 AS bekleme_sn,
    waiting_tasks_count,
    CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER () AS decimal(5,2)) AS yuzde
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (N'SLEEP_TASK', N'LAZYWRITER_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
                        N'XE_TIMER_EVENT', N'XE_DISPATCHER_WAIT', N'REQUEST_FOR_DEADLOCK_SEARCH',
                        N'LOGMGR_QUEUE', N'CHECKPOINT_QUEUE', N'BROKER_TO_FLUSH',
                        N'HADR_FILESTREAM_IOMGR_IOCOMPLETION', N'DIRTY_PAGE_POLL',
                        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'WAITFOR')
ORDER BY wait_time_ms DESC;

2. Okuyanların ve yazanların birbirini bloklamasını önleyin

Raporlar ve işlemler birbirini blokluyorsa, Read Committed Snapshot Isolation (RCSI) okuyucuların kilit beklemek yerine satırın son onaylanmış sürümünü görmesini sağlar. Tüm sürümlerde kullanılabilir ve çoğu zaman raporlamayı ayırmayı gerekli gösteren blocking sorununu ortadan kaldırır. Yine de önce test edin: RCSI, tempdb’de satır sürümlemesi kullanır ve bazı uygulamaların dayandığı okuma davranışını hafifçe değiştirir.

3. Raporların kullanabileceği kaynakları sınırlayın

SQL Server 2025 ile Enterprise’ın yanı sıra Standard sürümde de kullanılabilen Resource Governor, raporlama login’lerinin kullanabileceği CPU’yu, bellek tahsisini ve paralelliği sınırlayabilir. Böylece ağır bir rapor işlemsel iş yükünü kaynaksız bırakamaz.

4. Raporların kendisini iyileştirin

Yükün büyük kısmı genellikle birkaç sorgudan gelir. Query Store bu sorguları gösterir; hedefli indeks değişiklikleri, analitik sorgular için nonclustered columnstore indeks ya da raporun yeniden yazılması, yükü başka bir sunucuya taşımaktan daha fazla azaltabilir. DMV’lerle yavaş sorguları bulma rehberimiz pratik bir başlangıç noktasıdır.

Ayrı Raporlama Sunucusu Ne Zaman Doğru Tercihtir?

Raporlamayı ayırmak şu durumlarda haklı bir karardır: iyileştirmelere rağmen raporlama yükü üretimle kaynak için yarışmaya devam ediyorsa, raporlar analiz için tasarlanmış bir veri ambarı gibi farklı bir veri modeline ihtiyaç duyuyorsa, primary üzerindeki bakım çalışmaları sırasında raporlamanın sürmesi gerekiyorsa veritabanı sunucusunun ağ olarak izole edilmesi, web trafiğine ve internete kapatılması gerekiyorsa ya da düzenleyici veya güvenlik gereklilikleri raporlama kullanıcılarını üretim sisteminden ayırmayı zorunlu kılıyorsa. Bu durumlarda karar, toplam maliyet göz önünde bulundurularak verilmelidir: ilgili tüm sunucuların lisansları, donanım, veri aktarımı, izleme ve arıza anındaki operasyonel prosedürler.