Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisini detaylı şekilde kurulum ve yapılandırma adımlarıyla inceleyecek; High Availability (Yüksek Erişilebilirlik) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli ön koşulları ele alacağız.

Daha önceki yazımızda

Microsoft SQL Server 2025 Failover Cluster Instance Kurulumu 1

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını başarıyla tamamladık.

Daha sonraki yazımızda

Microsoft SQL Server 2025 Failover Cluster Instance Kurulumu 2

W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulumu öncesi Cluster Shared Volumes (CSV) gereksinimleri, Failover Cluster Instance (FCI) mimarisine özgü teknik noktalar ve best practice yaklaşımlarını paylaşmıştık.

Bu yazımızda, W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulum adımlarını detaylı olarak alıyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server 2025 kurulumunu başlatıyoruz.

Kurulum sürecini başlattığımızda karşımıza SQL Server Installation Center ekranı gelir. Bu ekran, Microsoft SQL Server 2025 kurulum ve yönetim işlemlerinin merkezi olarak gerçekleştirildiği ana kontrol panelidir.

SQL Server Installation Center ekranında Installation menüsüne tıklayarak Microsoft SQL Server 2025 kurulum sürecini başlatıyoruz. Bu adım, yeni bir Microsoft SQL Server 2025 kurulumu yapmak veya mevcut bir kurulum üzerine ek özellikler eklemek için kullanılan temel giriş noktasıdır. Installation menüsü üzerinden başlatılan sihirbaz, sonraki adımlarda kurulum türü, lisanslama, özellik seçimi ve sistem yapılandırmasına yönelik adım adım ilerlememizi sağlar.

SQL Server Installation Center ekranında Installation menüsü karşımıza gelir.

SQL Server Installation Center ekranında Installation menüsü altında yer alan New SQL Server failover cluster installation seçeneğini işaretleyerek Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulum sürecini başlatıyoruz. Bu adım, cluster ortamında ilk node (primary node) üzerine SQL Server FCI kurulumu gerçekleştirmek için kullanılan ana başlangıç noktasıdır.

Bu seçenek seçildikten sonra kurulum sihirbazı otomatik olarak devreye girer ve sistem üzerinde gerekli Prerequisite (Önkoşul) kontrollerini gerçekleştirir. Donanım, işletim sistemi sürümü, Windows Server Failover Cluster (WSFC) bileşenleri, ağ yapılandırması ve Cluster Shared Volume (CSV) erişimi gibi kritik gereksinimler kontrol edilerek ortamın Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulumuna hazır olup olmadığı doğrulanır. Ön kontrollerin başarıyla tamamlanmasının ardından; ürün anahtarı, lisans sözleşmesi, instance yapılandırması, cluster kaynaklarının (Network Name, IP, disk seçimi), servis hesapları ve veritabanı dizinleri gibi temel kurulum adımlarına geçilerek kurulum süreci adım adım ilerletilir.

SQL Server Installation Center ekranında Microsoft SQL Server 2025 kurulumu için gerekli yapılandırma sürecinin başlatıldığını görüyoruz.

Bu aşamada kurulum sihirbazı devreye girerek sistem üzerinde ön hazırlık işlemlerini başlatır ve kurulumun sağlıklı şekilde ilerleyebilmesi için gerekli kontrolleri otomatik olarak gerçekleştirir.

Başlatılan bu yapılandırma süreci kapsamında; sistem uyumluluğu, gerekli bileşenler, donanım kaynakları ve işletim sistemi gereksinimleri detaylı olarak kontrol edilir. Herhangi bir eksiklik veya uyumsuzluk tespit edilmediği takdirde kurulum adımları sorunsuz şekilde ilerler ve Microsoft SQL Server 2025 kurulumu için lisanslama, Feature (Özellik) seçimi, servis hesapları ve servis yapılandırması gibi detaylı kurulum aşamalarına geçilmesine olanak sağlanır.

Edition ekranında Microsoft SQL Server 2025 kurulumu için gerekli olan lisans yapılandırmasını seçmemiz gerekir. Bu adımda, kurulacak sürümün lisans modeli belirlenir ve kurulum süreci buna göre devam eder.

Specify a free edition: Bu bölümde, lisans doğrulaması gerektirmeyen ücretsiz sürümlerden biri seçilerek kurulum başlatılabilir. Özellikle test, geliştirme ve eğitim amaçlı senaryolar için esnek bir başlangıç imkanı sunar.

• Enterprise: Enterprise Edition; maksimum performans, güvenlik ve ölçeklenebilirlik gerektiren kurumsal ortamlar için tasarlanmış en üst seviye sürümdür. Yapay zeka destekli veritabanı motoru, gelişmiş High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) yetenekleri ile kritik iş yüklerini şirket içi, bulut veya hibrit ortamlarda kesintisiz şekilde çalıştırmak üzere optimize edilmiştir.
• Standard: Standard Edition; performans, güvenlik ve maliyet arasında dengeli bir yapı sunar. Enterprise sürümüne kıyasla daha sade ancak kurumsal ihtiyaçları karşılayacak yeterli özellik setine sahiptir. Orta ölçekli işletmeler ve büyüyen yapılar için ideal bir tercihtir.
• Evaluation: Evaluation Edition, Enterprise sürümünün tüm özelliklerini içeren 180 günlük değerlendirme sürümüdür. Kurulum, mimari doğrulama ve performans testleri için uygundur. Süre sonunda lisanslama yapılması zorunludur.
• Enterprise Developer: Enterprise Developer Edition, Enterprise sürümündeki tüm özellikleri birebir içerir ancak yalnızca geliştirme ve test ortamlarında kullanılmak üzere lisanslanmıştır. Production (Üretim) ortamlarında kullanımı lisans koşulları gereği yasaktır.
• Standard Developer: Standard Developer Edition, Standard sürümün tüm yeteneklerini geliştiricilere sunar. Daha hafif iş yükleri için geliştirme ve test süreçlerinde tercih edilir ve Production (Üretim) ortamında kullanılamaz.
• Express: Express Edition, tamamen ücretsiz ve giriş seviyesi bir veritabanı çözümüdür. Öğrenme amaçlı çalışmalar, küçük ölçekli uygulamalar ve masaüstü tabanlı çözümler için idealdir. SQL Server 2025 (17.x) Express Edition ile birlikte ilişkisel veritabanı için maksimum desteklenen boyut 50 GB’a yükseltilmiştir. Ayrıca daha önce ayrı olarak sunulan Express Edition with Advanced Services (SQLEXPRADV) sürümü kaldırılmış ve bu sürümdeki tüm özellikler tek bir birleşik Express paketi altında standart olarak sunulmuştur. SQL Server Express LocalDB ise geliştiriciler için hafif, hızlı kurulan, kullanıcı modunda çalışan ve sıfır konfigürasyon gerektiren bir varyant olarak öne çıkar.

SQL Server Express Edition, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisini desteklemez. Kurulum sihirbazında Express Edition seçeneği görüntüleniyor olsa dahi, bu sürüm Windows Server Failover Cluster (WSFC) entegrasyonu gerektiren herhangi bir High Availability (Yüksek Erişilebilirlik) özelliğini içermez.

SQL Server Express Edition; Failover Cluster Instance (FCI) kurulumu, SQL ServerAlways On Availability Group oluşturma, Replica tanımlama, Automatic Failover (Otomatik Yük Devretme) mekanizmaları ve SQL Listener gibi SQL Server Always On Availability Group bileşenlerini desteklemez. Bu nedenle Express sürümü, hem Failover Cluster Instance (FCI) hem de SQL ServerAlways On Availability Group mimarilerinde kullanılamaz.

SQL Server Express, tek sunucu üzerinde çalışan, sınırlı kaynak kullanımına sahip ve temel veritabanı ihtiyaçlarını karşılamaya yönelik bir sürüm olarak konumlandırılmıştır. High Availability (Yüksek Erişilebilirlik) ve Kurumsal Süreklilik gerektiren senaryolarda ise SQL Server Standard, Enterprise veya Developer sürümlerinden birinin tercih edilmesi gerekmektedir.

Use pay-as-you-go billing through Microsoft Azure: Bu seçenek tercih edildiğinde SQL Server 2025 kurulumu Microsoft Azure hesabı ile ilişkilendirilir ve lisanslama kullandıkça öde (pay-as-you-go) modeliyle gerçekleştirilir. Ürün anahtarı girilmez; kullanım süresi ve kaynak tüketimi Azure üzerinden ölçülerek aylık faturalandırılır.

Enter the product key: Geçerli bir SQL Server lisans anahtarına sahip olunması durumunda bu seçenek kullanılır. Ürün anahtarı sistem tarafından otomatik algılanabilir veya manuel olarak girilerek lisans doğrulaması tamamlanır.

• I have a SQL Server license with Software Assurance or SQL Software Subscription: Bu seçenek, Software Assurance veya SQL Server Subscription modeli kapsamında lisans sahibi olan kurumlar içindir. Sürüm yükseltme hakları, ek destek avantajları ve esnek kullanım senaryoları nedeniyle kurumsal ortamlarda yaygın olarak tercih edilir.
• I have a SQL Server license only: Daha önce Perpetual (Bağımsız) olarak satın alınmış bir Microsoft SQL Server 2025 lisansına sahip kullanıcılar için kullanılır. Kurulum sırasında ürün anahtarı manuel olarak girilerek lisanslama işlemi tamamlanır.

Edition ekranında Microsoft SQL Server 2025 kurulumu için gerekli olan lisans yapılandırmasını seçmemiz gerekir. Bu adımda, kurulacak sürümün lisans modeli belirlenir ve kurulum süreci buna göre devam eder.

Specify a free edition: Bu bölümde, lisans doğrulaması gerektirmeyen ücretsiz sürümlerden biri seçilerek kurulum başlatılabilir. Özellikle test, geliştirme ve eğitim amaçlı senaryolar için esnek bir başlangıç imkanı sunar.

• Evaluation: Evaluation Edition, Enterprise sürümünün tüm özelliklerini içeren 180 günlük değerlendirme sürümüdür. Kurulum, mimari doğrulama ve performans testleri için uygundur. Süre sonunda lisanslama yapılması zorunludur.
• Enterprise Developer: Enterprise Developer Edition, Enterprise sürümündeki tüm özellikleri birebir içerir ancak yalnızca geliştirme ve test ortamlarında kullanılmak üzere lisanslanmıştır. Production (Üretim) ortamlarında kullanımı lisans koşulları gereği yasaktır.
• Standard Developer: Standard Developer Edition, Standard sürümün tüm yeteneklerini geliştiricilere sunar. Daha hafif iş yükleri için geliştirme ve test süreçlerinde tercih edilir ve Production (Üretim) ortamında kullanılamaz.
• Express: Express Edition, tamamen ücretsiz ve giriş seviyesi bir veritabanı çözümüdür. Öğrenme amaçlı çalışmalar, küçük ölçekli uygulamalar ve masaüstü tabanlı çözümler için idealdir. SQL Server 2025 (17.x) Express Edition ile birlikte ilişkisel veritabanı için maksimum desteklenen boyut 50 GB’a yükseltilmiştir. Ayrıca daha önce ayrı olarak sunulan Express Edition with Advanced Services (SQLEXPRADV) sürümü kaldırılmış ve bu sürümdeki tüm özellikler tek bir birleşik Express paketi altında standart olarak sunulmuştur. SQL Server Express LocalDB ise geliştiriciler için hafif, hızlı kurulan, kullanıcı modunda çalışan ve sıfır konfigürasyon gerektiren bir varyant olarak öne çıkar.

SQL Server Express Edition, yalnızca Stand-alone (Tek Sunucu) çalışacak şekilde tasarlanmıştır ve Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinin gerektirdiği hiçbir High Availability (Yüksek Erişilebilirlik) bileşenini desteklemez.

Bu kapsamda SQL Server Express Edition, aşağıdaki FCI gereksinimlerini karşılamaz:

• Microsoft SQL Server 2025 Failover Cluster Instance (FCI) özelliği Express Edition’da bulunmaz
• Windows Server Failover Cluster (WSFC) entegrasyonu desteklenmez
• Database Mirroring ve Availability Group (AG) replica yetenekleri yer almaz
• Readable Secondary, Automatic Failover ve Listener gibi AG bileşenleri Express sürümünde mevcut değildir
• Bu nedenle, kurulum ekranında Express Edition listeleniyor olsa bile, bu sürüm:
• Failover Cluster Instance (FCI)
• Always On Availability Group (AG)

mimarilerinin hiçbirinde kullanılamaz.
Hangi Sürümler Kullanılabilir?
Always On Availability Groups (AG):

• Standard Edition (Kısıtlı Özelliklerle)
• Enterprise Edition (Tam Özellik Seti)
• Developer Edition (Enterprise Özellikleri – Yalnızca Test/Geliştirme Ortamları için)

Failover Cluster Instance (FCI):

• Standard Edition
• Enterprise Edition
• Developer Edition
• Evaluation Edition

Özetle, SQL Server Express Edition, High Availability (Yüksek Erişilebilirlik) gerektiren Failover Cluster Instance (FCI) veya SQL Server Always On Availability Group senaryoları için uygun değildir. Bu tür mimarilerde, Microsoft SQL Server 2025 Standard, Enterprise veya Developer sürümlerinden biri tercih edilmelidir.

Edition ekranında Enter the product key bölümünde, Microsoft SQL Server 2025 lisansımız sistem tarafından otomatik olarak algılanıp görüntülendiği için bu alanda herhangi bir değişiklik yapmıyoruz. Mevcut lisansımız Perpetual (Bağımsız) Microsoft SQL Server 2025 lisansı olduğundan, lisanslama türünü doğru şekilde belirtmek için I have a SQL Server license only seçeneğini işaretliyoruz.

Edition ekranında gerekli lisans yapılandırmasını tamamladıktan sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz. Bu adımla birlikte kurulum sihirbazı, lisans doğrulamasını tamamlayarak özellik seçimi ve sistem yapılandırmasına yönelik adımlara ilerlememizi sağlar.

License Terms ekranında Microsoft SQL Server 2025 kurulumunun devam edebilmesi için lisans sözleşmesi ve gizlilik bildirimini inceleyerek I accept the license terms and Privacy Statement seçeneğini işaretleyip kabul etmemiz gerekir.

License Terms ekranında lisans koşullarını onayladıktan sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

Global Rules, Product Updates ve Install Setup Files ekranlarında kurulum için gerekli yapılandırmalar sırasıyla kontrol edilir.

• Global Rules ekranında kurulumun başlatılabilmesi için sistem genelinde gerekli olan temel ön koşullar değerlendirilir ve olası engelleyici durumlar tespit edilir.
• Product Updates ekranında Microsoft SQL Server 2025 kurulumu sırasında gerekli olan güncelleştirmeler denetlenir ve seçilen ayarlara bağlı olarak en güncel güncelleştirmeler indirilip kuruluma dahil edilir.
• Install Setup Files ekranında ise Microsoft SQL Server 2025 kurulum dosyaları sisteme kopyalanır ve kurulum sihirbazının ilerleyen adımlarında kullanılacak altyapı hazırlanır.

Bu kontroller ve gerekli güncelleştirme/yüklemeler başarıyla tamamlandıktan sonra, kurulum sihirbazı otomatik olarak Install Failover Cluster Rules ekranına yönlendirir.

Install Failover Cluster Rules ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumunun devam edebilmesi için ortamda gerekli olan tüm ön koşullar ve yapılandırmalar detaylı olarak kontrol edilir. Bu aşamada; Windows Server Failover Cluster (WSFC) durumu, Cluster Shared Volume (CSV) erişimi, ağ yapılandırması ve cluster bileşenlerinin uyumluluğu doğrulanır.

Kontrollerin tamamlanmasının ardından tüm maddelerin Passed olarak işaretlendiğini görüyoruz. Bu durum, ortamın Microsoft SQL Server 2025 Failover Cluster kurulumu için hazır olduğunu ve kurulum sürecinin bir sonraki adıma sorunsuz şekilde ilerleyebileceğini gösterir.

Not: Bu aşamada bazı ortamlarda ile ilgili uyarı (Warning) veya bilgilendirme mesajları ile karşılaşılabilir. Bu mesajlar her zaman kritik bir hata anlamına gelmeyebilir; ancak detayları dikkatlice incelenmeli ve gerekiyorsa cluster doğrulama (Validate Cluster) testleri tekrar çalıştırılarak ortamın desteklenebilirliği teyit edilmelidir.

Install Failover Cluster Rules ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumunun devam edebilmesi için gerekli olan tüm cluster ön koşulları kontrol edilir. Görüldüğü üzere kontrollerin tamamına yakını Passed durumundadır ve kurulumu engelleyen herhangi bir Failed (Kritik Hata) bulunmamaktadır.

Install Failover Cluster Rules ekranında karşılaşılan Microsoft Cluster Service (MSCS) cluster verification warnings uyarısı, Windows Server Failover Cluster (WSFC) doğrulama testlerinin daha önce çalıştırıldığını ancak bazı testlerin Warning ile sonuçlandığını veya bazı doğrulama adımlarının Skipped (atlanmış) olabileceğini ifade eder.

Install Failover Cluster Rules ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumunun devam edebilmesi için gerekli olan tüm cluster ön koşulları kontrol edilir. Görüldüğü üzere kontrollerin tamamına yakını Passed durumundadır ve kurulumu engelleyen herhangi bir Failed (Kritik Hata) bulunmamaktadır.

Install Failover Cluster Rules ekranında karşılaşılan Microsoft Cluster Service (MSCS) cluster verification warnings uyarısı, Windows Server Failover Cluster (WSFC) doğrulama testlerinin daha önce çalıştırıldığını ancak bazı testlerin Warning ile sonuçlandığını veya bazı doğrulama adımlarının Skipped (atlanmış) olabileceğini ifade eder.

Bu uyarı, kurulumu engelleyen bir hata değildir ve SQL Server Failover Cluster Instance (FCI) kurulumunun devam etmesine izin verir. Ancak desteklenebilirlik ve en iyi uygulamalar açısından, Failover Cluster Manager üzerinden Validate Cluster sihirbazının yeniden çalıştırılması ve oluşan Cluster Validation Report’un incelenmesi önerilir. Raporda Error seviyesinde bir problem bulunmadığı sürece, SQL Server Failover Cluster Instance (FCI) kurulumuna güvenle devam edilebilir.

Install Failover Cluster Rules ekranında yapılan kontrollerin başarıyla tamamlandığını gördükten sonra, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulumuna devam etmek için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Bu adım ile birlikte, SQL Server Failover Cluster Instance (FCI) kurulum sihirbazı bir sonraki yapılandırma ekranına ilerler ve kurulum süreci planlanan şekilde devam eder.

Feature Selection ekranında Microsoft SQL Server 2025 kurulumunda hangi bileşenlerin ve servislerin kurulacağını belirlediğimiz kritik yapılandırma adımıdır. Bu ekranda özellikle Database Engine Services bileşeninin seçilmesi zorunludur; çünkü SQL Server’ın temel veritabanı işlevlerini sağlayan ana servisidir. Diğer servisler ve özellikler ise ortamın gereksinimlerine, kullanım senaryosuna ve SQL Server’ın hangi amaçla yapılandırılacağına bağlı olarak isteğe bağlı şekilde seçilir.

Ayrıca, Microsoft SQL Server 2016 sürümünden önce SQL Server Management Tools ve SQL Server Reporting Services (SSRS) bileşenleri Microsoft SQL Server 2025 kurulum ISO’su içerisinde yer almakta ve kurulumla birlikte yüklenmekteydi. Ancak SQL Server 2016 sürümüyle birlikte mimari değişikliğe gidilmiş ve SQL Server Management Studio (SSMS) ile SQL Server Reporting Services (SSRS) artık Microsoft SQL Server 2025 kurulum paketinden bağımsız olarak yayımlanmaya başlamıştır. Bu nedenle SQL Server 2025 kurulumunda da SQL Server Management Studio (SSMS) ve SQL Server Reporting Services (SSRS) bileşenleri Microsoft’un resmi sitesinden ayrıca indirilip kurulmalıdır.

