sunucu.com.tr
İş Yazılımları

SQL Express 10 GB sınırı doldu: Logo ve Mikro için SQL Server 2025 Express mi, Standard mı?

SQL Express 10 GB sınırına dayanan Logo ve Mikro veritabanınızın ne kadar dolduğunu T-SQL ile ölçün. Geçici rahatlama yollarını, SQL Server 2025 Express'in 50 GB sınırını, Standard'a geçişte nelere bakacağınızı ve SQL Agent olmadan otomatik yedeği nasıl kuracağınızı öğrenin.

sunucu.com.tr Ekibi11 dk okuma

Logo, Mikro, Netsis ya da ETA'yı ücretsiz SQL Server Express üzerinde çalıştırıyorsanız bir gün SQL Express 10 GB sınırına dayanırsınız. Fatura kesilirken hata çıkar, aktarım yarıda kalır ve kimse nedenini hemen anlamaz. Bu yazı, sınıra ne kadar yaklaştığınızı ölçmenize, kısa vadede nasıl rahatlayacağınızı görmenize ve SQL Server 2025 Express ile Standard arasında doğru seçimi yapmanıza yardım eder. Hedef okuyucu, iş yazılımının veritabanından sorumlu sistem yöneticisi ya da KOBİ sahibidir.

SQL Express 10 GB sınırı nedir: hangi dosyalar sayılır?

SQL Server 2008 R2'den 2022'ye kadar tüm Express sürümlerinde sınır veritabanı başına 10 GB'tır. Sunucunun toplam diski ya da tüm veritabanlarının toplamı sayılmaz. Her veritabanı kendi 10 GB hakkına sahiptir.

Sayılan kısım yalnızca veri dosyalarıdır (.mdf ve varsa .ndf). İşlem günlüğü (.ldf) bu sınıra dahil değildir. Bu yüzden 25 GB'lık bir log dosyası diski doldurabilir ama 10 GB sınırını tetiklemez. Tersine, log'u küçültmek de sınır sorununu çözmez.

Express'in iki kısıtı daha vardır ve veritabanı büyüdükçe bunlar da hissedilir:

  • Bellek: Buffer pool için en fazla 1.410 MB (yaklaşık 1,4 GB) kullanılır. Sunucuda 32 GB RAM olsa bile SQL Server veriyi bellekte bu kadar tutar.
  • İşlemci: Bir soket ya da dört çekirdekten hangisi küçükse o kadar kullanılır.

Bu yüzden 9 GB'lık bir Logo veritabanı sınıra gelmeden önce de yavaşlar: verinin büyük kısmı belleğe sığmaz ve her raporda diske gidilir.

Logo ve Mikro veritabanınızın ne kadar dolduğunu ölçme

Önce hangi sürümü ve hangi edition'ı kullandığınızı doğrulayın. Aşağıdaki sorgu SQL Server Management Studio (SSMS) ya da sqlcmd ile çalışır, salt okunurdur ve geri alınacak bir değişiklik yapmaz.

sql
-- Sürüm ve edition bilgisi (SQL Server 2012 ve sonrası için hazırlandı)
SELECT
    SERVERPROPERTY('Edition')        AS edition,
    SERVERPROPERTY('ProductVersion') AS surum,
    SERVERPROPERTY('ProductLevel')   AS guncelleme_seviyesi;

edition sütununda "Express Edition" görüyorsanız sınır sizin için geçerlidir. Sonraki sorgu tüm veritabanlarının veri ve log dosyası boyutlarını listeler. Bu da salt okunurdur.

sql
-- Tüm veritabanlarında ayrılan veri ve log boyutu (MB)
-- size değeri 8 KB'lık sayfa sayısıdır
SELECT
    DB_NAME(database_id) AS veritabani,
    CAST(SUM(CASE WHEN type_desc = 'ROWS' THEN CAST(size AS BIGINT) ELSE 0 END) * 8 / 1024.0 AS DECIMAL(12,1)) AS veri_mb,
    CAST(SUM(CASE WHEN type_desc = 'LOG'  THEN CAST(size AS BIGINT) ELSE 0 END) * 8 / 1024.0 AS DECIMAL(12,1)) AS log_mb
FROM sys.master_files
GROUP BY database_id
ORDER BY veri_mb DESC;

veri_mb 10.240'a yaklaşıyorsa sınırın yakınındasınız. Bu değer dosyanın diskte ayrılmış boyutudur. Dosyanın içinde ne kadar gerçek veri olduğunu görmek için ilgili veritabanına geçip şu sorguyu çalıştırın. ORNEK_VERITABANI yerine kendi Logo ya da Mikro veritabanı adınızı yazın.

