ABAP Performans Analizi: ST05, SAT ve SQL Monitor ile Yavaş Programı Bulmak ve Hızlandırmak

"Rapor çok yavaş" şikâyeti geldiğinde ilk refleks genellikle koda bakıp şüpheli görünen bir satırı düzeltmektir. Bazen işe yarar; çoğu zaman ise yarım gün bir döngüyü iyileştirdikten sonra sürenin neredeyse hiç değişmediği görülür, çünkü zaman orada değil, hiç bakılmayan bir veritabanı okumasında harcanıyordur.

Performans çalışması bir tahmin oyunu değil, bir ölçüm işidir. SAP bunun için olgun araçlar sunar ve hepsi standart sistemde gelir. Bu yazıda hangi aracın hangi soruyu cevapladığını, ölçüm sonucunun nasıl okunacağını ve en sık karşılaşılan darboğazların nasıl düzeltileceğini anlatıyorum.

Önce Ölç, Sonra Değiştir

Bir düzeltmenin işe yarayıp yaramadığını söyleyebilmek için önce bir başlangıç ölçümüne ihtiyacınız var. Bu ölçüm üç koşulu sağlamalıdır:

• Gerçekçi veri hacmi: Geliştirme sisteminde yüz kayıtla saniyeler süren bir program, canlıda yüz bin kayıtla saatler sürebilir. Mümkünse canlının yakın tarihli kopyası olan bir test sisteminde ölçün.
• Tekrarlanabilir koşul: Aynı seçim ekranı değerleri, aynı kullanıcı, mümkünse benzer sistem yükü. Seçimi bir varyanta kaydedin.
• İkinci çalıştırma: İlk çalıştırmada tablo tamponları, program tamponu ve veritabanı önbellekleri soğuktur. İlk ve ikinci çalıştırmayı ayrı ayrı not edin; karşılaştırmayı aynı türden çalıştırmalar arasında yapın.

Ölçümü kısa bir notla kayıt altına alın. Sonradan "eskiden ne kadar sürüyordu?" sorusunun cevabı bu not olacak:

Program      : ZSD_ORDER_REPORT (varyant: AYLIK_1000)
Sistem / veri: QAS, canlı kopyası (kopya tarihi: ...)
Çalıştırma   : 2. çalıştırma, ön planda
Toplam süre  : ...
DB süresi    : ...        CPU süresi: ...
SQL özeti    : ... ifade çalıştırması, ... kayıt (ST05)

Hangi Araç Hangi Soruyu Cevaplar?

İlk Bakış: Süre Nereye Gitti?

Analize doğrudan ST05 veya SAT ile başlamak, haritaya bakmadan yola çıkmaya benzer. Önce STAD'daki istatistik kayıtlarıyla toplam yanıt süresinin nasıl bölündüğüne bakın. Kullanıcı, işlem kodu veya program adı ve zaman aralığıyla filtreleyip ilgili çalıştırmayı açtığınızda üç değer belirleyicidir:

• Veritabanı süresi yüksekse: Sorun büyük olasılıkla SQL tarafındadır; ST05 ile devam edin.
• CPU süresi yüksekse: Zaman ABAP kodunda, çoğu zaman iç tablo işlemlerinde geçiyordur; SAT ile devam edin.
• İkisinin toplamı yanıt süresinin çok altındaysa: Program bir şey bekliyordur: RFC çağrısı, dış sistem, kilit, boş iş süreci. Bu durumda kod optimizasyonu değil, bekleme sebebi aranmalıdır.

İstatistik kayıtları sistem ayarına bağlı olarak sınırlı bir süre tutulur. "Dün gece iş çok uzun sürdü" şikâyetinde ilk iş, kayıt silinmeden STAD'a bakmaktır.

ST05 ile SQL İzi

ST05, programın veritabanına gönderdiği her ifadeyi süresi, getirdiği kayıt sayısı ve çağrıldığı ABAP satırıyla birlikte kaydeder. Temel akış şöyledir:

1. ST05'te SQL Trace seçeneğini işaretleyin ve izi filtreyle açın: kullanıcı adı ve mümkünse işlem kodu veya program. Filtresiz iz, aynı sunucudaki herkesin ifadelerini toplar.
2. Programı başka bir oturumda çalıştırın.
3. Program biter bitmez izi kapatın. İz dosyaları sınırlıdır; açık unutulan bir iz, ilgili kayıtların üzerine yazılmasına neden olabilir.
4. İzi görüntüleyin ve tek tek ifadeler yerine yapısal olarak özdeş ifadeler (structure-identical statements) özetine geçin.