Instance Features: SQL Server Instance Features, SQL Server’ın kurulumunda işletim sistemine özel olarak yapılandırılabilen ve her bir Instance için ayrı ayrı çalışan çeşitli özellikler sunar. Bu özellikler, SQL Server’ın performansını, yönetilebilirliğini ve güvenilirliğini artırmak için tasarlanmıştır. Her bir SQL Server Instance’ı bağımsız olarak çalışabildiğinden, farklı veri tabanları ve uygulamalar için ayrı Instance’lar oluşturulabilir ve bu Instance’lar üzerinde çeşitli özellikler etkinleştirilebilir. Örneğin Database Engine, veritabanı yönetimi ve veri sorgulama işlemlerinin temel bileşenidir ve her Instance’da bağımsız olarak yapılandırılabilir. Integration Services, veri entegrasyonuna yönelik işlemleri yürütmek için tasarlanmıştır ve ETL (Extract, Transform, Load) süreçlerinde kullanılan güçlü bir araçtır. Reporting Services ise, kurumların veriye dayalı raporlar oluşturmasına olanak tanır ve kullanıcıların ihtiyaçlarına uygun raporlar hazırlamasını sağlar. Başka bir örnekte ise PolyBase, SQL Server’ın dış veri kaynaklarına bağlanmasını sağlarken Analysis Services, büyük veri kümelerinde çok boyutlu analiz ve tahmin modelleri kurmak için kullanılır. Her bir SQL Server Instance’ı bu özelliklerin yapılandırılmasını ve kullanımını destekler, böylece kullanıcılar aynı sunucu üzerinde farklı Instance’lar kurarak her biri için özelleştirilmiş veri çözümleri oluşturabilir. SQL Server Instance Features, esneklik ve ölçeklenebilirlik sağlayarak, veri yönetimi ve analitik süreçlerde kullanıcıların ihtiyaçlarına uygun çözümler geliştirmesine olanak tanır.

Database Engine Services: Database Engine, SQL Server’ın en temel bileşenidir ve veritabanı yönetimini mümkün kılmak için zorunlu bir bileşendir. SQL Server’ın diğer servisleri isteğe bağlı olarak kurulabilirken, Database Engine olmadan sistemin işleyişi sağlanamaz. Yönetici olarak erişilen bu servis, veritabanı işlemleri üzerinde Authentication (Kimlik Doğrulama) seçenekleriyle kullanıcıları yönetir.

Database Engine’ın Temel Bileşenleri: Database Engine yapısı, Storage Engine ve Query Processor olmak üzere iki önemli bileşen üzerine kuruludur.

• Storage Engine: Verilerin Disk gibi depolama birimlerine yazılmasından ve gerektiğinde bu birimlerden alınmasından sorumludur. Storage Engine, verilerin güvenli ve tutarlı bir biçimde saklanmasını sağlar, veritabanı performansının temelini oluşturur.
• Query Processor: SQL sorgularının işlenmesinden ve çözülmesinden sorumludur. Örneğin, bir kullanıcı bir SELECT komutu ile veri sorgulamak istediğinde, Query Processor devreye girer ve gerekli Data’ları ilgili dosyalardan getirir. Bu dosyalar genellikle .mdf (Primary Data File) uzantısına sahiptir. Bir veritabanı sorgulaması yapılmak istendiğinde Query Processor, doğrudan SELECT komutunu ele alır ve bu talebi Storage Engine ile iş birliği içinde yürütür. Sorgulanan veriler, güvenli ve hızlı bir şekilde kullanıcıya ulaştırılır; bu işlem sırasında her iki bileşenin de kusursuz çalışması, Database Engine’in performansını belirleyen unsurlar arasındadır. Bu temel bileşenler, SQL Server üzerinde çalışacak tüm uygulamaların temelini oluşturarak veritabanı sistemlerinin yüksek performans ve güvenlik sunmasını sağlar.