sql
USE ORNEK_VERITABANI;
-- Dosya başına ayrılan ve kullanılan alan (MB)
SELECT
    name      AS dosya,
    type_desc AS tur,
    CAST(size / 128.0 AS DECIMAL(12,1))                         AS ayrilan_mb,
    CAST(FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS DECIMAL(12,1)) AS kullanilan_mb
FROM sys.database_files;

Ayrılan alan 10 GB'a yakın ama kullanılan 7 GB ise içeride hâlâ yer vardır, yalnızca dosya önceden büyümüştür. İkisi de 10 GB'a yakınsa veritabanı gerçekten doludur. Neyin yer kapladığını görmek için en büyük tabloları listeleyin:

sql
USE ORNEK_VERITABANI;
-- En çok yer kaplayan 15 tablo
SELECT TOP (15)
    OBJECT_SCHEMA_NAME(object_id) + '.' + OBJECT_NAME(object_id) AS tablo,
    SUM(reserved_page_count) * 8 / 1024 AS ayrilan_mb,
    SUM(CASE WHEN index_id IN (0, 1) THEN row_count ELSE 0 END) AS satir_sayisi
FROM sys.dm_db_partition_stats
WHERE OBJECTPROPERTY(object_id, 'IsUserTable') = 1
GROUP BY object_id
ORDER BY ayrilan_mb DESC;

Listenin başında hareket tabloları beklenir. Ama belge eki, ürün resmi ya da işlem geçmişi tutan bir tablo öndeyse, büyümenin asıl kaynağını bulmuşsunuz demektir. Bu tablolara iş yazılımının kendi aracı dışında müdahale etmeyin; bayinize ya da yazılım destek ekibine danışın.

Sınır dolunca ne olur?

Veri dosyası büyümek istediğinde SQL Server izin vermez ve aşağıdaki türden hatalar döner:

  • 1105: "Could not allocate space for object ... because the 'PRIMARY' filegroup is full." Yeni satır yazılacak yer kalmamıştır.
  • 1827: Veritabanı boyutunun lisanslı sınır olan 10.240 MB'ı aşacağını bildiren hata. Genellikle dosyayı elle büyütmeye çalışınca görülür.

İş yazılımı bu hataları kendi mesajıyla sarabilir. Kullanıcı yalnızca "kayıt yapılamadı" ya da "veritabanı hatası" görür. Okuma işlemleri çalışmaya devam eder: raporlar açılır, eski faturalar görüntülenir. Ama yeni fiş, fatura, irsaliye ve stok hareketi yazılamaz. Ay sonu ya da e-fatura gönderimi sırasında bu durum ciddi iş kaybına dönüşür.

Geçici rahatlama: log, shrink ve dönem arşivleme

Bu yöntemler zaman kazandırır, sorunu çözmez. Hiçbirine başlamadan önce tam yedek alın.

Log dosyası sınırı etkilemez

Log dosyası 10 GB hesabına girmediği için onu küçültmek sınırı geri itmez. Yine de büyük bir log diski doldurabilir. Veritabanı FULL kurtarma modelindeyse ve düzenli log yedeği almıyorsanız log sürekli büyür. Ya log yedeği planlayın ya da iş yazılımı üreticinizin önerisine göre SIMPLE modele geçin. SIMPLE modelde belirli bir ana geri dönme imkânını kaybettiğinizi unutmayın.

Shrink yalnızca boş alanı geri verir

DBCC SHRINKFILE dosyanın içindeki boş sayfaları diske iade eder. Ölçümde "ayrılan" ile "kullanılan" arasında büyük fark varsa işe yarar. Dosya gerçekten doluysa hiçbir şey kazandırmaz. Ayrıca shrink indeksleri parçalar ve performansı düşürür. Mesai dışında çalıştırın, ardından indeks bakımı yapın ve bunu rutin bir bakım işi hâline getirmeyin.

Dönem arşivleme ve devir

Asıl kalıcı rahatlama, eski dönem verisini ayrı bir veritabanına almaktır. Logo ve Mikro'nun dönem devri, firma kopyalama ya da arşivleme araçları bunun için vardır. Express sınırı veritabanı başına olduğu için, eski yılları ayrı bir veritabanına taşıyan kurulumlarda her arşiv veritabanı kendi 10 GB hakkına sahip olur. Bu işlemi mutlaka yazılımın kendi aracıyla, bayinizin desteğiyle yapın. Tabloları elle silmek, bütünlüğü bozulmuş bir muhasebe verisiyle sonuçlanabilir.

SQL Server 2025 Express: 50 GB sınırı, değişmeyen kısıtlar

