Site icon Baki ÇUBUK

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 2

bakicubuk

Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisinin kurulumunu ve yapılandırmasını detaylı şekilde inceleyecek, High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları ele alacağız.

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

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

Önceki yazımızda W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını tamamladık.

Bu yazımızda aynı sunucular üzerinde Microsoft SQL Server 2025 kurulum adımlarını ele alıyoruz. Kurulum sırasında karşımıza çıkan bileşen (Feature) ekranındaki seçeneklerin ne işe yaradığını merak ediyorsanız, ayrıntılı açıklamalar için Bölüm 3 — SQL Server 2025 Bileşenleri Rehberi yazımıza göz atabilirsiniz.

Disk Yapılandırması

W25SQL25NOD1 isimli sunucumuz üzerinde planlanan disk yapılandırması aşağıdaki gibidir:

Bu disk ayrımı, 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 Disaster Recovery süreçlerini daha yönetilebilir hale getirir.

Always On Notu: Bu disk yapısı her iki node üzerinde de birebir aynı sürücü harfi ve klasör adıyla oluşturulmalıdır. Always On mimarisinde replica’lar arasında dosya yolları eşleşmezse failover sonrası sorunlar yaşanır.

 

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

SQL Server 2025 Kurulumu

Kurulum sürecini başlattığımızda karşımıza SQL Server Installation Center ekranı gelir. Installation menüsüne tıklayarak kurulum sürecini başlatıyoruz.

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 kurulum sürecini başlatıyoruz.

Kurulum sihirbazı devreye girerek sistem üzerinde ön hazırlık işlemlerini başlatır ve gerekli Prerequisite (Önkoşul) kontrollerini gerçekleştirir.

Edition ekranında, kurulacak SQL Server 2025 sürümünün lisans modeli belirlenir. Bu ekranda hem lisans doğrulaması gerektirmeyen ücretsiz sürümler hem de lisanslı kurulum seçenekleri sunulur.

Ücretsiz Sürümler (Specify a free edition)

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

Lisanslı Sürümler

Enterprise: Maksimum performans, güvenlik ve ölçeklenebilirlik gerektiren kurumsal ortamlar için tasarlanmış en üst seviye sürümdür. Yapay zeka destekli veritabanı motoru, gelişmiş High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) yetenekleri ile kritik iş yüklerini şirket içi, bulut veya hibrit ortamlarda kesintisiz şekilde çalıştırmak üzere optimize edilmiştir. Tam özellikli Always On Availability Group (birden fazla replica, okunabilir secondary, otomatik failover) yalnızca bu sürümde desteklenir.

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

Lisanslama Yöntemleri

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 pay-as-you-go (kullandıkça öde) 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.

⚠️ Express Edition ve Always On

SQL Server Express Edition, Always On Availability Group mimarisini desteklemez. Kurulum ekranında Express Edition listeleniyor olsa dahi bu sürüm; Windows Server Failover Cluster (WSFC) entegrasyonu, Availability Group oluşturma, replica, automatic failover ve listener gibi Always On bileşenlerini içermez. Bu nedenle SQL Server Express, ne Failover Cluster Instance (FCI) ne de Always On Availability Group mimarisinde kullanılabilir.

Hangi Sürüm Hangi Yüksek Erişilebilirlik Özelliğini Destekler?

Aşağıdaki tablo, SQL Server 2025 sürümlerinin yüksek erişilebilirlik yeteneklerini özetler (kaynak: Microsoft Learn — Editions and supported features of SQL Server 2025):

Özellik Enterprise Standard Express
Always On Availability Groups (tam) ✅ (8 secondary’e kadar, 5 senkron) ❌ ❌
Basic Availability Groups ❌ ✅ (2 replica, 1 veritabanı) ❌
Always On Failover Cluster Instance (FCI) ✅ (16 node) ✅ (2 node) ❌
Contained / Distributed AG ✅ ❌ ❌
Log Shipping ✅ ✅ ❌
Backup Compression / Encrypted Backup ✅ ✅ ❌