SQL Server Replication: SQL Server Replication, bir veritabanını veya veritabanı tablolarını başka bir sunucuya düzenli olarak replike etmek için kullanılan bir teknolojidir. Bu çözüm, verilerin yüksek erişilebilirliğini (High Availability (Yüksek Erişilebilirlik) sağlamak amacıyla uygulanan yöntemlerden biridir. High Availability (Yüksek Erişilebilirlik) çözümleri arasında yer alan Replication, daha gelişmiş bir teknoloji olan Always ON devreye girmeden önce SQL Server Failover Cluster Instance (FCI) ve Database Mirroring gibi yöntemlerle destekleniyor.

SQL Server Replication Türleri ve Özellikleri: SQL Server Replication, farklı veri dağıtım ihtiyaçlarına göre çeşitli türlere ayrılır:

• Snapshot Replication: Snapshot Replication, belirli bir anlık görüntüyü alıp, bu veriyi başka bir sunucuya aktarır. Düzenli değişiklik gerektirmeyen ya da nadir güncellenen veri yapılarında kullanımı uygundur.
• Transactional Replication: Transactional Replication, asıl sunucudaki değişikliklerin anında veya çok kısa gecikmelerle replike edilmesi amacıyla tercih edilir. Özellikle veri değişiminin sürekli olduğu senaryolarda ideal bir çözümdür. Bu yapıda her değişiklik bir Transaction olarak ele alınır ve hedefe aktarılır.
• Merge Replication: Merge Replication, verilerin çift yönlü senkronizasyonunu sağlar. Farklı konumlarda yapılan güncellemelerin birleştirildiği bu çözüm, özellikle dağıtık veri yapıları için uygundur.

SQL Server Replication Kullanım Amacı ve Avantajları (Failover Cluster Instance (FCI) Perspektifi): SQL Server Replication’ın sunduğu en önemli avantajlardan biri, verilerin Failover Cluster Instance (FCI) üzerinde çalışan ana SQL Server instance’ından bağımsız bir hedef sunucuya aktarılabilmesi ve bu sunucu üzerinde ayrı iş yükleriyle kullanılabilmesidir. Failover Cluster Instance mimarisinde Failover Cluster Instance (FCI), High Availability (Yüksek Erişilebilirlik) sağlarken; Replication, raporlama ve benzeri okuma ağırlıklı senaryolar için ek bir esneklik sunar. Replike edilen veriler üzerinde bağımsız index yapıları oluşturulabilmesi, raporlama performansını artırır ve Failover Cluster Instance (FCI) üzerindeki aktif Node’un işlem yükünü önemli ölçüde azaltır.

SQL Server Failover Cluster Instance (FCI) ve High Availability (Yüksek Erişilebilirlik) Çözümleri ile Kıyaslama: Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi, sunucu ve instance seviyesinde High Availability (Yüksek Erişilebilirlik) sağlamak üzere tasarlanmıştır. Ancak Failover Cluster Instance (FCI), verinin farklı bir sunucuya kopyalanmasını değil, aynı Cluster Shared Volumes (CSV) üzerinde çalışan instance’ın Node’lar arasında taşınmasını hedefler. Bu noktada Replication, Failover Cluster Instance (FCI) mimarisini tamamlayıcı bir rol üstlenir. Özellikle raporlama, veri dağıtımı veya coğrafi olarak farklı lokasyonlara veri aktarımı gerektiren senaryolarda, Transactional Replication ile düşük gecikmeli veri transferi sağlanabilir. Anlık veri tutarlılığının kritik olmadığı durumlarda Replication, Failover Cluster Instance (FCI) ile birlikte kullanıldığında hem High Availability (Yüksek Erişilebilirlik) hem de operasyonel esneklik sunar. Bu yönüyle Replication; raporlama, yedekleme dışı veri kopyalama ve yük dağıtımı gibi senaryolarda Failover Cluster Instance (FCI) mimarisi için ideal bir tamamlayıcı çözüm olarak öne çıkar.

Machine Learning Services (In-Database): SQL Server’daki Machine Learning Services, Relational Data Model içinde Python ve R yazılım dillerinde Script’ler çalıştırmaya olanak tanıyan yenilikçi bir özelliktir. Bu özellik sayesinde veriler, SQL Server dışına çıkmadan doğrudan veritabanı ortamında analiz edilip işlenebilir. Özellikle büyük veri kümeleri üzerinde yapılan analizlerde, veriyi Network dışına taşımadan işleyebilmek hem güvenliği artırır hem de hız kazandırır.

• In-Database Script Çalıştırma : Machine Learning Services ile çalışan Script’ler, SQL Server’ın sağladığı in-database olanakları sayesinde veriyi sunucu içinde işleyebilir. Bu durum, analiz için dışarıya veri çıkarmaya gerek kalmadan tüm işlemleri veritabanı içerisinde yürütmeyi sağlar. Verilerin in-database tutulması, özellikle hassas ve gizlilik gerektiren veri analizlerinde büyük bir avantaj sunar.
• R Programlama Dili ile İstatistiksel Analiz : SQL Server’daki Machine Learning Services bünyesinde R dili, istatistiksel analiz ve görselleştirme için güçlü bir araç olarak öne çıkar. R dili, R Foundation tarafından desteklenen ve GNU projesi kapsamında özgür yazılım olarak sunulan, istatistiksel hesaplama için geniş bir kütüphane desteğine sahip bir programlama dilidir. R Script’leri, SQL Server ortamında çalıştırılarak doğrudan veri üzerinde istatistiksel analiz yapılmasına olanak tanır. Bu özellik, veri bilimciler için veriyi dışarıya çıkarmadan analiz yapmayı kolaylaştırır.
• Python Programlama Dili ile Makine Öğrenimi : Python, Machine Learning Services ile SQL Server’da kullanılabilen diğer bir dildir ve makine öğrenimi algoritmalarının çalıştırılmasında oldukça etkilidir. 90’ların başında Guido Van Rossum tarafından geliştirilmeye başlanan Python, nesne yönelimli, yorumsal ve modüler yapısıyla kullanıcı dostu bir dil olarak bilinir. Python’un yüksek seviyeli yapısı, Machine Learning modellerinin SQL Server’da in-database çalıştırılabilmesine olanak tanır. Böylece, veriyi SQL Server dışına çıkarmadan makine öğrenimi modelleri doğrudan veri üzerinde uygulanabilir.

Machine Learning Services Avantajları: Machine Learning Services (In-Database), veriyi SQL Server içerisinde güvenli ve hızlı bir şekilde analiz edebilme imkanı sağlar. Hem Python hem de R desteği sayesinde kullanıcılar istatistiksel analiz, makine öğrenimi ve veri görselleştirme gibi farklı ihtiyaçlarını SQL Server ortamında çözebilir. Özellikle büyük veri setleri ve gizlilik gerektiren projeler için in-database analiz büyük bir kolaylık ve güvenlik avantajı sunmaktadır.

Full-Text and Sematic Extractions for Search: SQL Server’da Full-Text Search, büyük metin içeren varchar(max) gibi kolonlarda hızlı ve kapsamlı arama yapmayı sağlar. Full-Text Search, metin içerisindeki kelimeleri analiz ederek verimli arama yapma yeteneğine sahip bir yapıdır. Kelimelere özel indeksler oluşturur ve bu indeksler üzerinden sorguları işleyerek belirli anahtar kelimeleri içeren kayıtları hızlıca bulur. Özellikle yoğun metin içeren kolonlarda performans sağlamak için kullanılır ve aramayı optimize eder.

• Semantic Search: Anlam Bütünlüğüne Dayalı Arama : Full-Text Search’ün bir adım ötesine geçen Semantic Search, SQL Server’ın metin tabanlı arama yeteneklerini daha anlam odaklı hale getirir. Bu özellik, metinlerde sadece anahtar kelime aramakla kalmaz; aynı zamanda kelimelerin anlam bağlamını analiz eder. Semantic Search, kelimeler arasındaki ilişkiyi inceleyerek, dökümanın genel anlamını çözümleyebilir. Böylece yapılan aramalar, kelime bazlı kısıtlamalardan çıkarak içeriklerin anlam bütünlüğü üzerine kurulu hale gelir. Özellikle dosya bazlı veri saklamalarında, örneğin bir CV veri tabanında belirli yetkinlikleri veya becerileri aramak gibi daha sofistike sorgular için kullanışlıdır.
• Semantic Search için Gereklilikler : Semantic Search kullanımı için Semantic Language Statistics Database’in indirilip SQL Server’a attach edilmesi ve register edilmesi gerekir. Bu veritabanı, SQL Server’ın anlam tabanlı analizler yapabilmesini sağlayan dil istatistiklerini içerir. Kurulumdan sonra, verilerinizde anlam bazlı arama işlemlerini daha kapsamlı bir şekilde gerçekleştirmek mümkün olur.
• Kullanım Senaryoları : Özellikle IK departmanları, Semantic Search’ü kullanarak veritabanında bulunan CV’leri anlamlarına göre sorgulamak için bu özelliği tercih edebilir. Örneğin, bir CV içerisindeki belirli becerilerin ya da deneyimlerin aranması gerektiğinde, Semantic Search dökümanın tamamındaki bağlama göre arama yaparak, daha kapsamlı sonuçlar sunar. Bu sayede sadece belirli anahtar kelimeleri değil, dökümanın bütünsel anlamını dikkate alarak arama yapılabilir. Full-Text ve Semantic Search, SQL Server’da gelişmiş metin aramaları yapabilmeyi mümkün kılar ve büyük metin veri tabanlarında anlam bazlı analizler yaparak kapsamlı sonuçlar sağlar.

PolyBase Query Service for External Data: PolyBase Query Service for External Data, SQL Server’ın farklı veri kaynaklarıyla doğrudan ve kolayca iletişim kurmasını sağlayan güçlü bir özelliktir. Bu özellik sayesinde SQL Server, heterojen yapıda olan, yani farklı platformlarda yer alan veri kaynaklarına erişim sağlayabilir. Hadoop ve Microsoft Azure gibi farklı yapılardaki veri kaynaklarıyla entegrasyonu mümkün hale getiren PolyBase, büyük veri ve bulut çözümleriyle uyumlu bir şekilde çalışır. Yönetimi, T-SQL komutları ile yapılır ve oldukça esneklik sunar.

PolyBase’in Temel Bileşenleri: PolyBase, SQL Server Polybase Engine Service ve SQL Server Polybase Data Movement Service olmak üzere iki ana hizmet üzerinden çalışır :

• SQL Server Polybase Engine Service: Bu hizmet, dış veri kaynaklarına yönelik paralel sorgu planları oluşturmak, yürütmek ve sonuçlarını sorgulamak için kullanılır. Özellikle büyük veri kaynaklarına erişim sağlarken paralel işleme imkanı sunması sayesinde performansı artırır. Bu bileşen, farklı kaynaklardan gelen verileri SQL Server ortamında tek bir sorguda birleştirerek işlemlerin hızlı ve verimli bir şekilde yapılmasını sağlar.
• SQL Server Polybase Data Movement Service: Dış veri kaynaklarıyla SQL Server arasında veri transferini sağlamak ve bu iletişimi yönetmek için kullanılan bu hizmet, Instance seviyesinde çalışır. Yani, veri hareketi SQL Server’ın bulunduğu Instance üzerinden gerçekleşir ve SQL Server ile dış kaynaklar arasında köprü görevi görür.

Farklı Veri Yapılarıyla Entegrasyon: PolyBase’in en büyük avantajlarından biri, farklı veri yapılarında saklanan bilgilere doğrudan erişim sağlamasıdır. Bu özellik, SQL Server kullanıcılarının Hadoop ve Microsoft Azure gibi platformlardaki verilere SQL sorguları ile ulaşabilmesine olanak tanır. Örneğin, Hadoop üzerinde büyük bir veri kümesi varsa, bu veri SQL Server ortamına taşınmadan PolyBase ile sorgulanabilir ve analiz edilebilir. Aynı şekilde, bulut platformlarındaki verilere de PolyBase sayesinde erişmek mümkündür, böylece büyük veriyi SQL Server altyapısına yüklemeden analiz etme imkanı sunar.

Kullanım Alanları: PolyBase, SQL Server kullanıcıları için veri analizinde büyük kolaylık sağlar. Özellikle büyük veri analitiği ve bulut platformlarıyla entegre çalışması gereken sistemler için PolyBase ideal bir çözüm sunar. Farklı kaynaklarda yer alan verilerin birleştirilmesi ve analiz edilmesi gereken projelerde, veri taşımaya gerek kalmadan veriye hızlıca erişim sağlamak, PolyBase’in en önemli avantajlarından biridir. PolyBase Query Service for External Data, SQL Server’ın veri entegrasyon yeteneklerini genişleterek, heterojen veri kaynaklarına sorunsuz bir erişim ve yönetim sağlar.

PolyBase ile Neler yapabilirsiniz: PolyBase, SQL Server veya Parallel Data Warehouse (PDW) üzerinden T-SQL kullanarak büyük veri ve bulut ortamlarında yer alan verilere doğrudan erişim sağlar. Farklı platformlarda saklanan büyük veri kümelerine kolayca ulaşabilmek için PolyBase ile yapılabilecekler oldukça geniş bir yelpazeye sahiptir.

• Hadoop Üzerindeki Veriyi Sorgulama : PolyBase sayesinde SQL Server veya PDW üzerinden T-SQL sorgularını kullanarak Hadoop üzerindeki verilere doğrudan ulaşabiliriz. Bu özellik, veriyi SQL Server’a taşımadan analiz etme imkanı sunarak büyük veri kümeleriyle çalışma sürecini hızlandırır. Hadoop’taki veriyi T-SQL ile sorgulamak, SQL Server kullanıcıları için büyük kolaylık sağlar.
• Azure Blob Storage Üzerindeki Veriyi Sorgulama : Azure Blob Storage’da saklanan verilere PolyBase ile erişmek, SQL Server kullanıcıları için başka bir önemli avantajdır. T-SQL sorguları ile Azure Blob Storage üzerindeki verilere SQL Server ortamından erişim sağlayarak analiz işlemleri yapılabilir. Bu yöntem, özellikle büyük verilerin hızlı bir şekilde analiz edilmesi gereken durumlarda avantaj sağlar.
• Verileri SQL Server’a Import Etme : PolyBase, Hadoop, Azure Blob Storage veya Azure Data Lake Store gibi harici veri kaynaklarından verileri SQL Server’a import etmeyi de mümkün kılar. Bu özellik, veriyi farklı platformlardan SQL Server’a taşımayı kolaylaştırır. Böylece analiz ve işleme işlemlerinin SQL Server’da yapılması gerektiği durumlarda, veri aktarma işlemleri hızlı ve sorunsuz bir şekilde gerçekleştirilir.
• Verileri Dış Kaynaklara Export Etme : PolyBase yalnızca veriyi SQL Server’a aktarmakla kalmaz; aynı zamanda veriyi SQL Server’dan Hadoop, Azure Blob Storage veya Azure Data Lake Store gibi harici veri kaynaklarına export etmeye de olanak tanır. Bu sayede SQL Server’daki veriyi bulut veya büyük veri platformlarına taşımak isteyen kullanıcılar için ideal bir çözüm sunar.
• PolyBase ile Microsoft BI ve Diğer Third Party Araçlarla Entegrasyon : PolyBase, Microsoft BI (Business Intelligence) araçları veya SQL Server’ın desteklediği diğer Third Party araçlarla birlikte kullanılabilir. Bu entegrasyon, analiz süreçlerini daha esnek ve güçlü hale getirir. Özellikle farklı veri kaynaklarına erişim sağlanması gereken karmaşık projelerde, PolyBase’in üçüncü parti araçlarla uyumu, veri analizini daha kapsamlı bir hale getirir. PolyBase, büyük veri analitiği ve bulut veri yönetimi alanlarında güçlü bir çözümdür ve SQL Server’ın veri erişim yeteneklerini genişleterek, kullanıcıların farklı platformlarda saklanan verilere doğrudan erişim sağlamasına imkan tanır.

Analysis Services: Analysis Services, büyük veri ile çalışan kurumlar için güçlü bir analiz ve tahmin platformudur. Verilere çok hızlı erişim sağlamak ve çok boyutlu analiz yapabilmek için geliştirilmiştir. İlk başlarda bir OLAP (Online Analytical Processing) motoru olarak kullanıma sunulan Analysis Services, zamanla çok daha kapsamlı bir çözüm haline gelmiştir. Artık iş zekası ihtiyaçlarını karşılamak için kapsamlı veri modelleme ve tahmin araçlarıyla donatılmıştır.

• İş Performansını Ölçmek için Veri Analizi : Kurumlar, işlerinin performansını ölçmek ve karar alma süreçlerini desteklemek için veri analizine büyük ölçüde ihtiyaç duyarlar. Veri analizleri sayesinde karzarar durumları, birim maliyetler ve diğer performans ölçütleri detaylı bir şekilde takip edilebilir. Örneğin, bir üretim firması üretim sürecindeki hata oranlarını analiz edebilirken, bir havayolu şirketi uçak doluluk oranlarını takip edebilir. Bu analizler, işletmenin verimliliğini artırmak ve kaynaklarını daha etkili kullanmak için temel bilgiler sunar.
• İş Trendlerini ve Sorunları Analiz Etme : Veri analizleri, kurumların iş trendlerini ve potansiyel sorunları görmesine olanak tanır. Örneğin, firmanın hangi stratejilerinin başarılı olduğunu ve hangi alanlarda sorun yaşadığını belirlemek için bu analizlerden yararlanılır. Karar vericiler, bu analizleri inceleyerek işlerin gidişatını değerlendirebilir, sorunlara çözüm üretebilir ve işletmenin gelecekteki adımlarını planlayabilir. Böylece iş trendleri, daha net bir şekilde görülebilir ve mevcut stratejiler üzerinde iyileştirmeler yapılabilir.
• Öngörücü Modellerle Geleceği Planlama : Analysis Services, öngörücü modellemeler yaparak gelecek için tahminlerde bulunulmasına da olanak sağlar. Öngörücü modeller, geçmiş veriye dayanarak gelecekteki olayları tahmin etmek için kullanılan güçlü araçlardır. Örneğin, bir sigorta şirketi, her bir talep için topladığı detaylı verilerle sahte talepleri tespit edebilir. Bu modeller sayesinde işletmeler, riskleri daha iyi yönetebilir ve operasyonel stratejilerini daha güvenilir verilerle destekleyebilir. İlgili datalar, gerektiğinde soruşturma süreçlerinde detaylı analiz için kullanılabilir.
• Analysis Services’in Avantajları : SQL Server Analysis Services, kurumlara veriye dayalı kararlar alma imkanı tanır. Çok boyutlu analizler, hızlı veri erişimi ve öngörücü modelleme özellikleri ile veri üzerinde derinlemesine analizler yapılabilir. Bu özellikleri ile Analysis Services, kurumların iş süreçlerinde stratejik bir araç haline gelmiştir ve büyük verilerle çalışan her sektör için vazgeçilmez bir çözüm sunar.

Shared Features: SQL Server Shared Features, Microsoft SQL Server 2025 kurulumunda farklı Instance’lar arasında ortak olarak kullanılabilen özellikleri ifade eder. Bu özellikler, sistem kaynaklarının verimli bir şekilde paylaşılmasını sağlarken, yönetimsel görevleri ve geliştirme süreçlerini de kolaylaştırır. Shared Features arasında en çok öne çıkan bileşenlerden biri olan SQL Server Management Studio (SSMS), veritabanı yönetimi ve izleme işlemlerini kullanıcı dostu bir arayüzle sunar. Integration Services gibi Shared Features, veri entegrasyonu ve veri taşıma işlemlerini gerçekleştirir ve ETL (Extract, Transform, Load) süreçlerini destekler. SQL Server Data Tools (SSDT), SQL Server üzerinde geliştirme yapan kullanıcılar için önemli bir araç olup, veri modelleri ve iş akışları oluşturmayı kolaylaştırır. Aynı zamanda, Full-Text Search gibi özellikler, metin tabanlı veriler üzerinde daha hızlı arama ve analiz yapmayı sağlar ve bu özellikler tüm Instance’lar tarafından ortaklaşa kullanılabilir. Shared Features, SQL Server’ın sunduğu çözümleri daha esnek ve erişilebilir hale getirirken, kaynakların etkin bir şekilde kullanılmasını destekleyerek tüm sistemin performansını artırır.

Intregration Services: SQL Server Integration Services (SSIS), Microsoft’un SQL Server ürünüyle birlikte gelen güçlü bir ETL (Extract, Transform, and Load) aracıdır ve farklı veri kaynaklarından verileri çekip bir araya getirerek veri ambarı oluşturmak için kullanılır. Bu süreç, farklı kaynaklardan alınan verilerin işlenip, belirlenen bir hedef ortamda toplanmasını sağlayarak veri analizine ve raporlamaya zemin hazırlar. SQL Server Integration Services (SSIS), veriyi ihtiyaçlara uygun hale getirerek veri temizliği, hesaplama, dönüşüm ve yükleme işlemlerini gerçekleştirir. Eski adıyla DTS (Data Transformation Services) olarak bilinen bu araç, günümüzde SQL Server Integration Services (SSIS) adıyla, DTS (Data Transformation Services)‘ten çok daha kapsamlı ve güçlü bir işleyiş sunar.

• Extract (Source) aşamasında, veriyi kaynağından alarak analiz için hazır hale getirir. Bu işlemde veri, SQL Server, Excel dosyaları, metin dosyaları gibi çeşitli kaynaklardan okunur ve daha sonra işlenmek üzere taşınır.
• Transform aşaması, alınan veriyi istenen formata dönüştürmek için kullanılır. Örneğin, kaynak verilerde yapılan veri temizliği, hesaplama ve dönüşüm işlemleri bu aşamada gerçekleştirilir. Verilerin belirlenen hedef yapı için uygun hale getirilmesi sağlanarak, veriler anlamlı ve analiz edilebilir bir hale getirilir.
• Load aşamasında ise, veri ambarı veya başka bir hedefe aktarılır. Yükleme işlemi, veriyi Excel, SQL Server, Access DB gibi farklı hedeflere aktararak, analiz yapılabilir bir ortam oluşturur.

SQL Server Integration Services (SSIS)’in daha büyük veri işlemleri için sunduğu Scale Out Master ve Scale Out Worker bileşenleri, ETL (Extract, Transform, and Load) süreçlerini hızlandırmak ve büyük veri ortamlarında performansı artırmak için geliştirilmiştir.

• Scale Out Master, ETL (Extract, Transform, and Load) süreçlerinin merkezi kontrolünü sağlar ve iş yüklerini Scale Out Worker’lara dağıtarak işlemlerin paralel olarak gerçekleştirilmesine olanak tanır.
• Scale Out Worker ise, Scale Out Master tarafından gönderilen görevleri yerine getirir ve veri işlemleri için gerekli iş gücünü sağlar. Bu dağıtık yapı, ETL (Extract, Transform, and Load) işlemlerinin büyük veri setleri üzerinde yüksek performansla çalışmasını destekler. SQL Server Integration Services (SSIS), farklı veri kaynaklarından veri çekip entegre ederek, veri ambarı oluşturma ve veri analizini destekleme noktasında geniş bir esneklik sunar. Bu özellikleriyle, veri yönetiminde kapsamlı ve güçlü bir çözüm olarak öne çıkar.

Reporting Services’i mi arıyorsunuz: Feature Selection ekranında Features’ların listelendiği alanın üstünde Looking for Reporting Services? Download it from Web uyarısını fark etmişsinizdir. Microsoft SQL Server 2025 ile birlikte, Reporting Service tarafında da yenilikler gelmiş oldu. Reporting Services, ilk olarak SQL Server 2005 ile yayınlanmıştı. SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 ve SQL Server 2014 sürümlerinde neredeyse aynı olan SQL Server Reporting Services (SSRS), SQL Server 2016’da tamamen yepyeni bir SQL Server Reporting Services (SSRS) karşımıza çıktı. Bu yenilikler Microsoft SQL Server 2025 ile de devam etmektedir. İlk olarak SQL Server Reporting Services (SSRS), artık Microsoft SQL Server 2025 kurulumu içerisinde Feature Selection ekranından çıkmış oldu. SQL Server Management Studio (SSMS) gibi Internet’ten indirilebilir bir özellik haline geldi.

Reporting Services Nedir: Reporting Services, Microsoft SQL Server tarafından sunulan güçlü ve esnek bir raporlama platformudur. Bu platform, veritabanı içeriğinden veri çekerek kullanıcı dostu ve görsel olarak zengin raporlar oluşturmanıza imkan tanır. Kullanıcılar, oluşturulan raporlar üzerinden veriyi analiz edebilir ve stratejik karar alma süreçlerini bu analizlere dayandırabilir. Reporting Services, tablolar, grafikler ve diğer görsel unsurlarla dinamik raporlar hazırlamayı kolaylaştırır. Ayrıca, raporların Web üzerinden erişilebilir olması, uzaktan veri analizi yapmayı mümkün kılarak kullanıcı deneyimini artırır. Reporting Services, farklı programların sunduğu sınırlı raporlama araçlarına kıyasla büyük bir esneklik sağlar. Çoğu muhasebe veya işletme yazılımının kendine özgü raporlama araçları olsa da, bu araçlar genellikle yalnızca kendi veritabanlarıyla çalışır ve farklı veri kaynaklarını birleştirerek rapor oluşturmak için yetersiz kalabilir. Reporting Services ise bu noktada devreye girerek, farklı veri kaynaklarını entegre edip tek bir raporda birleştirmenize olanak tanır. Üstelik, SQL Server ile birlikte sunulan bu özellik, ek bir maliyet gerektirmediğinden, maliyet etkin bir raporlama çözümü olarak öne çıkar. Reporting Services, veri analistleri için vazgeçilmez bir araç olup işletmelerin geniş veri setlerini yönetmelerini ve anlamlandırmalarını sağlar. Kullanıcılar, bu araçla ihtiyaçlarına göre özelleştirilmiş raporlar hazırlayabilir, veriyi en etkili şekilde sunabilir. Böylece, iş süreçlerinde daha hızlı ve doğru kararlar alınmasını destekler.

Feature Selection ekranında Microsoft SQL Server 2025 kurulumu için gerekli bileşenleri seçerek kurulum kapsamını belirliyoruz. Bu ekran, sunucuya hangi servislerin yükleneceğini ve buna bağlı olarak hangi ek bileşenlerin kurulacağını gösterdiği için kurulumun en kritik adımlarından biridir.

Feature Selection ekranında Database Engine Services servisini seçiyoruz. Database Engine Services seçildikten sonra, SQL Server Replication ve Full-Text and Semantic Search for Search bileşenlerinin otomatik olarak işaretlendiğini görüyoruz. Bu bileşenler, Database Engine Services ile bağımlı çalıştığından dolayı kurulum sihirbazı tarafından varsayılan olarak seçilmektedir.

Database Engine Services, Microsoft SQL Server’ın çekirdek (core) bileşenidir ve SQL Server’ın temel veritabanı işlevlerinin tamamını sağlar. Bu servis, veritabanlarının oluşturulması, yönetilmesi ve çalıştırılmasından sorumludur; tablolar, indeksler, görünümler, saklı yordamlar (stored procedures) ve tetikleyiciler (triggers) gibi tüm veritabanı nesneleri bu bileşen üzerinden yönetilir. Database Engine Services; sorgu işleme, transaction yönetimi, kilitleme (locking), eşzamanlılık (concurrency control), loglama, güvenlik ve yetkilendirme, backup/restore ve High Availability (Yüksek Erişilebilirlik) mekanizmalarının (Failover Cluster, Always On gibi) temelini oluşturur. SQL Server’a bağlanan tüm uygulamalar ve kullanıcılar, veri okuma ve yazma işlemlerini bu servis aracılığıyla gerçekleştirir.

Full-Text and Semantic Search for Search, SQL Server üzerinde tutulan metin tabanlı veriler üzerinde gelişmiş arama yetenekleri sunan bir bileşendir. Bu servis sayesinde VARCHAR, NVARCHAR, XML gibi alanlar üzerinde klasik LIKE sorgularının ötesine geçilerek; kelime kökleri, eş anlamlılar ve dilbilgisel yapılar dikkate alınarak arama yapılabilir. Ayrıca Semantic Search özelliği ile metinler arasındaki anlamsal ilişkiler analiz edilerek daha isabetli ve bağlamsal sonuçlar elde edilir. Özellikle doküman yönetim sistemleri, içerik arama senaryoları ve büyük metin veri kümeleri üzerinde performanslı arama ihtiyacı olan uygulamalarda kritik bir rol üstlenir.

SQL Server Replication ise seçilen veritabanı, tablo veya nesnelerin farklı SQL Server instance’larına belirli kurallar çerçevesinde çoğaltılmasını (replikasyon) sağlayan bir teknolojidir. Bu mekanizma sayesinde veriler tek yönlü veya çift yönlü, anlık (near real-time) ya da zamanlanmış olarak başka sunuculara aktarılabilir. Özellikle raporlama sunucuları, uzak lokasyon senaryoları, yük dengeleme, okuma performansının artırılması ve dağıtık veri mimarileri gibi yapılarda SQL Server Replication kritik bir rol üstlenir.

• Prerequisite for selected features bölümünde, seçtiğimiz bileşenlerin çalışabilmesi için kurulacak ek bağımlılıkları / önkoşulları görüntüleyebilirsiniz. Bu alan sayesinde hangi yardımcı bileşenlerin otomatik olarak ekleneceğini kurulum ilerlemeden önce net şekilde görmüş oluruz.
• Disk Space Requirements alanında ise seçilen özelliklerin sunucuda ne kadar disk alanı tüketeceğini görebiliriz. Bu kontrol, özellikle çok sayıda bileşen seçilmiş kurulumlarda veya disk alanı kısıtlı ortamlarda kurulumun yarıda kalmasını engellemek açısından önemlidir.

Ekranın alt kısmında bulunan Instance root directory, Shared features directory ve Shared features directory (x86) bölümlerinde Microsoft SQL Server 2025 için varsayılan kurulum dizinleri görüntülenir.

• Instance root directory, ilgili SQL Server instance’ına ait bileşenlerin temel kurulum yolunu ifade eder.
• Shared features directory, instance’lar arasında ortak kullanılabilen bileşenlerin (paylaşımlı bileşenler) yükleneceği dizindir.
• Shared features directory (x86) ise 32-bit mimariye sahip bileşenlerin Program Files (x86) altında konumlanacağını gösterir. Bu durum, ortamda 64-bit Microsoft SQL Server 2025 kurulsa bile bazı yardımcı bileşenlerin 32-bit yapıda olabilmesinden kaynaklanır.

Feature Selection ekranında gerekli seçimleri tamamladıktan sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

Feature Rules ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumunun devam edebilmesi için gerekli olan tüm özellik ve bileşenlere ait ön koşullar kontrol edilir.

Bu aşamada seçilen SQL Server özelliklerinin, Failover Cluster mimarisi ile uyumlu olup olmadığı ve ortamda herhangi bir eksik yapılandırma bulunup bulunmadığı doğrulanır.

Feature Rules ekranında yapılan kontrollerin tamamının Passed olarak sonuçlandığını gördükten sonra, kurulum sürecine devam etmek için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Instance Configuration ekranında Microsoft SQL Server 2025 kurulumu için Default instance seçeneğinin MSSQLSERVER olarak geldiğini görüyoruz ve bu ayarı varsayılan haliyle bırakıyoruz. Default instance kullanımı, sunucu üzerinde tek bir SQL Server instance’ı planlanan senaryolarda yönetim ve bağlantı açısından kolaylık sağlar.

Aynı ekranda yer alan Named instance seçeneği kullanılarak istenirse instance adı MSSQLSERVER yerine farklı bir isimle yapılandırılabilir. Ancak bu kurulumda Default instance tercih edildiği için herhangi bir değişiklik yapmıyoruz.

Instance ID alanı da varsayılan olarak MSSQLSERVER şeklinde gelmektedir. Instance ID, SQL Server servisleri ve dizin yapısı açısından referans olarak kullanıldığı için bu alanda da default ayarları değiştirmiyoruz.

Ekranın alt kısmında yer alan SQL Server directory bölümünde ise SQL Server’ın C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER dizini altına kurulacağını görüyoruz. Bu dizin yapısını daha önce Feature Selection ekranında da görüntülemiştik.

Instance Configuration ekranında Microsoft SQL Server 2025 Always On Availability Group kurulumundan farklı olarak SQL Server Network Name seçeneğinin yer aldığını görüyoruz.

SQL Server Network Name alanında, Microsoft SQL Server 2025 Failover Cluster (FCI) yapısının istemciler tarafından hangi isimle erişileceğini belirliyoruz. Bu ağ adı, Failover Cluster içerisinde bir cluster kaynağı olarak oluşturulur ve failover senaryolarında aktif Node değişse bile istemcilerin aynı isim üzerinden SQL Server’a erişmeye devam etmesini sağlar.

Instance adı, Instance ID ve SQL Server Network Name gibi gerekli ayarları yapılandırdıktan sonra, Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumuna devam etmek için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Instance Configuration ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumu için gerekli olan yapılandırmalar kontrol edilir.

Bu aşamada; Instance türü (Default / Named), Instance ID, SQL Server Network Name ve kurulum dizinleri gibi temel ayarların cluster mimarisi ile uyumlu olup olmadığı doğrulanır.

Instance Configuration ekranında yapılandırma kontrollerinin başarıyla tamamlanmasının ardından, kurulum sihirbazı bir sonraki adıma geçilmesine izin verir ve SQL Server Failover Cluster kurulum süreci planlanan şekilde devam eder.

Cluster Resource Group ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) kurulumu sırasında SQL Server’a ait kaynakların hangi cluster resource group altında oluşturulacağını ve yönetileceğini görüyoruz. Bu resource group; SQL Server servisleri, Network Name (Ağ Adı), IP adresi ve disk kaynaklarının birlikte taşındığı mantıksal bir konteyner görevi görür.

Ekranda varsayılan olarak SQL Server (MSSQLSERVER) isimli cluster resource group’un seçili geldiğini görüyoruz. Ayrıca listelenen Available Storage ve Cluster Group resource group’larının, Windows Server Failover Cluster tarafından sistemsel olarak rezerve edilmiş gruplar olduğu bilgisi gösterilmektedir. Bu gruplar Microsoft SQL Server 2025 kurulumu için kullanılamaz ve yalnızca bilgilendirme amaçlı listelenir.

Cluster Resource Group ekranında varsayılan ayarlarda herhangi bir değişiklik yapmadan Next seçeneğine tıklayarak kurulum sürecinde bir sonraki adıma geçiyoruz.

Cluster Disk Selection ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) yapımızda kullanılabilecek diskleri görüntülüyoruz. Bu ekranda, Windows Server Failover Cluster (WSFC) mimarisi kapsamında Quorum için ayrılmış diskler haricinde; SQL Server’a ait Data, Log, TempDB ve Backup dizinlerinin tutulacağı Cluster Diskler listelenmektedir.

Cluster Disk 1 diskimiz, Windows Server Failover Cluster (WSFC) Quorum yapılandırması kapsamında Disk Witness olarak tanımlandığı için bu ekranda seçilebilir durumda değildir. Disk Witness; Cluster Quorum mekanizması içerisinde Quorum Vote (Oy Hakkı) sağlayan bir kaynak olarak görev yapar ve Cluster Membership, Quorum State ve Resource Ownership kararlarının sağlıklı şekilde alınabilmesi için kullanılır. Bu disk, SQL Server veri depolama amacıyla kullanılamaz.

Daha önceki Microsoft SQL Server 2025 Failover Cluster Instance Kurulumu 2 yazımızda da olduğu gibi, bu mimaride Data, Log, TempDB ve Backup dizinleri için ayrı ayrı Cluster Diskler oluşturduk. Bu yaklaşım; disk I/O yüklerinin izole edilmesini, performansın artırılmasını ve Failover Cluster ortamında kaynak yönetiminin daha deterministik ve öngörülebilir olmasını sağlar.