SQL Server 2025 ile Express sürümünün veritabanı başına boyut sınırı 10 GB'tan 50 GB'a çıktı. Ayrıca ayrı bir "Express with Advanced Services" paketi kalktı; tam metin arama gibi özellikler Express'in içine alındı. Ayrıntılar Microsoft'un SQL Server 2025 yenilikler sayfasında yer alıyor.

Değişmeyenler ise şunlar:

  • Buffer pool için yaklaşık 1,4 GB bellek sınırı sürüyor.
  • Bir soket ya da dört çekirdek sınırı sürüyor.
  • SQL Server Agent hâlâ yok, zamanlanmış iş tanımlayamazsınız.

Bu ne anlama geliyor? Sorununuz yalnızca boyutsa ve kullanıcı sayınız azsa, 2025 Express ücretsiz ve yeterli bir çözüm olabilir. 5 ile 10 kullanıcılı, günde birkaç yüz fiş işleyen bir ofis için 50 GB uzun yıllar yeter. Ama veritabanı 10 GB'ı aşmışsa ve sunucu yalnızca 1,4 GB'ını önbellek olarak kullanabiliyorsa, raporlar ve büyük listeler yavaş kalır. Boyut sorunu çözülür, performans sorunu çözülmez.

Bir uyarı daha: Logo ya da Mikro sürümünüzün SQL Server 2025'i resmi olarak desteklediğini yükseltmeden önce bayinizden ya da üreticinin uyumluluk listesinden teyit edin. Eski bir iş yazılımı sürümü yeni SQL sürümünde kurulum, güncelleme ya da rapor aşamasında sorun çıkarabilir.

Express'ten Standard'a yükseltme

Standard sürümünde veritabanı boyutu için pratik bir sınır yoktur. SQL Server 2025 Standard, bellekte 256 GB'a ve 32 çekirdeğe kadar çıkabiliyor. Bu, 1,4 GB'lık Express ile kıyaslanamayacak bir fark demek: 20 ya da 30 GB'lık bir veritabanının tamamı belleğe sığabilir.

Lisans seçenekleri

Standard için iki temel lisanslama modeli vardır:

  • Çekirdek başına: Sunucudaki (sanal makinede atanan) çekirdek sayısı kadar lisans alınır, kullanıcı sayısı önemli değildir. Sanal makinelerde en az dört çekirdek lisanslanır.
  • Sunucu + CAL: Bir sunucu lisansı ve SQL Server'a erişen her kullanıcı ya da cihaz için bir CAL alınır. Kullanıcı sayısı az ve sabitse daha ekonomik olabilir.

Bulut sunucuda çalışıyorsanız, sağlayıcınızdan aylık kiralanan lisans (SPLA) üçüncü bir seçenektir; peşin lisans maliyetini aylık gidere çevirir. Bazı iş yazılımı bayileri de kendi paketleriyle SQL lisansı sunar. Fiyat ve koşullar değiştiği için hangi modelin size uyduğunu güncel teklifle karşılaştırın.

Donanım nasıl seçilmeli?

Standard'ın asıl faydası belleği kullanabilmesidir. Kaba bir kural olarak, veritabanının sık kullanılan kısmı belleğe sığacak kadar RAM ayırın ve işletim sistemine ayrıca pay bırakın. Diskte SSD ya da NVMe kullanın, veri ve log dosyalarını mümkünse ayrı disklere koyun. Yeni bir makine gerekiyorsa, Standard lisansını ve yeterli belleği barındıracak bir SQL Server veritabanı sunucusu üzerinde aynı adımları uygulayabilirsiniz.

Yükseltme öncesi kontrol listesi

Hangi yolu seçerseniz seçin, şu sırayı izleyin:

  1. Tam yedek alın ve yedeği sunucu dışına kopyalayın. Yedeği bir test sunucusunda geri yükleyerek çalıştığını doğrulayın.
  2. İş yazılımı uyumluluğunu bayinizle teyit edin: hedef SQL sürümü, gerekli iş yazılımı güncellemesi ve varsa ek ayarlar.
  3. Test ortamı kurun. Yedeği yeni sürüme geri yükleyin, iş yazılımını bağlayın, fatura kesme, rapor alma ve e-belge gönderimini deneyin.
  4. Kesinti penceresi belirleyin. Kullanıcılar çıkış yapmadan son yedeği almayın.
  5. Geri dönüş planınızı yazın. Eski sunucuyu birkaç gün kapatmadan bekletin.

