SAP Business One HANA'da Sorgu Optimizasyonu Rehberi

SAP Business One'ın HANA sürümünde yavaş çalışan bir rapor, neredeyse hiçbir zaman "sunucu yetersiz" demek değildir; sorunun kaynağı çoğunlukla sorgunun kendisidir. Gerçek nedenler dar bir listede toplanır: gereksiz kolon çekmek, filtreyi kolonun üzerine fonksiyon yazarak sargable olmaktan çıkarmak, satır satır dönen prosedürler, kardinalitesi düşünülmemiş JOIN'ler ve ölçmeden yapılan "iyileştirme" denemeleri. Optimizasyonun ilk adımı kod değiştirmek değil, hangi ifadenin ne kadar sürdüğünü ölçmektir.

Bu yazı, SAP Business One'ın HANA sürümünü kullanan şirketlerde rapor ve özel sorgu performansı sorunlarını çözerken izlediğimiz sırayı anlatıyor. Hedef okur, B1 üzerinde sorgu ve rapor yazan danışman, BT sorumlusu veya geliştirici.

Ölçmeden optimizasyon yok: teşhis sırası

Performans şikâyeti geldiğinde ilk yaptığımız şey, şikâyeti ölçülebilir bir ifadeye indirgemektir. "Sistem yavaş" bir teşhis değildir; "ay sonu stok değerleme raporu 4 dakikada dönüyor" teşhistir. Bunu ayırt etmenin en hızlı yolu plan önbelleğine bakmaktır:

SELECT TOP 20
  "STATEMENT_STRING",
  "EXECUTION_COUNT",
  "TOTAL_EXECUTION_TIME" / 1000 AS "TOPLAM_MS",
  "AVG_EXECUTION_TIME" / 1000 AS "ORTALAMA_MS"
FROM "M_SQL_PLAN_CACHE"
ORDER BY "TOTAL_EXECUTION_TIME" DESC;

Bu sorgu iki farklı derdi birbirinden ayırır. Tek çalışmada dakikalar süren bir ifade ile saniyede onlarca kez koşan, tek başına hızlı ama toplamda sistemi yiyen bir ifade tamamen farklı çözümler ister. Sahada ikinci tip daha sinsidir: kimse şikâyet etmez, sunucu sürekli meşguldür.

Teşhis sırası şu şekilde ilerler:

1. Plan önbelleği ile en pahalı ifadeleri toplam süreye göre listele.
2. Expensive statements trace'i bir eşik süreyle açıp tekil yavaş ifadeleri yakala; hangi kullanıcının, hangi uygulamadan çalıştırdığı burada görünür.
3. EXPLAIN PLAN ile o ifadenin planını oku; hangi tabloda kaç satır okunduğu, filtrenin ne zaman uygulandığı burada anlaşılır.
4. Plan yetmiyorsa Plan Visualizer ile adım adım süre ve satır sayılarına bak.

EXPLAIN PLAN FOR
SELECT T0."CardCode", SUM(T0."DocTotal")
FROM OINV T0
WHERE T0."DocDate" >= '2026-01-01'
GROUP BY T0."CardCode";

SELECT * FROM "EXPLAIN_PLAN_TABLE";

Bu dört adımı atlayıp doğrudan indeks eklemeye başlayan her çalışma, sahada gördüğümüz kadarıyla ya hiçbir şeyi değiştirmiyor ya da başka bir yeri yavaşlatıyor.

HANA neden farklı davranır

HANA verinin ağırlıklı olarak bellekte ve sütun bazlı tutulduğu bir motordur. Bu mimari üç pratik sonuç doğurur ve optimizasyon kararlarının tamamı bu üç sonuçtan türer.

Birincisi, kolon budama çok değerlidir. Sütun bazlı bir tabloda SELECT * yazmak, ihtiyacınız olmayan onlarca sütunu belleğe açmak demektir. Satır bazlı bir veritabanında bu israf küçüktür; HANA'da doğrudan sorgu süresine yansır. Yalnızca kullandığınız kolonu seçmek, HANA'da en ucuz ve en etkili optimizasyondur.

İkincisi, filtrenin erken uygulanması belirleyicidir. Motor filtreyi mümkün olduğunca aşağı, veriye en yakın katmana iter. Kolonun üzerine yazdığınız her fonksiyon bu itmeyi engeller:

-- kötü: filtre kolonun üzerinde fonksiyonla sarılı
SELECT * FROM OINV T0 WHERE YEAR(T0."DocDate") = 2026;

-- iyi: aralık filtresi, yalnızca gerekli kolonlar
SELECT T0."DocNum", T0."DocDate", T0."CardCode", T0."DocTotal"
FROM OINV T0
WHERE T0."DocDate" >= '2026-01-01'
  AND T0."DocDate" <  '2027-01-01';

