Merhaba

 

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server 2025 için planlanan disk yapılandırması aşağıdaki gibidir. Bu yapılandırma, performans, yönetilebilirlik ve yedekleme süreçlerinin sağlıklı şekilde ayrıştırılması amacıyla tasarlanmıştır.

• E: sürücüsü DATA olarak yapılandırılmış olup veritabanlarına ait Data (mdf / ndf) dosyalarının tutulduğu alandır.
• F: sürücüsü LOG olarak ayrılmıştır ve veritabanı Transaction Log (ldf) dosyaları bu disk üzerinde konumlandırılır.
• G: sürücüsü TempDB için ayrılmıştır ve geçici tablolar, sıralama işlemleri ve ara sorgu çıktılarının kullanıldığı TempDB veritabanı bu disk üzerinde çalışır.
• H: sürücüsü ise Backup amacıyla yapılandırılmış olup SQL Server yedekleme (Full, Differential ve Log backup) dosyalarının tutulduğu alan olarak kullanılır.

Bu disk ayrımı, özellikle yüksek işlem hacmine sahip ortamlarda I/O yükünün dengelenmesini sağlar, SQL Server performansını artırır ve bakım ile felaket kurtarma süreçlerini daha yönetilebilir hale getirir.

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 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 SQL Server 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ü geliyor karşımıza.

SQL Server Installation Center ekranında Installation menüsü altında yer alan New SQL Server stand-alone installation or add features to an existing installation seçeneğini işaretleyerek Microsoft SQL Server 2025 kurulum sürecini başlatıyoruz. Bu adım, ister tamamen yeni bir SQL Server kurulumu gerçekleştirmek ister mevcut bir kurulum üzerine ek bileşenler (feature) eklemek isteyelim, kurulum sihirbazının 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, disk alanı ve gerekli bileşenlerin uyumluluğu kontrol edilerek ortamın Microsoft SQL Server 2025 kurulumuna hazır olup olmadığı doğrulanır. Ön kontrollerin başarıyla tamamlanmasının ardından, SQL Server 2025’e ait lisans, özellik seçimi, servis yapılandırması ve veritabanı ayarları gibi ilk yapılandırma 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 ilerleyebilmesi için gerekli kontrolleri gerçekleştirir.

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

Product Key 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 zekâ destekli veritabanı motoru, gelişmiş yüksek erişilebilirlik ve 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.

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 bağımsız olarak satın alınmış bir 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.

Product Key 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.

Product Key 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.

Product Key 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 ekranında, Microsoft SQL Server 2025 kurulumu başlatılmadan önce hedef sistem üzerinde tüm önkoşul kontrolleri detaylı şekilde doğrulanır. Bu aşamada; işletim sistemi uyumluluğu, gerekli Windows bileşenleri ve rollerinin durumu, güvenlik yapılandırmaları, güncel sistem bileşenleri, mevcut SQL Server servisleri ile kurulumun ilerlemesini engelleyebilecek olası bağımlılık ve çakışmalar otomatik olarak taranır.

Yapılan kontroller başarıyla tamamlandığında her kuralın karşısında Passed durumu görüntülenir. Tüm doğrulama adımlarının Passed olarak işaretlenmesi, kurulum ortamının Microsoft SQL Server 2025 kurulumu için teknik olarak hazır olduğunu gösterir.

Global Rules ekranında tüm adımları Passed olarak gördükten sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

Install Setup Files ekranında, Microsoft SQL Server 2025 kurulumu için gerekli olan kurulum bileşenleri ve güncelleme paketleri otomatik olarak hazırlanır. Bu aşamada kurulum sihirbazı, Microsoft SQL Server 2025 için gereken en güncel Setup dosyalarını indirir veya mevcut dosyaları doğrular ve kurulum motorunun kullanacağı temel bileşenleri yapılandırır. Bu işlem sırasında herhangi bir kullanıcı müdahalesine gerek kalmadan arka planda gerekli hazırlıklar tamamlanır.

Install Setup Files ekranında, sürecin başarıyla sonuçlanmasının ardından sistem, Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçmeye hazır hale gelir ve kurulum sihirbazı otomatik olarak ilerlemeye devam eder.

Install Rules ekranında Microsoft SQL Server 2025 kurulumu için gerekli olan sistem gereksinimleri ve yapılandırmaların eksiksiz olup olmadığı kontrol edilir. Bu aşamada kurulum sihirbazı; güvenlik ayarlarını, gerekli Windows bileşenlerini, servislerin güncel durumunu, dosya ve klasör izinlerini ve kurulumun ilerlemesini engelleyebilecek olası bloklayıcı koşulları otomatik olarak doğrular.

Install Rules ekranında tüm kontroller başarıyla tamamlanmış ve kritik bir hata tespit edilmemişse her kuralın karşısında Passed durumu görüntülenir. Install Rules ekranında tüm adımları Passed olarak gördükten sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

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 SQL Server 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 SQL Server kurulum paketinden bağımsız olarak yayımlanmaya başlamıştır. Bu nedenle SQL Server 2025 kurulumunda da SSMS ve 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 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 – HA) sağlamak amacıyla uygulanan yöntemlerden biridir. HA çözümleri arasında yer alan Replication, daha gelişmiş bir teknoloji olan Always ON devreye girmeden önce SQL Server Failover Cluster 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ı: Replication’ın sunduğu en büyük avantajlardan biri, verilerin asıl sunucudan bağımsız olarak hedef sunucuda işlenebilmesidir. Bu, özellikle raporlama amaçlı kullanılan verilerde büyük bir esneklik sağlar. Replike edilen veri üzerinde bağımsız Index’ler tanımlayabilmek, raporlama performansını optimize eder ve kaynak sunucunun yükünü azaltır

SQL Server Always On ve (High Availability – HA) Çözümleri ile Kıyaslama: Always On teknolojisi, Database Mirroring’in geliştirilmiş bir versiyonu olarak Replication’ın bazı kullanım alanlarını azaltmış olsa da, Replication halen belirli durumlar için ideal bir çözümdür. Özellikle hızlı veri aktarımı gerektiren, ancak anlık veri tutarlılığı sağlanmasının zorunlu olmadığı durumlarda, Transactional Replication ile düşük gecikmeli veri transferi sağlanabilir. Replication’ın esnek yapısı, çeşitli veri senaryolarında, özellikle veri raporlama ve yedekleme gibi amaçlar için uygun bir çözüm sunar.

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, SQL Server 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 SQL Server 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 ve SQL Server Replication servislerini işaretleyerek kurulacak özellikleri seçiyoruz. Database Engine Services, SQL Server’ın temel veritabanı motorunu kurar; veritabanı oluşturma, sorgu çalıştırma, güvenlik ve erişim yönetimi gibi tüm temel işlemler bu bileşen üzerinden yürütülür. SQL Server Replication ise seçilen veritabanı veya tabloların farklı sunuculara belirli kurallarla çoğaltılmasını (replike edilmesini) sağlayan teknolojiyi aktif eder. Özellikle raporlama sunucuları, uzak lokasyon senaryoları veya dağıtık veri mimarilerinde bu özellik kritik rol oynar.

• 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 SQL Server 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.

Instance Configuration ekranında, Microsoft SQL Server 2025 kurulumunda hangi Instance türünün kullanılacağını belirlediğimiz kritik yapılandırma adımlarından biridir. Bu aşamada SQL Server’ın Default Instance (Varsayılan) mı yoksa Named Instance (Adlandırılmış) olarak mı kurulacağı belirlenir.

Default Instance, bir sunucu üzerinde yalnızca bir kez kurulabilir ve doğrudan sunucu adı ile erişim sağlanır. Örneğin istemci tarafında bağlantı kurarken yalnızca sunucu adı kullanılır. Varsayılan Instance, geriye dönük uyumluluk nedeniyle hâlâ desteklenen ve en sade bağlantı modelini sunan kurulum tipidir.

Named Instance ise aynı sunucu üzerinde birden fazla SQL Server kurulumu yapılmasına olanak tanır. Bu yapılandırmada SQL Server’a erişim sunucuAdı\InstanceAdı formatı ile sağlanır ve genellikle Microsoft SQL Browser servisinin açık olması gerekir. Named Instance, özellikle aynı sunucu üzerinde farklı uygulamaların veya farklı yapılandırmaların çalıştırılması gereken senaryolarda tercih edilir.

Bir Sunucuda Birden Fazla Instance Kullanımı: Bir sunucu üzerine birden fazla Microsoft SQL Server kurulumu yapılabilir ve her bir kurulum Instance olarak adlandırılır. Bu Instance’lardan yalnızca biri Default Instance olabilir; diğer tüm kurulumlar Named Instance olarak yapılandırılmak zorundadır. Bu yaklaşım, aşağıdaki senaryolarda önemli avantajlar sağlar:

• Farklı uygulamalar veya veritabanları için ayrı güvenlik ve yönetim sınırları oluşturulabilir.
• Uygulamalar arasında uyumsuz sunucu veya SQL Server yapılandırmalarının izole edilmesi sağlanabilir.
• Farklı SLA (Service Level Agreement) gereksinimlerine sahip iş yükleri birbirinden ayrılabilir.
• Aynı işletim sistemi üzerinde farklı SQL Server sürümleri yan yana çalıştırılabilir.
• Farklı Collation (dil ve sıralama) gereksinimleri olan uygulamalar için ayrı Instance’lar yapılandırılabilir. Özellikle geçici nesnelerin kullanıldığı tempdb veritabanının Collation bağımlılığı bu senaryolarda önemlidir.
• Instance belirtilmeden yapılan bağlantı istekleri otomatik olarak Default Instance’a yönlendirilir.
• Yükseltme ve geçiş senaryolarında, eski ve yeni sürümler aynı sunucu üzerinde test edilebilir.

Ayrıca Instance kullanımının önemli avantajlarından biri de, SQL Server yönetim araçlarının (örneğin SSMS) her Instance için ayrı ayrı kurulmasına gerek olmamasıdır. Tek bir araç seti ile tüm Instance’lar merkezi olarak yönetilebilir.

Default Instance ve Named Instance Kavramlarının Tarihsel Arka Planı: Microsoft SQL Server 2000 sürümünden önce, bir Windows sunucu üzerinde yalnızca tek bir SQL Server kurulumu yapılabiliyordu. Bu kurulum, sunucu adı ile birebir ilişkilendirilmişti. Geriye dönük uyumluluğu korumak amacıyla bu yapı günümüzde hâlâ desteklenmektedir ve Default Instance olarak adlandırılır. Varsayılan Instance, sistemde MSSQLSERVER adıyla tanımlanır; bu Instance yeniden adlandırılamaz ve Alias atanamaz. Ek SQL Server kurulumları ise Named Instance kavramı ile birlikte gelmiştir. Named Instance kullanıldığında, istemci uygulamalar SQL Server’a sunucuAdı\InstanceAdı formatı ile bağlanır. Örneğin, W25SQL25 isimli Windows Server 2025 sunucusu üzerinde BAKICUBUK adlı bir Instance yapılandırılmışsa bağlantı adresi W25SQL25\BAKICUBUK olacaktır.

Instance Configuration ekranında

• Instance ID alanı varsayılan olarak MSSQLSERVER şeklinde otomatik gelir. Default Instance kullanıldığında Instance ID değiştirilemez ve bu değer Always On yapılandırmasıyla tam uyumludur.
• SQL Server directory alanında, Microsoft SQL Server 2025 bileşenlerinin C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER dizini altına kurulacağı görülür. Bu dizin yapısı, önceki Feature Selection ekranında da görüntülenmiş olup Default Instance için standart kurulum yolunu temsil eder.

Instance Configuration ekranında, SQL Always On mimarisine uygun şekilde Instance 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.

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 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.

SQL Server Always On Senaryolarında Service Account Yapılandırması: SQL Server Always On Availability Groups mimarisinde Service Account yapılandırması, hem yüksek erişilebilirlik mekanizmalarının doğru çalışması hem de güvenlik gereksinimlerinin karşılanması açısından büyük önem taşır. Always On yapısında kullanılan SQL Server Database Engine ve SQL Server Agent servislerinin, Active Directory Domain ortamında 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 hesapların ele geçirilmesi, tüm domain altyapısının risk altına girmesine neden olabilir. Güvenlik açısından ideal yöntem, her Always On node’u üzerinde SQL Server servislerinin ayrı domain hesapları ile çalıştırılmasıdır. Yönetim kolaylığı sağlamak amacıyla tüm node’larda ortak bir SQL Server Engine hesabı kullanılması da tercih edilebilir. Güncel ve kurumsal ortamlarda Microsoft’un önerdiği en güvenli yöntem ise Group Managed Service Account (gMSA) kullanımıdır. Group Managed Service Account (gMSA) hesapları; otomatik parola yönetimi, merkezi kontrol ve güvenli kimlik doğrulama avantajları sunarak Always On senaryoları için ideal bir servis hesabı yapısı sağlar.

Always On mimarisinde servis hesaplarının;

• Windows üzerinde Log on as a service yetkisine sahip olması,
• SQL Server tarafında HADR endpoint için gerekli CONNECT izinlerinin tanımlanması,
• SPN (Service Principal Name) kayıtlarının doğru şekilde yapılandırılması

zorunludur. SPN (Service Principal Name) yapılandırmasının eksik veya hatalı olması durumunda Kerberos kimlik doğrulaması başarısız olabilir ve failover sonrasında istemci bağlantılarında problemler yaşanabilir. Bu nedenle servis hesaplarının minimal yetki prensibine uygun tasarlanması, doğru SPN yönetimi ve endpoint izinlerinin eksiksiz yapılandırılması, Always On ortamlarında hem güvenlik hem de kesintisiz hizmet sürekliliği açısından kritik öneme sahiptir.

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ü) alanlarını ortam mimarimize ve Always On gereksinimlerimize uygun şekilde yapılandırıyoruz.

Server Configuration ekranında, Microsoft SQL Server 2025 sunucumuz üzerinde çalışacak olan SQL Server Agent 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 Agent 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 Agent 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 Agent 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 Agent 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 yetki ve erişim problemleri yaşamamak adına Domain Admin yetkisine sahip bir hesap tercih edilmiştir. Ancak tekrar vurgulamak gerekir ki, Production (Üretim) ortamlarında SQL Server Agent servisinin Domain Admin gibi geniş yetkilere sahip hesaplarla çalıştırılması güvenlik açısından önerilmez. Bunun yerine, yalnızca gerekli izinlere sahip, özel olarak oluşturulmuş bir Service Account veya tercihen Group Managed Service Account (gMSA) kullanılması, hem güvenlik hem de SQL Server Always On gibi yüksek erişilebilirlik senaryoları için en doğru yaklaşımdır.

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 Agent servisinin, belirtilen kullanıcı hesabı ile kimlik doğrulaması yaparak çalışması sağlanmış olur.

Bu aşamada girilen parola, SQL Server Agent 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, Microsoft SQL Server 2025 sunucumuz üzerinde çalışan SQL Server Agent servisinin Startup Type (Başlangıç Türü) yapılandırmasını gerçekleştiriyoruz. Bu bölümde, servisin işletim sistemi açılışı sırasında nasıl davranacağını belirleyebileceğimiz üç farklı seçenek bulunur: , ve .

• Automatic (Otomatik): Automatic (Otomatik) seçeneği tercih edildiğinde, sunucu her yeniden başlatıldığında SQL Server Agent servisi otomatik olarak devreye girer.
• Manual (Manuel): Manual (Manuel)  seçeneğinde servis yalnızca ihtiyaç duyulduğunda manuel olarak başlatılır.
• Disabled (Devre Dışı): Disabled (Devre Dışı) seçeneği servisin tamamen kapalı kalmasını sağlar ve çalışmasına izin vermez.

SQL Server Agent; bakım planları, yedekleme işlemleri, zamanlanmış görevler (Jobs), izleme ve otomasyon süreçlerinin yönetiminden sorumlu kritik bir bileşen olduğu için bu kurulum senaryosunda Startup Type (Başlangıç Türü) ayarını Automatic (Otomatik) olarak yapılandırıyoruz. Bu tercih, özellikle Production (Üretim) ve SQL Server Always On Availability Groups mimarilerinde servis sürekliliğini garanti altına alır ve otomasyon görevlerinin kesintisiz şekilde çalışmasını sağlar.

Server Configuration ekranında, Microsoft SQL Server 2025 sunucumuz üzerinde çalışan SQL Server Agent servisi için gerekli tüm yapılandırmaları tamamlamış oluyoruz. Bu kapsamda Account Name (Hesap Adı) alanında BAKICUBUK\administrator kullanıcısı seçilmiş, ilgili Password (Parola) bilgisi girilmiş ve Startup Type (Başlangıç Türü) değeri Automatic (Otomatik) olarak yapılandırılmıştır.

Bu yapılandırma ile birlikte SQL Server Agent servisi, belirlenen kullanıcı hesabı altında doğru yetkilere sahip olacak şekilde çalışmaya başlar ve sunucu her açıldığında otomatik olarak devreye girer. SQL Server Agent; zamanlanmış işler (Jobs), bakım planları (Maintenance Plans), yedekleme görevleri ve otomasyon süreçlerinin yönetiminden sorumlu olduğu için, bu servisin doğru hesap ve başlangıç ayarlarıyla yapılandırılması büyük önem taşır.

Kurulum sürecinin bu aşaması, özellikle Always On Availability Groups gibi yüksek erişilebilirlik senaryolarında, görevlerin kesintisiz ve güvenilir şekilde çalışmasını sağlamak açısından kritik bir rol oynar. Gerekli servis hesabı, parola ve başlangıç ayarları doğru şekilde tanımlandığında, SQL Server altyapısının operasyonel sürekliliği ve yönetilebilirliği önemli ölçüde artar.

Server Configuration ekranında Service Accounts sekmesinde SQL Server Database Engine 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 Database Engine servisi için gerekli yapılandırmaları tamamlamış bulunuyoruz. SQL Server Database Engine 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 Database Engine 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.

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ı, Always On 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 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 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/ndf) 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. 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. SQL Server 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: SQL Server 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 (Veri), Log (Günlük), Backup (Yedekleme) ve TempDB 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 Data Directories sekmesi, Microsoft SQL Server 2025 üzerinde veritabanı dosyalarının hangi dizinlerde tutulacağını belirlediğimiz kritik yapılandırma adımlarından biridir. Bu aşamada; Database (Data), Transaction Log (Log), Backup ve dolaylı olarak TempDB dosyalarının konumları belirlenerek hem performans hem de yönetilebilirlik açısından en uygun disk mimarisi oluşturulur.

