Logo Veritabanı Yavaşladı mı? SQL Server Tarafında Kontrol Listesi

Kısaca: Logo veritabanı yavaşladı diye düşünüyorsanız önce yavaşlığın tek bir ekranda mı, yoksa tüm kullanıcılarda mı olduğunu ayırın. Sonra SQL Server tarafında sırasıyla sürüm sınırlarını, bellek ayarını, disk beklemelerini, kilitlenmeleri, istatistikleri ve indeksleri kontrol edin. Her değişiklikten önce ve sonra ölçüm alın.

Logo Edge T-Series (eski adıyla Logo Tiger 3) ve Logo Edge N-Series (eski adıyla Logo Netsis 3) kurulumlarında şirket verisi Microsoft SQL Server veritabanında tutulur. Fatura kaydı uzadığında, rapor dakikalarca açılmadığında ya da ay sonunda ekranlar donduğunda ilk akla gelen cümle “sunucu yetmiyor” olur. Logo iş ortağı olarak projelerimizde gördüğümüz tablo çoğu zaman farklıdır: donanımdan önce ayar, bakım ve kilitlenme sorunları çıkar. Bu yazıda sizin ya da BT ekibinizin sırayla uygulayabileceği bir kontrol listesi bulacaksınız.

İçindekiler

• Logo yavaşlığı gerçekten veritabanından mı geliyor?
• Değiştirmeden önce ölçün
• Logo veritabanı yavaşladı: SQL Server kontrol listesi
• Belirtiden kaynağa: hızlı teşhis tablosu
• Yavaşlığı büyüten 5 hatalı müdahale
• Ne zaman destek almalısınız?
• Özet

Logo yavaşlığı gerçekten veritabanından mı geliyor?

SQL Server, Microsoft’un ilişkisel veritabanı yönetim sistemidir. Logo ürünleri kayıtları bu sistemdeki tablolara yazar ve raporları bu tablolardan okur.

Yavaşlığın kaynağı her zaman veritabanı değildir. Ağ, terminal sunucusu, istemci bilgisayar veya tek bir rapor tasarımı da aynı belirtiyi verir. Kontrol listesine geçmeden önce şu üç soruyu yanıtlayın:

• Nerede? Tek bir ekran veya rapor mu yavaş, yoksa tüm modüller mi?
• Kimde? Tek kullanıcı mı etkileniyor, yoksa herkes mi? Uzak şubedeki kullanıcılar daha mı çok şikâyetçi?
• Ne zaman? Belirli saatlerde mi (yedekleme, toplu aktarım, ay sonu), yoksa gün boyu mu?

Tek kullanıcı ve tek bilgisayar etkileniyorsa önce istemciye ve ağa bakın. Herkes, her modülde ve aynı saatlerde yavaşlıyorsa sorun büyük olasılıkla SQL Server tarafındadır. Yalnızca bir rapor yavaşsa raporun filtreleri ve tarih aralığı ilk şüphelidir.

Değiştirmeden önce ölçün

En sık gördüğümüz hata, ölçmeden ayar değiştirmektir. Üç değişiklik birden yapıldığında hangisinin işe yaradığı, hangisinin işleri bozduğu anlaşılmaz. Şu sırayı izleyin:

1. Yavaş işlemi not edin: hangi ekran, hangi rapor, hangi saat ve ne kadar sürdü.
2. SQL Server’ın bekleme istatistiklerini (wait statistics) ve en çok kaynak tüketen sorguları kaydedin.
3. Tek bir değişiklik yapın.
4. Aynı işlemi aynı koşulda tekrar ölçün ve karşılaştırın.

Bu iş için Query Store kullanışlıdır. Query Store, sorguların çalışma sürelerini ve planlarını veritabanının içinde saklar. Böylece önceki ve sonraki durumu yan yana görebilirsiniz. Microsoft’un Query Store belgesine göre bu özellik SQL Server 2022 ile oluşturulan yeni veritabanlarında varsayılan olarak açıktır. Daha eski sürümlerde elle açmanız gerekir.

Logo veritabanı yavaşladı: SQL Server kontrol listesi

Aşağıdaki sekiz adımı sırayla uygulayın. İlk adımlar hızlıdır ve çoğu zaman sorunu tek başına açıklar.

1. SQL Server sürümü ve sınırları