Sonuç: Yüksek erişilebilirlik gereksinimleri olan production senaryolarında, ihtiyaca göre Standard (temel HA için) veya Enterprise (tam özellikli HA için) sürümü tercih edilmelidir. Bu yazı dizisinde kuracağımız çoklu replica + okunabilir secondary + otomatik failover mimarisi, yalnızca Enterprise / Enterprise Developer / Evaluation sürümlerinde desteklenir. Standard Edition yalnızca tek veritabanı ve tek secondary içeren Basic Availability Group kurmanıza izin verir.

Mevcut lisansımız Perpetual bir SQL Server 2025 lisansı olduğundan I have a SQL Server license only seçeneğini işaretliyoruz ve Next ile devam ediyoruz.

License Terms ekranında I accept the license terms and Privacy Statement seçeneğini işaretleyip Next ile devam ediyoruz.

Global Rules ekranında kurulum öncesi tüm önkoşul kontrolleri doğrulanır. Tüm adımların Passed olduğunu gördükten sonra Next ile devam ediyoruz.

Install Setup Files ekranında kurulum için gerekli bileşenler ve güncelleme paketleri otomatik olarak hazırlanır.

Install Rules ekranında sistem gereksinimleri ve yapılandırmaların eksiksiz olup olmadığı kontrol edilir. Tüm adımların Passed olduğunu gördükten sonra Next ile devam ediyoruz.

Feature Selection ekranı, kurulumda hangi bileşenlerin yükleneceğini belirlediğimiz kritik adımdır. Database Engine Services bileşeninin seçilmesi zorunludur; SQL Server’ın temel veritabanı işlevlerini sağlayan ana servistir.

Not: SQL Server 2016 sürümünden itibaren SQL Server Management Studio (SSMS) ve SQL Server Reporting Services (SSRS) bileşenleri SQL Server kurulum paketinden bağımsız olarak yayımlanmaktadır. Bu bileşenlerin Microsoft’un resmi sitesinden ayrıca indirilip kurulması gerekir.

Bu Kurulumda Seçtiğimiz Bileşenler

Always On Availability Group mimarisi için Database Engine Services ve SQL Server Replication bileşenlerini seçiyoruz. Bu iki bileşen, hem veritabanı motorunu hem de replikasyon altyapısını sağlar.

💡 Feature Selection ekranındaki diğer bileşenler ne işe yarar? PolyBase, Machine Learning Services, Analysis Services, Full-Text Search, Integration Services (SSIS) ve Reporting Services (SSRS) gibi bileşenlerin ne olduğunu, hangi senaryolarda kullanıldığını ve Always On ile ilişkisini ayrı bir yazıda detaylıca anlattık:

➡️ Bölüm 3 — SQL Server 2025 Bileşenleri Rehberi – burayalink

Bu kurulumda bu bileşenlerin hiçbirini seçmiyoruz; Always On için gerekli değildir.

Feature Selection ekranında Database Engine Services ve SQL Server Replication servislerini işaretliyoruz.

Ekranın alt kısmında Instance root directory, Shared features directory ve Shared features directory (x86) dizinleri görüntülenir.

Feature Selection ekranı, kurulumda hangi bileşenlerin yükleneceğini belirlediğimiz kritik adımdır. Database Engine Services bileşeninin seçilmesi zorunludur; SQL Server’ın temel veritabanı işlevlerini sağlayan ana servistir.

Not: SQL Server 2016 sürümünden itibaren SQL Server Management Studio (SSMS) ve SQL Server Reporting Services (SSRS) bileşenleri SQL Server kurulum paketinden bağımsız olarak yayımlanmaktadır. Bu bileşenlerin Microsoft’un resmi sitesinden ayrıca indirilip kurulması gerekir.

Bu Kurulumda Seçtiğimiz Bileşenler

Always On Availability Group mimarisi için Database Engine Services ve SQL Server Replication bileşenlerini seçiyoruz. Bu iki bileşen, hem veritabanı motorunu hem de replikasyon altyapısını sağlar.

💡 Feature Selection ekranındaki diğer bileşenler ne işe yarar? PolyBase, Machine Learning Services, Analysis Services, Full-Text Search, Integration Services (SSIS) ve Reporting Services (SSRS) gibi bileşenlerin ne olduğunu, hangi senaryolarda kullanıldığını ve Always On ile ilişkisini ayrı bir yazıda detaylıca anlattık:

➡️ Bölüm 3 — SQL Server 2025 Bileşenleri Rehberi

Bu kurulumda bu bileşenlerin hiçbirini seçmiyoruz; Always On için gerekli değildir.

Feature Selection ekranında Database Engine Services ve SQL Server Replication servislerini işaretliyoruz.

Ekranın alt kısmında Instance root directory, Shared features directory ve Shared features directory (x86) dizinleri görüntülenir.

Instance Configuration ekranında SQL Server’ın Default Instance mi yoksa Named Instance 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. Sistemde MSSQLSERVER adıyla tanımlanır; yeniden adlandırılamaz ve alias atanamaz.

Named Instance ise aynı sunucu üzerinde birden fazla SQL Server kurulumuna olanak tanır. Erişim sunucuAdı\InstanceAdı formatı ile sağlanır ve genellikle SQL Server Browser servisinin açık olması gerekir.

Tarihsel arka plan: SQL Server 2000 sürümünden önce, bir Windows sunucu üzerinde yalnızca tek bir SQL Server kurulumu yapılabiliyordu ve bu kurulum sunucu adı ile birebir ilişkilendirilmişti. Geriye dönük uyumluluk için bu yapı hala desteklenmektedir ve Default Instance olarak adlandırılır.

Bir Sunucuda Birden Fazla Instance

Aynı sunucuda birden fazla instance kullanmak şu senaryolarda avantaj sağlar:

Bu kurulumda:

Next ile devam ediyoruz.

Server Configuration ekranında SQL Server servislerinin Service Account ve Startup Type ayarlarını yapılandırıyoruz.

Service Accounts sekmesinde şu servisler listelenir: SQL Server Agent, SQL Server Database Engine ve SQL Server Browser. – burayıkontrol et bunların açıklamasıı ekleyelim mi? Hangisi ne için çalışır ne işe yarar. burayıkontrolet – SQL Server Agent,

Always On Senaryolarında Service Account Yapılandırması

Always On yapısında kullanılan SQL Server Database Engine ve SQL Server Agent servislerinin, Active Directory ortamında düşük yetkili ancak gerekli izinlere sahip özel servis hesapları ile çalıştırılması önerilir.

Production ortamlarında Domain Admin veya Local Administrator gibi geniş yetkili hesapların servis hesabı olarak kullanılması önerilmez. Bu hesapların ele geçirilmesi tüm domain altyapısının risk altına girmesine neden olur.

Microsoft’un önerdiği en güvenli yöntem Group Managed Service Account (gMSA) kullanımıdır. gMSA hesapları otomatik parola yönetimi, merkezi kontrol ve güvenli kimlik doğrulama avantajları sunar.

Always On mimarisinde servis hesaplarının:

zorunludur. SPN yapılandırmasının eksik olması durumunda Kerberos kimlik doğrulaması başarısız olabilir ve failover sonrası istemci bağlantılarında problem yaşanabilir.

🟢 EKLENMESİ GEREKEN — Servis Hesabı Karşılıklı Login

Node’lar farklı servis hesapları kullanıyorsa, her node’da diğerinin hesabı için login oluşturulması ve endpoint izni verilmesi gerekir. Aksi halde replikalar birbirine bağlanamaz. Bu adımı Bölüm 5’te, Endpoint yapılandırmasından önce ele alacağız:

sql CREATE LOGIN [BAKICUBUK\sqlsvc] FROM WINDOWS; GO GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [BAKICUBUK\sqlsvc]; GO

Bu kurulumda her iki node da aynı hesabı kullandığı için bu adım atlanabilmiştir — ancak PROD senaryosunda mutlaka gereklidir.

 

SQL Server Agent servisi için Account Name, Password ve Startup Type alanlarını yapılandırıyoruz.

Account Name alanında Browse seçeneğine tıklıyoruz.

NOT: Bu kurulum senaryosu bir LAB ortamı üzerinde gerçekleştirildiği için, olası yetki problemleriyle karşılaşmamak adına geçici olarak Domain Admin yetkisine sahip bir hesap tercih edilmiştir. Production ortamlarında bu yaklaşım kesinlikle kullanılmamalıdır.

 

Select User, Computer, Service Account, or Group ekranında Enter the object name to select alanına hesap adını giriyoruz ve Check Names ile doğruluyoruz.