Bu sekmede, SQL Server kurulumu ile birlikte gelen Default (Varsayılan) dizinleri görüntüleriz. Ancak kurumsal ve özellikle SQL Server Always On Availability Groups mimarisinde, bu varsayılan dizinlerin ihtiyaca göre mutlaka özelleştirilmesi önerilir.

Data root directory: SQL Server’ın tüm veri bileşenleri için temel kök dizinidir. Varsayılan olarak sistem veritabanları (master, model, msdb) ve bazı yapılandırma bileşenleri bu dizin altında bulunur. Diğer veri dizinleri için referans noktasıdır.

User database directory: Kullanıcı veritabanlarına ait MDF / NDF 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 uzantılı transaction log dosyalarının tutulduğu dizindir. Transaction log dosyaları; veri bütünlüğü, Rollback (Geri Dönüş) ve point-in-time recovery için kritik olduğundan, mutlaka veri 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 veri ve log disklerinden ayrı olması; performans, güvenlik ve felaket senaryoları açısından en iyi pratiktir. Ayrıca Veeam, DPM gibi üçüncü parti yedekleme çözümleri için de kaynak dizin görevi görür.

Disk Ayrımının Önemi: Diskleri farklı dizinler ve disk birimleri üzerinde yapılandırmamızı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 sorunlarının tüm sistemi etkilemesini önlemek

Microsoft SQL Server 2025 Failover Cluster yapısında mimari, Shared Storage (Paylaşımlı Disk) üzerine kuruludur. Bu senaryoda Data, Log, TempDB ve Backup dizinleri Cluster Shared Volumes (CSV) üzerinde konumlandırılır. Böylece Cluster’a dahil olan tüm Node’lar aynı Shared Storage (Paylaşımlı Disk) alanını görür ve veritabanı dosyalarına ortak dizinler üzerinden erişim sağlar. Failover gerçekleştiğinde aktif rol alan node, herhangi bir ek kopyalama veya senkronizasyon ihtiyacı olmadan aynı disk yapısı üzerinden çalışmaya devam eder.

Microsoft SQL Server 2025 Always On Availability Groups mimarisinde ise yapı tamamen farklıdır. Always On yapısında paylaşımlı disk kullanılmaz; her bir replica kendi yerel diskleri üzerinde çalışır. Yani Data, Log, TempDB ve Backup dizinleri her SQL Server Node’u üzerinde ayrı ayrı, ancak aynı dizin yapısı ve standart ile oluşturulmalıdır. Veritabanı dosyaları Node’lar arasında disk seviyesinde değil, SQL Server replikasyon mekanizması üzerinden senkronize edilir.

Örneğin W25SQL25NOD1 ve W25SQL25NOD2 isimli iki sunucu üzerinde Always On yapılandırması yaptığınızda; User database directory, User database log directory ve Backup directory için tanımlanan dizinlerin her iki sunucu üzerinde de birebir aynı olacak şekilde yapılandırılması gerekir.

Örnek bir standart dizin yapısı şu şekilde olabilir:

• E:\DATA – Kullanıcı veritabanı data dosyaları (MDF / NDF)
• F:\LOG – Transaction log dosyaları (LDF)
• G:\TEMP – TempDB dosyaları
• H:\BACKUP – Yedekleme dosyaları

Bu dizinlerin tüm node’larda aynı sürücü harfi ve klasör yapısına sahip olması;

• Always On failover senaryolarında sorunsuz geçiş yapılabilmesi
• Yönetim ve otomasyon süreçlerinin sadeleşmesi
• Yedekleme, izleme ve bakım işlemlerinin standart hale getirilmesi

açısından kritik öneme sahiptir.

Database Engine Configuration ekranında Data Directories sekmesinde, Microsoft SQL Server 2025 üzerinde SQL Server Always On mimarisi kurduğumuz için User database directory, User database log directory ve Backup directory alanlarını Always On gereksinimlerine uygun, node’lar arasında tutarlı olacak şekilde yapılandırıyoruz.

Database Engine Configuration ekranında Data Directories sekmesinde, User database directory bölümünde kullanıcı veritabanı dosyalarının (MDF / NDF) tutulacağı dizini yapılandırmak için ilgili alanın sağ tarafında yer alan üç nokta ( … ) simgesine tıklıyoruz. Bu işlemle birlikte sunucumuz üzerindeki 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 yedekleme stratejileri açısından kritik öneme sahiptir. Kullanıcı veritabanı dosyalarının, işletim sistemi diskinden ayrı, yüksek IOPS ve düşük gecikme süresine sahip disk birimleri üzerinde konumlandırılması en iyi pratiktir. Always On mimarisinde ise bu dizin yapısının, tüm replica node’lar üzerinde aynı sürücü harfi ve klasör yapısıyla oluşturulması gerekir.

Bu dizin altında tutulan dosya türleri şu şekildedir:

• MDF (Primary Data File): MDF, 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 için 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; veritabanı performansının artırılması, disk darboğazlarının önlenmesi ve Always On senaryolarında sorunsuz failover süreçlerinin sağlanması açısından büyük önem taşır.

Browse For Folder ekranında, W25SQL25NOD1 isimli sunucumuz üzerinde daha önce yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada kullanıcı veritabanı dosyalarının tutulacağı disk olarak DATA (E:) sürücüsünü seçiyoruz. Seçtiğimiz E: sürücüsü altında, veritabanı dosyalarını daha düzenli ve yönetilebilir bir yapı altında tutmak amacıyla yeni bir klasör oluşturuyoruz. Örneğin DATA isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK butonuna tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 üzerinde oluşturulacak kullanıcı veritabanlarına ait MDF (Primary Data File) ve NDF (Secondary Data File) dosyaları, belirlediğimiz E:\DATA dizini altında konumlandırılacaktır. Bu yapılandırma; disk I/O performansının artırılması, depolama yönetiminin sadeleştirilmesi ve SQL Server Always On mimarisinde Node’lar arasında tutarlı bir dizin standardı sağlanması açısından kritik öneme sahiptir.

Database Engine Configuration ekranında 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 / NDF veri dosyalarının sunucu üzerinde hangi dizinde saklanacağını netleştirmiş oluyoruz. Bu yapılandırma; SQL Server depolama mimarisinin doğru planlanması, 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.

SQL Server mimarisinde yalnızca veri dosyaları değil, Transaction Log (LDF) 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ı olarak 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.

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 ortamlarda, log yedekleri sayesinde veritabanı istenilen zaman noktasına kadar geri döndürülebilir. Bu nedenle LDF dosyalarının, yüksek yazma trafiği nedeniyle veri dosyalarından ayrı bir disk birimi üzerinde tutulması en iyi pratiktir. Ayrı disk kullanımı, hem yazma performansını artırır hem de veri ve log I/O işlemlerinin birbirini etkilemesini engeller.

Bu yapılandırma ile birlikte SQL Server 2025 ortamında veri dosyaları (MDF/NDF), log dosyaları (LDF) ve yedekleme dosyaları için ayrıştırılmış, performans odaklı ve yönetilebilir bir depolama mimarisi oluşturulmuş olur. Bu yaklaşım, özellikle SQL Server Always On, yüksek erişilebilirlik, 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 Transaction Log (LDF) 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. Transaction Log dosyaları yüksek yazma I/O’su ürettiği için, veri dosyalarından (MDF / NDF) 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 yapılandırılmış olan LOG (F:) sürücüsünü seçiyoruz. Bu sürücü altında, veritabanı işlem günlüklerinin tutulacağı LOG isimli bir klasör oluşturup seçiyoruz ve ardından OK butonuna tıklayarak dizin yapılandırmasını tamamlıyoruz.

Bu işlem sonrasında kullanıcı veritabanlarına ait LDF (Transaction Log) dosyaları belirtilen klasör altında saklanacaktır. Transaction Log dosyalarının veri dosyalarından ayrı bir disk ve dizin yapısında konumlandırılması; yüksek yazma I/O’sunun izole edilmesini sağlar, performansı artırır ve bakım ile izleme süreçlerini daha yönetilebilir hale getirir.

Database Engine Configuration ekranında Data Directories sekmesi altında yer alan User database log directory bölümünü yapılandırarak, kullanıcı veritabanlarına ait LDF (Transaction Log) dosyalarının sunucu üzerinde hangi dizinde tutulacağını belirlemiş oluyoruz.

Bu adımda yapılan yapılandırma sayesinde transaction log dosyaları, veritabanı data (MDF/NDF) dosyalarından ayrı bir disk ve dizin üzerinde konumlandırılır. Bu yaklaşım, SQL Server mimarisinde en iyi uygulamalar (best practice) arasında yer alır ve özellikle aşağıdaki konularda önemli avantajlar sağlar:

• Performans Artışı: Transaction log dosyaları yüksek oranda sıralı (sequential) yazma işlemleri üretir. Log dosyalarının veri dosyalarından ayrı bir disk üzerinde tutulması, disk I/O çakışmalarını azaltarak genel veritabanı performansını artırır.
• Veri Bütünlüğü ve Kurtarma: SQL Server, tüm işlemleri önce log dosyasına yazar. Log dosyalarının ayrı bir disk üzerinde tutulması, sistem hataları veya disk sorunları yaşandığında veri bütünlüğünün korunmasına ve recovery (kurtarma) süreçlerinin daha sağlıklı yürütülmesine katkı sağlar.
• Yedekleme ve Felaket Kurtarma Senaryoları: Point-in-time recovery, log shipping ve Always On gibi senaryolarda transaction log dosyalarının ayrı bir yapıda tutulması yönetimi kolaylaştırır ve kurtarma sürelerini optimize eder.
• Ölçeklenebilirlik ve Yönetilebilirlik: Log dosyalarının büyümesi, izlenmesi ve gerektiğinde disk kapasitesinin artırılması, veri dosyalarından bağımsız şekilde yönetilebilir hale gelir.

Bu nedenle User database log directory ayarının doğru disk ve dizin üzerinde yapılandırılması, Microsoft SQL Server 2025 ortamında hem performans hem de yüksek erişilebilirlik (HA) ve felaket kurtarma (DR) senaryoları açısından kritik bir adımdır.

Database Engine Configuration ekranında 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, SQL Server üzerinde alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizinde saklanacağını belirlememizi sağlar. Doğru bir yedekleme dizini yapılandırması; yedek dosyalarının düzenli yönetilmesi, performansın korunması ve olası veri kaybı senaryolarında hızlı geri dönüş sağlanması açısından kritik öneme sahiptir.

• Full Backup, veritabanının o andaki tüm veri ve nesnelerini kapsayan eksiksiz bir yedektir. Geri yükleme 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. Boyutu daha küçüktür ve daha hızlı alınır. Geri yükleme sırasında Full Backup’tan sonra en güncel Differential Backup restore edilir.
• Transaction Log Backup ise veritabanında gerçekleşen işlemlerin kayıtlarını içerir ve point-in-time restore (belirli bir zaman noktasına geri dönüş) imkânı sağlar. Düzenli olarak alındığında hem veri kaybı riskini minimize eder hem de log dosyasının kontrolsüz büyümesini engeller.

Bu nedenle Backup directory için, veri ve log disklerinden ayrı bir disk birimi (örneğin H:\BACKUP) seçilmesi en iyi pratiktir. Böylece hem yedekleme performansı artar hem de disk arızaları veya veri bozulmaları gibi senaryolarda yedeklerin güvenliği sağlanmış olur.

Browse For Folder ekranında W25SQL25NOD1 isimli sunucumuz üzerinde yapılandırılmış olan BACKUP (H:) sürücüsünü seçiyoruz. Bu disk altında, SQL Server tarafından oluşturulacak yedek dosyalarının merkezi ve düzenli bir şekilde tutulabilmesi için BACKUP isimli bir klasör oluşturuyoruz. Klasörü seçtikten sonra OK butonuna tıklayarak dizin yapılandırmasını tamamlıyoruz.

Bu işlem sonrasında Full Backup, Differential Backup ve Transaction Log Backup dosyaları varsayılan olarak bu dizin altında saklanacaktır. Backup dizininin veri ve log disklerinden ayrı bir disk birimi üzerinde konumlandırılması; hem disk I/O yükünün izole edilmesini sağlar hem de yedekleme işlemlerinin performanslı, güvenli ve yönetilebilir şekilde yürütülmesine katkı sunar. Ayrıca bu yapı, harici yedekleme çözümleri ve felaket kurtarma senaryoları için standart ve erişilebilir bir kaynak dizin oluşturulması açısından da büyük önem taşır.

Database Engine Configuration ekranında Data Directories sekmesinde Backup directory bölümünü yapılandırarak, Microsoft SQL Server 2025 üzerinde alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizinde saklanacağını belirlemiş oluyoruz.

Bu yapılandırma sayesinde SQL Server tarafından oluşturulan tüm yedekleme dosyaları tek ve standart bir klasör yapısı altında toplanır. Yedeklerin ayrı bir disk birimi üzerinde tutulması; hem veri ve log disklerinden I/O yükünün ayrıştırılmasını sağlar hem de olası disk arızalarına karşı ek bir güvenlik katmanı oluşturur. Ayrıca yedekleme operasyonlarının izlenmesi, dış yedekleme çözümleri (örneğin Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity vb.) tarafından bu dizinlerin hedeflenmesi ve Restore (Geri Yükleme) senaryolarının yönetilmesi çok daha kolay hale gelir.

Doğru yapılandırılmış bir Backup directory, kurumsal SQL Server ortamlarında yedekleme stratejisinin sürdürülebilir, düzenli ve denetlenebilir şekilde uygulanabilmesi açısından kritik bir öneme sahiptir.

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 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, SQL Server 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 önceden yapılandırılmış olan TEMP (G:) dizinini seçiyoruz. Bu dizin altında, TempDB veri dosyalarının tutulacağı TEMP isimli bir klasör oluşturup seçtikten sonra OK butonuna tıklayarak dizin yapılandırma işlemini tamamlıyoruz.

Bu adım sayesinde TempDB, diğer veritabanı veri ve log disklerinden ayrılmış, performans odaklı bir disk üzerinde konumlandırılmış olur. Özellikle yoğun geçici tablo kullanımı, sort ve hash operasyonları ile index bakım işlemlerinin bulunduğu ortamlarda TempDB’nin ayrı bir disk üzerinde çalışması; disk I/O çakışmalarını azaltır, bekleme sürelerini düşürür ve Microsoft SQL Server 2025’in genel performansına doğrudan olumlu katkı sağlar.

Database Engine Configuration ekranında TempDB sekmesinde yer alan Data directories bölümüne ait dizin yapılandırmasını tamamlıyoruz. Bu adım ile TempDB veri dosyalarının 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.

TempDB’nin doğru disk ve doğru dizin altında yapılandırılması, özellikle yoğun Geçici Tablo, Sort, Hash ve 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 Microsoft SQL Server 2025’in daha kararlı ve öngörülebilir bir performans sunmasına önemli katkı 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 önceden yapılandırılmış olan LOG (F:) dizinini seçiyoruz. Bu dizin altında, TempDB’ye ait log dosyalarının tutulacağı TEMPLOG isimli bir klasör oluşturup seçtikten sonra OK butonuna tıklayarak yapılandırmayı tamamlıyoruz.

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, Always On Availability Group mimarisi için doğrudan kritik bileşenler arasında yer almaz. Always On’un sağlıklı bir şekilde çalışması; Windows Server Failover Cluster (WSFC) yapılandırması, Quorum ayarları, Replica tanımları, Endpoint bağlantıları, Listener yönetimi ve veri senkronizasyon modları (Synchronous / Asynchronous) gibi bileşenlere bağlıdır. Bu nedenle MaxDOP, bellek veya FILESTREAM ayarlarının hatalı yapılandırılması, Always On Availability Group’un temel işlevlerini doğrudan engellemez. Ancak bu ayarların doğru planlanması, Always On üzerinde çalışan veritabanlarının performansı ve sistemin genel verimliliği açısından önemini korur.

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 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.

1. 1. 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.
   2. 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.
   3. 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 / .ndf 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ı;

1. 1. • 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. Always On Availability Group 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 imkânı elde edersiniz.

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

1. 1. • 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 / .ndf) oluşturulacağı dizin yolu,
      • User Database Log Directory: Kullanıcı veritabanlarına ait transaction log dosyalarının (.ldf) 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ı.

Always On Availability Group 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, Always On 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’ı Always On Availability Group 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, Client Tools, Management 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, DPM 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ı, Standalone veya Always On mimarisi gibi ileri seviye yapılandırmalar için 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 Microsoft SQL Server 2025 kurulumunu başarıyla tamamladıktan sonra, Always On Availability Group mimarisinde ikinci node (secondary replica) olarak görev alacak olan W25SQL25NOD2 isimli sunucumuz üzerinde Microsoft SQL Server 2022 kurulum sürecini başlatıyoruz.

Bu aşamada, W25SQL25NOD2 üzerinde gerçekleştirilecek SQL Server kurulumu; sürüm uyumluluğu, instance yapılandırması, servis hesapları, dizin mimarisi ve Always On gereksinimleri açısından birincil sunucu ile tutarlı olacak şekilde planlanmalıdır. Özellikle veri dizinleri, log dizinleri ve backup dizinlerinin birebir aynı yapıda olması, ilerleyen adımlarda Availability Group yapılandırmasının sorunsuz ilerlemesi açısından kritik öneme sahiptir.

Not: Always On Availability Group yapısında tüm replikaların aynı SQL Server ana sürümünde (major version) olması gerekir. Eğer W25SQL25NOD2 üzerinde SQL Server 2022 kurulumu bilinçli bir tercih değilse ve hedef mimari SQL Server 2025 ise, ikinci node üzerinde de Microsoft SQL Server 2025 kurulması gerekmektedir. Bu nokta, kurulum planı açısından mutlaka teyit edilmelidir.

