Merhaba

Kurumsal ortamlarda High Availability (Yüksek Erişilebilirlik) ve kesintisiz hizmet sunumu, Database (Veritabanı) altyapılarının en kritik gereksinimlerinden biridir. Bu ihtiyacı karşılamak üzere kullanılan Failover Cluster Instance (FCI) mimarisi, SQL Server seviyesinde sunucu ve instance bazlı High Availability (Yüksek Erişilebilirlik) sağlayarak donanım veya işletim sistemi kaynaklı kesintilerin önüne geçmeyi hedefler. Microsoft SQL Server 2025 ile birlikte gelen mimari iyileştirmeler ve performans geliştirmeleri, Failover Cluster Instance (FCI) yapılarının daha kararlı, yönetilebilir ve ölçeklenebilir şekilde kurgulanmasına olanak tanımaktadır.

Failover Cluster Instance (FCI) mimarisinde veritabanları, paylaşımlı depolama alanları üzerinde konumlandırılır ve SQL Server instance’ı aktif node’dan pasif node’a taşındığında veritabanı dosyalarıyla birlikte kesintisiz olarak hizmet vermeye devam eder. Bu nedenle Failover Cluster Instance (FCI) ortamında veritabanı oluşturma süreci, klasik standalone SQL Server kurulumlarından farklı olarak disk mimarisi, Cluster Shared Volume (CSV) yapısı ve yüksek erişilebilirlik prensipleri göz önünde bulundurularak planlanmalıdır.

Bu yazıda, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısı üzerinde yeni bir Database (Veritabanı) oluşturma sürecini adım adım ele alacağız. Database (Veritabanı) oluşturulurken dikkat edilmesi gereken disk konumlandırmaları, Options ve Filegroups ayarları, Recovery Model seçimi ve FCI mimarisine özgü teknik gereksinimler detaylı şekilde açıklanacaktır. Böylece üretim ortamlarında kullanılabilecek, güvenli ve sürdürülebilir bir veritabanı yapısının nasıl oluşturulması gerektiği net bir şekilde ortaya konulacaktır.

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

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

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

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

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

W25SQL25NOD1 isimli sunucumuz üzerinde yapılandırılmış olan SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısına, Microsoft SQL Server Management Studio (SSMS) konsolu üzerinden bağlandığımızda, Databases bölümü altında herhangi bir Database (Veritabanı) bulunmadığını görüyoruz.

Microsoft SQL Server 2025 Always On Availability Group yapılandırması öncesinde, sunucumuz üzerinde mutlaka en az bir Database (Veritabanı) oluşturulması gerekmektedir. Çünkü SQL Server Always On Availability Group mimarisinde, yapılandırma sihirbazının ilerleyebilmesi için ortama dahil edilecek bir Database (Veritabanı) mevcut olması zorunludur.

Buna karşılık, Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapılandırması öncesinde sunucumuz üzerinde herhangi bir Database (Veritabanı) oluşturulmasına gerek yoktur. Failover Cluster Instance (FCI) mimarisi, veritabanı seviyesinden bağımsız olarak instance ve sunucu seviyesinde High Availability (Yüksek Erişilebilirlik) sağladığı için, veritabanı olmadan da kurulum ve yapılandırma süreci sorunsuz şekilde tamamlanabilir.

Bu kapsamda, W25SQL25NOD1 isimli sunucumuz üzerinde yapılandırılmış olan SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısına, Microsoft SQL Server Management Studio (SSMS) konsolu üzerinden bağlanıyor ve Databases bölümü üzerinde sağ tuş menüsünden New Database seçeneğini kullanarak yeni bir Database (Veritabanı) oluşturma işlemine başlıyoruz.

New Database ekranında General menüsünde yer alan Database name alanında, oluşturacağımız Database (Veritabanı) için bir Name (İsim) belirlememiz gerekmektedir.

New Database ekranında General menüsünde yer alan Database name alanında, BAKICUBUKDB isimli bir Database (Veritabanı) oluşturacağız.

New Database ekranında General menüsünde, Failover Cluster Instance (FCI) mimarisinde yeni bir Database (Veritabanı) oluştururken yapılan temel ayarların yapılandırıldığı ilk adımdır.

Bu aşamada:

• Database name alanında oluşturulacak veritabanı için BAKICUBUKDB ismi belirlenmiştir. Bu isim, SQL Server instance’ı içerisinde veritabanını tanımlayan benzersiz addır.
• Owner alanı varsayılan değer olan <default> şeklinde bırakılmıştır. Bu, veritabanı sahibinin SQL Server tarafından otomatik olarak atanacağı anlamına gelir.
• Database files bölümünde, veritabanına ait Data (ROWS Data) ve Log (LOG) dosyaları otomatik olarak oluşturulacak şekilde listelenmektedir.
  • Data ve Log dosyaları için başlangıç boyutu 8 MB olarak tanımlanmıştır.
  • Autogrowth ayarı her iki dosya için de 64 MB artış ve sınırsız maksimum boyut olacak şekilde yapılandırılmıştır.
• Path bölümünde, oluşturulacak olan Database (Veritabanı) dosyalarının yolları, Failover Cluster Instance (FCI) mimarisine uygun olacak şekilde Cluster Shared Volume (CSV) diskleri üzerinde konumlandırılmaktadır.
• File name bölümünde ise, veritabanına ait Data ve Log dosyalarının dosya adları belirlenmektedir.

New Database ekranı üzerinden yapılan ayarlar, Failover Cluster Instance (FCI) yapısında veritabanının tüm Node’lar arasında sorunsuz şekilde erişilebilir olmasını ve Failover senaryolarında veri bütünlüğünün korunmasını sağlar.

New Database ekranında Database files bölümü altında yer alan Path alanında, oluşturulacak olan Database (Veritabanı) için Failover Cluster Instance (FCI) mimarisine uygun şekilde yapılandırılmış Cluster Shared Volume (CSV) disk dizinlerini görüyoruz.

Microsoft SQL Server Always On Availability Group mimarisinde, Data, Log, TempDB ve Backup dizinleri her bir sunucuya ait lokal diskler üzerinde tutulur. Bu yapıda her replica kendi disk alanını kullanır ve veritabanı senkronizasyonu SQL Server seviyesinde sağlanır.

Buna karşılık, Microsoft SQL Server Failover Cluster Instance (FCI) mimarisinde Data, Log, TempDB ve Backup dizinleri Cluster Shared Volume (CSV) diskleri üzerinde konumlandırılır. Böylece tüm node’lar aynı paylaşımlı depolama alanını kullanır ve failover durumlarında SQL Server instance’ı disklerle birlikte diğer node’a sorunsuz şekilde taşınır.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) kapsamında yapılandırılmış olan disk birimlerini görüyoruz. Bu kapsamda, Cluster Disk 4 üzerinde konumlandırılmış DATA (C:\ClusterStorage\Volume1) dizini ile Cluster Disk 2 üzerinde konumlandırılmış LOG (C:\ClusterStorage\Volume2) dizinleri yer almaktadır.

New Database ekranında General menüsünde gerekli yapılandırmayı tamamladıktan sonra Options menüsüne geçiyoruz.

New Database ekranında Options menüsünde oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) için gerekli yapılandırma seçeneklerini görüyoruz.

New Database ekranında Options menüsünde Collation bölümü

Collation: Collation, bir veritabanında metin tabanlı verilerin nasıl saklanacağını, sıralanacağını ve karşılaştırılacağını belirleyen temel bir ayardır. Bu ayar; karakter setini, harflerin büyük–küçük duyarlılığını, aksanlı karakterlerin değerlendirilme şeklini ve alfabetik sıralama kurallarını kapsar. Özellikle Türkçe karakterler (ç, ğ, ı, İ, ö, ş, ü) gibi dile özgü harflerin doğru şekilde karşılaştırılması ve sıralanması açısından kritik öneme sahiptir.

Varsayılan olarak, yeni oluşturulan bir veritabanı SQL Server instance’ının collation ayarını devralır. Bu durum, aynı instance üzerinde çalışan tüm veritabanlarında tutarlı bir davranış sağlar ve uygulamalar arasında karşılaştırma hatalarının oluşmasını engeller. Eğer uygulamanın özel bir dil, sıralama veya büyük–küçük harf duyarlılığı gereksinimi yoksa, bu değerin değiştirilmeden kullanılması önerilir.

Collation ayarının sonradan değiştirilmesi, özellikle mevcut tablolar ve indeksler üzerinde ek işlemler gerektirdiği için karmaşık ve riskli olabilir. Bu nedenle, veritabanı oluşturulurken kullanılacak uygulamanın dil ve karakter ihtiyaçları mutlaka göz önünde bulundurulmalı ve doğru collation seçimi en başta yapılmalıdır. Kurumsal ve FCI tabanlı üretim ortamlarında, standart ve uygulama ile uyumlu bir collation kullanmak yönetilebilirlik ve veri tutarlılığı açısından en sağlıklı yaklaşımdır.

