Microsoft SQL Server 2025 Always On Availability Group Kurulumu 3

bakicubuk

2 ay önce

Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisinin kurulumunu inceliyoruz.

Yazı dizisi beş bölümden oluşuyor:

Bölüm 1 – Windows Server Failover Cluster (WSFC) Kurulumu
Bölüm 2 – Microsoft SQL Server 2025 Kurulumu
Bölüm 3 – SQL Server 2025 Bileşenleri Rehberi (Bu Yazı)
Bölüm 4 – Always On Ön Hazırlık ve Servis Ayarları
Bölüm 5 – Availability Group Kurulumu ve Failover Testi

Bölüm 2‘deki SQL Server 2025 kurulumunda Feature Selection ekranında pek çok bileşen ile karşılaştık. Always On Availability Group için yalnızca Database Engine Services ve SQL Server Replication bileşenlerini seçmiştik.

Ancak Feature Selection ekranında bunların dışında birçok bileşen daha bulunur. Bu yazıda, kurulum ekranında karşınıza çıkan tüm bileşenlerin ne işe yaradığını, hangi senaryolarda kullanıldığını, nasıl çalıştığını ve Always On ile ilişkisini derinlemesine ele alacağız. Her bileşen için mümkün olduğunda gerçek hayattan bir kullanım senaryosu, ilgili T-SQL doğrulama sorguları ve güvenlik/performans açısından dikkat edilmesi gereken noktaları da paylaşacağız.

Bu yazı bir referans (sözlük) niteliğindedir; ihtiyaç duyduğunuzda ilgili bileşene dönüp bakabilirsiniz.

Bileşenlere Genel Bakış

SQL Server kurulumunda karşımıza çıkan bileşenler mimari olarak iki ana grupta toplanır. Bu ayrım yalnızca kurulum ekranında nerede göründükleriyle ilgili değildir; bileşenin nasıl lisanslandığını, nasıl yamalandığını (patch) ve birden fazla instance kurulduğunda nasıl davrandığını da belirler.

Instance Features: Belirli bir SQL Server instance’ına bağlı çalışan, o instance’a özel bileşenlerdir (Database Engine, Analysis Services vb.). Aynı sunucuya iki farklı instance kurarsanız, her birinin kendi Database Engine kopyası olur; biri yeniden başlatıldığında diğeri etkilenmez.
Shared Features: Sunucu üzerindeki tüm instance’lar tarafından ortak kullanılan, instance’tan bağımsız bileşenlerdir (Integration Services, yönetim araçları vb.). Sunucuda kaç instance olursa olsun tek bir kopya kurulur ve hepsi tarafından paylaşılır.

Bu ayrımın Always On açısından pratik bir sonucu vardır: Always On yalnızca Database Engine düzeyinde çalışan bir yüksek erişilebilirlik teknolojisidir. Shared Features (SSIS gibi) veya ayrı instance’lar olarak çalışan Analysis Services, Always On Availability Group tarafından korunmaz. Bu bileşenlerin yüksek erişilebilirliği için ayrı stratejiler (WSFC üzerinde ayrı rol, yük dengeleme, yedekli kurulum vb.) gerekir.

Bileşen	Grup	Always On için gerekli mi?
Database Engine Services	Instance	✅ Zorunlu
SQL Server Replication	Instance	Bu kurulumda seçildi (opsiyonel)
Machine Learning Services	Instance	❌ Hayır
Full-Text and Semantic Extractions	Instance	❌ Hayır
PolyBase Query Service	Instance	❌ Hayır
Analysis Services	Instance	❌ Hayır
Integration Services (SSIS)	Shared	❌ Hayır
Reporting Services (SSRS)	Ayrı Kurulum	❌ Hayır

Özet: Always On Availability Group mimarisi için yukarıdaki bileşenlerden yalnızca Database Engine Services zorunludur. Diğerlerini yalnızca uygulama gereksinimleriniz varsa kurun. Gereksiz bileşen kurulumu; saldırı yüzeyini genişletir, kaynak (CPU, RAM, disk) tüketir, yama yükünü artırır ve her yeni bileşen ayrı bir güvenlik güncellemesi takibi demektir.