Üçüncüsü, toplulaştırma HANA'nın güçlü olduğu iştir. Milyonlarca satırı gruplayıp toplamak motorun doğal işidir; asıl maliyet, toplulaştırmadan önce gereksiz yere büyüttüğünüz ara sonuçtadır. Bu yüzden "önce filtrele, sonra birleştir, en sonda topla" sırası neredeyse her zaman doğru sıradır.

Sahada en sık gördüğümüz kötü desenler

Desen	Neden yavaşlatır	Yerine
SELECT *	Sütun bazlı depoda tüm kolonlar materyalize olur	Yalnızca kullanılan kolonları seç
Kolon üzerinde fonksiyonlu filtre	Filtre aşağı itilemez, tam tarama olur	Aralık veya doğrudan eşitlik filtresi
Satır satır dönen prosedür	Her tur ayrı bir sorgu maliyeti getirir	Küme bazlı tek ifade
Gereksiz JOIN	Kullanılmayan tablo yine de plana girer	Sonuçta kolonu kullanılmayan JOIN'i kaldır
Kardinalitesi yanlış JOIN	Ara sonuç katlanır, bellek şişer	Anahtar alanlar ve çoğaltma riski kontrol edilir
Alt sorgu yığını	Aynı tablo defalarca okunur	Ortak tablo ifadesiyle (WITH) tek okuma

Satır satır dönen prosedür maddesi özellikle önemli, çünkü çoğu zaman iyi niyetli bir "kontrol" ihtiyacından doğuyor:

-- kötü desen: her sipariş için ayrı sorgu
FOR r AS c_orders DO
  SELECT COUNT(*) INTO v_satir FROM RDR1 WHERE "DocEntry" = r."DocEntry";
END FOR;

Aynı iş, tek bir gruplama ifadesiyle karşılaştırılamayacak kadar hızlı yapılır:

SELECT "DocEntry", COUNT(*) AS "SatirSayisi"
FROM RDR1
GROUP BY "DocEntry";

Kural olarak şunu söylüyoruz: HANA üzerinde bir döngü yazdığınızı fark ettiğiniz an durun ve aynı işi küme bazlı ifade edip edemeyeceğinizi sorun. Cevap neredeyse her zaman evet.

İndeks kararı: ne zaman, neye

HANA'da indeks, satır bazlı veritabanlarındaki kadar merkezi bir araç değildir. Sütun deposu zaten sözlük kodlamalı çalışır ve birincil anahtar üzerinde örtük bir yapı vardır; bu yüzden "yavaşlığı indeksle çözelim" refleksi çoğu zaman sonuç vermez.

İndeks eklemeyi yalnızca şu koşullar bir aradayken tartışırız: tablo gerçekten büyük, sorgu tek bir kolon üzerinde çok seçici bir eşitlik filtresi kullanıyor, bu filtre sık çalışıyor ve ölçüm bu adımın darboğaz olduğunu gösteriyor. Dördü birden sağlanmıyorsa indeks, yazma maliyeti ve bellek getiren ama okuma kazandırmayan bir eklentiye dönüşür.

Standart B1 tablolarında indeks eklerken ekstra dikkat gerekir: standart şema üzerinde yapılan değişiklikler sürüm yükseltmelerinde ve destek süreçlerinde soru işareti üretir. Kendi kullanıcı tanımlı tablolarınızda ise eliniz rahattır. Her iki durumda da eklediğiniz her indeksi tarih ve gerekçesiyle kayda geçirin; iki yıl sonra kimsenin hatırlamadığı indeksler, performans çalışmalarının en sık rastlanan enkazıdır.

Modelleme tercihi: görünüm, tablo fonksiyonu, prosedür

Tek bir raporun ötesine geçip tekrar kullanılabilir bir katman kuruyorsanız üç seçenek arasından seçim yaparsınız:

• Hesaplama görünümü (calculation view): Grafik modelleme, filtre aşağı itme ve kolon budama konusunda motorla en uyumlu seçenek. Birden fazla rapora hizmet edecek toplulaştırma katmanları için varsayılanımız budur.
• Tablo fonksiyonu: Parametreli, SQL ile yazılmış ve sorgunun içinden tablo gibi çağrılabilen yapı. Karmaşık mantığı okunur tutarken motorun optimizasyonundan yararlanmak istediğinizde tercih ederiz.
• Saklı prosedür: Yan etkisi olan, adım adım ilerleyen işler için. Salt okuma yapan bir raporu prosedüre gömmek genellikle hatadır; prosedür, içindeki mantığı optimize ediciden kısmen saklar.

