Logo Tiger raporu yavaşladığında nereden başlanır?

Yavaşlık uygulama, veritabanı veya kaynak katmanında olabilir

Bir Logo Tiger raporunun geç tamamlanması tek başına sunucu kapasitesinin yetersiz olduğunu kanıtlamaz. Sorgunun SQL Server’da beklemesi, başka bir işlemin kaynağı tutması, disk yanıtı, ağ gecikmesi, raporun kapsamı veya uygulama tarafındaki işlem sırası sonucu etkileyebilir. Doğru ilk adım, kullanıcı şikâyetinin zamanı ve etkilenen iş akışını belirlemektir.

Rokunet AI-Agent’ın SQL Server kontrolleri servis, veritabanı durumu, disk, yedek, hata kaydı ve uygun erişim bulunduğunda blocking, wait statistics, index veya Query Store gibi bulguların incelenmesine yardımcı olabilir. Her kontrol her ortamda erişilebilir değildir; yetki veya bağlantı yoksa sonuç başarılı gibi gösterilmemelidir.

Kanıta dayalı ilk inceleme

1. Yavaşlayan raporun adını, kullanıcıyı, başlangıç zamanını ve tekrar sıklığını kaydedin.
2. SQL Server ve ilgili veritabanının o zaman aralığındaki durumunu kontrol edin.
3. Blocking veya belirgin beklemeler varsa zaman damgası ve kanıtıyla kaydedin.
4. CPU, bellek, disk, hata kayıtları ve diğer eşzamanlı iş yükleriyle karşılaştırın.
5. Uygulama günlüğü ve sorgu ayrıntısı gerekiyorsa yetkili Logo iş ortağını sürece dahil edin.

Bir örnek bulguyu nasıl yorumlamalı?

Bir raporda toplam çalışma süresinin önemli bölümünün kilit beklemesinde geçtiği görülürse bu, inceleme yönünü belirleyen ölçümdür. Tek başına hangi iş kuralının değişmesi gerektiğini söylemez. Bekleten oturum, sorgu, işlem zamanı ve uygulama bağlamı kontrol edilmelidir. Her müdahale öncesi müşterinin yetkili uygulama sorumlusu ile değişiklik planı netleştirilmelidir.

Rokunet uzman ekibi altyapı ve SQL sağlık bulgularını inceler; Logo lisansı, uygulama iş akışı ve ürün desteği ilgili Logo sağlayıcısı veya iş ortağıyla yürütülür. Logo bulut sunucu hizmeti ve ERP geçiş planı hakkında bilgi alın.

SQL ve sunucu kapsamını görüşelim →

Blocking ve bekleme bulgularını bağlamıyla değerlendirin

Blocking bulgusu, bir oturumun başka bir işlem nedeniyle ilerleyemediği zaman aralığını gösterebilir. Wait statistics ise SQL Server kaynaklarının ne zaman beklediğine dair daha geniş bir işaret verir. Bu iki veri rapor yavaşlığının kesin açıklaması değildir; hangi oturum, sorgu veya iş akışının etkilediği ayrıca incelenmelidir. Query Store veya ayrıntılı sorgu bilgisi yoksa rapor bunu açıkça belirtmelidir.

Ölçüm penceresi önemlidir: sorun geçtikten sonra alınan bir anlık görüntü geçmişteki blocking’i göstermeyebilir. Bu nedenle olay bildiriminin zamanı, SQL sağlık kontrolünün toplandığı zaman ve kullanıcının raporu başlattığı zaman kaydedilmelidir. Destek ekibinin ölçümleri müşteri verisiyle birleştirebilmesi için host, veritabanı ve uygulama sürümü de doğrulanmalıdır.

Örnek senaryo

Bir raporun süresi uzadığında kullanıcı, hangi raporun etkilendiğini ve sorunun ne zaman başladığını bildirir. Uzman ekip aynı aralıkta CPU, disk ve SQL bulgularına bakar. Blocking mevcutsa ilgili oturum ve erişim izinleri kontrol edilir; yoksa bu durum kanıtla belirtilir ve inceleme uygulama, ağ veya istemci katmanına genişletilir. Bu yaklaşım, yalnızca sunucu kaynağını artırma varsayımına dayanmaz.

Rokunet AI-Agent hiçbir sorguyu değiştirmez veya kilidi kendiliğinden sonlandırmaz. Uygulama güncellemesi ya da SQL yapılandırma değişikliği, yetkili müşteri/ERP sağlayıcı onayı ve kontrollü bakım planıyla yürütülür.

Uzman incelemesine hangi bilgileri ekleyin?

Bir destek kaydında rapor adı, kullanıcı, yaklaşık başlangıç zamanı, tekrar sıklığı, ilgili Logo modülü ve hata mesajı yer alsın. Sunucu veya veritabanı adı biliniyorsa ekleyin; kimlik bilgilerini ticket içine yazmayın. Raporun test ortamında mı canlı sistemde mi çalıştığı ve başka kullanıcıların etkilenip etkilenmediği de öncelik kararına yardımcı olur.

Teknik raporda agent telemetrisinin toplama zamanı ile SQL kontrol zamanını ayırın. Yetki olmadığı için sorgu beklemesi veya Query Store bilgisi alınamadıysa bunu yazın. Bir kayıt yokluğu, olayın yaşanmadığını kanıtlamaz; incelemenin hangi veriyle sınırlı kaldığını belirler. Uygulama sağlayıcısına eskale edilirken aynı zaman aralığı ve kanıtlar paylaşılabilir.

Bu yöntem tekrar eden yavaşlıkları zaman içinde karşılaştırmayı ve kaynak artışı kararını daha iyi temellendirmeyi sağlar. Yine de herhangi bir kaynak artışı kalıcı iyileşme garantisi değildir; darboğazın uygulama sorgusu, depolama, ağ veya kullanıcı cihazında olması mümkündür.

Veritabanı ve kullanıcı deneyimini birlikte izleyin

SQL Server’ın sağlık kontrolleriyle kullanıcının şikâyetini aynı zaman çizelgesinde birleştirin. Aynı rapor başka bir kullanıcıda da yavaş mı, yalnızca belirli bir kayıt kümesinde mi, yoğun saatte mi tamamlanıyor? Bu sorular uygulama sağlayıcısına hangi senaryonun inceleneceğini anlatır. Veri tabanı boyutu veya sunucu CPU’su tek başına deneyimi açıklamayabilir.

Bir işlem kilit bekliyorsa, bekleyen oturum ve işlem süresi yetkili veriler mevcutsa incelenir. SQL erişim izni bulunmuyorsa bunu sonuç bölümünde not edin; buna rağmen bağlantı, servis ve temel Windows telemetrisi ayrı kanıt sağlayabilir. Kanıtlar yetersizse belirli bir sorguyu suçlamak doğru değildir.

Üretim ortamında sorgu veya indeks değişikliği, geri dönüş planı ve uygulama sahibinin onayı olmadan yapılmamalıdır. Tanı aşamasını kontrollü değişiklik aşamasından ayrı tutmak, raporun güvenilirliğini korur.