İzin, açıldığı uygulama sunucusunda tutulduğunu unutmayın: birden çok uygulama sunucusu olan bir sistemde arka plan işi başka bir sunucuda çalışırsa iz boş kalır.

Özet ekranını okumak

Özet ekranı, aynı yapıdaki ifadeleri tek satırda toplar. Sütunlar sürüme göre küçük farklılıklar gösterse de okunacak şey aynıdır ve dört tipik desen vardır:

Özet ekranında bir ifadeyi seçip Explain ile yürütme planını görebilir, ABAP konumuna atlayarak ifadenin hangi satırdan geldiğini bulabilirsiniz. Satırlar toplam süreye göre sıralandığında, programın veritabanı süresinin büyük kısmının genellikle birkaç ifadede toplandığı görülür; çalışmaya en üstteki ifadeden başlayın.

SAT ile ABAP Tarafını Ölçmek

CPU süresi baskınsa ölçülecek yer ABAP kodudur. SE30'un yerini alan SAT (ABAP Runtime Analysis), programın hangi işlem bloğunda ve hangi ifadede ne kadar zaman harcadığını gösterir.

1. SAT'ta işlem kodunu, programı veya fonksiyon modülünü girin.
2. Bir ölçüm varyantı seçin. Varsayılan varyant çağrı konumuna göre toplama yapar ve iz dosyasını küçük tutar. Çağrı hiyerarşisini görmek istiyorsanız toplamasız (aggregation: none) bir varyant gerekir; bu dosyayı hızla büyütür, ölçümü kısa tutun.
3. Ölçümü çalıştırın. Ekranlı bir programı doğrudan, başka bir kullanıcının veya arka plan işinin çalıştırmasını zamanlanmış ölçümle yakalayabilirsiniz.
4. Değerlendirmede isabet listesini (hit list) net süreye göre sıralayın.

Brüt süre bir metodun ve onun çağırdığı her şeyin toplam süresidir; net süre yalnız o metodun kendi içinde geçen süredir. Brüt süresi yüksek bir metot sadece "sorun bunun altında bir yerde" der; net süresi yüksek bir satır ise doğrudan sorunun kendisidir. Tipik bulgular, büyük bir standart tabloda anahtarsız READ TABLE veya LOOP ... WHERE, iç içe döngüler ve döngü içinde tekrar tekrar sıralanan tablolardır.

ADT kullanıyorsanız aynı ölçümü Eclipse içinden ABAP Profiler ile alabilirsiniz; isabet listesi, çağrı ağacı ve veritabanı erişimleri kaynak koda bağlı görünümlerde açılır. Bir Fiori uygulaması veya OData servisi yavaşsa da yöntem değişmez: istek HTTP ile geldiği için ölçümü kullanıcı filtresiyle açar, ilgili isteği yakalarsınız.

Sahada En Sık Görülen Darboğazlar

Aşağıdaki örnekler klasik SD tablolarıyla yazıldı, çünkü hemen her sistemde bulunurlar. Desenler tablodan bağımsızdır; ABAP Cloud'da aynı mantık tablo yerine released CDS view'larla kurulur.

1. Döngü içinde SELECT

En yaygın ve en pahalı desen budur. Kod okunaklıdır, küçük veriyle hızlıdır ve canlıda yavaşlar:

" Her sipariş için ayrı bir veritabanı turu: 5.000 sipariş = 5.000 SELECT
SELECT vbeln, kunnr, netwr, waerk
  FROM vbak
  WHERE erdat IN @s_erdat
  INTO TABLE @DATA(orders).

LOOP AT orders INTO DATA(order).
  SELECT SINGLE name1 FROM kna1
    WHERE kunnr = @order-kunnr
    INTO @DATA(customer_name).
  " ... çıktı satırını doldur
ENDLOOP.

Her bir SELECT SINGLE hızlı olabilir; sorun, her turun ağ ve veritabanı arayüzü maliyetinin binlerce kez ödenmesidir. Veri aynı veritabanındaysa en temiz çözüm JOIN'dir:

SELECT vbak~vbeln, vbak~kunnr, vbak~netwr, vbak~waerk,
       kna1~name1
  FROM vbak
  INNER JOIN kna1 ON kna1~kunnr = vbak~kunnr
  WHERE vbak~erdat IN @s_erdat
  INTO TABLE @DATA(orders).

2. FOR ALL ENTRIES'in iki tuzağı