Cluster Disk Selection ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) yapımızda kullanılacak uygun diskleri seçerek SQL Server Failover Cluster (FCI) yapılandırmasına dahil ediyoruz.

Cluster Disk Selection ekranında gerekli disk seçimlerini tamamladıktan sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Cluster Network Configuration ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) yapısı için IP Address (IP Adresi) yapılandırmasını gerçekleştiriyoruz.

Bu adımda, SQL Server Failover Cluster (FCI)’a atanacak statik IP adresi belirlenir ve cluster servislerinin ağ üzerinden erişilebilir olması sağlanır. Yapılandırma sırasında girilen IP adresinin, ilgili subnet’e uygun olması ve ağ altyapısı tarafından desteklenmesi gerekmektedir.

NOT: Bu aşamada belirleyeceğiniz IP Address (IP Adresi)’nin, ortamınızda herhangi bir sunucu, cihaz veya servis tarafından kullanılmıyor olmasına özellikle dikkat edilmelidir. Kullanımda olan bir IP adresinin seçilmesi, ilerleyen aşamalarda cluster servislerinin başlatılamamasına veya ağ çakışmalarına neden olabilir.

Cluster Network Configuration ekranında Microsoft SQL Server 2025 Failover Cluster (FCI) yapısı için Address bölümünde IP Address (IP Adresi) yapılandırmasını gerçekleştiriyoruz.

Bu ekranda ayrıca Network bölümünde, Microsoft SQL Server 2025 Failover Cluster (FCI) yapısında hangi Network Adapter (Ağ Kartı)’nın kullanılacağını görüyoruz. Seçilen Network Adapter (Ağ Kartı), cluster trafiğini taşıyacak doğru network üzerinde yapılandırılmış olması önemlidir.

Cluster Network Configuration ekranında gerekli tüm yapılandırmaları tamamladıktan sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Server Configuration ekranında Microsoft SQL Server 2025 kurulumu sırasında sunucu üzerinde çalışacak SQL Server servislerinin Service Account (Servis Hesabı) ve Startup Type (Başlangıç Türü) ayarlarını yapılandırıyoruz. Bu adım, SQL Server servislerinin güvenli, yetkilendirilmiş ve işletim sistemi ile uyumlu şekilde çalışabilmesi açısından kurulumun en kritik aşamalarından biridir.

Service Accounts sekmesinde, SQL Server’a ait temel servislerin listelendiğini görürüz. Bu servisler; SQL Server Agent, SQL Server Database Engine ve SQL Server Browser servisleridir. Bu bölümde her bir servisin hangi kullanıcı hesabı altında çalışacağı ve servislerin ne zaman başlatılacağı belirlenir.

• Account Name: Account Name alanı, ilgili servisin hangi kullanıcı hesabı ile çalışacağını tanımlamak için kullanılır. Kurulum sırasında varsayılan olarak sanal servis hesapları atanmış olarak gelir. Ancak kurumsal güvenlik politikaları, yetkilendirme gereksinimleri ve Audit (Denetim) ihtiyaçları doğrultusunda, özellikle Production (Üretim) ortamlarında özel domain servis hesaplarının kullanılması tercih edilir. Bu yaklaşım, servislerin minimal yetki prensibine göre çalışmasını sağlar ve olası güvenlik risklerini azaltır.
• Startup Type: Startup Type bölümünde ise servislerin başlatılma davranışı yapılandırılır. Automatic olarak ayarlanan servisler, sunucu her açıldığında otomatik olarak başlatılır. Manual seçeneği ise servislerin ihtiyaç duyulduğunda manuel olarak başlatılmasını sağlar. Production (Üretim) ortamlarında High Availability (Yüksek Erişilebilirlik) ve süreklilik gerektiren senaryolarda, özellikle SQL Server Database Engine ve SQL Server Agent servislerinin Automatic olarak yapılandırılması en doğru yaklaşımdır.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) Senaryolarında Service Account Yapılandırması: Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinde Service Account yapılandırması; hem High Availability (Yüksek Erişilebilirlik) mekanizmasının sorunsuz çalışması hem de güvenlik gereksinimlerinin karşılanması açısından kritik öneme sahiptir. Failover Cluster Instance (FCI) yapısında kullanılan SQL Server Database Engine ve SQL Server Agent servislerinin, Active Directory Domain ortamında tanımlı, düşük yetkili ancak gerekli izinlere sahip özel servis hesapları ile çalıştırılması önerilir.

Production (Üretim) ortamlarında Domain Admin veya Local Administrator gibi geniş yetkilere sahip hesapların servis hesabı olarak kullanılması önerilmez. Bu tür yetkilere sahip hesapların ele geçirilmesi, yalnızca SQL Server altyapısını değil, tüm domain ortamını ciddi şekilde riske atabilir.

Failover Cluster Instance (FCI) mimarisinde SQL Server servisi, Cluster üzerinde tek bir instance olarak çalışır ve aktif Node değiştiğinde (Failover) servisler otomatik olarak diğer Node üzerinde başlatılır. Bu nedenle SQL Server Database Engine ve SQL Server Agent servisleri için:

• Tüm Node’larda aynı servis hesabının kullanılması
• Servis hesabının cluster genelinde tutarlı yetkilere sahip olması

best practice olarak kabul edilir.

Güncel ve kurumsal ortamlarda Microsoft’un en güvenli ve önerilen yaklaşımı, Group Managed Service Account (gMSA) kullanımıdır.

Group Managed Service Account (gMSA) hesapları;

• Otomatik parola yönetimi
• Manuel parola yenileme ihtiyacının ortadan kalkması
• Merkezi ve güvenli kimlik doğrulama
• Cluster ortamlarında sorunsuz Failover desteği

gibi avantajlar sunarak Microsoft SQL Server 2025 Failover Cluster Instance (FCI) senaryoları için ideal bir servis hesabı yapısı sağlar.

Failover Cluster Instance (FCI) Mimarisinde Servis Hesapları İçin Zorunlu Gereksinimler
SQL Server 2025 FCI ortamında kullanılan servis hesaplarının aşağıdaki gereksinimleri sağlaması zorunludur:

• Windows üzerinde Log on as a service yetkisine sahip olması
• SQL Server servislerinin cluster node’ları arasında sorunsuz taşınabilmesi için gerekli dosya ve registry erişim izinlerine sahip olması
• Service Principal Name (SPN) kayıtlarının doğru ve eksiksiz şekilde yapılandırılması.

Service Principal Name (SPN) yapılandırmasının eksik veya hatalı olması durumunda Kerberos kimlik doğrulaması başarısız olabilir ve özellikle failover sonrası istemci bağlantılarında erişim problemleri yaşanabilir. Bu nedenle servis hesaplarının minimal yetki prensibine uygun şekilde tasarlanması ve SPN yönetiminin doğru yapılması, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) ortamlarında hem güvenlik hem de kesintisiz hizmet sürekliliği açısından kritik öneme sahiptir.

Server Configuration – Service Accounts Yapılandırması
Server Configuration ekranında yer alan Service Accounts sekmesinde;

• SQL Server Database Engine
• SQL Server Agent

servisleri için;

• Account Name (Hesap Adı)
• Password (Parola) (gMSA kullanımı durumunda parola alanı devre dışı kalır)
• Startup Type (Başlangıç Türü)

alanlarını, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisine ve ortam gereksinimlerine uygun olacak şekilde yapılandırıyoruz.

Server Configuration ekranında Microsoft SQL Server 2025 sunucumuz üzerinde çalışacak olan SQL Server Database Engine servisinin hangi kullanıcı hesabı ile çalışacağını belirlemek için Account Name (Hesap Adı) alanında yer alan Browse seçeneğine tıklıyoruz. Bu adımda amaç, SQL Server Database Engine servisinin Active Directory Domain ortamında yetkilendirilmiş bir kullanıcı hesabı ile çalışmasını sağlamaktır.

Ancak bu yaklaşım yalnızca test ve laboratuvar ortamları için kabul edilebilir bir yöntemdir. Gerçek Production (Üretim) ortamlarında Domain Admin yetkisine sahip hesapların SQL Server servis hesabı olarak kullanılması kesinlikle önerilmez. Domain Admin grubu, Active Directory Domain yapısındaki en yüksek yetkilere sahiptir ve bu hesaba ait kimlik bilgilerinin ele geçirilmesi durumunda tüm Domain altyapısı ciddi bir güvenlik riski altına girer.

Bu nedenle Production (Üretim) ortamlarında, Active Directory Domain üzerinde SQL Server servisleri için özel olarak oluşturulmuş, yalnızca ihtiyaç duyulan minimum izinlere sahip ayrı bir Service Account (Hizmet Hesabı) kullanılmalıdır. SQL Server Agent servisinin bu özel servis hesabı ile çalışacak şekilde yapılandırılması; güvenlik, denetlenebilirlik ve sürdürülebilirlik açısından en doğru yaklaşımdır. Bu yöntem, Least Privilege (en az yetki) prensibine uygun bir mimari sağlar ve kurumsal güvenlik standartlarıyla tam uyumlu bir yapı oluşturur.

NOT: Bu kurulum senaryosu bir LAB ortamı üzerinde gerçekleştirildiği için, olası yetki veya erişim problemleriyle karşılaşmamak adına geçici olarak Domain Admin yetkisine sahip bir kullanıcı hesabı tercih edilmiştir ve yapılandırma Administrator kullanıcısı ile yapılmıştır.

Select User, Computer, Service Account, or Group ekranında Enter the object name to select alanına Domain Admin yetkisine sahip kullanıcı hesabının adını giriyoruz ve Check Names seçeneğine tıklıyoruz. Bu işlem, girilen kullanıcı adının Active Directory Domain üzerinde mevcut olup olmadığını doğrulamak için kullanılır. Kullanıcı adı doğruysa sistem tarafından otomatik olarak doğrulanır ve altı çizili hale getirilir.

İhtiyaç duyulması halinde Advanced seçeneği kullanılarak daha detaylı bir arama da yapılabilir. Advanced bölümünde Active Directory Domain içerisindeki kullanıcılar, bilgisayarlar, gruplar veya servis hesapları filtrelenerek liste halinde görüntülenebilir. Bu yöntem, özellikle büyük domain yapılarında doğru hesabın seçilmesini kolaylaştırır ve yapılandırma hatalarının önüne geçer.

Bu kurulum senaryosunda, Enter the object name to select alanına Domain Admin yetkisine sahip Administrator hesabını yazıyoruz, doğrulama işlemini tamamladıktan sonra OK seçeneğine tıklayarak yapılandırmaya devam ediyoruz.

NOT: Bu yapılandırma bir LAB ortamı üzerinde gerçekleştirildiği için, olası yetki veya erişim problemleriyle karşılaşmamak adına geçici olarak Domain Admin yetkisine sahip Administrator hesabı kullanılmıştır. Gerçek Production ortamlarında SQL Server servisleri için Domain Admin yetkisine sahip hesapların kullanılmaması, bunun yerine yalnızca gerekli izinlere sahip, özel olarak oluşturulmuş Service Account’ların tercih edilmesi güvenlik açısından kritik öneme sahiptir.

Server Configuration ekranında Microsoft SQL Server 2025 sunucumuz üzerinde yapılandırmakta olduğumuz SQL Server Database Engine servisinin Account Name (Hesap Adı) alanında, Active Directory Domain ortamında tanımlı Domain Admin yetkisine sahip BAKICUBUK\administrator kullanıcısının otomatik olarak görüntülendiğini görüyoruz.

Bu alan, SQL Server Database Engine servisinin hangi kullanıcı hesabı altında çalışacağını açıkça belirtir. Bir önceki adımda Select User, Computer, Service Account, or Group ekranında doğruladığımız ve seçtiğimiz kullanıcı hesabı, kurulum sihirbazı tarafından otomatik olarak bu alana yerleştirilir. Böylece SQL Server Database Engine servisi, ilgili domain hesabının sahip olduğu yetkilerle çalışacak şekilde yapılandırılmış olur.

Bu kurulum senaryosunda, yapılandırma bir LAB ortamında gerçekleştirildiği için olası yetki ve erişim problemleriyle karşılaşmamak adına Domain Admin yetkisine sahip bir hesap tercih edilmiştir. Bu yaklaşım, test ve doğrulama amaçlı ortamlarda kurulum sürecini hızlandırmak ve olası konfigürasyon hatalarını minimize etmek amacıyla uygulanabilir.

Ancak özellikle vurgulamak gerekir ki, Production (Üretim) ortamlarında SQL Server Database Engine servisinin Domain Admin gibi geniş yetkilere sahip hesaplar ile çalıştırılması güvenlik açısından kesinlikle önerilmez. Bu tür hesapların yetki kapsamı oldukça geniş olduğu için, olası bir güvenlik ihlali durumunda yalnızca SQL Server altyapısı değil, tüm Active Directory Domain ortamı risk altına girebilir.

Üretim ortamlarında en doğru yaklaşım; yalnızca gerekli izinlere sahip, özel olarak oluşturulmuş bir Service Account veya tercihen Group Managed Service Account (gMSA) kullanılmasıdır. Group Managed Service Account (gMSA) yapısı; otomatik parola yönetimi, merkezi kontrol ve güvenli kimlik doğrulama avantajları sunarak, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) gibi High Availability (Yüksek Erişilebilirlik) gerektiren mimariler için hem güvenlik hem de operasyonel süreklilik açısından best practice olarak kabul edilmektedir.

Database Engine servisinin doğru şekilde yapılandırılması, veritabanı motorunun sürekli erişilebilir olması, istemci bağlantılarının kesintisiz sağlanması ve SQL Server’ın temel işlevlerinin stabil bir şekilde çalışabilmesi açısından kritik öneme sahiptir. Bu adımın doğru tamamlanması, Failover Cluster Instance (FCI) yapılandırmaları, veritabanı işlemleri, performans yönetimi ve kurumsal uygulamaların sürekliliği için temel bir gerekliliktir.

Server Configuration ekranında yer alan Password (Parola) bölümüne, Active Directory Domain ortamında Domain Admin yetkisine sahip BAKICUBUK\administrator kullanıcısına ait parolayı giriyoruz. Bu işlem ile birlikte SQL Server Database Engine servisinin, belirtilen kullanıcı hesabı ile kimlik doğrulaması yaparak çalışması sağlanmış olur.

Bu aşamada girilen parola, SQL Server Database Engine servisinin Windows işletim sistemi üzerinde ilgili kullanıcı bağlamında başlatılabilmesi için gereklidir. Kurulum sihirbazı, girilen hesap bilgilerini doğrular ve servislerin doğru yetkilerle çalışmasını garanti altına alır.

NOT: Bu yapılandırma yalnızca LAB ortamı için tercih edilmiştir. Gerçek Production ortamlarda, Domain Admin yetkisine sahip kullanıcıların servis hesabı olarak kullanılması güvenlik açısından önerilmez. Bunun yerine, minimum yetkilere sahip, yalnızca SQL Server servisleri için oluşturulmuş özel Service Account veya tercihen Group Managed Service Account (gMSA) kullanılması en güvenli yaklaşımdır.

Server Configuration ekranında Service Accounts sekmesinde SQL Server Agent servisi için Account Name (Hesap Adı), Password (Parola) ve Startup Type (Başlangıç Türü) bölümlerini aynı şekilde yapılandırıyoruz.

Server Configuration ekranında Microsoft SQL Server 2025 sunucumuz üzerindeki SQL Server Agent servisi için gerekli yapılandırmaları tamamlamış bulunuyoruz. SQL Server Agent servisi için Account Name (Hesap Adı) bölümünde servis hesabı olarak BAKICUBUK\administrator kullanıcısını seçtik, Password (Parola) bölümünde ilgili kullanıcı parolasını girdik ve Startup Type (Başlangıç Türü) seçeneğini Automatic (Otomatik) olarak yapılandırdık. Bu yapılandırma ile SQL Server Agent servisinin doğru kullanıcı hesabı altında, uygun yetkilerle ve sunucu her yeniden başlatıldığında otomatik olarak devreye alınacak şekilde çalışması sağlanmıştır.

Server Configuration ekranında Service Accounts sekmesinde SQL Server Browser servisinin yapılandırılıp başlatılmasına ihtiyaç duyulup duyulmayacağı, ortamda kullanılan bağlantı yöntemlerine ve SQL Server mimarisine bağlıdır. Eğer sunucu üzerinde yalnızca Default Instance (Varsayılan Instance) kullanılıyor ve istemci bağlantıları doğrudan sunucu adı üzerinden yapılıyorsa, SQL Server Browser servisinin çalışmasına zorunlu bir ihtiyaç yoktur. Bu nedenle birçok kurulumda SQL Server Browser servisi Disabled (Devre Dışı) bırakılabilmektedir. Ancak ortamda Named Instance (Adlandırılmış Instance) kullanılıyorsa veya kullanıcıların SQL Server’a dinamik portlar üzerinden erişmesi gerekiyorsa, SQL Server Browser servisinin Automatic (Otomatik) yada en azından Manual (Manuel) olarak etkinleştirilmesi önerilir. Çünkü SQL Server Browser servisi, istemcilerin doğru SQL Instance’ına yönlendirilmesini sağlayan port bilgisini yayınlar ve bu bilgi olmadığında bağlantı sorunları ortaya çıkabilir.

Server Configuration ekranında Service Accounts sekmesinde Startup Type alanının Manual (Manuel) olarak gelmesi ve değiştirilememesi beklenen ve normal bir durumdur.

Bunun nedeni, SQL Server Failover Cluster Instance (FCI) ve SQL Server Always On Availability Group gibi Windows Server Failover Cluster (WSFC) tabanlı mimarilerde servislerin Windows servis başlangıç türü ile değil, Cluster tarafından yönetilmesidir.

Bu tür yapılarda:

• SQL Server Database Engine
• SQL Server Agent

servislerinin Start / Stop işlemleri Failover Cluster Manager üzerinden kontrol edilir. Servislerin hangi node üzerinde, ne zaman ve hangi sırayla çalışacağına Cluster karar verir.

Bu nedenle Startup Type alanı:

• Manual (Manuel) olarak sabit gelir
• Kullanıcı tarafından Automatic (Otomatik) veya başka bir değere değiştirilemez

Bu bir kısıtlama değil, High Availability (Yüksek Erişilebilirlik) tasarımının bir parçasıdır.

Özetle:

• • Manual (Manuel) görünmesi bir hata değildir
  • Failover Cluster Instance (FCI) mimarisi için doğru ve desteklenen davranıştır
  • Servislerin otomatik başlatılması Cluster rolü üzerinden sağlanır

Kurulum tamamlandıktan sonra SQL Server servislerinin durumu Failover Cluster Manager konsolu üzerinde Roles menüsü altında ilgili SQL Server Failover Cluster Instance (FCI) rolü üzerinden izlenebilir ve yönetilebilir.

Server Configuration ekranında Grant Perform Volume Maintenance Task privilege to SQL Server Database Engine Services seçeneğini işaretliyoruz. Bu ayar, Instant File Initialization (Anında Dosya Oluşturma) özelliğinin etkinleştirilmesini sağlar.

Microsoft SQL Server 2005 sürümü ile birlikte gelen Instant File Initialization, özellikle hızlı büyüyen ve büyük hacimli veritabanlarında performansı artırmak için kritik öneme sahiptir. Bu özellik etkinleştirildiğinde, SQL Server tarafından oluşturulan veya genişletilen veri dosyaları (Data File – .mdf (Primary Data File) ve .ndf (Secondary Data File)) disk üzerinde sıfırlarla doldurulmadan, ayrılan alanın anında kullanılabilir hale gelmesini sağlar.

Eğer Grant Perform Volume Maintenance Task privilege seçeneği işaretlenmezse, SQL Server yeni bir data file oluştururken veya mevcut bir data file’ı büyütürken ayrılan disk alanını sıfır (zeroing) ile doldurur. Bu işlem disk I/O açısından oldukça maliyetlidir ve özellikle büyük veritabanlarında oluşturma, büyütme ve restore işlemlerinin ciddi şekilde yavaşlamasına neden olabilir.

Instant File Initialization etkinleştirildiğinde aşağıdaki işlemler çok daha hızlı gerçekleştirilir:

• Yeni Database (Veritabanı) oluşturma
• Mevcut bir Database’e Data File ekleme
• Mevcut Data File boyutunun manuel olarak büyütülmesi
• Database Restore işlemlerinin hızlandırılması

Microsoft SQL Server 2016 öncesi sürümlerde bu yetkinin verilmesi kurulum sonrasında manuel olarak yapılması gereken bir işlemdi. Ancak Microsoft SQL Server 2016 ve sonrası sürümlerde, bu ayrıcalık doğrudan kurulum sırasında Server Configuration ekranı üzerinden kolayca etkinleştirilebilmektedir. Microsoft SQL Server 2025 ile birlikte de bu yapılandırma, kurulum sürecinin doğal bir parçası olarak sunulmaktadır.

Not: Microsoft SQL Server 2025 kurulumu tamamlandıktan sonra servis hesapları Services konsolu üzerinden değiştirilebilir. Ancak yanlış kullanıcı veya yetki tanımlamaları yapılması durumunda SQL Server servisleri başlatılamayabilir. Bu nedenle servis hesabı değişiklikleri dikkatle yapılmalıdır.

Not: Bu kurulum bir LAB ortamı üzerinde gerçekleştirildiği için, yapılandırma sırasında olası yetki sorunlarıyla karşılaşmamak adına geçici olarak Domain Admin yetkisine sahip Administrator kullanıcısı tercih edilmiştir. Production (Üretim) ortamlarında ise Domain Admin en yetkili kullanıcı grubudur ve bu hesabın ele geçirilmesi tüm Active Directory yapısının risk altına girmesi anlamına gelir. Bu nedenle gerçek ortamlarda SQL Server servisleri için sadece gerekli izinlere sahip, ayrı ve sınırlı yetkili Service Account kullanılması her zaman en doğru ve güvenli yaklaşımdır.

Server Configuration ekranında Service Accounts sekmesi üzerindeki tüm yapılandırmaları tamamladıktan sonra Collation sekmesine geçiyoruz.

Collation sekmesi, Microsoft SQL Server 2025 Database Engine’in karakter kümesi, sıralama (sorting) mantığı ve karşılaştırma (comparison) kurallarını belirlediğimiz kritik bir yapılandırma adımıdır. Bu ayarlar; veritabanı içerisindeki metinlerin nasıl sıralanacağını, büyük/küçük harf duyarlılığını, aksan (accent) ve dil kurallarının nasıl ele alınacağını doğrudan etkiler. Yanlış Collation seçimi, uygulama hatalarına, beklenmeyen sorgu sonuçlarına ve performans problemlerine yol açabilir.

Collation sekmesinde Customize seçeneğine tıklayarak kullanılacak Collation değerini manuel olarak belirleyebiliriz. Bu aşamada;

• Dil (Language) uyumu,
• Case-Sensitive (CS) / Case-Insensitive (CI) davranışı,
• Accent-Sensitive (AS) / Accent-Insensitive (AI) seçenekleri,
• Unicode uyumluluğu ve performans beklentileri göz önünde bulundurulmalıdır.

SQL Server Collation, veritabanındaki karakterlerin nasıl karşılaştırılacağını ve sıralanacağını tanımlar. Türkiye’de geliştirilen veya Türkçe karakterlerle yoğun çalışan uygulamalar için genellikle Turkish_CI_AS tercih edilir. Uluslararası uygulamalarda veya geriye dönük uyumluluk gerektiren sistemlerde SQL_Latin1_General_CP1_CI_AS yaygın olarak kullanılmaktadır. Daha modern, Unicode uyumluluğu yüksek ve Microsoft’un yeni projelerde önerdiği yapı ise Latin1_General_CI_AS olarak öne çıkar.

Eğer uygulama tarafında büyük/küçük harf ayrımı yapılması gerekiyorsa CS (Case-Sensitive) uzantılı Collation’lar tercih edilmelidir. Performansın kritik olduğu, karşılaştırmaların byte seviyesinde yapılmasının istendiği özel senaryolarda ise BIN2 Collation’lar kullanılabilir. Özellikle Always On, replikasyon veya çoklu uygulama kullanan ortamlarda tüm Instance ve veritabanlarında tutarlı Collation seçimi büyük önem taşır.

Server Configuration ekranında Collation ayarlarını ihtiyaca uygun şekilde yapılandırdıktan sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

NOT: Microsoft SQL Server 2025 kurulumu sırasında seçilecek Collation değeri, ortamda kullanılacak yazılım, ERP veya kurumsal uygulamaların gereksinimlerine göre değişiklik gösterebilir. Bu nedenle kurulum öncesinde uygulama üreticisinin Collation gereksinimlerinin mutlaka kontrol edilmesi ve seçimin buna göre yapılması önerilir.

Database Engine Configuration ekranında yer alan Server Configuration sekmesi, Microsoft SQL Server 2025 için istemci bağlantılarında kullanılacak Authentication Mode (Kimlik Doğrulama Modu) yapılandırmasının yapıldığı kritik aşamadır. Bu ekranda, SQL Server’a hangi yöntemle erişileceği belirlenir ve seçilen kimlik doğrulama modeli doğrudan güvenlik mimarisini etkiler.

Bu bölümde iki farklı kimlik doğrulama modeli bulunmaktadır:

• Windows Authentication Mode: Bu mod seçildiğinde SQL Server’a yalnızca Windows kullanıcı hesapları üzerinden erişim sağlanabilir. Active Directory Domain ortamlarında Kerberos tabanlı kimlik doğrulama kullanıldığı için en yüksek güvenlik seviyesini sunar. Kullanıcı ve yetki yönetimi tamamen Active Directory üzerinden merkezi olarak yapılır. Microsoft SQL Server 2025 kurulumu sırasında varsayılan olarak gelen ve Microsoft tarafından özellikle kurumsal yapılarda önerilen kimlik doğrulama modeli budur.
• Mixed Mode (SQL Server Authentication + Windows Authentication): Mixed Mode seçildiğinde SQL Server’a hem Windows hesapları hem de SQL Server Authentication ile oluşturulmuş kullanıcılar üzerinden bağlantı kurulabilir. Özellikle Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi SQL Server üzerinde çalışan birçok ERP ve ticari yazılım, SQL Authentication (çoğunlukla sa veya benzeri SQL login’ler) kullandığı için bu mod pratikte sıklıkla tercih edilir. Mixed Mode etkinleştirildiğinde sa hesabı için güçlü bir parola belirlenmesi zorunludur.

Authentication Mode Karşılaştırması ve Production Ortamlarında Güvenlik Etkileri: Microsoft SQL Server 2025 kurulumu sırasında seçilen Authentication Mode, veritabanı güvenliğinin temelini oluşturur. Windows Authentication Mode, Kerberos protokolü ve Active Directory politikaları sayesinde parola karmaşıklığı, hesap kilitleme ve merkezi denetim gibi gelişmiş güvenlik mekanizmalarını doğal olarak sunar. Bu nedenle büyük ölçekli ve güvenlik hassasiyeti yüksek kurumsal ortamlarda öncelikli olarak tercih edilmelidir. Mixed Mode ise uygulama uyumluluğu açısından esneklik sağlar ancak güvenlik risklerini de beraberinde getirir. SQL Authentication kullanan hesaplar, özellikle sa hesabı, brute-force saldırılarına daha açıktır ve Windows Authentication’daki domain bazlı güvenlik kontrollerinden yararlanamaz. Yanlış yapılandırılmış bir Mixed Mode ortamı, SQL Server’ı dış saldırılara karşı savunmasız hale getirebilir.

Production (Üretim) ortamlarında Mixed Mode kullanılacaksa aşağıdaki önlemlerin mutlaka alınması gerekir:

• sa hesabının devre dışı bırakılması veya yeniden adlandırılması
• Güçlü ve karmaşık parola politikalarının uygulanması
• Kullanılmayan SQL login’lerin kaldırılması
• SQL Server bağlantılarının TLS ile şifrelenmesi
• Firewall ve ağ seviyesinde erişim kısıtlamalarının yapılması

Bu önlemler alınmadan kullanılan Mixed Mode yapılandırmaları, hem veri güvenliğini zayıflatır hem de SQL Server’ı hedef haline getirir. Bu nedenle kimlik doğrulama modu seçimi, yalnızca uygulama gereksinimleri değil, aynı zamanda güvenlik politikaları göz önünde bulundurularak yapılmalıdır.

Database Engine Configuration ekranında yer alan Server Configuration sekmesi altında bulunan Specify SQL Server administrators bölümü, SQL Server üzerinde tam yetkili (sysadmin) olacak kullanıcı ve grupların tanımlandığı kritik bir yapılandırma adımıdır.

Bu aşamada, kurulum işlemini gerçekleştiren mevcut kullanıcı hesabının SQL Server yöneticisi olarak otomatik eklenmesi için Add Current User seçeneğine tıklıyoruz. Bu işlemle birlikte, aktif oturumla giriş yapılmış kullanıcı hesabı SQL Server üzerinde sysadmin yetkisine sahip olacak şekilde tanımlanır.

Add Current User seçeneğinin kullanılması sayesinde ilgili kullanıcı;

• SQL Server yapılandırmalarını yönetebilir
• Veritabanı oluşturma, silme ve yapılandırma işlemlerini gerçekleştirebilir
• Güvenlik, kullanıcı ve yetkilendirme ayarlarını düzenleyebilir
• Performans, bakım ve Always On gibi gelişmiş özellikleri yönetebilir

Bu adımın doğru şekilde tamamlanması, kurulum sonrasında SQL Server’a erişim ve yönetim yetkilerinin sorunsuz sağlanabilmesi açısından büyük önem taşır. Özellikle Production (Üretim) ortamlarda, yalnızca yetkili kullanıcı veya grupların SQL Server administrator olarak tanımlanması, güvenlik ve erişim kontrolü açısından kritik bir best practice olarak değerlendirilmelidir.

Database Engine Configuration ekranında Server Configuration sekmesi altında yer alan Specify SQL Server administrators bölümünde, SQL Server üzerinde tam yönetim yetkisine (sysadmin) sahip olacak kullanıcı hesaplarının listelendiğini görüyoruz. Bu alanda, kurulum sırasında Add Current User seçeneği kullanıldığı için BAKICUBUK\Administrator (Administrator) hesabının otomatik olarak SQL Server yöneticisi olarak eklendiğini doğrulayabiliyoruz.

Bu hesap, SQL Server üzerinde;

• • Veritabanı oluşturma ve silme
  • Güvenlik ve yetkilendirme yönetimi
  • Always On, bakım planları ve performans ayarları
  • Sistem seviyesinde tüm yapılandırma işlemleri

gibi tüm yönetimsel işlemleri eksiksiz olarak gerçekleştirme yetkisine sahiptir.

Database Engine Configuration ekranında Server Configuration sekmesi altındaki gerekli tüm yapılandırmaları tamamladıktan sonra, kurulumun bir sonraki aşaması olan Data Directories sekmesine geçiyoruz. Bu adımda; Data, Log, TempDB ve Backup dosyalarının hangi disk ve dizinlerde tutulacağını belirleyerek, hem performans hem de depolama yönetimi açısından en doğru mimariyi oluşturuyoruz.

Database Engine Configuration ekranında yer alan Data Directories sekmesi, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulumunda veritabanı dosyalarının hangi dizinlerde tutulacağını belirlediğimiz kritik yapılandırma adımlarından biridir. Bu aşamada yapılacak doğru bir planlama; High Availability (Yüksek Erişilebilirlik), Performans, Yönetilebilirlik ve Failover Sürekliliği açısından doğrudan etki yaratır.

Bu sekmede; Database (Data), Transaction Log (Log), Backup ve dolaylı olarak TempDB dosyalarının konumları belirlenerek, Failover Cluster Instance (FCI) mimarisine uygun Cluster Shared Volumes (CSV) tabanlı bir disk yapısı oluşturulur.

Kurulum sırasında Microsoft SQL Server 2025 ile birlikte gelen Default (Varsayılan) dizinler görüntülenir. Ancak kurumsal ortamlarda ve özellikle SQL Server Failover Cluster Instance (FCI) mimarisinde, bu varsayılan dizinlerin mutlaka ihtiyaca göre özelleştirilmesi önerilir.

Data root directory: Microsoft SQL Server’ın tüm veri bileşenleri için temel kök dizinidir ve varsayılan olarak sistem veritabanları (master, model, msdb) ile bazı instance seviyesindeki yapılandırma bileşenlerini barındırır. Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kurulumunda Data root directory teknik olarak değiştirilebilir ve bu değişiklik kurulum sihirbazı üzerinden doğrudan yapılabilir. Ancak Data root directory, Failover Cluster rolü kapsamında Cluster Shared Volumes (CSV) üzerinde taşınan bir cluster kaynağı değildir. Bu dizin her Node üzerinde lokal olarak bulunur ve Failover sırasında Node’lar arasında taşınmaz. Failover sonrasında SQL Server rolü, aktif olan Node üzerinde aynı dizin yapısının mevcut olmasını bekler.

Bu nedenle Data root directory’nin farklı diskler veya tutarsız dizin yapılarıyla yapılandırılması; Node’lar arasında uyumsuzluklara, bakım ve sorun giderme süreçlerinde karmaşıklığa ve operasyonel risklere yol açabilir. Failover Cluster Instance (FCI) mimarisinde asıl kritik olan, kullanıcı veritabanlarına ait Data (.mdf (Primary Data File) ve .ndf (Secondary Data File)) ve Log (.ldf (Transaction Log) dosyalarının Cluster diskleri (Cluster Shared Volumes (CSV) veya klasik cluster diskleri) üzerinde konumlandırılması ve tüm Node’lar tarafından ortak şekilde erişilebilir olmasıdır.

Bu bağlamda kurumsal Failover Cluster Instance ortamlarında, Data root directory’nin tüm Node’larda birebir aynı lokal yol olacak şekilde planlanması ve kullanıcı veritabanı dosyalarının Cluster Shared Volumes (CSV) üzerinde yapılandırılması best practice olarak kabul edilir.

User database directory: Kullanıcı veritabanlarına ait .mdf (Primary Data File) ve .ndf (Secondary Data File) dosyalarının tutulduğu dizindir.

• mdf (Primary Data File): Her veritabanında zorunlu olan ana veri dosyasıdır ve metadata bilgilerini içerir.
• ndf (Secondary Data File): İsteğe bağlıdır; büyük veritabanlarında depolamayı ölçeklemek, I/O yükünü dağıtmak ve Filegroup bazlı mimari kurmak için kullanılır.

Bu dizinin, yüksek IOPS sağlayan diskler üzerinde konumlandırılması performans açısından büyük önem taşır.

User database log directory: Kullanıcı veritabanlarının .ldf (Transaction Log) dosyalarının tutulduğu dizindir. .ldf (Transaction Log) dosyaları; Veri Bütünlüğü, Rollback (Geri Dönüş) ve point-in-time recovery için kritik olduğu için, mutlaka data dosyalarından ayrı bir disk üzerinde konumlandırılmalıdır.

Backup directory: SQL Server tarafından alınan Full, Differential ve Transaction Log yedeklerinin tutulduğu dizindir. Backup dizininin data ve log disklerinden ayrı olması;

• Performans
• Güvenlik
• Disaster Recovery(Felaket Kurtarma)

açısından best practice olarak kabul edilir. Ayrıca Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity vb. gibi üçüncü parti yedekleme çözümleri için de kaynak dizin görevi görür.

Disk Ayrımının (Disk Segregation) Önemi
Disklerin farklı dizinler ve disk birimleri üzerinde yapılandırılmasının temel nedenleri şunlardır:

• I/O yükünü izole etmek
• Performansı artırmak
• Yedekleme ve büyüme yönetimini kolaylaştırmak
• Olası disk problemlerinin tüm sistemi etkilemesini önlemek

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) Disk Mimarisi
Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi, Cluster Shared Volumes (CSV) yapısı üzerine kuruludur.
Bu senaryoda:

• Data
• Log
• TempDB
• Backup

dizinleri Cluster Shared Volumes (CSV) veya klasik cluster diskleri üzerinde konumlandırılır.

Bu sayede cluster’a dahil olan tüm Node’lar, aynı disk alanını görür ve veritabanı dosyalarına ortak dizinler üzerinden erişir. Failover gerçekleştiğinde, aktif rolü alan node; herhangi bir veri kopyalama veya senkronizasyon ihtiyacı olmadan, aynı disk yapısı üzerinden çalışmaya devam eder. Bu, FCI mimarisinin en önemli avantajlarından biridir.

Örnek Failover Cluster Instance (FCI) Standart Dizin Yapısı (Cluster Shared Volumes (CSV) Üzerinde)

• C:\ClusterStorage\Volume1\DATA – Kullanıcı veritabanı data dosyaları (.mdf (Master Data File) ve .ndf (Secondary Data File))
• C:\ClusterStorage\Volume2\LOG – Transaction log dosyaları (.ldf (Transaction Log File))
• C:\ClusterStorage\Volume3\TEMP – TempDB dosyaları (.mdf (Master Data File), .ndf (Secondary Data File) ve .ldf (Transaction Log File))
• C:\ClusterStorage\Volume4\BACKUP – Yedekleme dosyaları (Full, Differential ve Transaction Log Backup)

Not: Cluster Shared Volumes (CSV) kullanılan ortamlarda, Windows sürücü harfleri yerine C:\ClusterStorage\VolumeX yolu tercih edilir ve bu yapı tüm Node’larda otomatik olarak aynıdır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi kurulduğundan; Data root directory, User database directory, User database log directory ve Backup directory alanları Failover Cluster Instance (FCI) gereksinimlerine uygun olacak şekilde yapılandırılır.

Bu yapılandırmada temel amaç, SQL Server Failover Cluster Instance (FCI) rolü kapsamında çalışan instance’ın Failover sırasında hangi Node aktif olursa olsun aynı dizin yapısına sorunsuz şekilde erişebilmesini sağlamaktır. Bu nedenle kullanıcı veritabanlarına ait Data, Log, TempDB ve Backup dosyaları Cluster Shared Volume (CSV) üzerinde konumlandırılır.

Data root directory, Failover Cluster Instance (FCI) mimarisinde tüm Node’larda tutarlı olacak şekilde planlanmalıdır. Bu ortamda Cluster Shared Volume (CSV) kullanıldığından, SQL Server kurulum sırasında Data root directory alanı otomatik olarak C:\ClusterStorage\Volume2 gibi bir yol üzerinden gelmiştir. Bu dizin, Cluster Shared Volume (CSV) mimarisi sayesinde tüm Node’larda aynı yol ile erişilebilir olup failover sırasında değişmez. Dolayısıyla Data root directory’nin Cluster Shared Volume (CSV) altında konumlandırılması, Failover Cluster Instance (FCI) mimarisinin çalışma prensipleriyle uyumludur ve yol tutarsızlığına neden olmaz.

Bu yaklaşım, failover senaryolarında olası dizin uyumsuzluklarını önler, bakım ve işletim süreçlerini sadeleştirir ve kurumsal Failover Cluster Instance (FCI) mimarileri için best practice olarak kabul edilir.

 

 

 

 

 

 

 

 

 

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, Data root directory bölümü SQL Server instance’ına ait tüm veri bileşenleri için temel kök dizinin yapılandırıldığı alandır. Bu dizini belirlemek için ilgili alanın sağ tarafında yer alan üç nokta (…) simgesine tıklıyoruz. Bu işlemle birlikte sunucu üzerindeki mevcut disk ve klasör yapısı görüntülenir ve SQL Server’ın sistem veritabanları ile varsayılan veri yolları için kullanılacak kök dizin manuel olarak seçilebilir.

Microsoft SQL Server 2025 üzerinde Data root directory; varsayılan olarak master, model ve msdb gibi sistem veritabanlarını, ayrıca instance seviyesindeki bazı yapılandırma bileşenlerini barındırır. Aynı zamanda User database directory, User database log directory ve Backup directory gibi diğer dizinler için de referans noktası görevi görür.