Kurulu Bileşenleri Nasıl Görürüm?

Bir sunucuda hangi SQL Server bileşenlerinin kurulu olduğunu görmek için en pratik yöntem, SQL Server Installation Center üzerindeki Discovery Report taracını çalıştırmaktır. Bu rapor, o sunucudaki tüm instance’ları ve kurulu özellikleri (sürüm, edisyon, clustered/standalone bilgisi dahil) tek bir HTML sayfasında listeler.

SQL Server Installation Center açıyoruz. Sol menüden Tools bölümüne geçiyoruz. Tools ekranında Installed SQL Server features discovery report seçeneğine tıklıyoruz. Bu işlem, arka planda kurulum motorunu çalıştırarak sunucudaki tüm SQL Server ürün ve bileşenlerini tarar.

Tarama tamamlandığında, kurulu tüm bileşenleri, sürüm ve edisyon bilgileriyle birlikte gösteren bir rapor açılır. Bu rapor %ProgramFiles%\Microsoft SQL Server\<sürüm>\Setup Bootstrap\Log\ dizinine SqlDiscoveryReport.htm adıyla da kaydedilir.

Alternatif (komut satırı): Aynı raporu komut satırından da üretebilirsiniz. Bir komut istemcisinde Setup.exe /Action=RunDiscovery çalıştırmanız yeterlidir. Komuta /q eklerseniz arayüz gösterilmeden rapor doğrudan yukarıdaki dizine oluşturulur.

Alternatif olarak, bir T-SQL oturumundan mevcut instance hakkında hızlı bilgi almak için:

SELECT SERVERPROPERTY('MachineName') AS Sunucu, 
SERVERPROPERTY('InstanceName') AS Instance, 
SERVERPROPERTY('ProductVersion') AS Surum, 
SERVERPROPERTY('Edition') AS Edisyon, 
SERVERPROPERTY('IsHadrEnabled') AS AlwaysOn_Aktif;

AlwaysOn_Aktif sütunu (yani IsHadrEnabled özelliği) 1 dönüyorsa, Always On Availability Groups özelliği o instance üzerinde etkinleştirilmiş demektir. Etkin değilse 0 döner. Bu özelliği etkinleştirme adımlarını Bölüm 4‘te ele alacağız.

Instance Adı NULL Dönüyorsa

Yukarıdaki sorguyu çalıştırdığınızda InstanceName sütununun NULL döndüğünü görebilirsiniz. Bu bir hata değildir: SQL Server’ın default instance (varsayılan örnek) olarak kurulduğu anlamına gelir. SERVERPROPERTY('InstanceName') yalnızca named instance’larda (örneğin SQLEXPRESS>) bir değer döndürür; default instance’ta ise NULL döner.

Default instance’ın gerçek servis adı MSSQLSERVER‘dır. Her iki durumda da anlamlı bir sonuç almak için sorguya ISNULL ekleyebilirsiniz:

SELECT
    SERVERPROPERTY('MachineName')       AS Sunucu,
    ISNULL(CAST(SERVERPROPERTY('InstanceName') AS nvarchar(128)), 'MSSQLSERVER') AS Instance,
    @@SERVERNAME                        AS TamAd,
    SERVERPROPERTY('ProductVersion')    AS Surum,
    SERVERPROPERTY('Edition')           AS Edisyon,
    SERVERPROPERTY('IsHadrEnabled')     AS AlwaysOn_Aktif;

ISNULL(..., 'MSSQLSERVER') ifadesi, default instance için gerçek servis adı olan MSSQLSERVER değerini döndürür.
@@SERVERNAME default instance’ta yalnızca makine adını, named instance’ta ise MAKINE\INSTANCE formatını verir.

Database Engine Services

SQL Server’ın çekirdek bileşenidir ve kurulumda seçilmesi zorunludur. Veritabanlarının oluşturulması, yönetilmesi ve çalıştırılmasından sorumludur. Yazının geri kalanında anlatılan tüm bileşenler ya bu motorun üzerine kurulur ya da onunla konuşur; Database Engine olmadan hiçbiri anlam ifade etmez.