Account Name alanında seçilen hesabın görüntülendiğini görüyoruz.

Password bölümüne ilgili hesabın parolasını giriyoruz.

 

burayıkontrolet.

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.

Startup Type yapılandırmasını gerçekleştiriyoruz:

SQL Server Agent; bakım planları, yedekleme işlemleri, zamanlanmış görevler (Jobs) ve otomasyon süreçlerinden sorumlu kritik bir bileşen olduğu için Automatic olarak yapılandırıyoruz.

SQL Server Agent servisi için tüm yapılandırmaları tamamlamış oluyoruz.

SQL Server Database Engine servisi için de aynı şekilde Account Name, Password ve Startup Type yapılandırmasını gerçekleştiriyoruz.

 

burayıkontrolet – SQL Server Database Engine açıklaması. 

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.

SQL Server Browser servisinin başlatılmasına ihtiyaç duyulup duyulmayacağı, kullanılan bağlantı yöntemlerine bağlıdır:

Grant Perform Volume Maintenance Task privilege to SQL Server Database Engine Services seçeneğini işaretliyoruz. Bu ayar, Instant File Initialization özelliğinin etkinleştirilmesini sağlar.

Bu özellik etkinleştirildiğinde, oluşturulan veya genişletilen veri dosyaları disk üzerinde sıfırlarla doldurulmadan anında kullanılabilir hale gelir. İşaretlenmezse SQL Server ayrılan disk alanını sıfır (zeroing) ile doldurur — bu işlem disk I/O açısından oldukça maliyetlidir.

Instant File Initialization ile hızlanan işlemler:

Güvenlik Notu: Instant File Initialization, silinmiş disk alanının sıfırlanmaması nedeniyle teorik olarak bir veri sızıntısı riski taşır. Yüksek güvenlik gereksinimli ortamlarda bu risk değerlendirilmelidir.

Not: Kurulum tamamlandıktan sonra servis hesapları SQL Server Configuration Manager üzerinden değiştirilmelidir. Windows Services konsolu kullanılmamalıdır — Configuration Manager gerekli registry ve dosya izinlerini otomatik ayarlar.

 

 

burayıkontrolet – detaylıaçıklama 

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

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

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

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

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, Database Engine’in karakter kümesi, sıralama ve karşılaştırma kurallarını belirlediğimiz kritik adımdır. Bu ayarlar; metinlerin nasıl sıralanacağını, büyük/küçük harf duyarlılığını ve aksan kurallarının nasıl ele alınacağını doğrudan etkiler.

Dikkate alınması gerekenler:

Türkçe karakterlerle yoğun çalışan uygulamalar için genellikle Turkish_CI_AS tercih edilir. Uluslararası uygulamalarda SQL_Latin1_General_CP1_CI_AS yaygındır. Modern projelerde Latin1_General_CI_AS önerilir.

Always On Notu: Ö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. Replica’lar arasında Collation uyuşmazlığı sorun yaratır.

NOT: Seçilecek Collation değeri, ortamda kullanılacak ERP veya kurumsal uygulamaların gereksinimlerine göre değişir. Kurulum öncesinde uygulama üreticisinin Collation gereksinimlerinin kontrol edilmesi önerilir.

 

burayıkontrolet – detaylıaçıklama

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;

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.

Server Configuration sekmesinde Authentication Mode yapılandırması yapılır.

Windows Authentication Mode: SQL Server’a yalnızca Windows kullanıcı hesapları üzerinden erişim sağlanır. Active Directory ortamlarında Kerberos tabanlı kimlik doğrulama kullanıldığı için en yüksek güvenlik seviyesini sunar. Microsoft’un kurumsal yapılarda önerdiği moddur.

Mixed Mode (SQL Server Authentication + Windows Authentication): Hem Windows hesapları hem de SQL Server Authentication ile oluşturulmuş kullanıcılar üzerinden bağlantı kurulabilir. Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ERP yazılımları SQL Authentication kullandığı için pratikte sıklıkla tercih edilir. Bu modda sa hesabı için güçlü bir parola belirlenmesi zorunludur.

Production Ortamlarında Mixed Mode Kullanılacaksa

 