Bu adım ile birlikte Always On mimarisi için gerekli olan çoklu node SQL Server kurulum sürecinin ikinci aşamasına geçilmiş olur.
W25SQL25NOD2 isimli sunucumuz üzerinde Microsoft SQL Server 2025 için planlanan disk yapılandırması aşağıdaki gibidir. Bu yapılandırma, performans, yönetilebilirlik ve yedekleme süreçlerinin sağlıklı şekilde ayrıştırılması amacıyla tasarlanmıştır.

• E: sürücüsü DATA olarak yapılandırılmış olup veritabanlarına ait Data (mdf / ndf) dosyalarının tutulduğu alandır.
• F: sürücüsü LOG olarak ayrılmıştır ve veritabanı Transaction Log (ldf) dosyaları bu disk üzerinde konumlandırılır.
• G: sürücüsü TempDB için ayrılmıştır ve geçici tablolar, sıralama işlemleri ve ara sorgu çıktılarının kullanıldığı TempDB veritabanı bu disk üzerinde çalışır.
• H: sürücüsü ise Backup amacıyla yapılandırılmış olup SQL Server yedekleme (Full, Differential ve Log backup) dosyalarının tutulduğu alan olarak kullanılır.

Bu disk ayrımı, özellikle yüksek işlem hacmine sahip ortamlarda I/O yükünün dengelenmesini sağlar, SQL Server performansını artırır ve bakım ile felaket kurtarma süreçlerini daha yönetilebilir hale getirir.

W25SQL25NOD2 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 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 SQL Server 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ü geliyor karşımıza.

SQL Server Installation Center ekranında Installation menüsü altında yer alan New SQL Server stand-alone installation or add features to an existing installation seçeneğini işaretleyerek Microsoft SQL Server 2025 kurulum sürecini başlatıyoruz. Bu adım, ister tamamen yeni bir SQL Server kurulumu gerçekleştirmek ister mevcut bir kurulum üzerine ek bileşenler (feature) eklemek isteyelim, kurulum sihirbazının 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, disk alanı ve gerekli bileşenlerin uyumluluğu kontrol edilerek ortamın Microsoft SQL Server 2025 kurulumuna hazır olup olmadığı doğrulanır. Ön kontrollerin başarıyla tamamlanmasının ardından, SQL Server 2025’e ait lisans, özellik seçimi, servis yapılandırması ve veritabanı ayarları gibi ilk yapılandırma 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 ilerleyebilmesi için gerekli kontrolleri gerçekleştirir.

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

Product Key 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 zekâ destekli veritabanı motoru, gelişmiş yüksek erişilebilirlik ve 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.

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 bağımsız olarak satın alınmış bir 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.

Product Key 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.

Product Key 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.

Product Key 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 ekranında, Microsoft SQL Server 2025 kurulumu başlatılmadan önce hedef sistem üzerinde tüm önkoşul kontrolleri detaylı şekilde doğrulanır. Bu aşamada; işletim sistemi uyumluluğu, gerekli Windows bileşenleri ve rollerinin durumu, güvenlik yapılandırmaları, güncel sistem bileşenleri, mevcut SQL Server servisleri ile kurulumun ilerlemesini engelleyebilecek olası bağımlılık ve çakışmalar otomatik olarak taranır.

Yapılan kontroller başarıyla tamamlandığında her kuralın karşısında Passed durumu görüntülenir. Tüm doğrulama adımlarının Passed olarak işaretlenmesi, kurulum ortamının Microsoft SQL Server 2025 kurulumu için teknik olarak hazır olduğunu gösterir.

Global Rules ekranında tüm adımları Passed olarak gördükten sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

Install Setup Files ekranında, Microsoft SQL Server 2025 kurulumu için gerekli olan kurulum bileşenleri ve güncelleme paketleri otomatik olarak hazırlanır. Bu aşamada kurulum sihirbazı, Microsoft SQL Server 2025 için gereken en güncel Setup dosyalarını indirir veya mevcut dosyaları doğrular ve kurulum motorunun kullanacağı temel bileşenleri yapılandırır. Bu işlem sırasında herhangi bir kullanıcı müdahalesine gerek kalmadan arka planda gerekli hazırlıklar tamamlanır.

Install Setup Files ekranında, sürecin başarıyla sonuçlanmasının ardından sistem, Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçmeye hazır hale gelir ve kurulum sihirbazı otomatik olarak ilerlemeye devam eder.

Install Rules ekranında Microsoft SQL Server 2025 kurulumu için gerekli olan sistem gereksinimleri ve yapılandırmaların eksiksiz olup olmadığı kontrol edilir. Bu aşamada kurulum sihirbazı; güvenlik ayarlarını, gerekli Windows bileşenlerini, servislerin güncel durumunu, dosya ve klasör izinlerini ve kurulumun ilerlemesini engelleyebilecek olası bloklayıcı koşulları otomatik olarak doğrular.

Install Rules ekranında tüm kontroller başarıyla tamamlanmış ve kritik bir hata tespit edilmemişse her kuralın karşısında Passed durumu görüntülenir. Install Rules ekranında tüm adımları Passed olarak gördükten sonra Next seçeneğine tıklayarak Microsoft SQL Server 2025 kurulumunun bir sonraki aşamasına geçiyoruz.

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 SQL Server 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 SQL Server kurulum paketinden bağımsız olarak yayımlanmaya başlamıştır. Bu nedenle SQL Server 2025 kurulumunda da SSMS ve 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 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 – HA) sağlamak amacıyla uygulanan yöntemlerden biridir. HA çözümleri arasında yer alan Replication, daha gelişmiş bir teknoloji olan Always ON devreye girmeden önce SQL Server Failover Cluster 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ı: Replication’ın sunduğu en büyük avantajlardan biri, verilerin asıl sunucudan bağımsız olarak hedef sunucuda işlenebilmesidir. Bu, özellikle raporlama amaçlı kullanılan verilerde büyük bir esneklik sağlar. Replike edilen veri üzerinde bağımsız Index’ler tanımlayabilmek, raporlama performansını optimize eder ve kaynak sunucunun yükünü azaltır

SQL Server Always On ve (High Availability – HA) Çözümleri ile Kıyaslama: Always On teknolojisi, Database Mirroring’in geliştirilmiş bir versiyonu olarak Replication’ın bazı kullanım alanlarını azaltmış olsa da, Replication halen belirli durumlar için ideal bir çözümdür. Özellikle hızlı veri aktarımı gerektiren, ancak anlık veri tutarlılığı sağlanmasının zorunlu olmadığı durumlarda, Transactional Replication ile düşük gecikmeli veri transferi sağlanabilir. Replication’ın esnek yapısı, çeşitli veri senaryolarında, özellikle veri raporlama ve yedekleme gibi amaçlar için uygun bir çözüm sunar.

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, SQL Server 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 SQL Server 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 ve SQL Server Replication servislerini işaretleyerek kurulacak özellikleri seçiyoruz. Database Engine Services, SQL Server’ın temel veritabanı motorunu kurar; veritabanı oluşturma, sorgu çalıştırma, güvenlik ve erişim yönetimi gibi tüm temel işlemler bu bileşen üzerinden yürütülür. SQL Server Replication ise seçilen veritabanı veya tabloların farklı sunuculara belirli kurallarla çoğaltılmasını (replike edilmesini) sağlayan teknolojiyi aktif eder. Özellikle raporlama sunucuları, uzak lokasyon senaryoları veya dağıtık veri mimarilerinde bu özellik kritik rol oynar.

• 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 SQL Server 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.

Instance Configuration ekranında, Microsoft SQL Server 2025 kurulumunda hangi Instance türünün kullanılacağını belirlediğimiz kritik yapılandırma adımlarından biridir. Bu aşamada SQL Server’ın Default Instance (Varsayılan) mı yoksa Named Instance (Adlandırılmış) olarak mı kurulacağı belirlenir.

Default Instance, bir sunucu üzerinde yalnızca bir kez kurulabilir ve doğrudan sunucu adı ile erişim sağlanır. Örneğin istemci tarafında bağlantı kurarken yalnızca sunucu adı kullanılır. Varsayılan Instance, geriye dönük uyumluluk nedeniyle hâlâ desteklenen ve en sade bağlantı modelini sunan kurulum tipidir.

Named Instance ise aynı sunucu üzerinde birden fazla SQL Server kurulumu yapılmasına olanak tanır. Bu yapılandırmada SQL Server’a erişim sunucuAdı\InstanceAdı formatı ile sağlanır ve genellikle Microsoft SQL Browser servisinin açık olması gerekir. Named Instance, özellikle aynı sunucu üzerinde farklı uygulamaların veya farklı yapılandırmaların çalıştırılması gereken senaryolarda tercih edilir.

Bir Sunucuda Birden Fazla Instance Kullanımı: Bir sunucu üzerine birden fazla Microsoft SQL Server kurulumu yapılabilir ve her bir kurulum Instance olarak adlandırılır. Bu Instance’lardan yalnızca biri Default Instance olabilir; diğer tüm kurulumlar Named Instance olarak yapılandırılmak zorundadır. Bu yaklaşım, aşağıdaki senaryolarda önemli avantajlar sağlar:

• Farklı uygulamalar veya veritabanları için ayrı güvenlik ve yönetim sınırları oluşturulabilir.
• Uygulamalar arasında uyumsuz sunucu veya SQL Server yapılandırmalarının izole edilmesi sağlanabilir.
• Farklı SLA (Service Level Agreement) gereksinimlerine sahip iş yükleri birbirinden ayrılabilir.
• Aynı işletim sistemi üzerinde farklı SQL Server sürümleri yan yana çalıştırılabilir.
• Farklı Collation (dil ve sıralama) gereksinimleri olan uygulamalar için ayrı Instance’lar yapılandırılabilir. Özellikle geçici nesnelerin kullanıldığı tempdb veritabanının Collation bağımlılığı bu senaryolarda önemlidir.
• Instance belirtilmeden yapılan bağlantı istekleri otomatik olarak Default Instance’a yönlendirilir.
• Yükseltme ve geçiş senaryolarında, eski ve yeni sürümler aynı sunucu üzerinde test edilebilir.

Ayrıca Instance kullanımının önemli avantajlarından biri de, SQL Server yönetim araçlarının (örneğin SSMS) her Instance için ayrı ayrı kurulmasına gerek olmamasıdır. Tek bir araç seti ile tüm Instance’lar merkezi olarak yönetilebilir.

Default Instance ve Named Instance Kavramlarının Tarihsel Arka Planı: Microsoft SQL Server 2000 sürümünden önce, bir Windows sunucu üzerinde yalnızca tek bir SQL Server kurulumu yapılabiliyordu. Bu kurulum, sunucu adı ile birebir ilişkilendirilmişti. Geriye dönük uyumluluğu korumak amacıyla bu yapı günümüzde hâlâ desteklenmektedir ve Default Instance olarak adlandırılır. Varsayılan Instance, sistemde MSSQLSERVER adıyla tanımlanır; bu Instance yeniden adlandırılamaz ve Alias atanamaz. Ek SQL Server kurulumları ise Named Instance kavramı ile birlikte gelmiştir. Named Instance kullanıldığında, istemci uygulamalar SQL Server’a sunucuAdı\InstanceAdı formatı ile bağlanır. Örneğin, W25SQL25 isimli Windows Server 2025 sunucusu üzerinde BAKICUBUK adlı bir Instance yapılandırılmışsa bağlantı adresi W25SQL25\BAKICUBUK olacaktır.

Instance Configuration ekranında

• Instance ID alanı varsayılan olarak MSSQLSERVER şeklinde otomatik gelir. Default Instance kullanıldığında Instance ID değiştirilemez ve bu değer Always On yapılandırmasıyla tam uyumludur.
• SQL Server directory alanında, Microsoft SQL Server 2025 bileşenlerinin C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER dizini altına kurulacağı görülür. Bu dizin yapısı, önceki Feature Selection ekranında da görüntülenmiş olup Default Instance için standart kurulum yolunu temsil eder.

Instance Configuration ekranında, SQL Always On mimarisine uygun şekilde Instance 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.

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 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.

SQL Server Always On Senaryolarında Service Account Yapılandırması: SQL Server Always On Availability Groups mimarisinde Service Account yapılandırması, hem yüksek erişilebilirlik mekanizmalarının doğru çalışması hem de güvenlik gereksinimlerinin karşılanması açısından büyük önem taşır. Always On yapısında kullanılan SQL Server Database Engine ve SQL Server Agent servislerinin, Active Directory Domain ortamında 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 hesapların ele geçirilmesi, tüm domain altyapısının risk altına girmesine neden olabilir. Güvenlik açısından ideal yöntem, her Always On node’u üzerinde SQL Server servislerinin ayrı domain hesapları ile çalıştırılmasıdır. Yönetim kolaylığı sağlamak amacıyla tüm node’larda ortak bir SQL Server Engine hesabı kullanılması da tercih edilebilir. Güncel ve kurumsal ortamlarda Microsoft’un önerdiği en güvenli yöntem ise Group Managed Service Account (gMSA) kullanımıdır. Group Managed Service Account (gMSA) hesapları; otomatik parola yönetimi, merkezi kontrol ve güvenli kimlik doğrulama avantajları sunarak Always On senaryoları için ideal bir servis hesabı yapısı sağlar.

Always On mimarisinde servis hesaplarının;

• Windows üzerinde Log on as a service yetkisine sahip olması,
• SQL Server tarafında HADR endpoint için gerekli CONNECT izinlerinin tanımlanması,
• SPN (Service Principal Name) kayıtlarının doğru şekilde yapılandırılması

zorunludur. SPN (Service Principal Name) yapılandırmasının eksik veya hatalı olması durumunda Kerberos kimlik doğrulaması başarısız olabilir ve failover sonrasında istemci bağlantılarında problemler yaşanabilir. Bu nedenle servis hesaplarının minimal yetki prensibine uygun tasarlanması, doğru SPN yönetimi ve endpoint izinlerinin eksiksiz yapılandırılması, Always On ortamlarında hem güvenlik hem de kesintisiz hizmet sürekliliği açısından kritik öneme sahiptir.

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ü) alanlarını ortam mimarimize ve Always On gereksinimlerimize uygun şekilde yapılandırıyoruz.

Server Configuration ekranında, Microsoft SQL Server 2025 sunucumuz üzerinde çalışacak olan SQL Server Agent 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 Agent 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 Agent 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 Agent 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 Agent 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 yetki ve erişim problemleri yaşamamak adına Domain Admin yetkisine sahip bir hesap tercih edilmiştir. Ancak tekrar vurgulamak gerekir ki, Production (Üretim) ortamlarında SQL Server Agent servisinin Domain Admin gibi geniş yetkilere sahip hesaplarla çalıştırılması güvenlik açısından önerilmez. Bunun yerine, yalnızca gerekli izinlere sahip, özel olarak oluşturulmuş bir Service Account veya tercihen Group Managed Service Account (gMSA) kullanılması, hem güvenlik hem de SQL Server Always On gibi yüksek erişilebilirlik senaryoları için en doğru yaklaşımdır.

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 Agent servisinin, belirtilen kullanıcı hesabı ile kimlik doğrulaması yaparak çalışması sağlanmış olur.

Bu aşamada girilen parola, SQL Server Agent 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, Microsoft SQL Server 2025 sunucumuz üzerinde çalışan SQL Server Agent servisinin Startup Type (Başlangıç Türü) yapılandırmasını gerçekleştiriyoruz. Bu bölümde, servisin işletim sistemi açılışı sırasında nasıl davranacağını belirleyebileceğimiz üç farklı seçenek bulunur: , ve .

• Automatic (Otomatik): Automatic (Otomatik) seçeneği tercih edildiğinde, sunucu her yeniden başlatıldığında SQL Server Agent servisi otomatik olarak devreye girer.
• Manual (Manuel): Manual (Manuel)  seçeneğinde servis yalnızca ihtiyaç duyulduğunda manuel olarak başlatılır.
• Disabled (Devre Dışı): Disabled (Devre Dışı) seçeneği servisin tamamen kapalı kalmasını sağlar ve çalışmasına izin vermez.

SQL Server Agent; bakım planları, yedekleme işlemleri, zamanlanmış görevler (Jobs), izleme ve otomasyon süreçlerinin yönetiminden sorumlu kritik bir bileşen olduğu için bu kurulum senaryosunda Startup Type (Başlangıç Türü) ayarını Automatic (Otomatik) olarak yapılandırıyoruz. Bu tercih, özellikle Production (Üretim) ve SQL Server Always On Availability Groups mimarilerinde servis sürekliliğini garanti altına alır ve otomasyon görevlerinin kesintisiz şekilde çalışmasını sağlar.

Server Configuration ekranında, Microsoft SQL Server 2025 sunucumuz üzerinde çalışan SQL Server Agent servisi için gerekli tüm yapılandırmaları tamamlamış oluyoruz. Bu kapsamda Account Name (Hesap Adı) alanında BAKICUBUK\administrator kullanıcısı seçilmiş, ilgili Password (Parola) bilgisi girilmiş ve Startup Type (Başlangıç Türü) değeri Automatic (Otomatik) olarak yapılandırılmıştır.

Bu yapılandırma ile birlikte SQL Server Agent servisi, belirlenen kullanıcı hesabı altında doğru yetkilere sahip olacak şekilde çalışmaya başlar ve sunucu her açıldığında otomatik olarak devreye girer. SQL Server Agent; zamanlanmış işler (Jobs), bakım planları (Maintenance Plans), yedekleme görevleri ve otomasyon süreçlerinin yönetiminden sorumlu olduğu için, bu servisin doğru hesap ve başlangıç ayarlarıyla yapılandırılması büyük önem taşır.

Kurulum sürecinin bu aşaması, özellikle Always On Availability Groups gibi yüksek erişilebilirlik senaryolarında, görevlerin kesintisiz ve güvenilir şekilde çalışmasını sağlamak açısından kritik bir rol oynar. Gerekli servis hesabı, parola ve başlangıç ayarları doğru şekilde tanımlandığında, SQL Server altyapısının operasyonel sürekliliği ve yönetilebilirliği önemli ölçüde artar.