New Database ekranında Options menüsünde Recovery model bölümü

Recovery model bölümünde Full, Simple ve Bulk-Logged olmak üzere üç farklı seçenek bulunmaktadır.

Full Recovery Model: Full Recovery Model kullanılan veritabanlarında yapılan tüm işlemler, Transaction Log dosyasına eksiksiz olarak kaydedilir ve manuel bir işlem yapılmadığı sürece silinmez. Bu sayede Database (Veritabanı), belirli bir zaman noktasına kadar geri döndürülebilir.

Bu özellikleri sayesinde Full Recovery Model en güvenilir recovery modelidir. Ancak Transaction Log dosyalarının yönetimi manuel olarak yapılmalıdır. Transaction Log dosyalarının kontrolsüz büyümesini önlemek için iki temel yöntem kullanılır:

• Transaction Log Backup almak
• Transaction Log Shrink işlemi uygulamak

SQL Server 2005 ve sonrası sürümlerde Transaction Log shrink işlemi uygulanacaksa, Database (Veritabanı) Recovery Model’i geçici olarak Simple olarak ayarlanmalı, shrink işlemi tamamlandıktan sonra tekrar Full olarak yapılandırılmalıdır.

Full Recovery Model’de INSERT, DELETE, UPDATE gibi DML işlemlerinin yanı sıra index oluşturma, index rebuild, bulk insert ve bcp gibi bakım ve toplu işlemler de loglanır. Bu durum Transaction Log dosyalarının hızlı büyümesine ve işlemlerin kısmen yavaşlamasına neden olabilir. Bu tür senaryolar için Bulk-Logged Recovery Model tercih edilir.

Bulk-Logged Recovery Model: Bulk-Logged Recovery Model, Full Recovery Model’e benzer şekilde çalışır; ancak bulk işlemler sırasında her işlem ayrı ayrı loglanmak yerine, işlem için tek bir log kaydı tutulur. Bu sayede bulk işlemler Full Recovery Model’e kıyasla daha hızlı gerçekleştirilir. Ancak bulk işlem içeren bir zaman aralığına point-in-time restore yapmak mümkün değildir. Bu nedenle Bulk-Logged Recovery Model Production ortamları için kalıcı bir çözüm değildir.

Production ortamlarında yaygın kullanım senaryosu şu şekildedir:

• Bulk işlem öncesinde Transaction Log backup alınır
• Recovery Model geçici olarak Bulk-Logged yapılır
• Bulk işlem gerçekleştirilir
• İşlem tamamlandıktan sonra Recovery Model tekrar Full olarak ayarlanır

Bu nedenle Bulk-Logged Recovery Model, geçici olarak tercih edilen bir recovery modelidir.

Bulk İşlem Örnekleri

Bulk işlem olarak değerlendirilen bazı işlemler şunlardır:

• Index oluşturma
• Index rebuild
• SELECT INTO
• BULK INSERT
• BCP ile yapılan veri aktarım işlemleri

Simple Recovery Model: Simple Recovery Model kullanılan veritabanlarında tutulan Transaction Log kayıtları, checkpoint işlemi sonrasında otomatik olarak temizlenir. Bu nedenle Simple Recovery Model’de Transaction Log dosyalarının sürekli büyümesi söz konusu değildir. Ancak burada sıkça yanlış anlaşılan önemli bir noktaya değinmek gerekir: Simple Recovery Model dahil olmak üzere tüm recovery modellerinde transaction log tutulur. Simple Recovery Model’i diğerlerinden ayıran fark, bu log kayıtlarının checkpoint sonrasında otomatik olarak silinmesidir.

Simple Recovery Model’de log yönetimi kolaydır; ancak en büyük dezavantajı, geçmiş transaction log kayıtlarının silinmesi nedeniyle Transaction Log backup alınamaması ve dolayısıyla point-in-time restore işlemlerinin mümkün olmamasıdır. Bir felaket durumunda, en iyi ihtimalle yalnızca son alınan Full veya Differential backup tarihine kadar geri dönüş yapılabilir. Bu nedenle Simple Recovery Model Production ortamlarında önerilmez.

