# Logo veritabanı (SQL Server) bakımı ve yedeği: Sık yapılan hatalar > Logo programlarının SQL Server veritabanında sık yapılan yedekleme ve bakım hataları: Express sınırları, kurtarma modeli, shrink, CHECKDB ve geri yükleme testi. Kaynak: https://ebsbilgisayar.com/blog/logo-sql-server-veritabani-bakimi-ve-yedegi-sik-hatalar/ Tarih: 2026-04-15 Logo ürünlerinin büyük kısmı verilerini Microsoft SQL Server veritabanında tutar. Cari hesaplar, stoklar, faturalar ve muhasebe fişleri bu veritabanında yaşar. Program ne kadar iyi olursa olsun, altındaki SQL Server düzgün yönetilmediğinde yavaşlama, veri kaybı ve uzun kesintiler kaçınılmaz olur. Bu yazıda sahada en sık karşılaştığımız hataları ve doğru uygulamaları derledik. ### Hata 1: SQL Server Express sınırlarını bilmemek Küçük kurulumlarda ücretsiz **SQL Server Express** sürümü sık kullanılır. Ancak Express'in bazı önemli sınırları vardır. Microsoft'un resmi belgelerine göre: - SQL Server 2022 ve önceki sürümlerde Express için en büyük veritabanı boyutu **10 GB**, SQL Server 2025 Express'te ise **50 GB**'tır. - Express, veritabanı motoru için bellek havuzunda en fazla yaklaşık **1,4 GB** kullanabilir ve tek soket veya dört çekirdekle sınırlıdır. - Express sürümünde **SQL Server Agent** bulunmaz; yani zamanlanmış yedekleme ve bakım görevleri SQL Server'ın kendi aracıyla otomatik çalışmaz. Veritabanı sınıra yaklaştığında program kayıt almayı reddedebilir. Veritabanı boyutunu düzenli izleyin; sınıra yaklaşıyorsanız arşivleme, Express'in daha yeni bir sürümüne geçiş ya da Standard sürüm seçeneklerini önceden değerlendirin. Güncel sınırlar için [Microsoft'un sürüm karşılaştırma sayfasına](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2025) bakabilirsiniz. ### Hata 2: Express'te yedeğin "otomatik" alındığını sanmak SQL Server Agent olmadığı için Express kullanan işletmelerde yedekleme ya hiç zamanlanmamıştır ya da bir kullanıcının elle yaptığı işleme bağlıdır. Çözüm; Windows Görev Zamanlayıcı ile çalışan bir yedekleme betiği, yedekleme yazılımının SQL desteği veya Logo'nun kendi yedekleme araçlarıdır. Hangi yöntem seçilirse seçilsin, görevin her gün gerçekten çalıştığını gösteren bir bildirim veya kayıt olmalıdır. ### Hata 3: Yedeği aynı diske almak Veritabanı dosyalarıyla yedek dosyalarının aynı disk üzerinde durması, disk arızasında ikisinin birlikte kaybolması demektir. Yedekler en azından farklı bir fiziksel diske, tercihen de ağdaki bir NAS'a ve ofis dışındaki bir hedefe kopyalanmalıdır. Fidye yazılımı riskine karşı yedek hedefinin sunucudan sürekli erişilebilir bir paylaşım olmaması da önemlidir. ### Hata 4: Kurtarma modelini ve log dosyasını yönetmemek SQL Server'da veritabanının kurtarma modeli (recovery model) yedekleme stratejisini belirler: - **Simple:** İşlem günlüğü (log) kendiliğinden temizlenir; geri dönüş yalnızca son tam veya fark yedeğine yapılabilir. - **Full:** Belirli bir ana kadar geri dönüş mümkündür, ancak düzenli **log yedeği** alınmazsa log dosyası durmadan büyür. Sahada sık gördüğümüz tablo, Full modda çalışan ama hiç log yedeği alınmayan ve log dosyası veri dosyasından birkaç kat büyük olan veritabanlarıdır. Ya Full modda düzenli log yedeği alın ya da işletmenizin ihtiyacına uygunsa Simple modu bilinçli olarak tercih edin. ### Hata 5: Düzenli olarak "shrink" yapmak Veritabanını küçültmek (shrink) ilk bakışta disk tasarrufu gibi görünür. Ancak düzenli shrink, indekslerde ciddi parçalanmaya yol açar ve dosya bir süre sonra yeniden büyüyeceği için hem performans hem de disk tarafında kazanç sağlamaz. Shrink, büyük bir arşivleme sonrasında tek seferlik ve planlı bir işlem olmalıdır. ### Hata 6: Bütünlük kontrolü ve indeks bakımını ihmal etmek Disk veya bellek kaynaklı bozulmalar uzun süre fark edilmeden kalabilir ve bozuk veri yedeklere de taşınır. Düzenli olarak **DBCC CHECKDB** ile bütünlük kontrolü yapmak bu riski azaltır. Ayrıca zamanla parçalanan indekslerin yeniden düzenlenmesi ve istatistiklerin güncellenmesi, raporların ve listelerin yavaşlamasının önüne geçer. Bu işler mesai dışına zamanlanmalı ve sonuçları takip edilmelidir. ### Hata 7: Geri yüklemeyi hiç denememek Yedek dosyasının varlığı, verinin kurtarılabileceği anlamına gelmez. Aylık veya üç aylık periyotlarla yedeği ayrı bir test veritabanına geri yükleyin, Logo'yu bu veritabanına bağlayıp son kayıtları kontrol edin. Geri yüklemenin ne kadar sürdüğünü bilmek, olası bir arızada işletmeye gerçekçi bir süre vermenizi sağlar. ### Hata 8: Güncelleme öncesi yedek almamak Logo sürüm güncellemeleri veritabanı yapısında değişiklik yapabilir. Güncellemeden hemen önce tam yedek alınmalı ve bu yedek, güncelleme sorunsuz tamamlanıp birkaç gün kullanılana kadar saklanmalıdır. Aynı kural SQL Server ve Windows güncellemeleri için de geçerlidir. ### Hata 9: Antivirüs ve güç altyapısını unutmak - Antivirüs yazılımının veritabanı dosyalarını anlık taraması performansı düşürebilir. Üreticinin önerdiği dışlamaları, güvenlik açısından değerlendirerek uygulayın. - Elektrik kesintisinde sunucunun aniden kapanması veritabanı bozulmasına yol açabilir. Kesintisiz güç kaynağı ve kontrollü kapanma ayarı bu risk için temel önlemdir. ### Basit bir bakım planı Sıklıkİş Her günTam veya fark yedeği, yedeğin başka ortama kopyalanması, başarı kontrolü Gün içinde (Full modda)İşlem günlüğü yedekleri Her haftaİndeks ve istatistik bakımı, disk doluluk kontrolü Her hafta veya ayDBCC CHECKDB bütünlük kontrolü Üç ayda birTest ortamına geri yükleme denemesi ### Performans sorunlarında ilk bakılacak yerler Logo'nun yavaşladığı şikâyetlerinde sorun her zaman programda değildir. Sunucu belleğinin yetersiz kalması, disklerin yavaş veya dolu olması, SQL Server'ın tüm belleği kullanacak şekilde ayarlanıp işletim sistemine pay bırakmaması ve ağdaki kablosuz bağlantılar sık rastlanan nedenlerdir. Değişiklik yapmadan önce sorunun hangi saatlerde ve hangi işlemlerde yaşandığını not etmek, doğru teşhisi kolaylaştırır. ### Sonuç Logo veritabanı işletmenin en değerli varlıklarından biri. Express sınırlarının farkında olmak, yedekleri doğru yere almak, kurtarma modelini bilinçli seçmek ve geri yüklemeyi düzenli test etmek, olası bir arızada günler sürecek bir kesintiyi saatlere indirebilir. Ankara'da Logo SQL Server bakımı, yedekleme kurgusu veya performans sorunları için [hizmetlerimizi inceleyebilir](https://ebsbilgisayar.com/hizmetler/), [EBS Bilgisayar ile iletişime geçebilirsiniz](https://ebsbilgisayar.com/iletisim/).