burayıkontrolet – detaylıaçıklama

 

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:

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

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

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.

Specify SQL Server administrators bölümünde Add Current User seçeneğine tıklayarak kurulum işlemini gerçekleştiren hesabı sysadmin yetkisiyle ekliyoruz.

burayıkontrolet – detaylıaçıklama

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ı;

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.

burayıkontrolet – burasıkalmalımı

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;

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.

 

Data Directories sekmesinde veritabanı dosyalarının hangi dizinlerde tutulacağını belirliyoruz.

Data root directory: SQL Server’ın tüm veri bileşenleri için temel kök dizinidir; sistem veritabanlarını (master, model, msdb) barındırır.

Always On Notu: Data root directory teknik olarak değiştirilebilir olsa da, bu dizin Availability Group replikaları arasında senkronize edilmediğinden varsayılan bırakılması önerilir. Asıl kritik olan, kullanıcı veritabanlarına ait Data ve Log dosyalarının tüm replica’larda birebir aynı dizin yapısına sahip olmasıdır.

User database directory: Kullanıcı veritabanlarına ait .mdf ve .ndf dosyalarının tutulduğu dizindir.

User database log directory: .ldf (Transaction Log) dosyalarının tutulduğu dizindir. Transaction log dosyaları veri bütünlüğü, rollback ve point-in-time recovery için kritik olduğundan veri dosyalarından ayrı bir disk üzerinde konumlandırılmalıdır.

Backup directory: Full, Differential ve Transaction Log yedeklerinin tutulduğu dizindir. Veri ve log disklerinden ayrı olması performans, güvenlik ve DR senaryoları açısından en iyi pratiktir.

FCI ve Always On Arasındaki Kritik Fark

Failover Cluster Instance (FCI) mimarisinde Data, Log, TempDB ve Backup dizinleri Cluster Shared Volumes (CSV) üzerinde konumlandırılır. Cluster’a dahil tüm node’lar aynı CSV alanını görür.

Always On Availability Group mimarisinde ise CSV kullanılmaz; her replica kendi yerel diskleri üzerinde çalışır. 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.

Örnek standart dizin yapısı (her iki node’da aynı olmalı):

Sürücü Dizin İçerik
E: E:\DATA .mdf ve .ndf dosyaları
F: F:\LOG .ldf dosyaları
G: G:\TEMP TempDB dosyaları
H: H:\BACKUP Yedekleme dosyaları

 

burayıkontrolet – detaylıaçıklama

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, Microsoft SQL Server 2025 kurulumu ile birlikte gelen Default (Varsayılan) dizinleri görüntüleriz. Ancak kurumsal ve özellikle SQL Server Always On Availability Group mimarisinde, bu varsayılan dizinlerin ihtiyaca göre mutlaka özelleştirilmesi önerilir.

Data root directory: Microsoft SQL Server’ın tüm veri bileşenleri için temel kök dizinidir ve varsayılan olarak sistem veritabanları (master, model, msdb) ile bazı instance seviyesindeki yapılandırma bileşenlerini barındırır. Microsoft SQL Server 2025 Always On Availability Group mimarisinde Data root directory teknik olarak değiştirilebilir olsa da, bu dizin Availability Group replikaları arasında otomatik olarak senkronize edilmediğinden genellikle değiştirilmesi önerilmez. Availability Group mimarisinde asıl kritik olan, kullanıcı veritabanlarına ait Data ve Log dosyalarının Primary Replica (Node) ve tüm Secondary Replica (Node)’larda birebir aynı dizin yapısına sahip olmasıdır. Data root directory’nin farklı yapılandırılması; yönetim karmaşasına, Failover sonrası dosya yolu tutarsızlıklarına ve operasyonel risklere yol açabilir. Bu nedenle kurumsal Always On Availability Group ortamlarında Data root directory’nin varsayılan bırakılması, kullanıcı veritabanı dosyalarının ise performans ve yönetilebilirlik açısından ayrı diskler (DATA, LOG, TempDB, Backup) üzerinde konumlandırılması best practice olarak kabul edilir.

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

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