Microsoft SQL Server Always On Availability Group mimarisinde, veritabanlarının replikalar arasında senkronize edilebilmesi için Recovery Model mutlaka Full olmak zorundadır. Çünkü SQL Server Always On Availability Group, Transaction Log tabanlı bir replikasyon mekanizması kullanır ve bu yapı Full Recovery Model olmadan çalışamaz.

Buna karşılık, Microsoft SQL Server Failover Cluster Instance (FCI) mimarisi veritabanı seviyesinde değil, instance ve sunucu seviyesinde High Availability (Yüksek Erişilebilirlik) sağlar. Failover Cluster Instance (FCI) yapısında tüm node’lar aynı paylaşımlı depolama (CSV) alanını kullandığı için, veritabanı dosyaları tek bir kopya olarak erişilir ve herhangi bir replikasyon söz konusu değildir.

New Database ekranında Options menüsünde Compatibility Level bölümü

Compatibility Level: Compatibility Level, veritabanının hangi SQL Server sürümü davranışlarını kullanacağını belirler. Bu ayar, sorgu optimizasyonu ve execution plan davranışlarını doğrudan etkiler.

• Yeni oluşturulan veritabanlarında varsayılan olarak SQL Server 2025 uyumluluk seviyesi atanır.
• Eski uygulamalar veya legacy sorgular için daha düşük bir seviye tercih edilebilir.
• Yeni özelliklerden ve iyileştirmelerden faydalanmak için en güncel seviye önerilir.

Failover Cluster Instance (FCI) mimarisi açısından Compatibility Level, High Availability (Yüksek Erişilebilirlik) bağımsızdır ve tamamen uygulama uyumluluğuna göre belirlenir. Containment type, bir veritabanının SQL Server instance’ına olan bağımlılık seviyesini ve başka bir sunucuya taşınması durumunda ne kadar ek yapılandırma gerektireceğini ifade eder. Bu ayar, özellikle veritabanı taşıma, restore ve ortamlar arası geçiş senaryolarında önem kazanır.

Varsayılan değer olan None seçeneğinde, veritabanı SQL Server instance’ına tam bağımlı şekilde çalışır. Kullanıcı girişleri (logins), güvenlik tanımları, dil ve bazı yapılandırma ayarları instance seviyesinde tutulur. Bu nedenle veritabanı farklı bir SQL Server instance’ına taşındığında, ilgili login’lerin yeniden oluşturulması gerekebilir ve kullanıcı–login eşleşmelerinde (orphaned user) sorunlar yaşanabilir. Kurumsal üretim ortamlarında ve özellikle Failover Cluster Instance (FCI) mimarisinde en yaygın ve önerilen kullanım şekli budur.

Alternatif olarak Partial containment seçeneğinde, veritabanı belirli ölçüde instance’tan bağımsız hale gelir. Kullanıcılar veritabanı seviyesinde tanımlanabilir ve bazı ayarlar doğrudan veritabanı içinde saklanır. Bu yaklaşım, veritabanının başka bir sunucuya taşınmasını kolaylaştırır ve login bağımlılığını azaltır. Ancak güvenlik yönetimi daha karmaşık hale gelebilir ve kurumsal güvenlik politikalarıyla uyum sağlamak zorlaşabilir. Bu nedenle Partial containment genellikle test ortamlarında, sık taşınan veritabanlarında veya özel senaryolarda tercih edilir.

Özetle, Containment type ayarı veritabanının taşınabilirliğini doğrudan etkiler. Standart üretim ve Failover Cluster Instance (FCI) senaryolarında None seçeneği tercih edilirken, taşınabilirliğin ön planda olduğu özel durumlarda Partial containment değerlendirilebilir.

Not: Options menüsü altında yer alan Compatibility Level yapılandırması, oluşturulacak olan Database (Veritabanı)’nin kullanılacağı yazılım ve uygulamalara göre farklılık gösterebilir. Logo Tiger, Logo Bordro, Nebim, Mikro gibi kurumsal uygulamalarda, üretici firmaların desteklediği SQL Server sürümü ve önerilen uyumluluk seviyesi dikkate alınarak bu ayarın belirlenmesi gerekmektedir.

New Database ekranında Options menüsünde Other options bölümü altında

Automatic

