Bu makalede filegroup yapısının ne olduğunu ne gibi ayarlar yapıldığını ele almış olacağız. Filegroup temel anlamda veritabanı nesnelerini ve dosyalarını guruplamak için kullanılmaktadır. İşletim sisteminden alan tahsis etmek, yönetimi kolaylaştırmak ve data file’ları gruplamak için kullanılmaktadır. Bir veritabanı oluşturulurken primary filegroup altında oluşur. Tüm veriler tek mdf file üzerinde olduğu için zamanla I/O beklemesi artar. Primary Data File default file group olan PRIMARY File Group içerisinde yer alır. Bütün sistem tabloları da PRIMARY file group altındadır.
Not: Primary Data File yapısında veritabanı başlangıç bilgisi diğer file’lara ait bilgiler tutulur. Secondary Data File tanımlamazsak bütün veri Primary Data File içerisinde büyümektedir.
Not: Primary data file maksimum 16 TB kadar boyutu olmaktadır. Her veritabanında sadece 1 tane .mdf file yani primary data file bulunur. Kullanmış olduğum Dosya sistemine göre bu yapı değişebilir.
Yeni bir filegroup oluşturmazsak oluşturacağımız secondary data file’lar primary filegroup üzerinde büyür. Bu da bir veritabanı yöneticisinin istemediği bir durumdur. Çünkü bakım ve performans anlamında ileryen aşamalarda sıkıntıya sebebiyet verecektir. Veritabanımızın tek mdf file üzerinde büyümesi yerine mevcut veritabanı büyüklüğümüze göre yeni filegrouplar oluşturup bu filegrouplara bağlı data file’lar oluşturarak veritabanımızı daha performanslı hala getirebiliriz. Mevcut disk yapımıza göre data file’lar oluşturulur. Bu şekilde mevcut olan tablolarımızı filegrouplara aktararak tablomuzu disklere eşit bir şekilde yayabiliriz. mdf uzantılı data dosyasının dışında başka bir data file tanımlarsanız uzantısı ndf olacaktır. Bu yapı Secondary Data File olarak geçmektedir. Şuda unutulmamalı aynı file group altında birden fazla ndf dosyasının olması verilerimizin rastgele yazılmasını sağlayacaktır.
Not:MDF ve NDF dosyaları Veri Dosyaları Rastgele erişimlidir. Veritabanı veri dosyalarına (MDF/primary, NDF/secondary) veri yazarken, SQL Server genellikle sayfa (page) bazlı çalışır ve ihtiyaç duyduğu veri sayfalarını bellekten veya diskteki çeşitli adreslerden okur/yazar. Bu işlemler sıklıkla rastgele (random I/O) olduğundan, özellikle klasik disklerde yavaştır. SSD kullanan sistemlerde bu fark azalsa da, veri dosyalarına erişim hâlâ daha karmaşıktır.LDF dosyası yani Transaction Log Dosyasında ise Sıralı (sequential I/O) yapıda çalışır. Tüm işlemler (INSERT, UPDATE, DELETE) önce log dosyasına yazılır ve bu işlem diskte sıralı olarak yapılır.Bu yüzden LDF’ye veri yazmak genellikle çok daha hızlıdır.
Sql serverda veritabanı altında oluşturulan data file’ların herhangi bir önceliği bulunmamaktadır. Random yazılmaktadır. Kısacası aynı file group altında oluşturulan birden fazla data file verilerin veritabanı üzerinde bulunan data file’lara yazılması rastgele olmaktadır. Herhangi bir önceliği yoktur. Random yazılmaktadır. Filegroup mantığı ise bakım işlemlerini daha rahat oluşturmak için vardır. Eğer filegroup altında aynı disk veya farklı disk farketmeksizin oluşturulan data file’lar bizim sadece aynı disk altında veya farklı disk altında okunup yazıldığı zaman avantajları ve dezavantajları vardır. Filegroup ise tamamen bu yapıdan farklıdır. Filegroup işleminin avantajları dbcc check işlemleri filegroup bazında yapılabilmektedir. Backup işlemleri yine filegroup bazında gerçekleşmektedir. Büyük tabloları filegroup bazında partition yapılmaktadır. Yönetimsel anlamında bize faydaları olduğu için kullanılır. Primary file group altında farklı disklerde data file larda aynı yapıya gelmektedir. Ama bakım işlemleri genel olarak tek bir filegroup üzerinden yapılır.
Not: “SQL Server’da veri önce log (LDF) dosyasına yazılır. Bu veriler MDF dosyasına daha sonra yazılır.
Eğer Full Recovery Model kullanılıyorsa ve düzenli log backup alınmazsa, log dosyası büyür.
Bu da disk alanını tüketebilir ve sistem yavaşlayabilir.
Ancak backup işlemleri sırasında MDF ve LDF birlikte okunur, bu dosyalar kullanılabilir durumdadır.”
| Konu | Doğru mu? | Açıklama |
|---|---|---|
| Backup alırken MDF kullanılamaz | ❌ | Kullanılır; backup sırasında hem MDF hem LDF içerikleri işlenir |
| LDF → MDF yazımı gecikebilir | ✅ | Doğrudur, WAL mantığı gereği |
| Log dosyası büyür ve sistemi yavaşlatabilir | ✅ | Log backup alınmazsa büyür; disk/performans etkilenebilir |
Büyük veritabanlarımızda tüm verinin aynı filegroup üzerinde olması backup anlamında sıkıntı yaşamamıza sebep olacaktır. Veritabanımızı filegrouplara bölerek filegroup bazında backup işlemlerimizi gerçekleştirebiliriz. Filegroup aslında bize yönetim kolaylığı sağlar. Karmaşıklığı önler.
Büyük veritabanlarında datanın ve sistem objelerinin aynı filegroup ve data file üzerinde olması sıkıntı yaratacak bir durumdur.
- “Data” → Uygulama verileri (tablolar, indeksler, transaction’lar)
- “Sistem objeleri” → Stored procedure’ler, view’lar, trigger’lar, fonksiyonlar vb.
(Yani: SQL kodu, sorgular, tanımlar)
Bu iki şey aynı veritabanında olduğunda, bazı sorunlar ortaya çıkabilir. özellikle büyük ve yoğun veritabanlarında.
Büyük veritabanlarında her şeyi tek bir yapıya yığmak izolasyon, yönetim, performans ve güvenlik açısından risklidir.
Not: İndexlerin ayrı bir filegroup ve data file üzerinde olması tavsiye edilir. Sadece indexs yapılarımız için farklı bir filegroup oluşturulabilir. Bu durum indexslerimizin daha performanslı çalışmasını sağlamaktadır. File group bazlı bakım çalışmasını kolaylaştırır.
- Eğer tüm filegroup’lar aynı fiziksel disk üzerindeyse → hiçbir fark yaratmaz.
- Çünkü SQL Server diske yazarken yine aynı fiziksel I/O kanalını kullanır.
- Sadece mantıksal bir ayrım yapmış olursun, performans değişmez.
| Durum | Performansa Etkisi |
|---|---|
| Filegroup + Ayrı fiziksel disk | ✅ Evet, performans artabilir |
| Aynı disk, farklı filegroup | ❌ Hayır, fark yaratmaz |
| Yönetimsel nedenlerle ayırma | ✅ Kolaylık sağlar |
Index’ler ayrı filegroup’ta olmalı ifadesi tek başına yeterli değildir. Gerçek fayda için o filegroup’un farklı bir diske (veya I/O path’e) yönlendirilmiş olması gerekir. İki farklı file groupun aynı diski kullanması iki farklı gurubun aynı kasiyer üzerinden işlem yapması gibidir. Hız açısından herhangi bir kolaylık sağlamaz.
Veritabanımızın başlangıç boyutu büyükse farklı bir filegroup oluşturup veritabanımızın default olan yeni filegroupda büyümesi tavsiye edilir.
SQL Server’da büyük bir tabloyu tek bir filegroup içinde, birden fazla data file kullanarak saklayabiliriz. Bu sistem zamanla verinin düzensiz dağılmasına yol açabilir. Ne demek bu? Hemen açıklayalım:
Başlangıçta ne olur?
- Tablonuz küçükken, veriler sadece ilk oluşturulan data file üzerine yazılır.
- Ancak zamanla tablo büyüdükçe, SQL Server yeni verileri yeni eklenen diğer data file’lara da yazmaya başlar.
Sorun nerede başlıyor?
- Veri eşit dağılmayabilir. İlk baştaki data file büyük olurken, sonradan eklenenlerde daha az veri olabilir.
- Bu durum tabloda verilerin dengesiz yerleşmesine neden olur.
Peki, indeks rebuild ne yapar?
- Clustered index rebuild işlemi sırasında SQL Server, veriyi yeniden düzenler.
- SQL Server önce hangi data file’ların kullanılacağını belirler.
- Bu kararı verirken her data file’ın boyutuna ve boş alanına bakar.
Sonuç ne olur?
- SQL Server, en boş olan data file’a yeni verileri yazmayı tercih eder.
- Bu da veri dağılımının daha da dengesizleşmesine neden olur.
- Zamanla bazı data file’lar çok dolarken, bazıları boş kalabilir.
- Bu durum, disk üzerinde beklemelere (I/O yavaşlaması) ve performans sorunlarına yol açar.
Özetle:
Verinin eşit dağılmaması, index rebuild işlemlerinde SQL Server’ın veriyi hep en boş alana yazmasına neden olur. Bu da bazı dosyaların dolup bazı dosyaların boş kalmasına sebep olur. Sonuç olarak disk kullanımı dengesizleşir ve performans sorunları yaşanabilir.
Aynı filegroup içinde birden fazla data file varsa, bir büyük tablonun verisi bu dosyalar arasında parça parça dağılabilir. Bu performans açısından sorunlara neden olabilir.
Şimdi bunu anlaşılır şekilde açıklayalım:
- Diyelim ki UserDataFG adlı bir filegroup’ta 3 adet .ndf data file var:
- data1.ndf, data2.ndf, data3.ndf
- Bu filegroup’a bir büyük tablo (örneğin Orders) atanmış.
- SQL Server, bu tabloyu oluştururken hangi data file’a ne kadar veri yazılacağını kendisi belirler. Bu yapı sadece bir tablo olarak değilde veritabanı seviyesinde de aynı yapıda oluşmaktadır.
ÖZETLE aynı filegroup altında bulunan birden fazla data file’a ilgili filegroup altında oluşturulan nesnenin veya nesnelerin içindeki veriler data file’lara rastgele yazılmaktadır. Bu yapı bizlere performans anlamında sıkıntı oluşturacaktır.
Şimdi Potansiyel Sorunlara:
1. Veri Dağınıklığı (Fragmentation)
- Tablo verisi farklı fiziksel dosyalarda yer aldığında, veri süreksiz olur.
- Bu da I/O sırasında diskin daha fazla çalışmasına ve yavaşlamaya neden olabilir.
2. Disk Bazlı I/O Beklemeleri
- Data file’lar farklı disklerdeyse ve bu disklerin performansları farklıysa, SQL Server en yavaş olan diskin hızına göre performansı sınırlar.
3. Index Rebuild ve Page Movement
- Index rebuild gibi işlemler sırasında SQL Server veri sayfalarını yeniden düzenlemeye çalışır.
- Bu işlem, verilerin hangi file’a yazıldığını ve boşluk durumunu kontrol ederek yapılır.
- Sonuç: Veriler eşit dağılmaz, bazı dosyalar dolarken bazıları boş kalabilir.
- Zamanla bazı data file’lar tıkanabilir, I/O queue artar ve performans düşer.
Performans Açısından Ne Yapmalı?
| Tavsiye | Açıklama |
|---|---|
| Data file’lar aynı boyutta ve aynı büyüme oranında olmalı | SQL Server veriyi daha dengeli dağıtır. |
| Mümkünse aynı performans seviyesinde diskler kullanılmalı | Farklı disk hızları I/O dengesizliği yaratır. |
| IO ve file-level monitoring yapılmalı | Hangi file daha fazla yük altındaysa izlenmeli. |
| Çok fazla data file eklenmemeli (genelde 1-4 arası yeterli) | Gereksiz karmaşıklık yaratabilir. |
Sonuç:
Aynı filegroup içindeki birden fazla data file, veri dengesiz dağılırsa veya yanlış konumlandırılırsa performans kaybına neden olabilir. Özellikle büyük tablolarda, veri parçalara bölünerek farklı dosyalarda tutulursa bu, I/O yavaşlamaları ve index rebuild sırasında gecikmelere yol açabilir.
Not: Filegroup altında bulunan data file boyutu 16 TB’a ulaşmışsa sql server error loglarında aşağıdaki gibi bir hata mesajıyla karşılaşılır.
Could not allocate a new page for database ‘DB_NAME’ because of insufficient disk space in filegroup ‘TABLESGROUP’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
SQL Server, DB_NAME veritabanında yeni veri eklemek veya güncellemek için disk alanına ihtiyaç duyuyor ancak TABLESGROUP filegroup’unda yeterli boş alan yok. Yukarıda belirtiğimiz gibi tablo filegroup altında oluşturulur. Filegroup altında bulunan data file’lara veriler yazılmaktadır.
Yukarıdaki hata mesajıyla karşılaşılırsa aynı filegroup altında yeni bir data file oluşturulması sorunumuzu çözecektir. Sql server artık ilk data file dolduğu için ikinci data file’a yazma işlemi yapacaktır.
Veritabanımız altında yeni bir filegroup ve data file oluşturma işlemine geçelim.
Veritabanımızın üzerine sağ tıklanıp properties denilir. Gelen ekranda filegroups sekmesine gelinir.
Add Filegroup butonuna tıklanır. FG2024 adında bir filegroup oluşturulur.
Yukarıdaki ekranda Files sekmesi ilgili filegroup altındaki dosya sayısını gösteriyor. Primary .mdf dosyası var ama yeni oluşturduğum. FG2024’e herhangi bir data file tanımlamadım.
Read-Only bu seçenek işaretlenirse ilgili filegroupdaki sadece okunabilir olur ve herhangi bir işlem yapılamaz. Herhangi bir filegroup Default olarak işaretlenmişse, yeni oluşturulan veritabanı nesneleri tablo vs. default olan file group’a eklenir. Data file sekmesinde yeni bir ndf file oluşturacağımız zaman file group sekmesi yukarıdaki resimde hangisi default ayardaysa o gelmektedir.
SQL Server’da “Autogrow All Files” seçeneği (checkbox), veritabanı filegroup’ları için önemli bir ayardır. Bu seçenek, filegroup içinde birden fazla data file varsa, hangi dosyanın ne zaman ve nasıl büyüyeceğini kontrol eder.
Seçiliyse → Filegroup’taki tüm data file’lar eşzamanlı olarak büyür.
Seçili değilse → Sadece ihtiyaç duyulan tek bir data file büyür (default SQL Server davranışı).
Varsayalım:
- UserDataFG adlı filegroup içinde 3 data file var:
data1.ndf, data2.ndf, data3.ndf - Her biri 100 MB başlangıç boyutunda ve 50 MB autogrow ayarı var.
Eğer Autogrow All Files işaretliyse:
- Bir dosya dolduğunda, üçü birden 50 MB büyür → Hepsi olur 150 MB.
Eğer Autogrow All Files işaretli değilse:
- Sadece dolan dosya büyür → Diğerleri sabit kalır → Veri dengesizliği olur.
Ne zaman kullanılmalı?
| Durum | Tavsiye |
|---|---|
| Büyük veritabanı ve yüksek I/O varsa | ✅ Açılması önerilir |
| Dosyalar farklı disklerdeyse | ⚠️ Dikkatli kullanılmalı (disk performansı eşit değilse problem olabilir) |
| Tek data file varsa | 🚫 Etkisi yok |
Aynı anda bir filegroup hem “default” olarak atanabilir hem de “Autogrow All Files” özelliği açılabilir. Bu iki ayar birbirinden bağımsızdır ve birlikte çalışabilir.
Örnek Senaryo:
| Filegroup Adı | Data File Sayısı | Autogrow All Files Açık mı? |
|---|---|---|
| PRIMARY | 1 | (tek dosya – bu özellik etkisiz) |
| UserDataFG | 3 | ✅ Açık |
| ArchiveFG | 2 | ❌ Kapalı |
Bu durumda, sadece UserDataFG’deki data file’lar aynı anda büyür. Diğer filegroup’lardaki dosyalar bağımsız hareket eder.
Bu açıklamalardan sonra ilgili ekranın sol kısmında Files sekmesi altında Data file ekleme işlemi yapılır.
Not: Veritabanı default olarak iki dosya yapısına sahiptir. Bunlar mdf uzantılı data dosyası ve ldf uzantılı transaction log dosyasıdır.
Files sekmesine tıkladıktan sonra gelen ekranda yeni bir data file eklemek için alt kısımda bulunan Add kısmına tıklanır.
Data file oluşturmadan önce filegroup kısmında default olarak primary geleceğini yukarıda açıklamıştık.
Oluşturacağım data file’a yeni oluşturmuş olduğum FG2024 filegroup’u seçiyorum.
Not: Genellikle veritabanı boyutu 1 TB üzeri olan veritabanlarında IO performans sıkıntısı yaşacağımız için performans anlamında yeni file eklenir. Bu eklenen File’ın primary file group altında büyümektense yeni oluşturulacak file group üzerinde büyümesi tercih edilir. Çünkü yönetilebilirlik açısından bizlere daha iyi katkı sunar.
Path kısmında yeni oluşturduğum file group için yeni bir disk yolu belirtiyorum. Elimde C diskinden başka bir diskim olmadığı için bu şekilde bırakıyorum.
Şimdi yukarıdaki kavramların ne işe yaradığını açıklayalım.
- Logical Name: Bu sütun, dosyanın mantıksal adını gösterir.
- FILEGROUP: Bu, PRIMARY filegroup içinde yer alan veri dosyasını temsil eder.
- FILEGROUP_log: Bu, log dosyasını temsil eder.
- FG2024_DATA: Yeni oluşturulmuş olan FG2024 filegroup’una bağlı veri dosyasıdır.
File Type:
- ROWS : Bu tür, veritabanı içindeki veri satırlarını içeren dosyaları temsil eder.
- LOG: Bu tür ise veritabanı işlem günlüklerini (transaction log) içeren dosyaları ifade eder.
Filegroup: Dosyanın hangi filegroup’a ait olduğunu gösterir.
- PRIMARY: Veritabanının varsayılan filegroup’udur.
- Not Applicable: Log dosyaları, filegroup’a ait değildir.
- FG2024: Bu, yeni oluşturulan FG2024 filegroup’una bağlı bir dosyadır.
Size: Dosyanın şu anki boyutunu gösterir. Görüntüde her dosya için 8 MB başlangıç boyutu atanmış. Başlangıç olarak insert işlemlerinde sıkıntı yaşamamak için bu değer yükseltilebilir. İlerleyen aşamalarda size bölümünde ilgili dosyanın büyüklüğünü görebiliriz. Genelde data file için 512, log file için 256 MB olarak belirlenebilir.
Not: Initial size, autogrowth değerleri bizim model veritabanımızı baz alarak gelmektedir.
Autogrowth/Maxsize: Dosyaların otomatik olarak ne kadar büyüyeceğini ve maksimum ne kadar büyüyebileceğini ayarlar.
Örneğin, burada dosyalar 64 MB’lik artışlarla otomatik olarak büyüyecek şekilde ayarlanmış, ve bazıları için maksimum boyut Unlimited (sınırsız) olarak belirlenmiş.
Path: Dosyanın saklandığı dizini gösterir. Örnekte tüm dosyalar SQL Server’ın varsayılan veritabanı dizininde saklanıyor. Bu ekran, SQL Server veritabanı yönetiminde dosya yapılandırmalarını görselleştirmek ve düzenlemek için kullanılır.
File Name: Manuel olarak isim belirlenmekle birlikte default olarak logical name ile birlikte gelmektedir. Primary haricinde oluşturulan tüm data file’ların uzantısı .ndf olarak gelmektedir.
Not: Veritabanların aynı anda sadece 1 tane log dosyasına yazacağı için log dosyasının bulunduğu disk’in hızlı olması açısından diğer data file disklerinden ayrı bir disk ve Raid yapılandırması yapılabilir. Sorgularımızın bekleme tipi Write Log ise log dosyalarımızın olduğu disk’in yavaş çalıştığı anlamına gelmektedir.
Not: Bir data file, yalnızca ait olduğu filegroup tarafından kullanılır. Bir filegroup’a eklenmeyen data file, SQL Server tarafından veri yazımı için kullanılamaz.
Yukarıdaki açıklamalardan sonra Script’i alınarak işlem komut sırasıyla çalıştırılır. Filegroup ve data file oluşturulmuş olur.
USE [master]
GO
ALTER DATABASE [FILEGROUP] ADD FILEGROUP [FG2024]
GO
ALTER DATABASE [FILEGROUP] ADD FILE ( NAME = N'FG2024_Data', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL15.TEST\MSSQL\DATA\FG2024_Data.ndf' , SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [FG2024]
GOElimizde mevcut bulunan bir tabloyu yeni bir filegroup’a geçirmek için aşağıdaki yöntemler izlenir.Tablomuz küçük ve lob data içermiyorsa ilgili tablo altındaki filegroup’u değiştirebiliriz. Aşağıdaki resimde bir tablonun filegroup’unu görmekteyiz.
İlgili tablomuzdaki indexsler silinip yeni filegroup altında tekrar oluşturulur. Bu yapıda cluster indexsimizi sadece ilgili filegroup altında alınca tablomuz ilgili filegroup altında büyümüş oluyor.
USE [FILEGROUP]
go
CREATE CLUSTERED INDEX PK_TABLE ON [dbo].[TABLEE] (id) WITH (drop_existing = ON) on FG2024
Go
Diğer indexs’leride ilgili filegroup altına almaya gerek yoktur.
Text/Image Filegroup kısmı PRIMARY olarak karşımıza çıkmaktadır. Buda transactionlar için büyük bir sıkıntıdır.
USE FILEGROUP
GO
SELECT o.[name] AS TableName, i.[name] AS IndexName, fg.[name] AS FileGroupName
FROM sys.indexes i
INNER JOIN sys.filegroups fg ON i.data_space_id = fg.data_space_id
INNER JOIN sys.all_objects o ON i.[object_id] = o.[object_id]
WHERE i.data_space_id = fg.data_space_id AND o.type = 'U'
İlgi tablomuzun içerisinde lob data veriler varsa boyutumuzda büyükse veya lob data olma ihtimali olan tablolarda da bu yöntem uygulanır. Tablo normal bir şekilde ilgili filegroup’a atanırsa ve ilerleyen aşamalarda tablomuza lob data veriler gelirse gelen lob data veriler seçmiş olduğumuz filegroup’da değil primary filegroup’da kalacaktır. Bu yöntemin tüm tablolarda oluşturulması daha mantıklıdır. Çünkü sürekli lob data ihtimal dahilindedir.
Tablomuzun boyutu büyük ve lob data varsa aşağıdaki yöntem uygulanır. Dikkat edilmesi gereken geçici olarak oluşturulan tablo için log diskinde yeterli bir alan olması gerekmektedir.
İlgili tablo üzerine sağ tıklanıp Design kısmına tıklanır.
Gelen ekranda satır veya kolun üzerinde herhangi bir bölüme sağ tıklanıp properties ekranına gelinir.
Sağ tarafta açılan ekranda Regular Data Space Specification sekmesini açıyor ve Filegroup or Partition Scheme Name kısmından yeni file group’umuzu seçiyoruz. Daha sonra Text/Image Filegroup üzerinde de aynı işlemi yapıyoruz.
FG2024 olarak filegroup’umuzu değiştiriyoruz.
Bu işlemleri yaptıktan sonra Design ekranında boş bir yere sağ tıklayıp Generate Change Script’ini alıyoruz.
Gelen ekranda kodumuzu kopyalayıp yeni bir query’e yapıştırıyorum.
No deyip bu ekrandan çıkıyorum. Tablomuzda lob data veri veya olmaya ihtimali varsa bu yöntem yapılmaktadır.
Resimde görüldüğü gibi geçici bir tablo oluşturuyor. Oluşturmuş olduğu bu tabloya gerçek tablodaki verileri atıyor. Daha sonra oluşturmuş olduğu temp tablonun ismini değiştiriyor. Gerçek sistemde partition yapılarında sıfırdan partition işlemindede buna benzer bir yapı karşımıza çıkmaktadır.
Bir transaction içinde başka bir transaction açılmaması için ilgili transaction başlamadan önce önceki transaction Commit ediliyor.
Not: Tablomuz büyük ve tek insert işlemi olduğu için recovery model’i simple’a çeksek bile log büyümeye devam edecektir. Bunun için verileri insert edeceğimiz bölümün düzenlenip belli aralıklarla veri atan bir kod bloğu düzenlenebilir.
Not: Gerçek sistem üzerinden karşılaşılan bir soruna değinmek istiyorum. Aşağıdaki ekran resmi üzerinden açıklamalarımızı yapalım.
Yukarıda görülen her iki veri dosyası aynı filegroup’ta (PRIMARY) yer alıyor ve bunların boyutları oldukça büyük: 1. dosya: 16 TB’e yakın (16.7 TB) • 2. dosya: 2.1 TB Autogrowth ayarı, sınırsız büyüme olarak ayarlanmış. PRIMARY filegroup sınırı 16 TB olduğundan, bu dosya yapısı 16 TB sınırına yaklaştığında veya aşıldığında sorun çıkacaktır. Bu nedenle yeni bir filegroup veya data file eklenmeden aynı PRIMARY filegroup üzerinde büyümeye devam etmek hatalı bir tasarım yaklaşımıdır. Bunun için ya veritabanı altında yeni bir filegroup ve data file eklenmeli yada primary filegroup altında yeni bir data file eklenmesi gerekmektedir. Bu yapı ile makalenin başındada belirttiğimiz gibi verilerimiz dağınık bir şekilde olacaktır. İkinci bir filegroup gereği duymamız yönetim ve bakım işlemlerinde kolaylık sağlamasıdır.
PRIMARY filegroup’un toplam kapasite mdf data file sınırı 16 TB‘dir. Aynı filegroup altında ikinci bir secondary data file oluşturmamız sorunumuzun giderilmesine sağlayacaktır.
Aşağıdaki komutla veritabanları üzerinde bulunan data dosyalarının toplam boyutunu görmüş oluruz. Bu sayede veritabanlarını data dosyalarının16 tb sınırına ulaşıp ulaşılmadığı görülebilir. Eğer ulaşılmışsa aynı filegroup altında yeni bir data file oluşturularak verilerin ilgili data file bölümüne yazılması sağlanır. Veya farklı file group ve data dile oluşturarak yeni eklenecek verilerin bu data file üzerine yazmasını sağlayabiliriz.
SELECT
DB_NAME(mf.database_id) AS DatabaseName,
fg.name AS FileGroupName,
mf.name AS LogicalFileName,
mf.physical_name AS PhysicalFilePath,
(CAST(mf.size AS BIGINT) * 8 / 1024) AS SizeMB
FROM sys.master_files AS mf
LEFT JOIN sys.filegroups AS fg
ON mf.data_space_id = fg.data_space_id
WHERE mf.type_desc = 'ROWS' -- Sadece mdf / ndf
ORDER BY SizeMB DESC;Bu makalede FileGroup ve Data File konusunu ele almış olduk. Bir sonraki makalede görüşmek dileğiyle..
“Onlar her türlü boş söz ve faydasız işlerden yüz çevirirler.” Mü’minûn- 3