Bu aşama, özellikle mimari tutarlılık, yönetilebilirlik ve failover senaryoları açısından kritik öneme sahiptir. Data root directory’nin plansız veya node’lar arasında tutarsız bir şekilde yapılandırılması, ilerleyen süreçlerde bakım, taşıma ve sorun giderme aşamalarında ciddi operasyonel riskler doğurabilir.

Failover Cluster Instance (FCI) veya SQL Server Always On, High Availability gibi High Availability (Yüksek Erişilebilirlik) mimarilerinde Data root directory’nin, tüm Node’larda aynı yol yapısı ile erişilebilir olması esastır. Özellikle Cluster Shared Volume (CSV) kullanılan Failover Cluster Instance (FCI) ortamlarında bu dizin, kurulum sırasında C:\ClusterStorage\VolumeX benzeri bir yol altında otomatik olarak tanımlanabilir. Cluster Shared Volume (CSV) mimarisi sayesinde bu yol tüm Node’larda aynı şekilde erişilebilir olup failover sırasında değişmez.

Özetle, Data root directory için doğru dizinin seçilmesi; SQL Server mimarisinin standartlara uygun kurulması, failover süreçlerinin sorunsuz işlemesi ve uzun vadede yönetim kolaylığı sağlanması açısından büyük önem taşır. Bu nedenle Data root directory yapılandırması, kurulumun erken aşamasında dikkatle planlanmalı ve hedef mimariye uygun şekilde belirlenmelidir.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada kullanıcı veritabanı dosyalarının tutulacağı disk olarak Cluster Disk 4 (DATA – C:\ClusterStorage\Volume1) birimini seçiyoruz. Seçtiğimiz Cluster Disk 4, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm Node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Kullanıcı veritabanı dosyalarını daha düzenli ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume1 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume1\DATA isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde oluşturulacak kullanıcı veritabanlarına ait .mdf (Primary Data File) ve .ndf (Secondary Data File) dosyaları, belirlediğimiz C:\ClusterStorage\Volume1\DATA dizini altında konumlandırılacaktır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, Data root directory alanına ait yapılandırmayı tamamlamış bulunuyoruz. Bu adımda Data root directory belirlenerek, Microsoft SQL Server 2025 instance’ına ait tüm veri bileşenleri için temel kök dizin netleştirilmiş olur. Data root directory; sistem veritabanlarının (master, model, msdb) ve instance seviyesindeki bazı yapılandırma bileşenlerinin varsayılan olarak konumlandırıldığı dizindir ve aynı zamanda diğer veri dizinleri için referans noktası görevi görür.

Bu yapılandırma, SQL Server depolama mimarisinin doğru ve tutarlı şekilde planlanması açısından kritik öneme sahiptir. Data root directory’nin doğru belirlenmesi; bakım süreçlerinin sadeleştirilmesini, dizin standardizasyonunun korunmasını ve ilerleyen aşamalarda yapılacak genişletme veya taşıma işlemlerinin daha kontrollü yönetilmesini sağlar. Özellikle High Availability (Yüksek Erişilebilirlik) mimarilerinde, bu dizinin node’lar arasında tutarlı bir yol yapısına sahip olması operasyonel süreklilik açısından büyük önem taşır.

SQL Server mimarisinde kullanıcı veritabanlarına ait Data (.mdf (Primary Data File) ve .ndf (Secondary Data File)) ve .ldf (Transaction Log) dosyaları genellikle Data root directory dışında, performans odaklı ayrı diskler üzerinde konumlandırılır. Bu yaklaşım sayesinde Data root directory daha çok sistem veritabanları ve instance yapılandırmaları için sabit ve öngörülebilir bir merkez işlevi görür. Böylece veri ve log dosyalarının yoğun I/O yükü, sistem bileşenlerinden ayrıştırılmış olur.

Data root directory’nin doğru yapılandırılması; SQL Server’ın kararlı çalışması, failover veya yeniden başlatma senaryolarında beklenmeyen yol sorunlarının önlenmesi ve uzun vadede yönetilebilir bir altyapı oluşturulması açısından temel bir adımdır. Bu nedenle Data root directory ayarı, kurulumun erken aşamasında hedef mimariye uygun şekilde planlanmalı ve standartlara uygun olarak yapılandırılmalıdır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, User database directory bölümünde kullanıcı veritabanı dosyalarının (.mdf (Primary Data File) ve .ndf (Secondary Data File)) tutulacağı dizini yapılandırmak için ilgili alanın sağ tarafında yer alan üç nokta (…) simgesine tıklıyoruz. Bu işlemle birlikte sunucu üzerinde Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan mevcut disk ve klasör yapısı görüntülenir ve SQL Server kullanıcı veritabanlarının hangi dizin altında tutulacağı manuel olarak seçilebilir.

Bu aşama, özellikle performans, depolama yönetimi ve High Availability (Yüksek Erişilebilirlik) açısından kritik öneme sahiptir. Kullanıcı veritabanı dosyalarının, işletim sistemi diskinden ayrı ve Cluster Shared Volume (CSV) üzerinde konumlandırılması Failover Cluster Instance (FCI) mimarisinin temel gereksinimlerinden biridir. Bu sayede Failover sırasında hangi Node aktif olursa olsun, SQL Server instance’ı aynı veri dosyalarına kesintisiz şekilde erişebilir.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinde, User database directory olarak seçilen dizin tüm Node’lar tarafından ortak erişilebilen bir cluster disk üzerinde yer almalıdır. Bu yapı, node’lar arasında sürücü harfi veya yol uyumsuzluğu riskini ortadan kaldırır ve failover senaryolarının sorunsuz çalışmasını sağlar.
Bu dizin altında tutulan dosya türleri aşağıdaki gibidir:

• mdf (Primary Data File): mdf dosyası, SQL Server veritabanının birincil veri dosyasıdır ve her veritabanında yalnızca bir adet bulunur. Veritabanına ait temel metadata bilgileri, nesne tanımları (tablolar, index’ler, view’lar vb.) ve veritabanının başlangıç yapısı bu dosya içerisinde yer alır. mdf dosyası olmadan bir veritabanı çalışamaz ve veritabanının çekirdek bileşenini oluşturur.
• ndf (Secondary Data File): ndf dosyaları, SQL Server veritabanlarında isteğe bağlı olarak kullanılan ikincil veri dosyalarıdır ve bir veritabanında birden fazla ndf dosyası oluşturulabilir. Büyük ölçekli veritabanlarında depolamayı ölçeklendirmek, I/O yükünü farklı diskler arasında dağıtmak ve filegroup tabanlı mimariler oluşturmak amacıyla tercih edilir. mdf zorunlu çekirdek yapı iken, ndf dosyaları performans, esneklik ve yönetilebilirlik avantajı sağlar.

User database directory için doğru dizinin seçilmesi; disk I/O performansının artırılması, disk darboğazlarının önlenmesi ve Failover Cluster Instance (FCI) mimarisinde failover süreçlerinin sorunsuz şekilde gerçekleşmesi açısından büyük önem taşır. Kullanıcı veritabanı dosyalarının Cluster Shared Volume (CSV) üzerinde, standart ve tutarlı bir dizin yapısı altında konumlandırılması, kurumsal FCI ortamları için best practice olarak kabul edilir.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada kullanıcı veritabanı dosyalarının tutulacağı disk olarak Cluster Disk 4 (DATA – C:\ClusterStorage\Volume1) birimini seçiyoruz. Seçtiğimiz Cluster Disk 4, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm Node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Kullanıcı veritabanı dosyalarını daha düzenli ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume1 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume1\DATA isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde oluşturulacak kullanıcı veritabanlarına ait .mdf (Primary Data File) ve .ndf (Secondary Data File) dosyaları, belirlediğimiz C:\ClusterStorage\Volume1\DATA dizini altında konumlandırılacaktır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, veritabanı dosyalarının tutulacağı dizinlere ait yapılandırmayı tamamlamış bulunuyoruz. Bu aşamada özellikle User database directory alanını yapılandırarak, kullanıcı veritabanlarına ait .mdf (Primary Data File) ve .ndf (Secondary Data File) veri dosyalarının Failover Cluster Instance (FCI) mimarisinde hangi dizin altında saklanacağını netleştirmiş oluyoruz.

Bu yapılandırma; Microsoft SQL Server 2025 depolama mimarisinin doğru planlanması, disk I/O performansının artırılması ve veritabanı dosyalarının yönetilebilirliğinin sağlanması açısından kritik bir adımdır. FCI mimarisinde kullanıcı veritabanı dosyalarının, işletim sistemi diskinden ayrı ve Cluster Shared Volume (CSV) üzerinde konumlandırılması temel bir gereksinimdir. Böylece failover sırasında hangi node aktif olursa olsun SQL Server instance’ı aynı veri dosyalarına kesintisiz şekilde erişebilir.

SQL Server mimarisinde yalnızca veri dosyaları değil, .ldf (Transaction Log) dosyaları da ayrı bir öneme sahiptir. .ldf (Transaction Log) dosyası; SQL Server veritabanlarında gerçekleştirilen tüm işlemlerin (INSERT, UPDATE, DELETE, DDL değişiklikleri ve sistem işlemleri) sıralı ve güvenli şekilde kaydedildiği günlük dosyasıdır. Veritabanında yapılan her değişiklik önce log dosyasına yazılır, ardından veri dosyalarına işlenir. Bu mekanizma sayesinde SQL Server, veri bütünlüğünü korur ve beklenmeyen sistem kesintileri sonrasında veritabanını tutarlı bir duruma geri getirebilir.

.ldf (Transaction Log) dosyaları aynı zamanda point-in-time recovery (belirli bir zamana geri dönüş) senaryolarının temelini oluşturur. Özellikle Full Recovery Model kullanılan FCI ortamlarında, log yedekleri sayesinde veritabanı istenilen zaman noktasına kadar geri döndürülebilir. .ldf (Transaction Log) dosyalarının yüksek yazma trafiğine sahip olması nedeniyle, veri dosyalarından ayrı bir Cluster Shared Volume (CSV) birimi üzerinde tutulması best practice olarak kabul edilir. Bu yaklaşım, hem yazma performansını artırır hem de veri ve log I/O işlemlerinin birbirini olumsuz etkilemesini engeller.

Bu yapılandırma ile birlikte Microsoft SQL Server 2025 FCI ortamında;

• Veri dosyaları (.mdf (Primary Data File) ve .ndf (Secondary Data File)),
• .ldf (Transaction Log),
• Yedekleme dosyaları ((Full, Differential ve Transaction Log Backup))

için ayrıştırılmış, performans odaklı ve yönetilebilir bir depolama mimarisi oluşturulmuş olur. Bu yaklaşım, özellikle Failover Cluster Instance, High Availability (Yüksek Erişilebilirlik) gereksinimleri, yoğun işlem hacmi ve kurumsal uygulamaların çalıştığı Production ortamlarında kararlı ve sürdürülebilir bir altyapının temelini oluşturur.

Database Engine Configuration ekranında Data Directories sekmesinde, kullanıcı veritabanlarına ait .ldf (Transaction Log) dosyalarının tutulacağı dizini belirlemek için User database log directory alanının sağ tarafında bulunan üç nokta (…) simgesine tıklıyoruz. Bu adım sayesinde, SQL Server’ın işlem günlüklerini hangi disk ve klasör altında saklayacağını manuel olarak tanımlayabiliyoruz. .ldf (Transaction Log) dosyaları yüksek yazma I/O’su ürettiği için, veri dosyalarından (.mdf (Primary Data File) ve .ndf (Secondary Data File)) ayrı bir disk birimi üzerinde konumlandırılması performans ve kararlılık açısından en iyi pratiktir.

Browse For Folder ekranında log dosyaları için ayrılmış olan disk (örneğin F:\LOG) seçilerek gerekli klasör tanımlaması yapılır ve OK butonuna tıklanır. Bu yapılandırma ile birlikte, kullanıcı veritabanlarına ait tüm LDF dosyaları belirlenen dizin altında tutulacak şekilde ayarlanmış olur.

Bu ayrım; yoğun transaction trafiği olan sistemlerde disk darboğazlarını azaltır, Backup / Restore, Recovery ve Always On senaryolarında daha stabil ve öngörülebilir bir performans elde edilmesini sağlar.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada kullanıcı veritabanlarının Transaction Log dosyalarının tutulacağı disk olarak Cluster Disk 2 (LOG – C:\ClusterStorage\Volume2) birimini seçiyoruz. Seçtiğimiz Cluster Disk 2, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm Node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Transaction Log dosyalarını daha düzenli, okunabilir ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume2 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume2\LOG isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde oluşturulacak kullanıcı veritabanlarına ait .ldf (Transaction Log) dosyaları, varsayılan olarak C:\ClusterStorage\Volume2\LOG dizini altında konumlandırılacaktır.

Database Engine Configuration ekranında yer alan Data Directories sekmesi altında bulunan User database log directory bölümünü yapılandırarak, kullanıcı veritabanlarına ait .ldf (Transaction Log) dosyalarının Failover Cluster Instance (FCI) mimarisinde hangi dizin altında tutulacağını belirlemiş oluyoruz.

Bu adımda yapılan yapılandırma sayesinde .ldf (Transaction Log) dosyaları, kullanıcı veritabanlarına ait Data dosyalarından (.mdf (Primary Data File) ve .ndf – (Secondary Data File)) ayrı bir Cluster Shared Volume (CSV) ve dizin üzerinde konumlandırılır. .ldf (Transaction Log) dosyalarının veri dosyalarından ayrıştırılması, SQL Server mimarisinde best practice olarak kabul edilir ve FCI ortamlarında özellikle aşağıdaki avantajları sağlar:

• Performans Artışı: .ldf (Transaction Log) dosyaları, doğası gereği yüksek oranda sıralı (sequential) yazma işlemleri üretir. Log dosyalarının veri dosyalarından ayrı bir disk birimi üzerinde tutulması, disk I/O çakışmalarını minimize ederek genel veritabanı performansını artırır. Failover Cluster Instance (FCI) mimarisinde bu diskler paylaşımlı olduğu için, failover sonrası da aynı performans karakteristiği korunur.
• Veri Bütünlüğü ve Recovery (Kurtarma): SQL Server’da gerçekleştirilen tüm işlemler öncelikle .ldf (Transaction Log) dosyasına yazılır. Log dosyalarının ayrı bir disk üzerinde konumlandırılması; donanım arızaları, sistem kesintileri veya disk sorunları yaşandığında veri bütünlüğünün korunmasına ve recovery süreçlerinin daha sağlıklı yürütülmesine katkı sağlar.
• Yedekleme ve Disaster Recovery (Felaket Kurtarma) Senaryoları: Failover Cluster Instance (FCI) mimarisinde Full Recovery Model kullanılan ortamlarda, log backup süreçleri kritik öneme sahiptir. .ldf (Transaction Log) dosyalarının ayrı bir yapıda tutulması; log yedekleme, point-in-time recovery ve diğer Disaster Recovery (Felaket Kurtarma) senaryolarının daha yönetilebilir ve öngörülebilir şekilde uygulanmasını sağlar.
• Ölçeklenebilirlik ve Yönetilebilirlik: .ldf (Transaction Log) dosyalarının büyümesi, izlenmesi ve gerektiğinde disk kapasitesinin artırılması; veri dosyalarından bağımsız bir şekilde yönetilebilir. Bu durum, özellikle yoğun işlem hacmine sahip kurumsal Failover Cluster Instance (FCI) ortamlarında operasyonel esneklik sağlar.

Sonuç olarak, User database log directory ayarının doğru Cluster Shared Volume (CSV) ve dizin üzerinde yapılandırılması; Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinde hem yüksek performans, hem High Availability (Yüksek Erişilebilirlik), hem de Disaster Recovery (Felaket Kurtarma) gereksinimlerinin sağlıklı şekilde karşılanması açısından kritik bir adımdır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, Backup directory bölümünü yapılandırmak için ilgili alanın yanındaki üç nokta (…) simgesine tıklıyoruz. Bu adım, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinde SQL Server tarafından alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizin altında saklanacağını belirlememizi sağlar.

Doğru bir Backup directory yapılandırması; yedek dosyalarının düzenli yönetilmesi, yedekleme işlemleri sırasında performansın korunması ve olası veri kaybı veya sistem arızası senaryolarında hızlı ve güvenli geri dönüş sağlanması açısından kritik öneme sahiptir. Failover Cluster Instance (FCI) mimarisinde bu dizinin, tüm Node’lar tarafından erişilebilir ve failover sırasında kesintisiz kullanılabilir olması gerekir.

SQL Server yedekleme mimarisinde kullanılan temel yedek türleri şunlardır:

• Full Backup: Veritabanının o andaki tüm veri ve nesnelerini kapsayan eksiksiz yedektir. Geri yükleme (restore) senaryolarının temelini oluşturur ve diğer yedekleme türleri bu yedek üzerine inşa edilir.
• Differential Backup: Son alınan Full Backup’tan sonra değişen tüm veri sayfalarını içerir. Full yedeğe kıyasla daha küçük boyutludur ve daha kısa sürede alınır. Restore işlemi sırasında Full Backup’tan sonra en güncel Differential Backup geri yüklenir.
• Transaction Log Backup: Veritabanında gerçekleşen tüm işlemlerin kayıtlarını içerir ve point-in-time restore (belirli bir zaman noktasına geri dönüş) imkanı sağlar. Düzenli olarak alındığında hem veri kaybı riskini minimize eder hem de .ldf (Transaction Log) dosyasının kontrolsüz şekilde büyümesini engeller.

Failover Cluster Instance (FCI) mimarisinde Backup directory için; veri (DATA) ve işlem günlüğü (LOG) disklerinden ayrı bir Cluster Shared Volumes (CSV) seçilmesi best practice olarak kabul edilir. Örneğin BACKUP – C:\ClusterStorage\Volume4 gibi bir dizinin kullanılması; yedekleme işlemlerinin veri ve log I/O yükünden ayrıştırılmasını sağlar ve disk darboğazlarını önler.

Bu yaklaşım sayesinde hem yedekleme performansı artırılır hem de disk arızaları, veri bozulmaları veya node failover senaryolarında yedek dosyalarının güvenliği sağlanmış olur. Kurumsal Failover Cluster Instance (FCI) ortamlarında Backup directory’nin doğru disk ve dizin üzerinde yapılandırılması, High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) stratejilerinin sağlıklı şekilde işletilmesinin temel taşlarından biridir.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada SQL Server yedekleme dosyalarının tutulacağı disk olarak Cluster Disk 5 (BACKUP – C:\ClusterStorage\Volume4) birimini seçiyoruz. Seçtiğimiz Cluster Disk 5, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm Node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Yedek dosyalarını daha düzenli, merkezi ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume4 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume4\BACKUP isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde alınacak olan Full Backup, Differential Backup ve Transaction Log Backup dosyaları varsayılan olarak C:\ClusterStorage\Volume4\BACKUP dizini altında konumlandırılacaktır.

Database Engine Configuration ekranında yer alan Data Directories sekmesinde, Backup directory bölümünü yapılandırarak Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizin altında saklanacağını belirlemiş oluyoruz.

Bu yapılandırma sayesinde SQL Server tarafından oluşturulan tüm yedekleme dosyaları tek, standart ve merkezi bir klasör yapısı altında toplanır. FCI mimarisinde Backup directory’nin, tüm Node’lar tarafından erişilebilen paylaşımlı bir disk (Cluster Disk / CSV) üzerinde konumlandırılması gerekir. Böylece failover sırasında hangi node aktif olursa olsun, yedekleme ve geri yükleme işlemleri kesintisiz şekilde devam edebilir.

Yedeklerin veri (DATA) ve işlem günlüğü (LOG) disklerinden ayrı bir disk birimi üzerinde tutulması; disk I/O yükünün ayrıştırılmasını sağlar ve yedekleme işlemlerinin sistem performansını olumsuz etkilemesini engeller. Aynı zamanda bu yaklaşım, disk arızaları veya veri bozulmaları gibi senaryolara karşı ek bir güvenlik katmanı oluşturur.