Sorumlu olduğu temel işlevler:

Sorgu işleme ve transaction yönetimi
Kilitleme (locking) ve eşzamanlılık kontrolü (concurrency)
Loglama, güvenlik ve yetkilendirme
Backup ve restore işlemleri
Yüksek erişilebilirlik mekanizmaları (Failover Cluster, Always On)

Always On ile İlişkisi Neden Bu Kadar Temel?

Always On Availability Group, aslında Database Engine’in transaction log kayıtlarını bir replikadan diğerine göndermesi prensibine dayanır. Birincil replikada (primary) bir işlem gerçekleştiğinde, o işlemin log kayıtları ikincil replikalara (secondary) aktarılır ve orada yeniden uygulanır (redo). Bu mekanizmanın tamamı Database Engine içindeki şu bileşenler tarafından yürütülür:

Log Capture / Log Send: Birincil replikada log kayıtlarını yakalayıp ağ üzerinden gönderen iş parçacıkları
Log Receive / Redo: İkincil replikada gelen logları alıp veritabanına uygulayan iş parçacıkları
Database Mirroring Endpoint: Replikalar arası iletişimin gerçekleştiği, varsayılan olarak TCP 5022 portunu kullanan uç nokta

Yani “Always On kuruyoruz” dediğimizde, aslında Database Engine’in halihazırda sahip olduğu bu yetenekleri yapılandırıyoruz. Bu nedenle Feature Selection ekranında Always On diye ayrı bir kutucuk yoktur çünkü o, Database Engine’in bir özelliğidir, ayrı bir bileşen değildir.

Always On Availability Group mimarisinin temelini bu bileşen oluşturur. Database Engine Services olmadan ne replikasyon ne de Always On yapılandırılabilir.

SQL Server Replication

Seçilen veritabanı, tablo veya nesnelerin farklı SQL Server instance’larına çoğaltılmasını sağlayan teknolojidir. Raporlama sunucuları, uzak lokasyon senaryoları, yük dengeleme ve dağıtık veri mimarilerinde kullanılır.

Replikasyonun Always On’dan en temel farkı granülerliktir: Always On bir veritabanının tamamını bir bütün olarak korurken, Replication tek tek tabloları, hatta bir tablonun belirli sütunlarını veya satırlarını (filtered replication) hedefe taşıyabilir. Bu esneklik, onu farklı bir problem sınıfının çözümü yapar.

Replikasyon Türleri

Snapshot Replication: Verinin belirli bir andaki tam kopyasını (anlık görüntü) hedefe aktarır. Küçük ve seyrek değişen veri kümeleri için uygundur. Örneğin günde bir kez güncellenen bir ürün kataloğu veya döviz kuru tablosu için idealdir; her senkronizasyonda verinin tamamı yeniden yazılır.
Transactional Replication: Kaynak veritabanındaki değişiklikleri (INSERT, UPDATE, DELETE) neredeyse gerçek zamanlı olarak hedefe aktarır. Yüksek tutarlılık gerektiren senaryolarda kullanılır. Klasik kullanım örneği, üretim (OLTP) veritabanı üzerindeki raporlama yükünü ayrı bir sunucuya taşımaktır: raporlar replikadan çalışır, ana sunucu yalnızca işlem yüküyle ilgilenir.
Merge Replication: Hem kaynak hem de hedef tarafında yapılan değişikliklerin çift yönlü olarak birleştirilmesini sağlar. Bağlantının kesintili olduğu, çevrimdışı çalışılan senaryolar için uygundur. Örneğin sahada tablet ile çalışan satış ekiplerinin verileri, cihaz internete bağlandığında merkez veritabanıyla çift yönlü birleştirilir. Çakışma çözümleme (conflict resolution) mekanizması bu türe özgüdür.

Gerçek Hayat Senaryosu