Sürücü veri başka bir kaynaktan geliyorsa (bir BAPI sonucu, bir dosya, önceki bir hesaplama) JOIN mümkün değildir. Bu durumda anahtarlar tek seferde FOR ALL ENTRIES ile okunur ve sonuç, döngüde hızlı erişim için hashed tabloya alınır:

TYPES: BEGIN OF ty_customer,
         kunnr TYPE kunnr,
         name1 TYPE name1_gp,
       END OF ty_customer.
DATA customers TYPE HASHED TABLE OF ty_customer WITH UNIQUE KEY kunnr.

" Sürücü tablodaki tekrarları ayıkla
DATA(customer_keys) = orders.
SORT customer_keys BY kunnr.
DELETE ADJACENT DUPLICATES FROM customer_keys COMPARING kunnr.

" Boş sürücü tablo = WHERE koşulu yok sayılır = bütün tablo okunur
IF customer_keys IS NOT INITIAL.
  SELECT kunnr, name1
    FROM kna1
    FOR ALL ENTRIES IN @customer_keys
    WHERE kunnr = @customer_keys-kunnr
    INTO TABLE @customers.
ENDIF.

LOOP AT orders INTO DATA(order).
  ASSIGN customers[ kunnr = order-kunnr ] TO FIELD-SYMBOL(<customer>).
  IF sy-subrc = 0.
    " <customer>-name1 kullanılabilir
  ENDIF.
ENDLOOP.

3. Okunup atılan veri

İkinci büyük desen, veritabanından gereğinden fazla sütun ve satır okuyup elemeyi ve toplamayı ABAP'ta yapmaktır:

" Bütün sütunlar, bütün kalemler uygulama sunucusuna taşınıyor
SELECT * FROM vbap
  WHERE vbeln IN @s_vbeln
  INTO TABLE @DATA(items).

" Filtre veritabanında değil, ABAP'ta
DELETE items WHERE abgru IS NOT INITIAL.

" Toplama da ABAP'ta: döngüde para birimine göre toplanıyor
LOOP AT items INTO DATA(item).
  ...
ENDLOOP.

Aynı sonuç, filtre ve toplama veritabanında yapılarak tek ifadeyle alınır; uygulama sunucusuna yalnız para birimi başına bir satır gelir:

SELECT waerk,
       SUM( netwr ) AS net_total,
       COUNT( * )   AS item_count
  FROM vbap
  WHERE vbeln IN @s_vbeln
    AND abgru = @space
  GROUP BY waerk
  INTO TABLE @DATA(totals).

Seçim ekranı da bu başlığın parçasıdır. Tarih aralığı boş bırakılabilen bir rapor, bir gün mutlaka boş tarihle çalıştırılır. Büyük tablolara giden raporlarda tarih veya organizasyon birimi gibi seçici alanları zorunlu yapmak, en ucuz performans önlemidir.

4. Yanlış iç tablo tipi

SAT'ta net süresi yüksek çıkan satırların çoğu iç tablo aramalarıdır. Standart tabloda anahtarla arama baştan sona taramadır; dıştaki döngüyle çarpıldığında maliyet hızla büyür:

" items: anahtarsız STANDARD TABLE
LOOP AT headers INTO DATA(header).
  " Her başlık için bütün kalem tablosu baştan sona taranıyor
  LOOP AT items INTO DATA(item) WHERE vbeln = header-vbeln.
    " ...
  ENDLOOP.
ENDLOOP.

Tabloyu başka yerlerde sırasıyla kullanmaya devam etmek gerekiyorsa tipini değiştirmek yerine bir ikincil anahtar eklemek yeterlidir:

TYPES: BEGIN OF ty_item,
         vbeln TYPE vbeln_va,
         posnr TYPE posnr_va,
         matnr TYPE matnr,
         netwr TYPE netwr_ap,
         waerk TYPE waerk,
       END OF ty_item.
TYPES ty_items TYPE STANDARD TABLE OF ty_item
               WITH EMPTY KEY
               WITH NON-UNIQUE SORTED KEY by_order COMPONENTS vbeln.
DATA items TYPE ty_items.

LOOP AT headers INTO DATA(header).
  LOOP AT items INTO DATA(item) USING KEY by_order WHERE vbeln = header-vbeln.
    " ...
  ENDLOOP.
ENDLOOP.

Tablo tipi seçiminin ayrıntılarını Clean ABAP kılavuzunda, modern tablo ifadelerini modern ABAP söz dizimi yazısında anlattım.

5. Aynı veriyi tekrar tekrar okumak