User database log directory: Kullanıcı veritabanlarının .ldf (Transaction Log) dosyalarının tutulduğu dizindir. .ldf (Transaction Log) dosyaları; Veri Bütünlüğü, Rollback (Geri Dönüş) ve point-in-time recovery için kritik olduğ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 Disaster Recovery (Felaket Kurtarma) senaryoları açısından en iyi pratiktir. Ayrıca Veeam, Commvault, Veritas NetBackup, Rubrik ve Cohesity vb. gibi üçüncü parti yedekleme çözümleri için de kaynak dizin görevi görür.

Disk Ayrımının Önemi: Diskleri farklı dizinler ve disk birimleri üzerinde yapılandırmamızın temel nedenleri şunlardır:

Microsoft SQL Server 2025 Failover Cluster yapısında mimari, Cluster Shared Volumes (CSV) ü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ı Cluster Shared Volumes (CSV) 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 Group mimarisinde ise yapı tamamen farklıdır. Always On yapısında Cluster Shared Volumes (CSV) 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:

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

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.

User database directory için ilgili alanın sağındaki üç nokta (…) simgesine tıklıyoruz.

burayıkontrolet – detaylıaçıklama

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:

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 DATA (E:) sürücüsünü ve altında oluşturduğumuz DATA klasörünü seçiyoruz.

burayıkontrolet – detaylıaçıklama

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 (E:\DATA) isimli bir klasör oluşturup bu klasörü seçiyoruz. Klasör seçimini tamamladıktan sonra OK seçeneğine tıklayarak dizin tanımlama işlemini sonlandırıyoruz.

Bu işlem sonucunda, Microsoft SQL Server 2025 ü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.

burayıkontrolet – detaylıaçıklama

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 (Primary Data File) ve .ndf (Secondary Data File) 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, .ldf (Transaction Log) dosyaları da ayrı bir öneme sahiptir. .ldf (Transaction Log) dosyası, SQL Server veritabanlarında gerçekleştirilen tüm işlemlerin (INSERT, UPDATE, DELETE, DDL değişiklikleri ve sistem işlemleri) sıralı 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.