Bir e-ticaret şirketini düşünün. Sipariş ve stok işlemleri Always On ile korunan bir OLTP veritabanında tutuluyor. Ancak yöneticiler, ağır raporlama sorgularının bu kritik veritabanını yavaşlatmasını istemiyor. Çözüm: sipariş tablolarını Transactional Replication ile ayrı bir raporlama sunucusuna kopyalamak. Böylece Always On veritabanın erişilebilirliğini, Replication ise raporlama yükünün ayrıştırılmasını sağlar. İki teknoloji birbirinin rakibi değil, tamamlayıcısıdır.

Always On ile ilişkisi: Replication ve Always On farklı amaçlara hizmet eder. Always On tüm veritabanının yüksek erişilebilirliğini sağlarken, Replication seçili nesnelerin dağıtımını sağlar. İkisi birlikte de kullanılabilir; bu kurulumda Replication ileride gerekebileceği düşünülerek kurulmuştur, ancak Always On’un çalışması için zorunlu değildir. Not: Always On ile Replication’ı birlikte kullanırken, failover sonrası publisher’ın yeniden yapılandırılmasıyla ilgili ek adımlar gerekebilir; bu ileri seviye bir konudur.

Machine Learning Services (In-Database)

SQL Server içerisinde Python ve R dillerini çalıştırarak, veritabanı motoru üzerinde doğrudan makine öğrenmesi ve istatistiksel analiz yapılmasını sağlar. Buradaki kilit fikir, veriyi modele değil, modeli veriye götürmektir: veri, SQL Server dışına (örneğin ayrı bir Python sunucusuna) hiç çıkarılmadan, motorun içinde analiz edilir.

Kullanım senaryoları:

Öngörücü modelleme (predictive modeling) örneğin müşteri kaybı (churn) tahmini
İstatistiksel analiz ve veri bilimi çalışmaları
Veritabanı içinde model eğitimi ve skorlama (in-database scoring)

Python, günümüzde veri bilimi ve makine öğrenmesi alanında en yaygın kullanılan dillerden biridir. R ise istatistiksel hesaplama ve grafik üretimi için geliştirilmiş, akademik ve analitik çevrelerde tercih edilen bir dildir.

Neden Veriyi Dışarı Çıkarmamak Önemli?

Büyük veri kümelerinde, milyonlarca satırı bir uygulama sunucusuna çekip orada işlemek hem ağ bant genişliğini tüketir hem de veri güvenliği açısından risk oluşturur (veri, korunan sınırın dışına çıkar). Machine Learning Services, skorlama işlemini verinin bulunduğu yerde yaptığı için bu iki sorunu da ortadan kaldırır. Örneğin bir bankada kredi risk skoru, müşteri verisi hiç veritabanından çıkmadan hesaplanabilir bu, veri yönetişimi (data governance) açısından ciddi bir avantajdır.

Bu bileşeni kullanmak için kurulumdan sonra sp_configure ile harici script çalıştırmanın etkinleştirilmesi gerekir:

EXEC sp_configure 'external scripts enabled', 1;
RECONFIGURE;

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Makine öğrenmesi iş yükleriniz yoksa kurmanıza gerek yoktur. Kurmanız halinde, çalıştırdığı harici script süreçlerinin (Launchpad servisi) ek bir saldırı yüzeyi oluşturduğunu unutmayın.

Full-Text and Semantic Extractions for Search

Metin tabanlı verilerde gelişmiş arama yapılmasını sağlayan bileşendir. Standart LIKE sorgularının ötesinde, dil bilgisel analiz ve anlamsal arama yetenekleri sunar.

LIKE '%kelime%' ile yapılan aramaların iki büyük sorunu vardır: index kullanamadıkları için büyük tablolarda çok yavaştırlar ve dilbilgisinden habersizdirler (“koştu”, “koşuyor”, “koşmak” kelimelerini birbiriyle ilişkilendiremezler). Full-Text Search bu iki sorunu da çözer.

Full-Text Search: Büyük metin alanlarında kelime ve ifade bazlı hızlı arama sağlar. Kelime kökü analizi (stemming), eş anlamlı kelime desteği (thesaurus) ve yakınlık aramaları (proximity search) yapılabilir. Örneğin CONTAINS operatörüyle “veritabanı” ararken, arka planda kelimenin çekimli hallerini de kapsayacak biçimde sorgulanabilir:

SELECT baslik, icerik
FROM Makaleler
WHERE CONTAINS(icerik, 'FORMSOF(INFLECTIONAL, "kurulum")');

Semantic Search: Belgeler arasındaki anlamsal benzerlikleri tespit eder. Örneğin bir belge kütüphanesinde benzer içerikli dokümanların bulunması veya CV/özgeçmiş havuzunda benzer profillerin eşleştirilmesi gibi senaryolarda kullanılır. Full-Text “hangi belgede bu kelime geçiyor” sorusunu yanıtlarken, Semantic Search “hangi belgeler birbirine konu olarak benziyor” sorusunu yanıtlar.

Not: Doküman yönetim sistemleri, içerik arama motorları ve büyük metin arşivleri olan uygulamalarda değerlidir.

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Ancak önemli bir ayrıntı: Full-Text catalog’lar, veritabanının bir parçasıdır ve Always On ile korunan bir veritabanında yer alıyorlarsa ikincil replikalara da taşınırlar. Yani Full-Text kullanan bir veritabanını Always On’a alırsanız, arama işlevi failover sonrası da çalışmaya devam eder.

PolyBase Query Service for External Data

PolyBase, SQL Server’ın harici veri kaynaklarına T-SQL ile erişmesini sağlayan bileşendir. Farklı platformlardaki verileri, sanki yerel bir tablodaymış gibi sorgulama imkanı sunar. Buradaki temel yaklaşım Data Virtualization‘dır: veriyi kopyalamadan (ETL yapmadan), bulunduğu yerde sorgulamak.

Erişilebilen harici kaynaklar:

Hadoop (HDFS)
Azure Blob Storage
Azure Data Lake
Diğer SQL Server, Oracle, Teradata, MongoDB gibi kaynaklar

Sağladığı avantajlar:

Veriyi taşımadan (ETL yapmadan) yerinde sorgulama
Farklı kaynaklardaki verileri tek bir T-SQL sorgusunda birleştirme
Büyük veri (Big Data) platformlarıyla entegrasyon

Gerçek Hayat Senaryosu

Bir lojistik firması, geçmiş sensör verilerini maliyet nedeniyle bir Azure Blob Storage’da parquet dosyaları olarak saklıyor; güncel operasyonel verilerse SQL Server’da. Analistlerin “bu ayki teslimatları geçen yılın aynı ayıyla karşılaştır” sorusunu yanıtlamak için normalde iki ayrı sistemden veri çekip birleştirmek gerekir. PolyBase ile analist, Blob Storage’daki eski veriyi harici tablo (external table) olarak tanımlar ve tek bir JOIN sorgusuyla iki kaynağı birleştirir veriyi hiç taşımadan.

Harici tablo, yerel tabloyla aynı sorguda birleştirilebilir

SELECT g.SiparisNo, g.Tutar, e.EskiTeslimatSuresi
FROM GuncelSiparisler AS g
JOIN dbo.ArsivTeslimatlar_External AS e
    ON g.MusteriID = e.MusteriID;

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Harici veri kaynaklarıyla çalışma ihtiyacınız yoksa kurmanıza gerek yoktur. PolyBase kendi servislerini (PolyBase Engine ve Data Movement Service) çalıştırır; bu servisler ek kaynak tüketir ve harici ağ bağlantıları gerektirdiği için güvenlik açısından ayrıca değerlendirilmelidir.

Analysis Services (SSAS)

Kurumsal iş zekası (Business Intelligence) ve çok boyutlu analiz çözümüdür. Büyük veri kümeleri üzerinde hızlı analitik sorgular çalıştırmak için tasarlanmıştır. Burada kritik nokta şudur: SSAS, Database Engine’den ayrı bir instance olarak kurulur ve çalışır. Yani teknik olarak “SQL Server” başlığı altında olsa da, kendi servisine, kendi bellek yönetimine ve kendi yedekleme mantığına sahip bağımsız bir üründür.