Ayrıca bu yapı; harici yedekleme çözümleri (örneğin Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity) tarafından yedek dizinlerinin kolayca hedeflenmesini sağlar ve restore (geri yükleme) senaryolarının yönetimini önemli ölçüde sadeleştirir. Merkezi ve tutarlı bir Backup directory yapısı, denetim (audit), raporlama ve Disaster Recovery (Felaket Kurtarma) süreçlerinde de operasyonel kolaylık sunar.

Sonuç olarak, doğru yapılandırılmış bir Backup directory; kurumsal Failover Cluster Instance ortamlarında yedekleme stratejisinin sürdürülebilir, düzenli ve denetlenebilir şekilde uygulanabilmesi açısından kritik öneme sahiptir ve FCI mimarileri için best practice olarak kabul edilir.

Database Engine Configuration ekranında Data Directories sekmesinde, Microsoft SQL Server 2025 üzerinde oluşturulacak veritabanlarına ait veri dosyalarının (mdf), log dosyalarının (ldf) ve yedekleme dosyalarının (backup) hangi dizinlerde tutulacağını belirliyoruz.

Bu aşamada User database directory, User database log directory ve Backup directory alanları için önceden planlanmış disk ve klasör yapıları seçilerek yapılandırma tamamlanır. Veri, log ve yedek dosyalarının farklı diskler üzerinde konumlandırılması; performansın artırılması, disk I/O çakışmalarının azaltılması ve yedekleme süreçlerinin daha sağlıklı yönetilmesi açısından kritik öneme sahiptir. Ayrıca bu yapı, ilerleyen aşamalarda bakım ve Disaster Recovery (Felaket Kurtarma) senaryolarında da önemli avantajlar sağlar.

Database Engine Configuration ekranında Data Directories sekmesinde gerekli tüm dizin yapılandırmaları tamamlandıktan sonra, Microsoft SQL Server 2025 kurulum sürecinin bir sonraki önemli adımı olan TempDB yapılandırmasına geçiyoruz. TempDB, SQL Server’ın yoğun şekilde kullandığı sistem veritabanlarından biri olduğu için bu adımda yapılacak doğru yapılandırma; sorgu performansı, eş zamanlılık (concurrency) ve genel sistem kararlılığı açısından büyük önem taşır.

Database Engine Configuration ekranında yer alan TempDB sekmesi, Microsoft SQL Server 2025 kurulum sürecinin en kritik adımlarından biridir. Bu aşamada, SQL Server’ın geçici veri işlemlerini yürüttüğü TempDB sistem veritabanının nasıl yapılandırılacağı belirlenir. TempDB, SQL Server’ın en yoğun kullanılan bileşenlerinden biri olduğu için burada yapılacak doğru bir yapılandırma; hem performans hem de sistem kararlılığı açısından doğrudan etki yaratır. SQL Server; geçici tablolar, tablo değişkenleri, index rebuild işlemleri, sort ve hash operasyonları ile sorguların çalışma alanları gibi pek çok süreci TempDB üzerinden gerçekleştirir. Bu nedenle kurulum sırasında doğru boyutlama ve dosya dağılımının yapılması, ileride yaşanabilecek performans problemlerinin önüne geçilmesini sağlar.

• TempDB, Microsoft SQL Server 2025’in en yoğun kullanılan sistem veritabanlarından biridir ve tüm instance tarafından ortak olarak kullanılır. Bu durum, TempDB’nin performans üzerindeki etkisini daha da kritik hale getirir. Yanlış veya yetersiz yapılandırılmış bir TempDB, sistem genelinde darboğazlara, sorgu yavaşlamalarına ve eş zamanlılık problemlerine neden olabilir. Kurulum sırasında TempDB için birden fazla Data File oluşturulması önerilir. Bu yaklaşım, özellikle çok çekirdekli sistemlerde sıkça karşılaşılan PFS, GAM ve SGAM latch contention problemlerinin azaltılmasına yardımcı olur. Microsoft’un güncel best practice önerilerine göre, sekiz çekirdeğe kadar çekirdek sayısı kadar, daha yüksek çekirdekli sistemlerde ise maksimum sekiz adet TempDB data dosyası kullanılması ideal kabul edilmektedir. Data dosyalarının başlangıç boyutlarının yeterli seviyede belirlenmesi ve autogrowth değerlerinin yüzdesel yerine sabit MB cinsinden yapılandırılması (örneğin 64 MB veya 128 MB) daha kontrollü ve öngörülebilir bir büyüme sağlar. Bu yapı, ani disk I/O artışlarının ve performans dalgalanmalarının önüne geçer. Doğru yapılandırılmış bir TempDB, özellikle yoğun OLTP sistemlerinde sorguların daha hızlı tamamlanmasına, index bakım operasyonlarının daha sağlıklı yürütülmesine ve genel SQL Server performansının artmasına katkı sağlar. Buna karşılık, hatalı yapılandırılmış bir TempDB; uzun süren bakım işlemleri, metadata contention, bekleme türlerinin artması ve genel sistem performansının düşmesi gibi sorunlara yol açabilir. Microsoft SQL Server 2025 ile birlikte gelen geliştirilmiş TempDB yönetim ve optimizasyon mekanizmaları sayesinde, bu alanda yapılan doğru ayarlamalar önceki sürümlere kıyasla çok daha yüksek performans kazanımları sunmaktadır.
• TempDB Log dosyası ise TempDB üzerinde gerçekleşen tüm geçici işlemlerin transaction kayıtlarını tutar. SQL Server, her instance için yalnızca tek bir TempDB log dosyasını desteklediğinden, bu dosyanın doğru yapılandırılması ayrı bir önem taşır. Yetersiz başlangıç boyutuna sahip veya yanlış autogrowth ayarları yapılmış bir log dosyası, sık büyüme işlemleri nedeniyle ciddi performans kayıplarına ve disk I/O yükünün artmasına neden olabilir. Bu nedenle TempDB log dosyasının başlangıç boyutunun en az 512 MB, tercihen 1 GB olarak yapılandırılması önerilir. Autogrowth ayarının yüzdesel yerine sabit MB (örneğin 256 MB veya 512 MB) olarak belirlenmesi, log dosyasının daha stabil ve kontrollü bir şekilde büyümesini sağlar. Optimize edilmiş bir TempDB log yapılandırması yalnızca geçici işlemleri değil; büyük sorguların çalışma sürelerini, ETL süreçlerini, yoğun OLTP yüklerini ve TempDB kaynaklı bekleme türlerini de doğrudan etkiler. Microsoft SQL Server 2025’in sunduğu gelişmiş Memory Feedback ve TempDB metadata optimizasyonları ile birlikte doğru log yapılandırması yapıldığında, sistem kaynakları çok daha verimli kullanılır ve SQL Server genelinde daha stabil, öngörülebilir bir performans elde edilir.

Database Engine Configuration ekranında TempDB sekmesinde yer alan Data directories bölümünde, varsayılan olarak tanımlı gelen dizini değiştirmek istediğimizde mevcut dizini kaldırmak için Remove seçeneğine tıklıyoruz. Bu işlemle birlikte, Microsoft SQL Server 2025 kurulum sihirbazı tarafından otomatik olarak tanımlanmış olan varsayılan TempDB veri dizini yapılandırmadan çıkarılır.

Varsayılan dizin kaldırıldıktan sonra, Add seçeneğini kullanarak TempDB veri dosyalarının tutulacağı yeni dizin yolunu ekleyebilir ve bu alanı ortamın disk mimarisine ve performans gereksinimlerine uygun şekilde özelleştirebiliriz. TempDB’nin, mümkünse ayrı ve yüksek performanslı bir disk veya disk grubu üzerinde konumlandırılması; yoğun okuma-yazma işlemlerinin daha verimli yönetilmesini ve disk I/O çakışmalarının azaltılmasını sağlar. TempDB veri dosyalarının doğru dizinde ve doğru disk üzerinde konumlandırılması, özellikle yüksek I/O gerektiren OLTP ve yoğun sorgu yüküne sahip sistemlerde performans açısından kritik öneme sahiptir. Bu aşamada yapılan doğru planlama, ilerleyen dönemlerde yaşanabilecek performans sorunlarının ve darboğazların önüne geçilmesine önemli ölçüde katkı sağlar.

Database Engine Configuration ekranında TempDB sekmesinde yer alan Data directories bölümünde, TempDB veri dosyalarının tutulacağı dizini yapılandırmak için Add seçeneğine tıklıyoruz. Bu adımda, TempDB data file’larının konumlandırılacağı yeni dizin yolu tanımlanır ve SQL Server’ın geçici veri işlemleri sırasında kullanacağı fiziksel disk yapısı belirlenmiş olur.

TempDB’nin, mümkün olduğunca yüksek I/O performansına sahip ve diğer kritik veritabanı dosyalarından ayrılmış bir disk üzerinde konumlandırılması önerilir. Özellikle yoğun Geçici Tablo, Sort, Hash ve Index Bakım işlemlerinin gerçekleştiği ortamlarda TempDB disk performansı, SQL Server genel performansını doğrudan etkiler. Bu nedenle bu aşamada yapılacak doğru dizin ve disk seçimi, sorgu sürelerinin kısalmasına, bekleme sürelerinin azalmasına ve sistemin daha kararlı çalışmasına önemli katkı sağlar.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada TempDB veri dosyalarının tutulacağı disk olarak Cluster Disk 3 (TEMP – C:\ClusterStorage\Volume3) birimini seçiyoruz. Seçtiğimiz Cluster Disk 5, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm Node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Yedek dosyalarını daha düzenli, merkezi ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume3 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume3\TEMP isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde çalışan SQL Server instance’ına ait TempDB veritabanının .mdf (Primary Data File) ve .ndf (Secondary Data File) dosyaları, belirlediğimiz C:\ClusterStorage\Volume3\TEMP dizini altında oluşturulacaktır.

Failover Cluster Instance (FCI) mimarisinde TempDB, kullanıcı veritabanlarından farklı olarak Cluster Shared Volume (CSV) üzerinde tutulmak zorunda değildir. TempDB, SQL Server servisinin her başlatılmasında Recreated (Yeniden oluşturulan) bir sistem veritabanı olduğu için, her Node üzerinde local ve yüksek performanslı diskler üzerinde konumlandırılması best practice olarak kabul edilir.

Bu yapılandırma sayesinde TempDB; diğer veritabanı DATA ve LOG disklerinden tamamen ayrıştırılmış, yalnızca geçici işlemlere odaklı bir disk üzerinde çalışır. Özellikle:

• Yoğun temporary table kullanımı
• Sort ve hash operasyonları
• Index bakım ve rebuild işlemleri
• Snapshot tabanlı okuma senaryoları

bulunan ortamlarda TempDB’nin local ve ayrı bir disk üzerinde konumlandırılması; disk I/O çakışmalarını azaltır, bekleme sürelerini düşürür ve SQL Server’ın genel performansına doğrudan olumlu katkı sağlar.

Failover Cluster Instance (FCI) mimarisinde her node üzerinde aynı sürücü harfi ve dizin yapısının (Örneğin C:\ClusterStorage\Volume3\TEMP) birebir oluşturulması, failover sonrasında SQL Server servisinin aktif Node üzerinde TempDB’yi sorunsuz şekilde yeniden oluşturabilmesi açısından kritik öneme sahiptir. Bu yaklaşım, hem High Availability (Yüksek Erişilebilirlik) gereksinimlerini karşılar hem de öngörülebilir ve sürdürülebilir bir performans mimarisi sunar.

Database Engine Configuration ekranında yer alan TempDB sekmesindeki Data directories bölümüne ait dizin yapılandırmasını tamamlıyoruz. Bu adım ile TempDB veri dosyalarının Failover Cluster Instance (FCI) mimarisinde sunucu üzerinde hangi dizinde tutulacağı net olarak belirlenmiş olur ve SQL Server’ın geçici veri işlemleri için kullanacağı fiziksel disk konumu tanımlanır.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisinde TempDB, kullanıcı veritabanlarından farklı olarak her node üzerinde local ve yüksek performanslı diskler üzerinde konumlandırılır. TempDB’nin her SQL Server servis başlangıcında Recreated (Yeniden Oluşturulan) bir sistem veritabanı olması nedeniyle, bu yaklaşım hem performans hem de operasyonel süreklilik açısından best practice olarak kabul edilir.

TempDB’nin doğru disk ve doğru dizin altında yapılandırılması; özellikle yoğun Temporary Table (Geçici Tablo) kullanımı, sort ve hash operasyonları ile index bakım işlemleri üreten ortamlarda SQL Server performansını doğrudan etkileyen kritik bir faktördür. Bu aşamada yapılan doğru konumlandırma; disk I/O çakışmalarının azaltılmasına, bekleme sürelerinin düşürülmesine ve SQL Server’ın daha kararlı, öngörülebilir ve sürdürülebilir bir performans sunmasına önemli katkı sağlar.

Failover Cluster Instance (FCI) mimarisinde her node üzerinde aynı sürücü harfi ve dizin yapısının birebir oluşturulması, failover sonrasında SQL Server servisinin aktif Node üzerinde TempDB’yi sorunsuz şekilde yeniden oluşturabilmesi açısından kritik öneme sahiptir. Bu yaklaşım, High Availability (Yüksek Erişilebilirlik) gereksinimleri ile performans beklentilerinin birlikte karşılanmasını sağlar.

Database Engine Configuration ekranında TempDB sekmesinde, Log directories bölümünü yapılandırmak için ilgili alanın yanındaki üç nokta (…) simgesine tıklıyoruz. Bu işlem ile TempDB’ye ait log dosyasının (templog) sunucu üzerinde hangi dizinde tutulacağı belirlenir ve log dosyasının fiziksel konumu yapılandırılır.

TempDB log dosyalarının, mümkünse ayrı ve yüksek performanslı bir disk üzerinde konumlandırılması; yoğun transaction, geçici tablo kullanımı ve büyük sorguların çalıştığı SQL Server ortamlarında disk I/O verimliliğini artırır. Bu aşamada yapılan doğru yapılandırma, log dosyasında oluşabilecek sık autogrowth işlemlerinin ve buna bağlı performans düşüşlerinin önüne geçilmesine yardımcı olur. Microsoft SQL Server 2025’in gelişmiş TempDB yönetim mekanizmaları ile birlikte, uygun log dizini seçimi sistemin daha kararlı ve öngörülebilir şekilde çalışmasına önemli katkı sağlar.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada TempDB’ye ait log dosyalarının tutulacağı disk olarak Cluster Disk 2 (LOG – C:\ClusterStorage\Volume2) birimini seçiyoruz. Seçtiğimiz Cluster Disk 2, Cluster Shared Volume (CSV) olarak yapılandırılmış olup tüm node’lar tarafından ortak şekilde erişilebilen Cluster Shared Volume (CSV) alanıdır.

Transaction Log dosyalarını daha düzenli, okunabilir ve yönetilebilir bir yapı altında tutmak amacıyla, C:\ClusterStorage\Volume2 dizini altında yeni bir klasör oluşturuyoruz. Örneğin C:\ClusterStorage\Volume2\TEMPLOG isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi üzerinde oluşturulacak TempDB’ye ait log dosyaları, varsayılan olarak C:\ClusterStorage\Volume2\TEMPLOG dizini altında konumlandırılacaktır.

Bu adım ile TempDB log dosyaları (templog), diğer veritabanı veri ve log dosyalarından ayrılmış, performans odaklı ayrı bir disk üzerinde konumlandırılmış olur. Özellikle yoğun işlem hacmine sahip SQL Server ortamlarında TempDB log dosyalarının doğru disk üzerinde yapılandırılması; disk I/O çakışmalarını azaltır, log büyüme (autogrowth) işlemlerinin daha kontrollü gerçekleşmesini sağlar ve Microsoft SQL Server 2025’in genel performansına doğrudan olumlu katkı sunar.

Database Engine Configuration ekranında TempDB sekmesinde yer alan Log directories bölümüne ait yapılandırmayı tamamladıktan sonra, TempDB’nin hem veri hem de log dosyalarına ilişkin tüm dizin ayarları başarıyla gerçekleştirilmiş olur. Bu aşama ile TempDB’nin performans odaklı disk yerleşimi tamamlanır ve SQL Server’ın geçici veri işlemleri için gerekli altyapı hazır hale gelir.

Database Engine Configuration ekranında TempDB sekmesinde TempDB ve TempDB Log dizin yapılandırmalarını tamamladıktan sonra, Microsoft SQL Server 2025 kurulum sürecinin bir sonraki adımı olan MaxDOP yapılandırmasına geçiyoruz. MaxDOP (Maximum Degree of Parallelism), SQL Server’ın sorguları kaç çekirdek kullanarak paralel çalıştıracağını belirleyen önemli bir performans parametresidir ve özellikle CPU yoğun iş yüklerinde doğru yapılandırılması önerilir.

MaxDOP, Memory ve FILESTREAM seçenekleri, Microsoft SQL Server 2025 kurulumu sırasında yapılandırılabilse de, Failover Cluster Instance (FCI) mimarisi için doğrudan kritik bileşenler arasında yer almaz. Failover Cluster Instance (FCI) yapısının sağlıklı çalışması; Windows Server Failover Cluster (WSFC) yapılandırması, Quorum ayarları ve Cluster Shared Volumes (CSV) altyapısının tüm Node’lar tarafından tutarlı şekilde erişilebilir olmasına bağlıdır. Bu nedenle MaxDOP, Memory ve FILESTREAM ayarlarının hatalı yapılandırılması, Failover Cluster Instance (FCI) mimarisinin failover mekanizmasını doğrudan engellemez. Ancak bu ayarların doğru planlanması, Failover Cluster Instance (FCI) üzerinde çalışan veritabanlarının performansı ve sistemin genel verimliliği açısından önemlidir.

Database Engine Configuration ekranında yer alan MaxDOP sekmesi, Microsoft SQL Server 2019 ile birlikte kurulum sihirbazına eklenen önemli bir yapılandırma alanıdır. SQL Server’ın önceki sürümlerinde Max Degree of Parallelism ayarı kurulum aşamasında sunulmadığı için, bu değer yalnızca sp_configure komutu veya SQL Server Management Studio (SSMS) üzerinden manuel olarak yapılandırılabiliyordu. SQL Server 2019’dan itibaren MaxDOP ayarının doğrudan kurulum sırasında belirlenebilmesi; yapılandırma tutarlılığını artırmış, kurulum sonrası ek optimizasyon ihtiyacını önemli ölçüde azaltmıştır.

MaxDOP (Max Degree of Parallelism), SQL Server’ın bir sorguyu paralel olarak çalıştırırken kullanabileceği en fazla işlemci çekirdeği sayısını belirleyen kritik bir performans parametresidir. Bu ayar, paralel sorgu planlarında kullanılan operatörlerin kaç iş parçacığı (thread) ile çalışacağını tanımlar ve özellikle yüksek çekirdekli sistemlerde sorgu performansı üzerinde doğrudan etkiye sahiptir. SQL Server’ın çalıştığı donanım mimarisi; SMP, NUMA veya Hyper-Threading destekli işlemciler, MaxDOP değerinin nasıl belirlenmesi gerektiğini doğrudan etkiler. Bu nedenle uygun MaxDOP değeri belirlenirken sistemin çekirdek yapısı, donanım kapasitesi ve iş yükünün türü mutlaka dikkate alınmalıdır. Geçmiş sürümlerde MaxDOP ayarı yalnızca sp_configure komutu veya SQL Server Management Studio (SSMS) üzerinden yapılandırılabiliyordu. Ancak sorgu bazında kullanılan MAXDOP query hint, instance seviyesinde tanımlanan bu değeri geçersiz kılabilir. Ayrıca SQL Server 2008 ve sonraki sürümlerde, eğer Resource Governor üzerinde bir MAXDOP değeri tanımlanmışsa, SQL Server öncelikli olarak bu değeri uygular. Bu yaklaşım, farklı iş yükü grupları arasında daha kontrollü ve öngörülebilir bir paralellik yönetimi sağlar.

Doğru yapılandırılmış bir MaxDOP değeri:

• Paralel sorgu yürütmeyi dengeler,
• CPU kullanımını optimize eder,
• CXPACKET ve CXCONSUMER gibi bekleme türlerini azaltır,
• OLTP ve OLAP iş yüklerinde genel sistem performansını iyileştirir.

Bu nedenle Microsoft SQL Server 2025 kurulumu sırasında MaxDOP ayarının, hedeflenen iş yükü ve donanım mimarisiyle uyumlu şekilde belirlenmesi kritik önem taşır.

Database Engine Configuration ekranında MaxDOP sekmesinde gerekli yapılandırmayı tamamladıktan sonra, Microsoft SQL Server 2025 kurulum sürecinin bir sonraki adımı olan Memory yapılandırmasına geçiyoruz.

Database Engine Configuration ekranında yer alan Memory sekmesi, Microsoft SQL Server 2019 ile birlikte kurulum sihirbazına eklenen ve Microsoft SQL Server 2025 sürümünde daha da gelişmiş hale getirilen önemli bir yapılandırma bölümüdür. SQL Server’ın önceki sürümlerinde Memory (Bellek) yönetimi kurulum aşamasında yapılandırılamadığı için bu ayarlar yalnızca kurulum sonrasında SQL Server Management Studio (SSMS) veya sp_configure komutları aracılığıyla yapılabiliyordu. Microsoft SQL Server 2025 ile birlikte bellek sınırlarının doğrudan kurulum aşamasında belirlenebilmesi, özellikle kurumsal ve yüksek iş yüküne sahip ortamlarda performans optimizasyonu açısından önemli bir avantaj sunmaktadır.

Database Engine Configuration ekranında bulunan Recommended, Default, Minimum Server Memory ve Maximum Server Memory ayarları, Microsoft SQL Server 2025’in RAM kullanım davranışını kontrol eden temel parametrelerdir ve bellek yönetiminin nasıl şekilleneceğini belirler.

Recommended ve Default alanları, Microsoft SQL Server 2025 tarafından bellek yapılandırması için referans alınabilecek başlangıç değerlerini gösterir.

• Recommended: Sunucunun donanım özellikleri dikkate alınarak Microsoft tarafından önerilen ideal Maximum Server Memory değerini ifade eder.
• Default: SQL Server’ın varsayılan Dynamic Memory (Dinamik Bellek) yönetimi modeliyle çalışacağını belirtir. Bu modelde SQL Server, mevcut belleği mümkün olduğunca verimli kullanır ve işletim sistemi ihtiyaç duyduğunda belirli bir miktar belleği serbest bırakabilir. Bu değerler yalnızca öneri niteliğindedir; SQL Server’ın çalışacağı iş yükü tipi, kullanım senaryosu ve sunucu üzerinde çalışan diğer uygulamalar mutlaka göz önünde bulundurularak özelleştirilmelidir.
• Minimum Server Memory: Microsoft SQL Server 2025’in çalışma sırasında kullanabileceği en düşük RAM miktarını tanımlar. SQL Server, bu değere ulaşana kadar bellek talep etmeye devam eder; ancak belirlenen minimum seviyeye ulaştıktan sonra belleği otomatik olarak azaltmaz. Bu ayar, SQL Server için bir alt bellek sınırı oluşturur ve özellikle sürekli bellek tüketen yoğun OLTP sistemlerinde daha stabil bir çalışma ortamı sağlar. Çoğu senaryoda bu değerin varsayılan ayarda bırakılması yeterlidir.
• Maximum Server Memory: Microsoft SQL Server 2025’in kullanabileceği en yüksek RAM miktarını belirleyen ve bellek yapılandırmasının en kritik parametresidir. SQL Server, varsayılan davranış olarak erişebildiği tüm belleği kullanma eğilimindedir. Bu nedenle işletim sistemi, güvenlik yazılımları, izleme (monitoring) araçları ve diğer servisler için mutlaka yeterli RAM ayrılması gerekir. Doğru yapılandırılmış bir Max Server Memory değeri; işletim sisteminin bellek yetersizliği yaşamasını önler, SQL Server’ın aşırı RAM tüketerek sistem genelinde darboğaz oluşturmasını engeller ve buffer pool, query plan cache ile bellek tahsis mekanizmalarının daha dengeli çalışmasını sağlar.

Örnek bir yapılandırma olarak; toplam 64 GB RAM bulunan bir sunucuda, işletim sistemi için 6–8 GB bellek ayrılarak Maximum Server Memory ≈ 56 GB olacak şekilde yapılandırılması yaygın bir best practice yaklaşımıdır. Bu değer, ortamın ihtiyaçlarına göre artırılabilir veya azaltılabilir.

Microsoft SQL Server 2025 ile birlikte gelen geliştirilmiş bellek yönetim mekanizmaları (Intelligent Memory Grant Feedback, Memory Advisor) sayesinde, bu değerlerin doğru belirlenmesi performans ve sistem kararlılığı açısından her zamankinden daha büyük önem taşımaktadır.

Database Engine Configuration ekranında Memory sekmesinde gerekli yapılandırmaları tamamladıktan sonra, Microsoft SQL Server 2025 kurulum sürecinin bir sonraki adımı olan FILESTREAM yapılandırmasına geçiyoruz.

Database Engine Configuration ekranında yer alan FILESTREAM sekmesi, Microsoft SQL Server 2019 ile birlikte kurulum sihirbazına eklenen ve Microsoft SQL Server 2025 sürümünde de kullanılmaya devam eden önemli bir yapılandırma bölümüdür. Önceki SQL Server sürümlerinde FILESTREAM ayarları kurulum aşamasında sunulmadığından, bu özellik yalnızca SQL Server Configuration Manager veya T-SQL komutları aracılığıyla manuel olarak etkinleştirilebiliyordu. SQL Server 2019 ve sonrasında FILESTREAM yapılandırmasının doğrudan kurulum sırasında yönetilebilir hale gelmesi, özellikle büyük boyutlu dosya içeriğiyle çalışan uygulamalar için önemli bir operasyonel kolaylık sağlamıştır.

FILESTREAM: SQL Server üzerinde tutulan büyük boyutlu BLOB verilerin (dokümanlar, görüntüler, videolar, PDF’ler, medya dosyaları vb.) NTFS dosya sistemi üzerinde saklanmasını sağlayan bir teknolojidir. Bu mimaride veriler, veritabanı içindeki varbinary(MAX) alanlarıyla mantıksal ilişkisini korur; ancak fiziksel olarak .mdf (Primary Data File) ve .ndf (Secondary Data File) veritabanı dosyaları içine yazılmak yerine, NTFS üzerinde oluşturulan özel FILESTREAM klasörlerinde depolanır. Bu yaklaşım, hem performans hem de yönetilebilirlik açısından önemli avantajlar sunar. Küçük boyutlu BLOB veriler (genellikle 1 MB’tan küçük) doğrudan veritabanı içinde saklandığında daha düşük gecikme ve daha tutarlı performans sağlarken, büyük dosyaların veritabanı içerisinde tutulması;

• Yedekleme (Backup) sürelerini artırır,
• Geri yükleme (Restore) işlemlerini uzatır,
• DBCC CHECKDB işlemlerinde ek yük oluşturur,
• Veritabanı dosyalarının gereksiz büyümesine neden olur.

Bu nedenle FILESTREAM, özellikle büyük medya ve dosya içeriklerinin yoğun kullanıldığı uygulamalarda doğru şekilde yapılandırıldığında; veritabanı performansını artırır, depolama maliyetlerini düşürür ve yönetim operasyonlarını daha verimli hale getirir.

Database Engine Configuration ekranında FILESTREAM sekmesinde, Microsoft SQL Server 2025 kurulumu için gerekli yapılandırmalar kontrol edildikten sonra, ortamımızda FILESTREAM özelliğini kullanmayacağımız için bu bölümde herhangi bir değişiklik yapmıyoruz. Varsayılan yapılandırmayı doğruladıktan sonra Next seçeneğine tıklayarak, Microsoft SQL Server 2025 kurulum sürecinin bir sonraki aşamasına geçiyoruz.

Features Configuration Rules ekranında Microsoft SQL Server 2025 kurulumu için seçmiş olduğumuz tüm bileşenler ve yapılandırmalar sistem tarafından bir kez daha kapsamlı şekilde doğrulanır. Bu aşamada; kurulumu etkileyebilecek eksik bileşenler, uyumsuz ayarlar veya sistem gereksinimleriyle ilgili olası problemler kontrol edilerek kurulumun devamına engel teşkil edebilecek durumlar tespit edilir.

Features Configuration Rules ekranında Microsoft SQL Server 2025 kurulumu için gerekli olan tüm yapılandırmaların başarılı bir şekilde tamamlanıp tamamlanmadığı ayrıntılı olarak denetlenir. Yapılan kontrollerin tamamının Passed durumunda görünmesi, kurulumun sorunsuz bir şekilde ilerleyebileceğini ifade eder. Eğer herhangi bir Error veya Warning ile karşılaşılırsa, ilgili eksiklikler veya uyumsuzluklar giderildikten sonra Re-run seçeneği kullanılarak kontroller tekrar çalıştırılabilir ve yapılandırmanın doğruluğu yeniden teyit edilebilir.

Features Configuration Rules ekranında hatasız bir şekilde geçilmesi, Microsoft SQL Server 2025 kurulum ve yapılandırma sürecinin doğru ve sağlıklı ilerlediğinin en önemli göstergelerinden biridir. Tüm kontroller başarılı bir şekilde tamamlandığında Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

Ready to Install ekranında Microsoft SQL Server 2025 kurulumu boyunca gerçekleştirdiğiniz tüm yapılandırma adımlarının özet bilgisi görüntülenir. Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisine uygun bir kurulum gerçekleştirirken bu ekran, sürecin en kritik doğrulama noktalarından biri olarak değerlendirilmelidir. Çünkü kurulum sırasında seçmiş olduğunuz tüm bileşenlerin, dizin ayarlarının ve servis yapılandırmalarının sistem tarafından doğru şekilde algılanıp algılanmadığını bu ekranda toplu ve net bir şekilde görme imkanı elde edersiniz.

Bu özet ekranda aşağıdaki yapılandırmalar ayrıntılı olarak listelenir:

• Kurulacak SQL Server özellikleri,
• Instance adı ve instance yapılandırma bilgileri,
• Servis hesapları ve servislerin başlangıç türleri (Startup Type),
• Collation seçimi,
• User Database Directory: Kullanıcı veritabanlarının (.mdf (Primary Data File) ve .ndf (Secondary Data File)) oluşturulacağı dizin yolu,
• User Database Log Directory: Kullanıcı veritabanlarına ait .ldf (Transaction Log) dosyalarının tutulacağı dizin yolu,
• Backup Directory: SQL Server tarafından oluşturulan veritabanı yedeklerinin varsayılan olarak kaydedileceği dizin,
• TempDB Data ve TempDB Log dosyalarının dizinleri ve yapılandırma detayları.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisi için özellikle veri dizini, log dizini ve backup dizini kritik öneme sahiptir. Availability Group replikaları arasında tutarlı ve sorunsuz bir yapı sağlanabilmesi için, tüm replica sunucularda aynı dizin mimarisinin kullanılması güçlü bir best practice olarak önerilir. Aksi durumda failover senaryolarında dosya yolu uyumsuzlukları, permission (erişim) problemleri veya beklenmeyen hata durumlarıyla karşılaşılabilir.

Bu nedenle User Database Directory, User Database Log Directory ve Backup Directory seçimlerinin Ready to Install ekranında doğru ve eksiksiz şekilde listelendiğinin dikkatle kontrol edilmesi, Failover Cluster Instance (FCI) yapısının stabil, öngörülebilir ve kesintisiz çalışması açısından son derece önemlidir. Tüm bilgilerin doğruluğu teyit edildikten sonra kuruluma güvenle devam edilebilir.

Ready to Install ekranında tüm yapılandırma ayarlarının doğruluğunu dikkatlice teyit ettikten sonra Install seçeneğine tıklayarak W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server 2025 kurulumunu başlatıyoruz.

Bu aşamadan itibaren kurulum süreci otomatik olarak ilerler ve kurulum sırasında belirlemiş olduğumuz tüm SQL Server bileşenleri, dizin yapılandırmaları, servis hesapları ve hizmet başlangıç ayarları doğrultusunda Microsoft SQL Server 2025 sunucu üzerine yüklenir. Kurulum boyunca sistem, seçilen özellikleri sırasıyla kurar, gerekli servisleri oluşturur ve yapılandırmaları arka planda uygular.

Kurulumun bu adımı, yapılandırma sürecinin fiilen hayata geçirildiği noktadır. İşlem tamamlandığında, Microsoft SQL Server 2025 instance’ı SQL Server Failover Cluster Instance (FCI) mimarisi için hazır hale gelir ve bir sonraki aşamada kurulumun başarıyla tamamlandığının doğrulanacağı Installation Progress ve Complete ekranlarına geçilir.

Installation Progress ekranında Microsoft SQL Server 2025 kurulumunun başarıyla başlatıldığını ve seçmiş olduğumuz tüm bileşenlerin sistem üzerine adım adım yüklendiğini görüyoruz.

Bu aşamada SQL Server Database Engine, SQL Server Replication ve Full-Text and Semantic Search for Search bileşenleri, gerekli servisler ve tüm yapılandırmalar arka planda otomatik olarak kurulmaktadır.

Kurulum sürecinde her bir bileşenin durumu gerçek zamanlı olarak bu ekranda görüntülenir ve işlemlerin hangi aşamada olduğu net bir şekilde takip edilebilir. Kurulum sihirbazı, bu aşamada herhangi bir manuel müdahale gerektirmez; tüm bileşenler, daha önce belirlediğimiz yapılandırma ayarları doğrultusunda otomatik olarak yüklenir ve yapılandırılır.

Installation Progress ekranında kurulumun sağlıklı bir şekilde ilerlediğini izleyebileceğiniz ve olası bir hata durumunda hangi bileşende problem yaşandığını tespit edebileceğiniz kritik bir kontrol noktasıdır. Tüm adımlar başarıyla tamamlandığında, kurulum süreci otomatik olarak bir sonraki aşama olan Complete ekranına geçecektir.

Complete ekranında W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server 2025 kurulumunun başarılı bir şekilde tamamlandığını görüyoruz. Bu ekran, kurulum sırasında seçilen tüm bileşenlerin hatasız olarak yüklendiğini, yapılandırma adımlarının doğru şekilde uygulandığını ve Microsoft SQL Server 2025’in kullanıma hazır hale geldiğini doğrulayan son adımdır.

Microsoft SQL Server 2025 kurulum süreci boyunca herhangi bir sorun yaşanmadıysa, kurulumun son aşamasında tüm bileşenlerin Succeeded durumunda olduğunu görürüz. Bu ekran, kurulum sırasında seçilen ve yapılandırılan tüm bileşenlerin başarıyla yüklendiğini ve hatasız şekilde çalışmaya hazır olduğunu net biçimde doğrulayan kritik bir kontrol noktasıdır.

Bu aşamada özellikle aşağıdaki bileşenlerin Succeeded olarak görüntülendiğini teyit edebiliriz:

• Database Engine Services: SQL Server’ın temel veritabanı motoru
• SQL Server Replication: Replikasyon altyapısı ve ilgili servisler
• SQL Server Browser: Instance ve port bilgisini istemcilere yayınlayan servis
• SQL Server Writer: VSS tabanlı yedekleme çözümleri (Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity vb.) ile entegrasyonu sağlayan bileşen
• Setup Support Files: Kurulum ve yönetim süreçleri için gerekli destek dosyaları

Tüm bu bileşenlerin Succeeded durumunda olması; servis hesapları, dizin yapılandırmaları, güvenlik ayarları ve seçilen SQL Server özelliklerinin eksiksiz ve doğru şekilde uygulanmış olduğunu gösterir. Bu doğrulama ile birlikte Microsoft SQL Server 2025 ortamı, Failover Cluster Instance (FCI) mimarisi için yapılandırması hazır hale gelmiş olur.

Eğer kurulum sırasında Computer restart required uyarısı görüntülenirse, bu durum Microsoft SQL Server 2025’in tam ve sağlıklı şekilde çalışabilmesi için ilgili sunucunun yeniden başlatılması gerektiğini ifade eder. Sunucunun restart edilmesi, kurulum sırasında yapılan sistem değişikliklerinin uygulanmasını sağlar ve SQL Server servislerinin sorunsuz biçimde devreye alınmasını garanti altına alır.

Kurulum başarıyla tamamlandıktan sonra Close seçeneğine tıklayarak SQL Server 2025 Setup ekranını kapatıyoruz. Bu aşama ile Microsoft SQL Server 2025 kurulumu başarıyla tamamlanmış olur.

W25SQL25NOD1 isimli sunucumuz üzerinde Failover Cluster Manager konsolunu açıyoruz.

Failover Cluster Manager içerisinde Roles (Roller) menüsüne geldiğimizde, yapılandırmasını tamamladığımız SQL Server (MSSQLSERVER) rolünün başarıyla listelendiğini görüyoruz.

Bu görünüm; Microsoft SQL Server Failover Cluster Instance (FCI) yapısının cluster ortamına doğru şekilde dahil edildiğini ve MSSQLSERVER rolünün aktif ve çalışır durumda olduğunu doğrulamaktadır.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz ve karşımıza Connect ekranı geliyor.

Connect ekranında Connection Properties bölümü altında

• Server Name bölümünde, bağlantı kurulacak W25SQL25NOD1 isimli sunucumuzun adını giriyoruz. Bu alan, istemci veya yönetim aracının hangi SQL Server instance’ına bağlanacağını belirler.
• Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir. Windows Authentication, parola yönetimi ve merkezi güvenlik politikaları açısından SQL Authentication’a göre daha güvenli ve yönetilebilir bir yaklaşımdır.
• Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
• Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz. Bu ayar genellikle LAB, TEST ortamlarında veya self-signed sertifika kullanılan senaryolarda tercih edilir. PROD ortamlarda ise güvenilir bir iç CA veya public CA tarafından üretilmiş sertifikalar kullanılması ve bu seçeneğin kapalı bırakılması önerilir.

Connect seçeneği ile W25SQL25NOD1 isimli sunucumuza bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda W25SQL25NOD1 isimli sunucumuza bağlantı sağlamış oluyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunda Connect ekranını tekrar açıyoruz.

Connect ekranında Connection Properties bölümü altında aşağıdaki yapılandırmaları gerçekleştiriyoruz:

• Server Name alanında, bağlantı kurulacak SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısının adını giriyoruz. Bu alan, istemci veya yönetim aracının hangi SQL Server instance’ına bağlanacağını belirler.
• Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir. Windows Authentication; parola yönetimi, merkezi güvenlik politikaları ve denetim açısından SQL Authentication’a kıyasla daha güvenli ve yönetilebilir bir yaklaşımdır.
• Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
• Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz. Bu ayar genellikle LAB, TEST ortamlarında veya self-signed sertifika kullanılan senaryolarda tercih edilir. PROD ortamlarda ise güvenilir bir iç CA veya public CA tarafından üretilmiş sertifikalar kullanılması ve bu seçeneğin kapalı bırakılması önerilir.

Gerekli yapılandırmaları tamamladıktan sonra Connect seçeneğine tıklayarak SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısına bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster yapısına bağlantı sağlamış oluyoruz.

W25SQL25NOD1 isimli Windows Server 2025 sunucumuz üzerinde Microsoft SQL Server 2025 kurulumunu başarıyla tamamlamış bulunuyoruz. Kurulum süreci boyunca SQL Server Database Engine, SQL Server Replication ve Full-Text and Semantic Search for Search, servis yapılandırmaları, dizin ayarları ve gerekli tüm bileşenler sorunsuz şekilde yapılandırıldı.

Bir sonraki yazımızda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisine W25SQL25NOD2 isimli Windows Server 2025 sunucumuzu Add Node (Node Ekleme) sürecini; servis hesapları, güvenlik yapılandırmaları ve Microsoft SQL Server 2025 Failover Cluster Instance (FCI) best practice ayarlarıyla birlikte adım adım inceleyeceğiz.

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