Kurulumun hangi SQL Server sürümünde (edition) çalıştığını kontrol edin. Ücretsiz Express sürümünün belirgin sınırları vardır. Microsoft’un SQL Server 2022 sürüm karşılaştırmasına göre Express sürümünde bir veritabanı en fazla 10 GB olabilir, arabellek havuzu (buffer pool) en fazla 1.410 MB bellek kullanır ve işlemci kullanımı 1 soket veya 4 çekirdekten küçük olanla sınırlıdır. Şirket verisi büyüdükçe bu sınırlar yavaşlığın doğrudan nedeni olabilir. Sürüm değiştirmek ise planlama gerektiren bir proje işidir.

2. Bellek ayarı (max server memory)

SQL Server, varsayılan ayarda sunucudaki belleğin neredeyse tamamını kullanabilir. “max server memory” ayarının varsayılan değeri 2.147.483.647 MB’tır. Aynı sunucuda Logo uygulama servisleri, terminal oturumları veya başka yazılımlar da çalışıyorsa bellek yarışı başlar. Microsoft’un sunucu belleği yapılandırma belgesi, diğer işlemlerin kullanmadığı belleğin yaklaşık yüzde 75’ini SQL Server’a ayırmayı önerir. Ayarı değiştirmeden önce sunucuda başka neyin çalıştığını listeleyin.

3. Disk ve bekleme türleri

SQL Server bir görevi bekletirken bunun nedenini kaydeder. sys.dm_os_wait_stats görünümünde öne çıkan bekleme türleri size yön gösterir:

• PAGEIOLATCH_SH ve PAGEIOLATCH_EX: Veri sayfaları diskten okunurken beklenir. Uzun sürüyorsa disk alt sistemine bakın. Bellek azsa sayfalar daha sık diskten okunur ve bu bekleme de artar.
• WRITELOG: İşlem günlüğünün (log) diske yazılması beklenir. Log dosyasının bulunduğu diskin gecikmesini kontrol edin.
• LCK_M_ ile başlayanlar: Kilit beklenir. Sorun diskte değil, aynı anda çalışan işlemlerdedir.

Veri dosyaları, log dosyası ve tempdb’nin aynı yavaş diskte durması, projelerimizde sık karşılaştığımız bir durumdur.

4. Kilitlenmeler (blocking)

Bir kullanıcı uzun süren bir işlem başlattığında, aynı kayıtlara erişmek isteyen diğer kullanıcılar bekler. Kullanıcı bunu “Logo dondu” diye anlatır. SQL Server Management Studio’daki Activity Monitor’de “Blocked By” sütununa veya sys.dm_exec_requests görünümündeki blocking_session_id alanına bakın. Sıfırdan farklı bir değer, o oturumun başka bir oturumu beklediğini gösterir. Zinciri başlatan oturumu bulun. Bu çoğu zaman uzun bir rapor, toplu bir aktarım ya da açık bırakılmış bir işlemdir. Ayrıntılar için SQL kilitlenmeleri yazımıza bakabilirsiniz.

5. İstatistikler

SQL Server sorgu planını, tablolardaki veri dağılımını özetleyen istatistiklere göre seçer. Toplu veri aktarımından veya yoğun bir dönem sonundan sonra istatistikler eskiyebilir ve sorgu kötü bir plan seçer. Microsoft’un indeks bakımı belgesine göre indeksi yeniden oluşturmanın (rebuild) sağladığı iyileşme çoğu zaman istatistiklerin güncellenmesinden gelir. İstatistik güncellemek ise çok daha az kaynak tüketir. Bu yüzden önce istatistik bakımını planlayın.

6. İndeksler

İndeks parçalanmasını (fragmentation) sys.dm_db_index_physical_stats ile ölçün. Microsoft, bakım kararını yalnızca sabit bir parçalanma eşiğine göre vermemeyi, etkisini ölçerek karar vermeyi önerir. Her gece tüm indeksleri yeniden oluşturmak yerine, ölçtüğünüz ve etkisini gördüğünüz indekslere odaklanın. Logo tablolarına kendi başınıza yeni indeks eklemeyin; bu kararı iş ortağınızla ve önce test ortamında verin. Bakım yöntemlerini SQL Server indeks bakımı yazımızda karşılaştırdık.

7. tempdb

tempdb, SQL Server’ın geçici çalışma alanıdır. Sıralama, gruplama ve büyük raporlar burayı yoğun kullanır. Microsoft’un tempdb belgesine göre 8 veya daha az mantıksal işlemcide işlemci sayısı kadar, daha fazlasında 8 veri dosyası ile başlanır. Çekişme sürerse dosya sayısı dörder dörder artırılır. Dosyaların aynı başlangıç boyutuna ve aynı büyüme ayarına sahip olması gerekir.