Sunduğu modeller:

Multidimensional (OLAP): Klasik küp (cube) tabanlı analiz modeli. Önceden hesaplanmış toplulaştırmalarla (pre-aggregated) çok büyük veri kümelerinde bile milisaniyeler içinde yanıt verir.
Tabular: Bellek içi (in-memory) tablo tabanlı modern analiz modeli. Power BI’ın da altında yatan VertiPaq motorunu kullanır; geliştirmesi daha kolaydır ve çoğu modern senaryo için önerilir.

Kullanım senaryoları:

Çok boyutlu raporlama ve analiz (satışları ürün × bölge × zaman kırılımında anında görmek)
Öngörücü modelleme ve veri madenciliği
Kar-zarar analizleri, satış trendleri, bütçe/gerçekleşme karşılaştırmaları

OLAP ve OLTP Farkı

Database Engine bir OLTP (Online Transaction Processing) sistemidir: çok sayıda küçük, hızlı işlemi (bir sipariş eklemek, bir stok güncellemek) yönetmek için optimize edilmiştir. SSAS ise bir OLAP (Online Analytical Processing) sistemidir: az sayıda ama devasa, çok boyutlu sorguyu (üç yıllık satışın bölgesel dağılımı) hızlıca yanıtlamak için optimize edilmiştir. İkisi farklı problemleri çözer; bu yüzden ayrı motorlardır.

Not: Power BI, Excel ve diğer raporlama araçları Analysis Services modelleri üzerinden veri çekebilir.

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Önemli: SSAS ayrı bir instance olduğu için Always On Availability Group tarafından korunmaz. SSAS’ın yüksek erişilebilirliği gerekiyorsa, WSFC üzerinde ayrı bir küme rolü veya yedekli SSAS kurulumu gibi farklı çözümler değerlendirilmelidir.

Integration Services (SSIS)

SQL Server Integration Services (SSIS), veri entegrasyonu ve ETL (Extract, Transform, Load) işlemleri için kullanılan platformdur. Farklı kaynaklardan veri çekme, dönüştürme ve hedefe yükleme süreçlerini yönetir.

Temel yetenekleri:

Farklı kaynaklardan (Excel, CSV, XML, diğer veritabanları) veri okuma
Veri temizleme, dönüştürme ve zenginleştirme
Zamanlanmış veri aktarım işleri (data pipeline)
Veri ambarı (Data Warehouse) yükleme süreçleri

Gerçek Hayat Senaryosu

Bir perakende zinciri, her gece 200 mağazadan gelen satış dosyalarını (kimi Excel, kimi CSV) merkezi veri ambarına yüklemek istiyor. SSIS ile kurulan bir paket (package): dosyaları klasörden okur, tarih formatlarını standartlaştırır, hatalı satırları ayıklayıp bir hata tablosuna yazar, geçerli satırları ambara yükler ve işlem bittiğinde bir e-posta raporu gönderir. Bu paket, SQL Server Agent ile her gece 02:00’de otomatik tetiklenir. Bu tür tekrar eden, çok kaynaklı veri akışları SSIS’in klasik kullanım alanıdır.

Scale Out Mimarisi

SSIS, büyük ölçekli ETL iş yüklerini dağıtmak için Scale Out mimarisini destekler:

Scale Out Master: İş yükünü koordine eden ve dağıtan ana bileşen
Scale Out Worker: İşleri fiilen çalıştıran işçi düğümler

Bu yapı sayesinde büyük ETL işleri birden fazla sunucuya dağıtılarak paralel çalıştırılabilir; tek bir sunucunun kapasitesiyle sınırlı kalmazsınız.

Not: SSIS bir Shared Feature‘dır instance’a bağlı değildir, sunucu genelinde çalışır.

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Ancak dolaylı bir ilişki vardır: SSIS paketlerinizi ve yapılandırmalarını sakladığınız SSISDB catalog veritabanı, Always On ile korunabilir. Bunun için SQL Server, SSISDB’nin Availability Group’a eklenmesini destekleyen özel bir mekanizma sunar; böylece failover sonrası SSIS ortamınız da erişilebilir kalır.