Basit bir seçim kuralı: sonuç bir sorgunun içinde kullanılacaksa görünüm veya tablo fonksiyonu, bir işlem yürütülecekse prosedür. Rapor tarafındaki seçenekleri ve hangisinin hangi ihtiyaca oturduğunu SAP Business One raporlama seçenekleri yazısında ayrıca ele aldık.

SAP Business One'a özgü tuzaklar

Genel HANA bilgisi, B1 üzerinde çalışırken yetmiyor; ürünün kendi davranışından doğan birkaç tuzak var:

• Formatlı aramalar (formatted search). Bir alanın her değişiminde tetiklenen sorgu, tek başına hızlı olsa bile gün içinde binlerce kez çalışır. Belge girişi yavaşladı diyen kullanıcıların arkasında sıklıkla bunlar çıkar; plan önbelleğinde yüksek EXECUTION_COUNT ile kendilerini belli ederler.
• Uyarı ve onay sorguları. Zamanlanmış uyarılar ve onay şablonlarındaki sorgular arka planda düzenli koşar. Kimse şikâyet etmediği için yıllarca gözden kaçarlar.
• Crystal rapor içindeki gömülü sorgular. Raporun kendisi değil, içindeki alt raporlar yavaşlatır; her alt rapor satır başına yeniden çalışabilir.
• Şema ve kolon adlandırma. B1 tablolarında kolon adları karışık büyük-küçük harflidir; HANA'da tırnaksız yazıldığında büyük harfe çevrilir ve sorgu kırılır. T0."DocDate" yazımı tercih değil, zorunluluktur.
• Entegrasyon yükü. Yoğun API trafiği veritabanına da yansır; entegrasyonun sorgu desenini Service Layer tarafında alan bazlı ve sayfalı kurgulamak, veritabanı tarafındaki yükü doğrudan azaltır.

Son bir ilke: her optimizasyonu ölçümle kapatın. Değişiklik öncesi ve sonrası süreleri aynı koşullarda kaydedilmemiş bir iyileştirme, iyileştirme değil inançtır. Canlı sistemlerde bu ölçümleri düzenli sağlık kontrollerinin parçası olarak teknik destek kapsamında yürütüyoruz; performans sorunlarının çoğu, biriktirilmeden yakalandığında birkaç saatlik iştir.

Sık sorulan sorular

HANA'ya geçtik ama raporlarımız hâlâ yavaş, neden?

Çünkü motor değişikliği kötü yazılmış bir sorguyu düzeltmez; yalnızca aynı hatayı daha hızlı bir donanımda tekrarlar. En sık neden, SQL Server döneminden taşınan ve kolon üzerinde fonksiyonlu filtre, SELECT * veya gereksiz JOIN içeren raporlardır. Geçiş sonrası ilk iş, en pahalı yirmi ifadeyi plan önbelleğinden çıkarıp tek tek gözden geçirmek olmalıdır.

SAP Business One'da standart tablolara indeks eklemek güvenli mi?

Teknik olarak mümkün ama varsayılan tercihimiz değil. Standart şemada yapılan değişiklikler sürüm yükseltmelerinde ve destek süreçlerinde tartışma konusu olur. Önce sorguyu düzeltmeyi deneriz; indeks, ölçümle kanıtlanmış ve başka yolu kalmamış durumlarda, kayıt altına alınarak eklenir.

Sorgunun gerçekte ne kadar sürdüğünü nasıl ölçerim?

En hızlı yol M_SQL_PLAN_CACHE görünümünden toplam ve ortalama süreye bakmaktır; tekil yavaş ifadeler için expensive statements trace'i bir eşik süreyle açmak gerekir. Tek bir ifadeyi derinlemesine anlamak istediğinizde EXPLAIN PLAN ile plana, yetmezse Plan Visualizer ile adım bazlı sürelere inersiniz.

Belge girişi yavaşladıysa suçlu rapor sorguları olabilir mi?

Evet ve bu, gözden en çok kaçan senaryodur. Formatlı aramalar, uyarı sorguları ve arka planda çalışan entegrasyonlar kullanıcı ekranını yavaşlatabilir. Plan önbelleğinde çalışma sayısı yüksek, tekil süresi düşük ifadeleri aramak bu tip sorunu hızla ortaya çıkarır.

Optimizasyon için sunucuyu büyütmek çözüm değil mi?

Bellek ve çekirdek eklemek bazı darboğazları geçici olarak rahatlatır ama yapısal sorunu çözmez; ölçmeden yapılan donanım yatırımı, yanlış yere harcanan bütçe olma riskini taşır. Doğru sıra önce ölçmek, sonra sorguyu düzeltmek, gerekiyorsa modeli değiştirmek, en sonda donanımı konuşmaktır.