8. Veri ve log dosyaları

Dosyaların otomatik büyüme (autogrowth) ayarlarına bakın. Çok küçük adımlarla büyüyen bir log dosyası, yoğun saatlerde sık sık büyüme beklemesi yaratır. AUTO_SHRINK seçeneğinin kapalı olduğundan emin olun; Microsoft’a göre sık küçülme ve büyüme fiziksel parçalanmaya yol açar. Kurtarma modeli tam (FULL) ise düzenli log yedeği alındığını da doğrulayın. Aksi halde log dosyası büyümeye devam eder.

Kısa kontrol listesi:

• Yavaş işlem, saat ve süre not edildi mi?
• SQL Server sürümü ve sınırları biliniyor mu?
• max server memory sunucudaki diğer işler düşünülerek ayarlandı mı?
• En çok görülen bekleme türleri kaydedildi mi?
• Kilitlenme zincirini başlatan oturum bulundu mu?
• İstatistik bakımı planlı mı?
• İndeks bakımı ölçüme göre mi yapılıyor?
• tempdb dosyaları eşit boyutta ve hızlı diskte mi?
• AUTO_SHRINK kapalı, log yedeği düzenli mi?

Belirtiden kaynağa: hızlı teşhis tablosu

Belirti	Muhtemel kaynak	İlk kontrol
Tüm ekranlar gün boyu yavaş	Bellek, disk veya sürüm sınırları	max server memory, bekleme türleri, SQL Server sürümü
Belirli saatlerde herkes donuyor	Kilitlenme, yedekleme veya bakım işi	blocking_session_id, zamanlanmış işlerin saatleri
Tek bir rapor çok yavaş	Eski istatistik, geniş tarih aralığı	Rapor filtreleri, istatistiklerin güncelliği
Toplu aktarımdan sonra yavaşlama	İstatistikler eskidi	İstatistik güncelleme, önce ve sonra ölçümü
Yalnızca uzak şube yavaş	Ağ veya terminal sunucusu	Ağ gecikmesi, oturum kaynakları
Log diski sürekli doluyor	Log yedeği yok, küçük büyüme adımı	Kurtarma modeli, log yedeği planı

Yavaşlığı büyüten 5 hatalı müdahale

• Veritabanını düzenli küçültmek (shrink): Dosya yeniden büyür ve parçalanma artar.
• Her gece tüm indeksleri yeniden oluşturmak: Uzun sürer, log dosyasını büyütür ve etkisi ölçülmez.
• Logo tablolarına test etmeden indeks eklemek veya veriyi SQL ile doğrudan değiştirmek: Ürün güncellemelerinde ve iş kurallarında sorun çıkarabilir.
• Yalnızca donanım eklemek: Kilitlenme veya eski istatistik varsa yeni sunucu da yavaş kalır.
• Aynı anda birden çok ayarı değiştirmek: Neyin işe yaradığını bilemezsiniz.

Ne zaman destek almalısınız?

Bu kontroller size yön gösterir, ama her ortam farklıdır. Kilitlenme zinciri her gün tekrarlanıyorsa, bekleme türleri disk ile bellek arasında net ayrışmıyorsa ya da sürüm değişikliği ve sunucu taşıma gündemdeyse uzman desteği zaman kazandırır. Logo tarafındaki parametreler, kullanıcı ve modül yapısı için ERP danışmanlığı ekibimizle çalışabilirsiniz. SQL Server ayarları, bakım planı ve izleme için SQL danışmanlığı hizmetimiz devreye girer. Henüz ürün seçimi aşamasındaysanız Logo Edge T-Series mi N-Series mi yazımız karar vermenize yardımcı olur.

Özet

Logo yavaşladığında ilk iş, sorunun nerede, kimde ve ne zaman olduğunu ayırmaktır. Sorun veritabanındaysa sürüm sınırlarından başlayın; bellek, disk beklemeleri, kilitlenmeler, istatistikler, indeksler, tempdb ve dosya ayarlarıyla devam edin. Her adımda önce ölçün, tek değişiklik yapın, sonra tekrar ölçün. ÇAP Teknoloji olarak Logo kurulumunuzun SQL Server tarafını sizinle birlikte inceleyebiliriz; iletişim sayfamızdan bize yazın.

Sıkça Sorulan Sorular