Reporting Services (SSRS)

SQL Server Reporting Services (SSRS), kurumsal raporlama çözümüdür. Veritabanındaki verileri kullanarak tablo, grafik ve pano (dashboard) biçiminde raporlar oluşturur, yayınlar ve yönetir.

Sağladığı imkanlar:

Sayfalanmış (paginated) raporlar oluşturma, özellikle yazdırılmaya uygun, sabit düzenli raporlar (fatura, bordro, resmi form)
Web tabanlı rapor portalı üzerinden yayınlama
Zamanlanmış rapor üretimi ve e-posta ile dağıtım (subscription)
Farklı formatlarda dışa aktarma (PDF, Excel, Word)

SSRS’in güçlü olduğu alan, Power BI’ın aksine piksel-hassas, sayfalanmış raporlardır. Bir faturanın her sayfada aynı düzende görünmesi, alt toplamların doğru yerde çıkması gereken senaryolarda hala tercih edilir.

Önemli: SSRS Artık Ayrı Kurulur

SQL Server 2016 sürümünden itibaren SSRS (SQL Server Reporting Services), SQL Server ana kurulum paketinden ayrılmıştır. Reporting Services kullanmak istiyorsanız Microsoft’un resmi sitesinden ayrı bir kurulum paketi (Microsoft SQL Server Reporting Services) olarak indirip kurmanız gerekir. Bu yüzden Feature Selection ekranında artık bir SSRS kutucuğu göremezsiniz. Aynı ayrılma durumu SQL Server Management Studio (SSMS) için de geçerlidir.

Always On ile ilişkisi: Yoktur. Bu kurulumda seçilmemiştir. Yine de SSRS’in kendi veritabanları (ReportServer ve ReportServerTempDB) Database Engine üzerinde tutulur ve bunlar Always On ile korunabilir; bu senaryo için Microsoft’un “scale-out deployment” rehberindeki adımlar izlenmelidir.

Management Tools (Yönetim Araçları)

SQL Server’ı yönetmek için kullanılan araçlar da artık ana kurulum paketinden ayrı olarak dağıtılmaktadır:

SQL Server Management Studio (SSMS): SQL Server’ı yönetmek için kullanılan temel grafik arayüzlü araçtır. Ayrı olarak indirilip kurulur. Availability Group oluşturma, izleme ve failover işlemlerinin büyük kısmını bu arayüzden yapacağız.
Azure Data Studio: Çapraz platform (Windows, macOS, Linux) çalışabilen, modern ve hafif bir veritabanı yönetim aracıdır. Notebook desteği ve eklenti mimarisiyle özellikle geliştiriciler arasında yaygındır.

Kurulum yazıları:

SQL Server Management Studio 22 kurulumu için: Microsoft SQL Server Management Studio 22 Kurulumu
SQL Server Management Studio 22 Çevrimdışı (Offline) Kurulumu için: SQL Server Management Studio 22 Çevrimdışı (Offline) Kurulumu
SQL Server Management Studio 22 Sessiz Kurulum (Silent Install) ile Dağıtmak için: SQL Server Management Studio 22 Sessiz Kurulum (Silent Install) ile Dağıtmak
SQL Server Management Studio 22.8.x Güncellemesi için: SQL Server Management Studio 22.8.x Güncellemesi

Hangi Bileşenleri Kurmalıyım?

Karar verirken şu ilkeyi izleyin: İhtiyaç duymadığınız hiçbir bileşeni kurmayın. Bu yalnızca bir düzen tercihi değil, temel bir güvenlik ve işletme prensibidir.

Senaryonuz	Kurmanız Gerekenler
Sadece Always On HA/DR	Database Engine Services
Always On + Replikasyon	Database Engine + SQL Server Replication
Veri ambarı / ETL süreçleri	+ Integration Services (SSIS)
İş zekası / OLAP raporlama	+ Analysis Services
Kurumsal raporlama	+ Reporting Services (ayrı kurulum)
Doküman/metin arama	+ Full-Text Search
Veri bilimi / ML	+ Machine Learning Services
Big Data / harici kaynak	+ PolyBase