Aynı ana sürüm içinde (ör. 2022 Express'ten 2022 Standard'a) SQL Server kurulum sihirbazındaki "Edition Upgrade" adımıyla, ürün anahtarı girerek yerinde yükseltme yapılabilir. Farklı sürüme geçişte ise en temiz yol, yeni sunucuya temiz kurulum yapıp veritabanını yedekten geri yüklemektir. Bu yöntemin adım adım anlatımı için SQL Server 2016'dan 2022'ye taşıma rehberimize bakabilirsiniz; aynı adımlar 2025 için de geçerlidir.

Express'te SQL Agent yok: otomatik yedeği unutmayın

Express kullanan pek çok işletmede yedek ya hiç alınmıyor ya da birinin hatırlamasına bağlı. Microsoft'un yedekleri zamanlama belgesi de Express için Windows Görev Zamanlayıcı ile sqlcmd kullanımını önerir.

Aşağıdaki betik tüm kullanıcı veritabanlarının tarihli tam yedeğini alır ve yalnızca yedek klasöründeki, belirlenen günden eski .bak dosyalarını siler. Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı. sqlcmd aracının kurulu olması gerekir. Dosyayı C:\Betikler\sql-yedek.ps1 olarak kaydedin. SQL Server hizmet hesabının yedek klasörüne yazma izni olmalıdır.

powershell
# sql-yedek.ps1 : Express için gece tam yedeği
# Değiştirin: örnek adı, yedek klasörü, saklama süresi
$Instance    = '.\SQLEXPRESS'   # ORNEK_SUNUCU\ORNEK_ORNEK_ADI
$YedekKlasor = 'D:\SQLYedek'    # Yalnızca yedeklere ayrılmış klasör
$SaklaGun    = 14

$Tarih = Get-Date -Format 'yyyyMMdd_HHmm'
New-Item -ItemType Directory -Path $YedekKlasor -Force | Out-Null
Start-Transcript -Path (Join-Path $YedekKlasor 'yedek-gunlugu.txt') -Append | Out-Null

# Sistem veritabanları hariç, çevrimiçi tüm veritabanlarını al
$dbler = & sqlcmd -S $Instance -E -h -1 -W -Q "SET NOCOUNT ON; SELECT name FROM sys.databases WHERE database_id > 4 AND state_desc = 'ONLINE';"

foreach ($db in $dbler) {
    $db = "$db".Trim()
    if (-not $db) { continue }
    $dosya = Join-Path $YedekKlasor ("{0}_{1}.bak" -f $db, $Tarih)
    # CHECKSUM ile sayfa bütünlüğü yedek sırasında denetlenir
    & sqlcmd -S $Instance -E -b -Q "BACKUP DATABASE [$db] TO DISK = N'$dosya' WITH CHECKSUM, INIT;"
    if ($LASTEXITCODE -ne 0) { Write-Output "HATA: $db yedeği alınamadı" }
    else { Write-Output "Tamam: $dosya" }
}

# Yalnızca yedek klasöründeki eski .bak dosyalarını temizle
Get-ChildItem -Path $YedekKlasor -Filter '*.bak' -File |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$SaklaGun) } |
    Remove-Item

Stop-Transcript | Out-Null

Görevi kaydetmek için aşağıdaki komutları yönetici PowerShell'de çalıştırın. -Force sayesinde tekrar çalıştırıldığında görev çoğaltılmaz, güncellenir. İstenen hesap (ORNEK_KULLANICI) SQL Server'da yedek alma yetkisine sahip bir Windows hesabı olmalıdır. Geri almak için Unregister-ScheduledTask -TaskName 'SQL Express Gece Yedegi' -Confirm:$false yeterlidir; alınmış yedek dosyalarına dokunmaz.

