Kısa cevap: Netsis’te rapor yavaşlığının en sık sebebi, geniş tarih aralığıyla çekilen filtresiz sorguların indeks eksikliği ve güncel olmayan istatistiklerle birleşmesidir. Tarih aralığını daraltmak, düzenli indeks/istatistik bakımı yapmak ve ağır raporları mesai dışına planlamak çoğu kurulumda rapor sürelerini belirgin biçimde kısaltır.
Netsis genel olarak akıcı çalışıyor ama rapor almaya kalkınca dakikalarca bekliyor musunuz? Bu makale özellikle rapor tarafındaki yavaşlığa odaklanıyor. Programın açılışı da yavaşsa o ayrı bir konudur; onun için Netsis açılış yavaşlığı çözümü yazımıza bakın.
Belirtiler: Sorun Gerçekten Raporda mı?
Önce sorunun kaynağını doğru teşhis edin:
- Sadece belirli raporlar yavaş, diğer ekranlar normal → sorgu/rapor tasarımı kaynaklı
- Tüm raporlar ve listeler yavaş → veritabanı bakımı (indeks/istatistik) kaynaklı
- Rapor sadece belli saatlerde yavaş → eşzamanlı yük veya zamanlanmış işler kaynaklı
- Rapor bir kullanıcıda yavaş, diğerinde normal → istemci PC veya ağ kaynaklı
Rapor Yavaşlığının 7 Yaygın Sebebi
- Geniş tarih aralığı: Yılların tamamını kapsayan hareket raporları milyonlarca satırı taramak zorunda kalır.
- İndeks eksikliği ve fragmantasyon: Rapor sorgularının kullandığı kolonlarda indeks yoksa SQL Server tüm tabloyu tarar.
- Güncel olmayan istatistikler: SQL Server yanlış sorgu planı seçer; aynı rapor bir gün hızlı, ertesi gün yavaş çalışır.
- tempdb darboğazı: Büyük sıralama ve gruplama işlemleri tempdb’ye taşar; tempdb yanlış diskte veya küçük boyutluysa her büyük rapor bu darboğaza takılır.
- Rapor tasarımı: Çok sayıda alt rapor, satır bazında çalışan formüller ve gereksiz alanlar süreyi katlar.
- Ağ ve istemci: Şubeden yavaş hatla bağlanan istemcilerde büyük rapor sonuçlarının taşınması uzar.
- Mesai saatinde ağır rapor: Herkes fatura keserken çekilen yıllık maliyet raporu hem kendisi yavaşlar hem sistemi yavaşlatır.
Adım Adım Çözüm
1. Tarih Aralığını ve Filtreleri Daraltın
En hızlı kazanım: raporu ihtiyaç kadar dönemle çalıştırın. Yıllık analiz gerekiyorsa aylık parçalar halinde alın veya mesai dışına planlayın.
2. İndeks ve İstatistik Bakımı Yapın
Rapor yavaşlığında en kalıcı çözüm düzenli veritabanı bakımıdır:
-- Fragmantasyon durumunu görüntüleme
SELECT OBJECT_NAME(ips.object_id) AS tablo,
ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
WHERE ips.avg_fragmentation_in_percent > 30;
-- İstatistikleri güncelleme
EXEC sp_updatestats;Kapsamlı bakım adımları için SQL Server performans optimizasyonu rehberimize bakın.
3. Eksik İndeksleri Tespit Edin
SELECT TOP 10 mid.statement, migs.avg_user_impact
FROM sys.dm_db_missing_index_details mid
JOIN sys.dm_db_missing_index_groups mig ON mid.index_handle = mig.index_handle
JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
ORDER BY migs.avg_user_impact DESC;Dikkat: Netsis tablolarına indeks eklemek sürüm güncellemelerinde ve destek süreçlerinde sorun çıkarabilir. Ekleme kararını mutlaka Netsis veritabanı yapısını bilen bir uzmanla birlikte verin.
4. Ağır Raporları Mesai Dışına Planlayın
Yıllık maliyet, envanter ve mutabakat raporlarını sabah erken veya akşam saatlerine kaydırın. Yoğun saatte çalıştırılan ağır bir rapor diğer kullanıcıların ekranlarını da kilitleyebilir.
5. Rapor Tasarımını Sadeleştirin
Özel tasarlanmış raporlarda alt rapor sayısını azaltın, kullanılmayan alanları kaldırın, hesaplamaları mümkünse SQL tarafına taşıyın. Rapor hiç açılmıyor veya hata veriyorsa Crystal Reports hatası yazımızdaki adımları izleyin.
6. Sunucu Kaynaklarını Kontrol Edin
Rapor çalışırken sunucuda CPU, RAM ve disk kuyruğunu izleyin. Disk sürekli %100 ise SSD’ye geçiş ve RAM artırımı değerlendirilmelidir. Sunucuda Netsis dışında çalışan başka yazılımlar (mail sunucusu, dosya paylaşımı, yedekleme aracı) varsa rapor saatlerinde bu servislerin kaynak tüketimini de gözlemleyin; rapor yavaşlığının kaynağı bazen Netsis’in kendisi değil, aynı saatte çalışan zamanlanmış bir yedek işidir.
7. Eski Dönem Verisini Ayırın
Yıllar içinde büyüyen hareket tabloları, güncel dönem raporlarını bile yavaşlatır. Kullanılmayan eski dönemlerin arşivlenmesi veya raporların dönem bazlı şirketler üzerinden alınması, tarama yükünü kalıcı olarak düşürür. Arşivleme kararı devir ve denetim gereksinimleriyle birlikte planlanmalıdır; bu adımı muhasebe ekibinizle koordineli yürütün.
Hızlı Kontrol Listesi
- ✅ Tarih aralığı ihtiyaç kadar mı?
- ✅ Aylık indeks bakımı yapılıyor mu?
- ✅ İstatistikler düzenli güncelleniyor mu?
- ✅ tempdb ayrı ve yeterli boyutta mı?
- ✅ Ağır raporlar mesai dışında mı?
- ✅ Özel raporlarda gereksiz alt rapor var mı?
Sıkça Sorulan Sorular
Rapor yavaşlığı ile program açılış yavaşlığı aynı sorun mu?
Hayır. Açılış yavaşlığı genellikle genel veritabanı bakımı, disk ve ağ kaynaklıdır; rapor yavaşlığı ise çoğunlukla sorgu kapsamı, indeks ve rapor tasarımı kaynaklıdır. Teşhis ve çözüm adımları farklıdır, bu yüzden iki konuyu ayrı ele alıyoruz.
Aynı rapor neden bazen hızlı bazen çok yavaş açılıyor?
En sık sebep güncel olmayan istatistikler yüzünden SQL Server’ın farklı (ve kötü) bir sorgu planı seçmesidir. Düzenli istatistik güncellemesi bu dalgalanmayı büyük ölçüde giderir. Eşzamanlı yük de (yoğun saatte kilit beklemeleri) aynı belirtiyi verir.
Netsis tablolarına kendim indeks ekleyebilir miyim?
Teknik olarak mümkündür ancak önerilmez. Yanlış indeks kayıt işlemlerini yavaşlatabilir, sürüm güncellemelerinde çakışma çıkarabilir. Eksik indeks raporunu çıkarıp uygulamayı Netsis veritabanı deneyimi olan bir ekiple yapmak en güvenlisidir.
Rapor yavaşlığı için hangi durumda profesyonel destek almalıyız?
Tarih aralığı daraltma ve temel bakım sonrası yavaşlık sürüyorsa, sorun eksik indeks, sorgu planı veya donanım boyutlandırması gibi uzmanlık gerektiren katmandadır. Bu noktada Netsis destek ekibimizden yerinde veya uzaktan analiz alabilirsiniz; 10+ yıllık saha deneyimimizle yavaşlığın kök nedenini raporlayıp kalıcı çözüm uyguluyoruz.
Raporlar normal ama ekranlardaki listeler (grid) yavaş; aynı sorun mu?
Büyük ölçüde evet: liste ekranları da arka planda sorgu çalıştırır ve aynı indeks/istatistik bakımından beslenir. Ek olarak liste ekranlarında varsayılan filtre olmadan tüm kayıtların çekilmesi yaygın bir sebeptir; kullanıcıları liste ekranlarını tarih veya kod filtresiyle açmaya yönlendirmek, hem ekran hem sunucu yükünü azaltır.