.ldf (Transaction Log File) 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 (Primary Data File) ve .ndf (Secondary Data File)), .ldf (Transaction Log) dosyaları 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, High Availability (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.

User database log directory için üç nokta (…) simgesine tıklıyoruz.

burayıkontrolet – detaylıaçıklama

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

Browse For Folder ekranında log dosyaları için ayrılmış olan disk (Örneğin F:\LOG) seçilerek gerekli klasör tanımlaması yapılır ve OK seçeneğine 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 LOG (F:) sürücüsünü ve LOG klasörünü seçiyoruz.

burayıkontrolet – detaylıaçıklama

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 seçeneğine 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. .ldf (Transaction Log File) 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.

burayıkontrolet – detaylıaçıklama

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 .ldf (Transaction Log File) dosyaları, veritabanı Data (.mdf (Primary Data File) ve .ndf (Secondary Data File)) 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:

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 High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryoları açısından kritik bir adımdır.

Backup directory için üç nokta (…) simgesine tıklıyoruz.

Yedekleme türleri:

 

burayıkontrolet – detaylıaçıklama

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.

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 BACKUP (H:) sürücüsünü ve BACKUP klasörünü seçiyoruz.

burayıkontrolet – detaylıaçıklama

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 seçeneğine 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 Disaster Recovery (Felaket Kurtarma) senaryoları için standart ve erişilebilir bir kaynak dizin oluşturulması açısından da büyük önem taşır.

burayıkontrolet – burasıkalmalımı detay açısından.

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.

Data Directories sekmesinde tüm dizin yapılandırmalarının tamamlandığını görüyoruz.

burayıkontrolet – burasıkalmalımı detay açısından.

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

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

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

TempDB sekmesi, SQL Server’ın geçici veri işlemlerini yürüttüğü TempDB sistem veritabanının yapılandırıldığı kritik adımdır. SQL Server; geçici tablolar, tablo değişkenleri, index rebuild işlemleri, sort ve hash operasyonları gibi pek çok süreci TempDB üzerinden gerçekleştirir.

TempDB Data Files

TempDB için birden fazla Data File oluşturulması önerilir. Bu yaklaşım, çok çekirdekli sistemlerde sıkça karşılaşılan PFS, GAM ve SGAM latch contention problemlerinin azaltılmasına yardımcı olur.

Microsoft’un best practice önerisi:

Data dosyalarının başlangıç boyutları yeterli seviyede belirlenmeli ve autogrowth değerleri yüzdesel yerine sabit MB cinsinden yapılandırılmalıdır (örneğin 64 MB veya 128 MB).

TempDB Log File

SQL Server, her instance için yalnızca tek bir TempDB log dosyasını destekler. Bu dosyanın başlangıç boyutunun en az 512 MB, tercihen 1 GB olarak yapılandırılması önerilir. Autogrowth ayarının sabit MB (256 MB veya 512 MB) olarak belirlenmesi, log dosyasının kontrollü büyümesini sağlar.

 

burayıkontrolet – burasıkalmalımı detay açısından.

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.

Data directories bölümünde varsayılan dizini kaldırmak için Remove seçeneğine tıklıyoruz.

 

burayıkontrolet – burasıkalmalımı detay açısından.

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.

Add seçeneğine tıklayarak yeni dizin yolunu ekliyoruz.

Browse For Folder ekranında TEMP (G:) dizinini seçiyoruz.

burayıkontrolet – burasıkalmalımı detay açısından.

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 seçeneğine 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.

Log directories bölümünü yapılandırmak için üç nokta (…) simgesine tıklıyoruz.

burayıkontrolet – burasıkalmalımı detay açısından.

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 LOG (F:) dizini altında TEMPLOG klasörünü seçiyoruz.

burayıkontrolet – burasıkalmalımı detay açısından.

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 seçeneğine 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.

TempDB’nin hem veri hem de log dosyalarına ilişkin tüm dizin ayarları tamamlanmış olur.

burayıkontrolet – burasıkalmalımı detay açısından.

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, SQL Server 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ı, SQL Server 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.

MaxDOP ve Memory Yapılandırması

MaxDOP, Memory ve FILESTREAM seçenekleri SQL Server 2025 kurulumu sırasında yapılandırılabilir, ancak Always On Availability Group mimarisi için doğrudan kritik bileşenler arasında yer almaz. Yine de bu ayarların doğru planlanması, Always On üzerinde çalışan veritabanlarının performansı açısından önemini korur.

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ı belirler. Doğru yapılandırılmış bir MaxDOP değeri paralel sorgu yürütmeyi dengeler, CPU kullanımını optimize eder ve CXPACKET / CXCONSUMER gibi bekleme türlerini azaltır.

burayıkontrolet – burasıkalmalımı detay açısından.

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

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

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

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.

Memory: SQL Server’ın kullanabileceği minimum ve maksimum bellek sınırlarının belirlendiği bölümdür. SQL Server 2019 ile kurulum sihirbazına eklenmiştir.

burayıkontrolet – burasıkalmalımı detay açısından.

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.

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

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

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

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

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

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. SQL Server 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 imkanı elde edersiniz.

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

SQL Server 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’ı SQL Server 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 ve SQL Server Replication 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:

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, SQL Server Always On Availability Group mimarisinde ikinci node (secondary replica) olarak görev alacak olan W25SQL25NOD2 isimli sunucumuz üzerinde Microsoft SQL Server 2025 kurulum sürecini başlatıyoruz.

Bu aşamada, W25SQL25NOD2 üzerinde gerçekleştirilecek Microsoft SQL Server 2025 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: SQL Server 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 2025 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 SQL Server Always On Availability Group mimarisi için gerekli olan çoklu Node Microsoft SQL Server 2025 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.

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 Disaster Recovery (Felaket Kurtarma) süreçlerini daha yönetilebilir hale getirir.

 

 

Sonuç

W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2025 kurulum adımlarını tamamladık.

Kurulum sırasında karşılaştığımız Feature Selection ekranındaki bileşenlerin (PolyBase, Analysis Services, Machine Learning Services, SSIS, SSRS ve diğerleri) ne işe yaradığını merak ediyorsanız, bir sonraki yazımız tam size göre:

➡️ Bölüm 3 — SQL Server 2025 Bileşenleri Rehberi

Ardından Bölüm 4‘te Always On mimarisine geçmeden önce yapılması gereken kritik ön hazırlıkları ele alacağız.

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

Exit mobile version