powershell
# Görev Zamanlayıcı'ya her gece 23:30 için görev ekler (PowerShell 5.1)
$GorevAdi = 'SQL Express Gece Yedegi'
$Eylem  = New-ScheduledTaskAction -Execute 'powershell.exe' `
          -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\Betikler\sql-yedek.ps1"'
$Tetik  = New-ScheduledTaskTrigger -Daily -At '23:30'
$Kimlik = Get-Credential -Message 'Yedeği çalıştıracak hesap (ör. ORNEK_ALAN\ORNEK_KULLANICI)'

Register-ScheduledTask -TaskName $GorevAdi -Action $Eylem -Trigger $Tetik `
    -User $Kimlik.UserName -Password $Kimlik.GetNetworkCredential().Password `
    -RunLevel Highest -Force

Yedeğin aynı diskte durması fidye yazılımına ya da disk arızasına karşı koruma sağlamaz. Dosyaları en azından başka bir konuma ya da sunucu dışı bir depoya kopyalayın.

Doğrulama

İlk gece görevin çalıştığını ve yedeğin okunabilir olduğunu kontrol edin. msdb geçmişi alınan yedekleri gösterir:

sql
-- Son 10 yedek kaydı
SELECT TOP (10)
    database_name,
    backup_finish_date,
    CAST(backup_size / 1048576.0 AS DECIMAL(12,1)) AS boyut_mb
FROM msdb.dbo.backupset
ORDER BY backup_finish_date DESC;

-- Yedek dosyasının okunabilirliğini denetler (geri yükleme yapmaz)
RESTORE VERIFYONLY FROM DISK = N'D:\SQLYedek\ORNEK_VERITABANI_20261008_2330.bak' WITH CHECKSUM;

VERIFYONLY dosyanın sağlam olduğunu gösterir ama gerçek güvence, yedeği ayda bir test sunucusuna geri yükleyip iş yazılımıyla açmaktır. Yükseltmeden sonra ise ilk bölümdeki edition sorgusunu yeniden çalıştırıp yeni edition'ı ve sürümü görün.

Sık yapılan hatalar

  • Log dosyasını küçültüp sorunun çözüldüğünü sanmak. Log sınıra dahil değildir; veri dosyası aynı kalır.
  • Shrink'i her gece çalıştırmak. Dosya tekrar büyür, indeksler parçalanır, performans düşer.
  • Tabloları elle silmek. Muhasebe verisinin bütünlüğü bozulur; arşivleme yazılımın kendi aracıyla yapılmalıdır.
  • Yalnızca boyuta bakıp belleği unutmak. 2025 Express'e geçmek yer açar ama 1,4 GB bellek sınırı yüzünden yavaşlık sürer.
  • Uyumluluk teyidi almadan SQL sürümü değiştirmek. İş yazılımı güncellemesi gerekebilir.
  • Yedeği yalnızca aynı sunucuda tutmak. Sunucu giderse yedek de gider.

Sık sorulan sorular

10 GB sınırı tüm sunucu için mi, veritabanı başına mı?

Veritabanı başınadır. Aynı Express örneğinde üç firma veritabanı varsa her biri ayrı ayrı 10 GB'a kadar büyüyebilir. Sistem veritabanları ve log dosyaları bu hesaba girmez.

2025 Express'e geçince yavaşlık da biter mi?

Büyük ihtimalle bitmez. 2025 Express boyut sınırını 50 GB'a çıkarır ama bellek ve çekirdek kısıtları aynı kalır. Veritabanınız büyüdükçe önbelleğe sığmayan veri için diske gidilir. Kullanıcı sayınız ve rapor yükünüz yüksekse Standard daha uygun olur.

Express'ten Standard'a geçerken veri kaybı olur mu?

Doğru yapılırsa olmaz. Edition yükseltmesi ya da yedekten geri yükleme veriyi değiştirmez. Yine de işleme başlamadan önce tam yedek alıp test ortamında denemek zorunlu kabul edilmelidir.

Logo ya da Mikro'yu Express ile buluta taşıyabilir miyim?

Evet, Express bulut sunucuda da aynı şekilde çalışır ve aynı sınırlar geçerlidir. Taşıma zamanını Standard'a ya da 2025 Express'e geçiş fırsatı olarak da kullanabilirsiniz. Ayrıntılar için Logo sunucu ve Mikro sunucu sayfalarına göz atabilirsiniz.

Shrink ne zaman gerçekten işe yarar?

Büyük bir arşivleme ya da silme işleminden sonra dosyanın içinde çok miktarda boş alan kaldığında işe yarar. Ölçüm sorgusunda ayrılan ve kullanılan alan arasındaki fark büyükse tek seferlik bir shrink anlamlıdır. Sonrasında indeks bakımı yapın.

Sonuç

SQL Express 10 GB sınırına yaklaştığınızda önce ölçün: ayrılan ve kullanılan alanı, en büyük tabloları ve sürümünüzü görün. Kısa vadede dönem arşivleme ve doğru log yönetimi size zaman kazandırır. Sorun yalnızca boyutsa ve iş yazılımınız destekliyorsa SQL Server 2025 Express ücretsiz bir çıkış yoludur. Performans da sorunsa ya da büyüme hızlıysa Standard ve yeterli bellekli bir sunucu kalıcı çözümdür. Hangi yolu seçerseniz seçin, SQL Agent'ın olmadığı Express'te otomatik ve sunucu dışına kopyalanan yedeği bugünden kurun.

  • #sql server express
  • #sql server 2025
  • #logo
  • #mikro
  • #veritabanı boyutu
  • #sql yedekleme
  • #t-sql