Neden “Az Bileşen” Bir Güvenlik Prensibidir?

Kurduğunuz her bileşen, sistemde çalışan yeni bir servis, dinlenen yeni bir port veya yürütülen yeni bir kod yolu demektir. Bunların her biri:

Saldırı yüzeyini genişletir: Kullanmadığınız PolyBase’in Data Movement servisi bile, açık kaldığında potansiyel bir hedeftir.
Yama yükü getirir: Her bileşen ayrı güvenlik güncellemeleri alır. Kurduğunuz ama kullanmadığınız bir bileşen, yamasız kaldığında bilinen bir zafiyeti barındırmaya devam eder.
Kaynak tüketir: Her servis CPU, RAM ve bazen disk G/Ç tüketir; bu, asıl iş yükünüzden (Always On veritabanınız) çalınan kaynaktır.
Karmaşıklığı artırır: Sorun giderme sırasında incelenecek her ek bileşen, kök neden analizini zorlaştırır.

Güvenlik ilkesi (least functionality): Kurumsal ve production ortamlarında yalnızca aktif olarak kullanılacak bileşenleri kurmak, hem güvenlik hem de bakım kolaylığı açısından en iyi pratiktir. Bu, birçok güvenlik standardında (ör. CIS Benchmark’ları) “gereksiz özellikleri devre dışı bırak” maddesiyle doğrudan karşılık bulur.

Kurulum Sonrası Hızlı Doğrulama

Bileşen tercihlerinizi yaptıktan ve kurulumu tamamladıktan sonra, instance’ın beklediğiniz gibi yapılandığını tek bir sorgu ile doğrulayabilirsiniz:

Instance genel durumu

SELECT
    SERVERPROPERTY('MachineName')     AS Sunucu,
    SERVERPROPERTY('InstanceName')    AS Instance,
    SERVERPROPERTY('ProductVersion')  AS Surum,
    SERVERPROPERTY('Edition')         AS Edisyon,
    SERVERPROPERTY('IsHadrEnabled')   AS AlwaysOn_Aktif;

Kurulu servisleri işletim sistemi tarafından görmek için PowerShell’den:

Get-Service | Where-Object { $_.DisplayName -like "*SQL*" } |
    Select-Object DisplayName, Status, StartType

Bu iki kontrol, hem hangi bileşenlerin fiilen çalıştığını hem de Always On’a geçişe hazır olup olmadığınızı hızlıca gösterir.

Sonuç

Bu yazıda SQL Server 2025 Feature Selection ekranında karşımıza çıkan tüm bileşenleri; ne işe yaradıklarını, hangi gerçek senaryolarda kullanıldıklarını ve Always On ile ilişkilerini inceledik. Temel çıkarım nettir: Always On Availability Group mimarisi için yalnızca Database Engine Services bileşeni zorunludur. Diğer bileşenler güçlü yeteneklere sahiptir, ancak yalnızca gerçek bir ihtiyaç karşılığında kurulmalıdır, aksi halde güvenlik, performans ve bakım açısından bedel öderiz.

Bir başka önemli nokta da şudur: Analysis Services gibi ayrı instance olarak çalışan veya SSIS gibi Shared Feature olan bileşenler, Always On Availability Group tarafından doğrudan korunmaz; bunların yüksek erişilebilirliği ayrı planlanmalıdır. Buna karşılık Full-Text catalog, SSISDB ve SSRS veritabanları gibi Database Engine üzerinde duran yapılar, ilgili veritabanı Always On’a alındığında birlikte korunabilir.

Bir sonraki yazımızda, Always On mimarisine geçmeden önce SQL Server servisleri üzerinde yapılması gereken kritik ön hazırlıkları Enable Always On Availability Groups ayarını, servis hesaplarını ve protokol yapılandırmalarını ele alacağız.

Bölüm 4 – Always On Ön Hazırlık ve Servis Ayarları

Bir sonraki yazımızda görüşmek dileğiyle…