ST05'te özdeş oranı yüksek bir ifade, programın aynı soruyu veritabanına tekrar tekrar sorduğunu gösterir. Çoğu zaman okuma, her satır için çağrılan bir metodun veya fonksiyon modülünün içine gömülüdür ve çağrı yapısını değiştirmek kolay değildir. Bu durumda okumayı küçük bir önbellek sınıfının arkasına almak, çağıranlara dokunmadan sorunu çözer:

CLASS lcl_material_texts DEFINITION.
  PUBLIC SECTION.
    METHODS get
      IMPORTING material      TYPE matnr
      RETURNING VALUE(result) TYPE maktx.
  PRIVATE SECTION.
    TYPES: BEGIN OF ty_text,
             matnr TYPE matnr,
             maktx TYPE maktx,
           END OF ty_text.
    DATA texts TYPE HASHED TABLE OF ty_text WITH UNIQUE KEY matnr.
ENDCLASS.

CLASS lcl_material_texts IMPLEMENTATION.
  METHOD get.
    ASSIGN texts[ matnr = material ] TO FIELD-SYMBOL(<text>).
    IF sy-subrc = 0.
      result = <text>-maktx.
      RETURN.
    ENDIF.

    SELECT SINGLE maktx FROM makt
      WHERE matnr = @material
        AND spras = @sy-langu
      INTO @result.

    " Bulunamayan malzemeyi de hatırla; aynı soruyu tekrar sorma
    INSERT VALUE #( matnr = material maktx = result ) INTO TABLE texts.
  ENDMETHOD.
ENDCLASS.

Önbelleğin iki bedeli vardır: bellek ve güncellik. Milyonlarca farklı anahtarla çalışan bir arka plan işinde önbellek sınırsız büyüyebilir; sık değişen veride ise program, çalıştığı süre boyunca eski değeri görür. Ana veri metinleri gibi bir çalıştırma içinde değişmeyen veriler için güvenlidir.

Küçük, sık okunan ve nadiren değişen tablolar (çoğu customizing tablosu) için bir diğer yol, SE11'deki teknik ayarlardan tablo tamponlamadır. Tamponlar uygulama sunucuları arasında gecikmeli eşitlenir; bu yüzden sık değişen veya anlık tutarlılık gerektiren tablolar tamponlanmamalıdır. Bazı SQL yapıları tamponu atlar; tamponun gerçekten kullanıldığını ST05'in tablo tamponu iziyle doğrulayın.

6. Satır satır yazmak

Aynı N+1 problemi yazma tarafında da vardır. Bir iç tablodaki değişiklikleri tek tek veritabanına göndermek yerine dizi işlemi kullanın:

" Satır satır: her kayıt için bir veritabanı turu
LOOP AT changes INTO DATA(change).
  UPDATE zsd_delivery_log FROM @change.
ENDLOOP.

" Toplu: tek ifade
UPDATE zsd_delivery_log FROM TABLE @changes.

7. Belleğe sığmayan hacim

Bir arka plan işi yüz binlerce satır işleyecekse, hepsini tek seferde iç tabloya almak hem belleği zorlar hem de ilk satırın işlenmesini en son satırın okunmasına kadar bekletir. Okumayı paketlere bölün:

DATA item_package TYPE STANDARD TABLE OF ty_item WITH EMPTY KEY.

SELECT vbeln, posnr, matnr, netwr, waerk
  FROM vbap
  WHERE erdat IN @s_erdat
  INTO TABLE @item_package
  PACKAGE SIZE 10000.

  process_items( item_package ).
  " Burada COMMIT WORK yok: veritabanı imleci kapanır, program kısa dökümle durur
ENDSELECT.

Paket döngüsünün içinde kayıt yazmanız ve commit etmeniz gerekiyorsa OPEN CURSOR WITH HOLD ile FETCH NEXT CURSOR ... PACKAGE SIZE kullanılır. Paralel işleme (iş paketlerini birden çok iş sürecine dağıtmak) bir sonraki adımdır, ilk adım değil: verimsiz bir SQL'i paralel çalıştırmak, sorunu çözmez, veritabanına aynı anda daha fazla yük bindirir.

HANA'da Ne Değişti, Ne Değişmedi?

S/4HANA'ya geçen ekiplerde sık duyulan bir cümle vardır: "Artık HANA var, performans sorun olmaz." Kısmen doğrudur; HANA tek tek sorguları çok hızlandırır. Ama bazı kurallar değişmez, bazıları ise daha da önemli hâle gelir:

• Veritabanı turu hâlâ pahalıdır. Her ifadenin ağ ve arayüz maliyeti, sorgu ne kadar hızlı olursa olsun ödenir. Döngü içinde SELECT, HANA'da da en yaygın darboğazdır.
• SELECT * daha pahalıdır. Sütun tabanlı depolamada her sütun ayrı tutulur; gereksiz her sütun ayrıca okunup birleştirilir. Yalnız ihtiyaç duyulan alanları seçmek her zamankinden önemlidir.
• Hesaplamayı veritabanına taşıyın. Filtre, toplama ve JOIN'i ABAP SQL veya CDS ile veritabanında yapmak (code pushdown) HANA'nın asıl gücünü kullanır. ABAP SQL veya CDS ile ifade edilemeyen karmaşık mantık için AMDP vardır; hata ayıklaması ve testi daha zor olduğu için son seçenek olarak görülmelidir.
• İndeks ihtiyacı azalır ama yok olmaz. Sütun tabanlı tablolarda ikincil indekse klasik veritabanlarına göre çok daha az ihtiyaç duyulur. Yine de seçici olmayan bir WHERE koşulu, büyük bir tabloda yavaş kalır.

CDS ile veritabanında toplama yapan rapor örneklerini ACDOCA yazısında, geçiş sırasında özel kodun ATC ile taranmasını S/4HANA geçiş rehberinde bulabilirsiniz.

Canlı Sistemde Ölçmek: SQL Monitor

Bazı sorunlar yalnız canlıda görünür: veri hacmi, eşzamanlı kullanıcılar ve ay sonu yükü test sisteminde yeniden üretilemez. Bu durumda SQL Monitor (SQLM) kullanılır. SQL Monitor, canlıda düşük ek yükle çalışacak şekilde tasarlanmıştır ve her SQL ifadesi için çalıştırma sayısını, toplam ve ortalama süreyi ve getirilen kayıt sayısını, ifadenin hangi program satırından ve hangi giriş noktasından (işlem kodu, rapor, RFC, URL, arka plan işi) geldiğiyle birlikte toplar.

• SQLM'i bir bitiş tarihiyle açın ve önemli dönemi kapsayacak kadar açık tutun; ay sonu sorunları için ay sonunu içeren bir aralık seçin.
• Sonuçları toplam süreye göre sıralayın. Tek başına yavaş bir ifade ile milyonlarca kez çalışan hızlı bir ifade, toplamda aynı yükü oluşturabilir.
• SWLT (SQL Performance Tuning Worklist), SQL Monitor verisini statik kod kontrolü bulgularıyla birleştirir ve "hangi özel kodu önce düzeltmeliyim?" sorusuna önceliklendirilmiş bir liste olarak cevap verir.

Belirtiye Göre İlk Bakılacak Yer

Dış sistem çağrılarının ekranı neden yavaşlattığını ve bu çağrıların ayrı bir adıma nasıl alınacağını SAP entegrasyon senaryoları yazısında anlattım.

Düzeltmeden Sonra: Doğrulama

Hızlı ama yanlış sonuç üreten bir program, yavaş ama doğru olandan daha kötüdür. Her performans düzeltmesi iki soruyla kapanmalıdır:

Aynı desenlerin yeniden girmesini önlemek için ATC'nin (Code Inspector) performans kontrollerini geliştirme sürecine ekleyin. Döngü içinde veritabanı erişimi, tamponu atlayan okumalar ve sorunlu SELECT * kullanımı gibi desenler statik olarak yakalanabilir. Statik kontrol ölçümün yerini tutmaz ama bilinen hataların canlıya taşınmasını engeller.

Sık Yapılan Hatalar

Sonuç

ABAP performans analizi, doğru sırayla sorulan birkaç sorudan ibarettir: Süre nereye gidiyor (STAD)? Veritabanındaysa hangi ifade (ST05)? ABAP'taysa hangi satır (SAT)? Sorun yalnız canlıda mı (SQL Monitor)? Bu sorular cevaplandığında düzeltme çoğu zaman şaşırtıcı derecede küçüktür: bir JOIN, bir hashed tablo, bir ikincil anahtar, veritabanına taşınan bir toplama.

Asıl farkı yaratan, düzeltmenin kendisi değil, düzeltmeden önce ve sonra yapılan ölçümdür. Yavaş raporlar, uzun süren arka plan işleri ve S/4HANA geçişi sonrası özel kod uyarlaması için sunduğum kapsamı SAP geliştirme hizmet sayfasında bulabilirsiniz.