“Kimsenin konuşmadığı performans tuzakları…Sessizce yavaşlamanın anatomisi.”
Bir SAP sistemi genellikle mükemmel bir düzenle başlar.
Tüm parametreler yerli yerindedir, job planları temizdir, raporlar saniyeler içinde çalışır.
Ama yıllar geçtikçe, o ilk günkü çeviklik yerini yavaş bir yorgunluğa bırakır.
Bir pazartesi sabahı, telefonlar çalmaya başlar: “Sistem çok yavaş.”
Bir SAP Basis danışmanı veya IT yöneticisi için bu cümle, haftanın en stresli anlarından biridir. İlk refleks genellikle donanım kaynaklarına bakmaktır. CPU kullanımı tavan mı yaptı? RAM yeterli mi? Disk I/O değerleri normal mi?
Ancak çoğu zaman, göstergeler yeşildir. Sunucular sağlıklı görünür, ancak son kullanıcı ekran başında kum saatinin dönmesini beklemektedir.
Kimse tam olarak nedenini gösteremez.
Çünkü performans düşüşü çoğu zaman aniden değil, sessizce olur.
Tıpkı bir binanın temelinde su sızıntısının yavaş yavaş yapıyı çürütmesi gibi…
Bir SAP sistemi, canlı bir organizma gibidir. Zamanla “metabolizması” yavaşlayabilir, damarları tıkanabilir ve gereksiz yükler biriktirebilir.
Çoğu performans sorunu, yetersiz donanımdan değil; sistem hijyeninin bozulmasından, konfigürasyon körlüğünden veya kötü yazılmış kodlardan kaynaklanır.
Bu yazıda, standart izleme (monitoring) araçlarında genellikle gözden kaçan, ancak SAP sistem performansını arka planda sessizce kemiren 5 temel nedeni ve çözüm yollarını inceleyeceğiz. Teknik detaylara dokunacağız, ama asıl amacımız bir farkındalık yaratmak:
1- Eski Konfigürasyonların Gölgesinde Kalan Sistemler
Bir SAP sistemine dokunan her el, iz bırakır.
Yeni modül devreye alınır, test parametresi eklenir, bir geçici job planlanır…
Ama çoğu zaman bu değişikliklerin ne zaman kaldırıldığı kimsenin aklında kalmaz.
Zamanla, sistemde yüzlerce “zombi” parametre ve job birikir.
Özellikle SM37 ekranında kimsenin sahiplenmediği, çakışan saatlerde (örneğin sabah 09:00’da) çalışan arka plan işleri sistemi fark ettirmeden yavaşlatır.
Bir projede karşılaştığımız klasik bir örnek:
5 yıl önce devreye alınmış, “haftada bir” çalışması gereken bir arşiv job’ı yanlışlıkla “her saat” olarak planlanmıştı.
CPU kullanımı %60’tan %95’e çıkmıştı — kimse nedenini göremiyordu.
💡 Uzman Görüşü
“Batch Window” dediğimiz gece saatleri yerine, mesai saatlerinin en yoğun olduğu (Peak Time) anlarda çalışan ağır raporları tespit edin. Job planlarını 3 ayda bir gözden geçirmeyi bir rutin haline getirin.
2- Veritabanı Şişkinliği: Arşivlenmeyi Bekleyen Tarihi Yükler
Bir başka sessiz düşman: veritabanı hacmi.
SAP sistemleri genellikle “sıcak” ve “soğuk” veriyi aynı potada saklar.
Yıllar içinde IDOC, BALDAT, change log gibi tablolar milyonlarca satıra ulaşır.
Sistem çalışmaya devam eder ama arka planda I/O işlemleri artar, backup süreleri uzar, HANA memory dolmaya başlar.
Bir üretim firmasındaki analizde gördüğümüz tablo:
10 yıl öncesine ait IDOC kayıtları hâlâ canlı sistemdeydi.
Sadece bu tablonun büyüklüğü 480 GB’a ulaşmıştı.
Kullanıcılar “her rapor geç geliyor” diyordu — oysa veritabanı sadece geçmişle meşguldü.
Veri temizliği sadece disk alanını boşaltmaz; veritabanının “düşünme hızını” da artırır.
Neden gizli kalır?
Çünkü veri büyümesi kademeli olur. Günlük 1 GB büyüme 3 yılda 1 TB’a dönüşür.
Kimse fark etmez, ta ki sistem alarm vermeye başlayana kadar.
🚀 Aksiyon Planı:Data Aging veya Data Archiving stratejisi bir lüks değil, zorunluluktur. SAP Cloud ALM veya Solution Manager üzerindeki “Data Volume Management” (DVM) raporları ile büyüme trendlerini izleyin. IDOC, BALDAT, COEP gibi kritik tabloları düzenli olarak temizleyin.
3 – Özelleştirmelerin Yan Etkisi: Zamanla Bozulan Kod Kalitesi
Her SAP sisteminde bir dönem “Z” furyası yaşanır.
İş birimleri süreçlerini hızlandırmak ister, danışmanlar özel raporlar yazar.
Ancak bu “hızlı çözümler” yıllar sonra performans darboğazına dönüşür.
“Z kodları” yaşlanır;
index’ler unutulur, sorgular “SELECT * FROM” şeklinde yazılır, veritabanı satır satır taranır.
Bir noktadan sonra sistemin en büyük yükünü, kullanıcılar değil, bu kod parçaları taşır.
Geçtiğimiz yıl bir müşterimizde yaptığımız SQL Trace (ST05) analizinde,
tek bir Z raporunun tüm CPU’nun %18’ini tükettiğini gördük.
Rapor sadece “müşteri listesi” getiriyordu.
Ama arkasında 10 milyon satırlık bir tabloyu baştan sona okuyordu.
🛠️ Basisci İpucu
Yazılımcı ve Basis uzmanı arasında bir “Kalite Kapısı” (Quality Gate) kurun. Canlıya geçişten önce Code Inspector (SCI) veya ATC (ABAP Test Cockpit) ile performans testleri yapılmasını şart koşun.
Ek Bilgi Kaynağı
SAP log yönetiminde akıllı izleme ve kök neden analiziyle ilgili yeni yaklaşımları keşfetmek için bu makalemize göz atın!
4 – Donanım Yeterli Ama Parametreler Uyumlu Değil
Birçok kurum, sistem yavaşlayınca doğrudan donanım ekler:
“RAM artırdık, CPU takviyesi yaptık, ama hâlâ yavaş!”
Çünkü asıl problem donanımda değil, parametre körlüğündedir.
Sistem büyür ama instance profilleri güncellenmez.
Tampon bellek (buffer) eski boyutlarda kalır.
Sonuç: sistem swap yapar, bellek yetmez, disk kullanımı artar.
Bazen bu durum “intermittent” görünür — sistem bir gün hızlı, ertesi gün yavaş.
Bir müşteride ST02 ekranında buffer utilization %98 idi, ama kimse fark etmemişti.
Donanım güçlüydü, ama bellek yönetimi parametreleri hâlâ 2018 konfigürasyonundaydı.
🔍 Kontrol NoktasıST02 işlem kodu (Tune Summary) sizin stetoskopunuzdur. Burada kırmızıya dönen “Swaps” değerleri görüyorsanız, parametrelerinizin güncel donanım ve yüke göre yeniden optimize edilme vakti gelmiştir. Donanım yetmezliğinin en büyük nedeni, yönetilmeyen bolluktur.
5 – Kullanıcı Davranışlarının Göz Ardı Edilmesi
Son gizli neden teknik değil, insani.
Sistemin yavaşlamasının arkasında bazen yanlış kullanıcı alışkanlıkları yatar.
Örneğin aynı anda 10 kullanıcı aynı raporu çalıştırır,
her biri milyon satırlık veri çeker,
ya da oturumlarını kapatmadan gün boyu açık bırakır.
Bir müşteri örneğinde,
tek bir kullanıcı sabah açtığı FBL3N ekranını gün boyu kapatmamıştı.
Her 10 dakikada bir veri güncellemesi tetikleniyordu.
Günün sonunda sistemde 2.000 aktif session vardı, yarısı “zombi.”
Bir diğer vakada, üçüncü parti bir uygulama SAP’ye dakikada 600 kez RFC çağrısı yapıyordu.
Bu yoğun trafik “lock entry” hatalarına yol açıyor, sistem zaman zaman donuyordu.
💡 Çözüm
- Kullanıcı davranış analitiği izlenmeli (ST03N, workload analizi).
- Otomatik session timeout ve paralel işlem limitleri tanımlanmalı.
- Entegrasyon tarafında RFC çağrıları denetlenmeli, queue sistemi kurulmalı.
Performans, sadece donanım işi değil;
doğru kullanıcı alışkanlıklarıyla desteklenen bir disiplindir.
Proaktif İzleme ve “Sistem Hijyeni”
SAP performans yönetimi, sadece bir kriz anı müdahalesi değil,
sürekli bir iyileştirme kültürüdür.
Performans sorunlarını kullanıcılar şikayet etmeden önce tespit etmek,
reaktif değil proaktif bir IT yönetimi gerektirir.
Tıpkı düzenli sağlık kontrolleri gibi, sistemin de periyodik “check-up”’a ihtiyacı vardır:
- Haftalık job temizlikleri
- Aylık log boyutu kontrolleri
- Yıllık parametre revizyonları
SAP ortamı yaşayan bir ekosistemdir.
Ve bu ekosistemde görünmeyen sorunlar, en sinsi olanlardır.
Gerçek performans artışı; daha güçlü sunucular satın almaktan değil, düzenli housekeeping, arşivleme stratejisi ve kod kalitesi denetiminden geçer. SAP sistemlerinizi sadece izlemeyin, onu anlayın.