Server Configuration ekranında Service Accounts sekmesinde SQL Server Database Engine 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 Database Engine servisi için gerekli yapılandırmaları tamamlamış bulunuyoruz. SQL Server Database Engine 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 Database Engine 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.

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ı, Always On 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 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 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/ndf) 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. 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. SQL Server 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: SQL Server 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 (Veri), Log (Günlük), Backup (Yedekleme) ve TempDB 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 Data Directories sekmesi, Microsoft SQL Server 2025 üzerinde veritabanı dosyalarının hangi dizinlerde tutulacağını belirlediğimiz kritik yapılandırma adımlarından biridir. Bu aşamada; Database (Data), Transaction Log (Log), Backup ve dolaylı olarak TempDB dosyalarının konumları belirlenerek hem performans hem de yönetilebilirlik açısından en uygun disk mimarisi oluşturulur.

Bu sekmede, SQL Server kurulumu ile birlikte gelen Default (Varsayılan) dizinleri görüntüleriz. Ancak kurumsal ve özellikle SQL Server Always On Availability Groups mimarisinde, bu varsayılan dizinlerin ihtiyaca göre mutlaka özelleştirilmesi önerilir.

Data root directory: SQL Server’ın tüm veri bileşenleri için temel kök dizinidir. Varsayılan olarak sistem veritabanları (master, model, msdb) ve bazı yapılandırma bileşenleri bu dizin altında bulunur. Diğer veri dizinleri için referans noktasıdır.

User database directory: Kullanıcı veritabanlarına ait MDF / NDF 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 uzantılı transaction log dosyalarının tutulduğu dizindir. Transaction log dosyaları; veri bütünlüğü, Rollback (Geri Dönüş) ve point-in-time recovery için kritik olduğundan, mutlaka veri 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 veri ve log disklerinden ayrı olması; performans, güvenlik ve felaket senaryoları açısından en iyi pratiktir. Ayrıca Veeam, DPM gibi üçüncü parti yedekleme çözümleri için de kaynak dizin görevi görür.

Disk Ayrımının Önemi: Diskleri farklı dizinler ve disk birimleri üzerinde yapılandırmamızı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 sorunlarının tüm sistemi etkilemesini önlemek

Microsoft SQL Server 2025 Failover Cluster yapısında mimari, Shared Storage (Paylaşımlı Disk) üzerine kuruludur. Bu senaryoda Data, Log, TempDB ve Backup dizinleri Cluster Shared Volumes (CSV) üzerinde konumlandırılır. Böylece Cluster’a dahil olan tüm Node’lar aynı Shared Storage (Paylaşımlı Disk) alanını görür ve veritabanı dosyalarına ortak dizinler üzerinden erişim sağlar. Failover gerçekleştiğinde aktif rol alan node, herhangi bir ek kopyalama veya senkronizasyon ihtiyacı olmadan aynı disk yapısı üzerinden çalışmaya devam eder.

Microsoft SQL Server 2025 Always On Availability Groups mimarisinde ise yapı tamamen farklıdır. Always On yapısında paylaşımlı disk kullanılmaz; her bir replica kendi yerel diskleri üzerinde çalışır. Yani Data, Log, TempDB ve Backup dizinleri her SQL Server Node’u üzerinde ayrı ayrı, ancak aynı dizin yapısı ve standart ile oluşturulmalıdır. Veritabanı dosyaları Node’lar arasında disk seviyesinde değil, SQL Server replikasyon mekanizması üzerinden senkronize edilir.

Örneğin W25SQL25NOD1 ve W25SQL25NOD2 isimli iki sunucu üzerinde Always On yapılandırması yaptığınızda; User database directory, User database log directory ve Backup directory için tanımlanan dizinlerin her iki sunucu üzerinde de birebir aynı olacak şekilde yapılandırılması gerekir.

Örnek bir standart dizin yapısı şu şekilde olabilir:

• E:\DATA – Kullanıcı veritabanı data dosyaları (MDF / NDF)
• F:\LOG – Transaction log dosyaları (LDF)
• G:\TEMP – TempDB dosyaları
• H:\BACKUP – Yedekleme dosyaları

Bu dizinlerin tüm node’larda aynı sürücü harfi ve klasör yapısına sahip olması;

• Always On failover senaryolarında sorunsuz geçiş yapılabilmesi
• Yönetim ve otomasyon süreçlerinin sadeleşmesi
• Yedekleme, izleme ve bakım işlemlerinin standart hale getirilmesi

açısından kritik öneme sahiptir.

Database Engine Configuration ekranında Data Directories sekmesinde, Microsoft SQL Server 2025 üzerinde SQL Server Always On mimarisi kurduğumuz için User database directory, User database log directory ve Backup directory alanlarını Always On gereksinimlerine uygun, node’lar arasında tutarlı olacak şekilde yapılandırıyoruz.

Database Engine Configuration ekranında Data Directories sekmesinde, User database directory bölümünde kullanıcı veritabanı dosyalarının (MDF / NDF) tutulacağı dizini yapılandırmak için ilgili alanın sağ tarafında yer alan üç nokta ( … ) simgesine tıklıyoruz. Bu işlemle birlikte sunucumuz üzerindeki 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 yedekleme stratejileri açısından kritik öneme sahiptir. Kullanıcı veritabanı dosyalarının, işletim sistemi diskinden ayrı, yüksek IOPS ve düşük gecikme süresine sahip disk birimleri üzerinde konumlandırılması en iyi pratiktir. Always On mimarisinde ise bu dizin yapısının, tüm replica node’lar üzerinde aynı sürücü harfi ve klasör yapısıyla oluşturulması gerekir.

Bu dizin altında tutulan dosya türleri şu şekildedir:

• MDF (Primary Data File): MDF, 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 için 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; veritabanı performansının artırılması, disk darboğazlarının önlenmesi ve Always On senaryolarında sorunsuz failover süreçlerinin sağlanması açısından büyük önem taşır.

Browse For Folder ekranında, W25SQL25NOD2 isimli sunucumuz üzerinde daha önce yapılandırılmış olan disk birimlerini görüntülüyoruz. Bu aşamada kullanıcı veritabanı dosyalarının tutulacağı disk olarak DATA (E:) sürücüsünü seçiyoruz. Seçtiğimiz E: sürücüsü altında, veritabanı dosyalarını daha düzenli ve yönetilebilir bir yapı altında tutmak amacıyla yeni bir klasör oluşturuyoruz. Örneğin DATA isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK butonuna tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 üzerinde oluşturulacak kullanıcı veritabanlarına ait MDF (Primary Data File) ve NDF (Secondary Data File) dosyaları, belirlediğimiz E:\DATA dizini altında konumlandırılacaktır. Bu yapılandırma; disk I/O performansının artırılması, depolama yönetiminin sadeleştirilmesi ve SQL Server Always On mimarisinde Node’lar arasında tutarlı bir dizin standardı sağlanması açısından kritik öneme sahiptir.

Database Engine Configuration ekranında 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 / NDF veri dosyalarının sunucu üzerinde hangi dizinde saklanacağını netleştirmiş oluyoruz. Bu yapılandırma; SQL Server depolama mimarisinin doğru planlanması, 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.

SQL Server mimarisinde yalnızca veri dosyaları değil, Transaction Log (LDF) 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ı olarak 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.

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 ortamlarda, log yedekleri sayesinde veritabanı istenilen zaman noktasına kadar geri döndürülebilir. Bu nedenle LDF dosyalarının, yüksek yazma trafiği nedeniyle veri dosyalarından ayrı bir disk birimi üzerinde tutulması en iyi pratiktir. Ayrı disk kullanımı, hem yazma performansını artırır hem de veri ve log I/O işlemlerinin birbirini etkilemesini engeller.

Bu yapılandırma ile birlikte SQL Server 2025 ortamında veri dosyaları (MDF/NDF), log dosyaları (LDF) ve yedekleme dosyaları için ayrıştırılmış, performans odaklı ve yönetilebilir bir depolama mimarisi oluşturulmuş olur. Bu yaklaşım, özellikle SQL Server Always On, yüksek erişilebilirlik, 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 Transaction Log (LDF) 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. Transaction Log dosyaları yüksek yazma I/O’su ürettiği için, veri dosyalarından (MDF / NDF) 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 W25SQL25NOD2 isimli sunucumuz üzerinde yapılandırılmış olan LOG (F:) sürücüsünü seçiyoruz. Bu sürücü altında, veritabanı işlem günlüklerinin tutulacağı LOG isimli bir klasör oluşturup seçiyoruz ve ardından OK butonuna tıklayarak dizin yapılandırmasını tamamlıyoruz.

Bu işlem sonrasında kullanıcı veritabanlarına ait LDF (Transaction Log) dosyaları belirtilen klasör altında saklanacaktır. Transaction Log dosyalarının veri dosyalarından ayrı bir disk ve dizin yapısında konumlandırılması; yüksek yazma I/O’sunun izole edilmesini sağlar, performansı artırır ve bakım ile izleme süreçlerini daha yönetilebilir hale getirir.

Database Engine Configuration ekranında Data Directories sekmesi altında yer alan User database log directory bölümünü yapılandırarak, kullanıcı veritabanlarına ait LDF (Transaction Log) dosyalarının sunucu üzerinde hangi dizinde tutulacağını belirlemiş oluyoruz.