• • Auto Close = False: Bağlantı kalmadığında veritabanının kapanmasını engeller.Üretim ortamlarında kapalı olmalıdır.
  • Auto Create Statistics = True: SQL Server’ın sorgular için otomatik istatistik oluşturmasını sağlar. Performans için önerilir.
  • Auto Create Incremental Statistics = False: Partitioned tablolar için incremental istatistiklerdir. Gerekli değilse kapalı kalabilir.
  • Auto Shrink = False: Dosyaların otomatik küçültülmesini engeller. Üretim ortamlarında kesinlikle kapalı olmalıdır.
  • Auto Update Statistics = True: İstatistiklerin otomatik güncellenmesini sağlar. Performans ve stabilite için önerilir.
  • Auto Update Statistics Asynchronously = False: İstatistik güncellemesinin sorguları bloklamasını önler. Yoğun sistemlerde isteğe bağlı olarak açılabilir.

Containment

• Default Fulltext Language / Default Language: Full-Text Search ve sistem dili varsayımlarıdır. Uygulama gereksinimine göre değiştirilebilir.
• Nested Triggers Enabled = True: Trigger’ların birbirini tetiklemesine izin verir. Varsayılan değer genellikle yeterlidir.

Cursor

• Close Cursor on Commit Enabled = False: Commit sonrası cursor’ların kapanmasını engeller.
• Default Cursor = GLOBAL: Cursor kapsamını belirler. Varsayılan kullanım için uygundur.

FILESTREAM
FILESTREAM Non-Transacted Access = Off: FILESTREAM kullanılmıyorsa kapalı kalmalıdır.

Ledger
Is Ledger Database = False: Blockchain tabanlı immutable yapı kullanılmadığını gösterir.

New Database ekranında Options menüsünde Other options bölümü altında

Miscellaneous

• Allow Snapshot Isolation = False: Snapshot Isolation kullanımını belirler. Yoğun okuma/yazma sistemlerinde isteğe bağlı açılabilir.
• ANSI ayarları (NULLS, WARNINGS, PADDING, vb.): Uygulama uyumluluğu için önemlidir. ERP ve muhasebe yazılımlarında üretici dokümantasyonu esas alınmalıdır.
• Arithmetic Abort Enabled = False: Bazı sorgu planlarını etkiler. ERP uygulamalarında üretici önerisine göre ayarlanmalıdır.
• Is Read Committed Snapshot On = False: RCSI kullanımını belirler. Concurrency ihtiyacına göre değerlendirilebilir.
• Parameterization = Simple: Varsayılan ve güvenli seçimdir.
• Trustworthy = False: Güvenlik açısından kapalı kalması önerilir.

Recovery
Page Verify = CHECKSUM: Disk veya bellek kaynaklı veri bozulmalarının tespit edilmesini sağlar. Sayfa bütünlüğünü kontrol ederek olası veri hatalarının erken fark edilmesine yardımcı olur. Üretim ortamlarında mutlaka CHECKSUM olarak yapılandırılmalıdır.
Target Recovery Time (Seconds) = 60: Indirect Checkpoint mekanizmasının hedef kurtarma süresini belirler. Checkpoint işlemlerinin I/O yükünü zamana yayarak sistem performansını dengelemeyi amaçlar. Değer, altyapının disk ve I/O performansına göre ayarlanabilir.

Service Broker
Broker Enabled = False: Service Broker altyapısının aktif olup olmadığını belirler. Service Broker tabanlı bir uygulama veya mimari kullanılmıyorsa, bu ayarın kapalı olması yeterlidir ve ek bir yapılandırmaya gerek yoktur.

Options menüsünde yapılan bu yapılandırmalar, veritabanının performansı, yönetilebilirliği ve yedekleme stratejileri açısından kritik öneme sahiptir. Failover Cluster Instance (FCI) mimarisinde bu ayarlar High Availability (Yüksek Erişilebilirlik) bağımsız olarak değerlendirilir ve kurumun operasyonel ihtiyaçlarına göre belirlenmelidir.

New Database ekranında Options menüsünde Other options bölümü altında
State

• Database Read-Only = False: Veritabanının yazılabilir durumda olduğunu gösterir. Bu ayar False olduğunda veritabanı hem okuma hem de yazma işlemlerine açıktır. Üretim ortamlarında genellikle bu şekilde yapılandırılır.
• Database State = NORMAL: Veritabanının aktif ve sağlıklı bir durumda olduğunu ifade eder. NORMAL durumu, veritabanının erişilebilir olduğunu ve herhangi bir hata veya kısıtlamanın bulunmadığını gösterir.
• Encryption Enabled = False: Veritabanı seviyesinde şifreleme (TDE) kullanılmadığını belirtir. Hassas verilerin bulunduğu ortamlarda güvenlik gereksinimlerine bağlı olarak bu ayar True olarak yapılandırılabilir.
• Restrict Access = MULTI_USER: Veritabanına birden fazla kullanıcının aynı anda erişebileceğini ifade eder. Üretim ortamlarında standart ve önerilen erişim modelidir.