Bu adımda yapılan yapılandırma sayesinde transaction log dosyaları, veritabanı data (MDF/NDF) dosyalarından ayrı bir disk ve dizin üzerinde konumlandırılır. Bu yaklaşım, SQL Server mimarisinde en iyi uygulamalar (best practice) arasında yer alır ve özellikle aşağıdaki konularda önemli avantajlar sağlar:

• Performans Artışı: Transaction log dosyaları yüksek oranda sıralı (sequential) yazma işlemleri üretir. Log dosyalarının veri dosyalarından ayrı bir disk üzerinde tutulması, disk I/O çakışmalarını azaltarak genel veritabanı performansını artırır.
• Veri Bütünlüğü ve Kurtarma: SQL Server, tüm işlemleri önce log dosyasına yazar. Log dosyalarının ayrı bir disk üzerinde tutulması, sistem hataları veya disk sorunları yaşandığında veri bütünlüğünün korunmasına ve recovery (kurtarma) süreçlerinin daha sağlıklı yürütülmesine katkı sağlar.
• Yedekleme ve Felaket Kurtarma Senaryoları: Point-in-time recovery, log shipping ve Always On gibi senaryolarda transaction log dosyalarının ayrı bir yapıda tutulması yönetimi kolaylaştırır ve kurtarma sürelerini optimize eder.
• Ölçeklenebilirlik ve Yönetilebilirlik: Log dosyalarının büyümesi, izlenmesi ve gerektiğinde disk kapasitesinin artırılması, veri dosyalarından bağımsız şekilde yönetilebilir hale gelir.

Bu nedenle User database log directory ayarının doğru disk ve dizin üzerinde yapılandırılması, Microsoft SQL Server 2025 ortamında hem performans hem de yüksek erişilebilirlik (HA) ve felaket kurtarma (DR) senaryoları açısından kritik bir adımdır.

Database Engine Configuration ekranında 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, SQL Server üzerinde alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizinde saklanacağını belirlememizi sağlar. Doğru bir yedekleme dizini yapılandırması; yedek dosyalarının düzenli yönetilmesi, performansın korunması ve olası veri kaybı senaryolarında hızlı geri dönüş sağlanması açısından kritik öneme sahiptir.

• Full Backup, veritabanının o andaki tüm veri ve nesnelerini kapsayan eksiksiz bir yedektir. Geri yükleme 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. Boyutu daha küçüktür ve daha hızlı alınır. Geri yükleme sırasında Full Backup’tan sonra en güncel Differential Backup restore edilir.
• Transaction Log Backup ise veritabanında gerçekleşen işlemlerin kayıtlarını içerir ve point-in-time restore (belirli bir zaman noktasına geri dönüş) imkânı sağlar. Düzenli olarak alındığında hem veri kaybı riskini minimize eder hem de log dosyasının kontrolsüz büyümesini engeller.

Bu nedenle Backup directory için, veri ve log disklerinden ayrı bir disk birimi (örneğin H:\BACKUP) seçilmesi en iyi pratiktir. Böylece hem yedekleme performansı artar hem de disk arızaları veya veri bozulmaları gibi senaryolarda yedeklerin güvenliği sağlanmış olur.

Browse For Folder ekranında W25SQL25NOD2 isimli sunucumuz üzerinde yapılandırılmış olan BACKUP (H:) sürücüsünü seçiyoruz. Bu disk altında, SQL Server tarafından oluşturulacak yedek dosyalarının merkezi ve düzenli bir şekilde tutulabilmesi için BACKUP isimli bir klasör oluşturuyoruz. Klasörü seçtikten sonra OK butonuna tıklayarak dizin yapılandırmasını tamamlıyoruz.

Bu işlem sonrasında Full Backup, Differential Backup ve Transaction Log Backup dosyaları varsayılan olarak bu dizin altında saklanacaktır. Backup dizininin veri ve log disklerinden ayrı bir disk birimi üzerinde konumlandırılması; hem disk I/O yükünün izole edilmesini sağlar hem de yedekleme işlemlerinin performanslı, güvenli ve yönetilebilir şekilde yürütülmesine katkı sunar. Ayrıca bu yapı, harici yedekleme çözümleri ve felaket kurtarma senaryoları için standart ve erişilebilir bir kaynak dizin oluşturulması açısından da büyük önem taşır.

Database Engine Configuration ekranında Data Directories sekmesinde Backup directory bölümünü yapılandırarak, Microsoft SQL Server 2025 üzerinde alınacak Full, Differential ve Transaction Log yedeklerinin varsayılan olarak hangi dizinde saklanacağını belirlemiş oluyoruz.

Bu yapılandırma sayesinde SQL Server tarafından oluşturulan tüm yedekleme dosyaları tek ve standart bir klasör yapısı altında toplanır. Yedeklerin ayrı bir disk birimi üzerinde tutulması; hem veri ve log disklerinden I/O yükünün ayrıştırılmasını sağlar hem de olası disk arızalarına karşı ek bir güvenlik katmanı oluşturur. Ayrıca yedekleme operasyonlarının izlenmesi, dış yedekleme çözümleri (örneğin Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity vb.) tarafından bu dizinlerin hedeflenmesi ve Restore (Geri Yükleme) senaryolarının yönetilmesi çok daha kolay hale gelir.

Doğru yapılandırılmış bir Backup directory, kurumsal SQL Server ortamlarında yedekleme stratejisinin sürdürülebilir, düzenli ve denetlenebilir şekilde uygulanabilmesi açısından kritik bir öneme sahiptir.

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 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, SQL Server 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, W25SQL25NOD2 isimli sunucumuz üzerinde önceden yapılandırılmış olan TEMP (G:) dizinini seçiyoruz. Bu dizin altında, TempDB veri dosyalarının tutulacağı TEMP isimli bir klasör oluşturup seçtikten sonra OK butonuna tıklayarak dizin yapılandırma işlemini tamamlıyoruz.

Bu adım sayesinde TempDB, diğer veritabanı veri ve log disklerinden ayrılmış, performans odaklı bir disk üzerinde konumlandırılmış olur. Özellikle yoğun geçici tablo kullanımı, sort ve hash operasyonları ile index bakım işlemlerinin bulunduğu ortamlarda TempDB’nin ayrı bir disk üzerinde çalışması; disk I/O çakışmalarını azaltır, bekleme sürelerini düşürür ve Microsoft SQL Server 2025’in genel performansına doğrudan olumlu katkı sağlar.

Database Engine Configuration ekranında TempDB sekmesinde yer alan Data directories bölümüne ait dizin yapılandırmasını tamamlıyoruz. Bu adım ile TempDB veri dosyalarının 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.

TempDB’nin doğru disk ve doğru dizin altında yapılandırılması, özellikle yoğun Geçici Tablo, Sort, Hash ve 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 Microsoft SQL Server 2025’in daha kararlı ve öngörülebilir bir performans sunmasına önemli katkı 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, W25SQL25NOD2 isimli sunucumuz üzerinde önceden yapılandırılmış olan LOG (F:) dizinini seçiyoruz. Bu dizin altında, TempDB’ye ait log dosyalarının tutulacağı TEMPLOG isimli bir klasör oluşturup seçtikten sonra OK butonuna tıklayarak yapılandırmayı tamamlıyoruz.

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, Always On Availability Group mimarisi için doğrudan kritik bileşenler arasında yer almaz. Always On’un sağlıklı bir şekilde çalışması; Windows Server Failover Cluster (WSFC) yapılandırması, Quorum ayarları, Replica tanımları, Endpoint bağlantıları, Listener yönetimi ve veri senkronizasyon modları (Synchronous / Asynchronous) gibi bileşenlere bağlıdır. Bu nedenle MaxDOP, bellek veya FILESTREAM ayarlarının hatalı yapılandırılması, Always On Availability Group’un temel işlevlerini doğrudan engellemez. Ancak bu ayarların doğru planlanması, Always On üzerinde çalışan veritabanlarının performansı ve sistemin genel verimliliği açısından önemini korur.

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 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.

1. 1. 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.
   2. 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.
   3. 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 / .ndf 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ı;

1. 1. • 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. Always On Availability Group 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 imkânı elde edersiniz.

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

1. 1. • 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 / .ndf) oluşturulacağı dizin yolu,
      • User Database Log Directory: Kullanıcı veritabanlarına ait transaction log dosyalarının (.ldf) 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ı.

Always On Availability Group 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, Always On 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’ı Always On Availability Group 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, Client Tools, Management 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, W25SQL25NOD2 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, DPM 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ı, Standalone veya Always On mimarisi gibi ileri seviye yapılandırmalar için 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 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Microsoft SQL Server 2025 kurulumlarını başarıyla tamamlamış bulunuyoruz. Kurulum süreci boyunca Database Engine, servis yapılandırmaları, dizin ayarları ve gerekli tüm bileşenler sorunsuz şekilde yapılandırıldı.

Bir sonraki yazımızda, SQL Server Always On Availability Groups mimarisine geçmeden önce Microsoft SQL Server 2025 servisleri üzerinde yapılması gereken kritik ön hazırlık ve ayarları detaylı şekilde ele alıyor olacağız. Bu kapsamda servis hesapları, güvenlik yapılandırmaları, Always On ön gereksinimleri ve best practice ayarlarını adım adım inceleyeceğiz.

Başka bir yazımızda görüşmek dileğiyle…