New Database ekranında Options menüsünde gerekli yapılandırmaları tamamladıktan sonra Filegroups menüsüne geçiyoruz.

New Database ekranında Filegroups sekmesinde, oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) için gerekli yapılandırmaları görüyoruz.

Filegroups menüsü, oluşturulacak BAKICUBUKDB isimli Database (Veritabanı) için verilerin nasıl ve hangi disk yapısı üzerinde tutulacağını tanımladığımız bölümdür. SQL Server’da veritabanı dosyaları mantıksal olarak filegroup’lar altında toplanır ve bu yapı, performans, yönetilebilirlik ve ölçeklenebilirlik açısından önemli avantajlar sağlar.

Varsayılan olarak veritabanı, PRIMARY filegroup ile oluşturulur ve sistem tabloları ile kullanıcı tabloları bu filegroup altında yer alır. Filegroups sekmesinde, ihtiyaç duyulması halinde ek filegroup’lar tanımlanabilir ve bu filegroup’lara bir veya birden fazla data dosyası (.mdf (Primary Data File) ve .ndf (Secondary Data File)) eklenebilir. Böylece büyük tabloların veya yoğun kullanılan nesnelerin farklı disk grupları üzerinde konumlandırılması mümkün hale gelir.

Failover Cluster Instance (FCI) mimarisinde Filegroups yapılandırması yapılırken, tüm filegroup’lara ait dosyaların Cluster Shared Volume (CSV) diskleri üzerinde yer alması gerekmektedir. Bu sayede failover durumlarında SQL Server instance’ı başka bir node’a taşındığında, veritabanı dosyalarına kesintisiz erişim sağlanır.

Özetle, Filegroups sekmesi veritabanının disk mimarisini planladığımız, performans optimizasyonu ve ileri seviye veri yönetimi için temel oluşturan kritik bir yapılandırma alanıdır. Standart kurulumlarda yalnızca PRIMARY filegroup yeterli olurken, büyük ve yoğun kullanılan üretim sistemlerinde ek filegroup’lar ile daha esnek ve yönetilebilir bir yapı tasarlanabilir.

New Database ekranında oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) için gerekli tüm yapılandırmaları tamamladıktan sonra OK butonuna tıklıyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde yapılandırılmış olan SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısına, Microsoft SQL Server Management Studio (SSMS) konsolu üzerinden bağlandığımızda, Databases bölümü altında BAKICUBUKDB isimli Database (Veritabanı)’nin başarıyla oluşturulduğunu görüyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde yapılandırılmış olan SQL25FOC isimli Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısına, Microsoft SQL Server Management Studio (SSMS) konsolu üzerinden bağlandığımızda, Databases bölümü altında BAKICUBUKDB isimli Database (Veritabanı)’nin başarıyla oluşturulduğunu görüyoruz.

W25SQL25NOD1 isimli sunucumuzun Local Disk (C:) dizini altında yer alan C:\ClusterStorage\Volume1\DATA klasörünü açıyoruz.

W25SQL25NOD1 isimli sunucumuzun Local Disk (C:) dizini altında yer alan C:\ClusterStorage\Volume1\DATA klasöründe, BAKICUBUKDB isimli Database (Veritabanı)’na ait SQL Server Database Primary Data File (.mdf) dosyasının başarıyla oluşturulduğunu görüyoruz.

W25SQL25NOD1 isimli sunucumuzun Local Disk (C:) dizini altında yer alan C:\ClusterStorage\Volume2\LOG klasörünü açıyoruz.

W25SQL25NOD1 isimli sunucumuzun Local Disk (C:) dizini altında yer alan C:\ClusterStorage\Volume2\LOG klasöründe, BAKICUBUKDB_log isimli SQL Server Database Transaction Log File (.ldf) dosyasının başarıyla oluşturulduğunu görüyoruz.

Bu yazımızda Microsoft SQL Server 2025 Failover Cluster Instance (FCI) mimarisine Database (Veritabanı) ekleme işlemini detaylı şekilde ele aldık.

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