24. April 2017
Cihan Toraman
0

Speicheroptimierung in der SAP-Entwicklung

Der Shared Memory ist ein Bereich vom Anwendungspuffer des Applikationsservers und kann als Zwischenablage für große Datenmengen genutzt werden. Dieser Artikel behandelt die explizite Ablage von Daten im transaktionsübergreifenden Anwendungspuffer mittels der Anweisung EXPORT TO SHARED BUFFER.

In einem Report (nachfolgend bezeichnet als Hauptprogramm) haben Sie mittels Array-Fetch eine sehr große Anzahl an Daten selektiert und möchten diese Informationen an einen oder zwei weitere Reports (nachfolgend bezeichnet als Programm A und Programm B) übergeben. Die Verarbeitung der Daten soll in Programm A und B erfolgen.

Ist die Anzahl der Daten die Sie übergeben möchten, kleiner oder gleich 10.000 Einträge, so haben Sie zum Beispiel die Möglichkeit mittels der Anweisung SUBMIT die Informationen über den VIA SELECTION SCREEN-Zusatz weiterzugeben. Übersteigt jedoch die Anzahl der Daten 10.000 Einträge, so besteht u.a. die Möglichkeit andere Technologien wie den Shared Memory zu benutzen, um diesen Bereich als Zwischenablage nutzen zu können.

sap-shared-memory-saxonia-systems

Shared Memory Einstellungen

Die beiden Anwendungspuffer Shared Memory und Shared Buffer können mit Profilparametern konfiguriert werden. Einstellungen, die den Shared Memory-Bereich betreffen, werden über den Profilparameter rsdb/esm/buffersize_kb vorgenommen. Der Profilparameter rsdb/obj/buffersize stellt den Shared Buffer-Bereich ein. Diese beiden Speicherbereiche unterscheiden sich darin, wie sie sich beim Erreichen der Speichergrenze verhalten. Wird die Höchstgrenze des Puffers im Shared Memory-Bereich erreicht, so sollte vor einem erneuten Export mit der Sprachanweisung DELETE FROM SHARED MEMORY der Puffer geleert werden. Wird dieser Schritt vernachlässigt kommt es zu der behandelbaren Ausnahme EXPORT_NO_SHARED_MEMORY.

Im Shared Buffer-Bereich hingegen wird der Speicher in einem Verdrängungsverfahren geleert. Ich möchte Ihnen Anhand eines Beispiels vorführen, wie dieser spezielle Speicherbereich optimal genutzt werden kann.

Hauptprogramm

REPORT zshm_hauptprogramm.

DATA: lt_tadir      TYPE TABLE OF tadir,
      lt_split1     TYPE TABLE OF tadir,
      lt_split2     TYPE TABLE OF tadir,
      lv_key        TYPE c LENGTH 60,
      lx_err        TYPE REF TO cx_sy_export_buffer_no_memory,
      ls_out_params TYPE pri_params,
      lv_jobname    TYPE tbtcjob-jobname,
      lv_jobcount   TYPE tbtcjob-jobcount,
      lv_submit     TYPE c LENGTH 20.

FIELD-SYMBOLS <fs_tadir> TYPE tadir.

START-OF-SELECTION.

* die zu übermittelnden Daten in lt_tadir lesen
  SELECT * FROM tadir INTO TABLE lt_tadir
    UP TO 40000 ROWS.

  lt_split1 = VALUE #( ( LINES OF lt_tadir TO   20000 ) ).
  lt_split2 = VALUE #( ( LINES OF lt_tadir FROM 20001 ) ).
  FREE lt_tadir.

* Programm A und Programm B starten
  DO 2 TIMES.
    CLEAR: ls_out_params, lv_jobname, lv_jobcount, lt_tadir.

    CASE sy-index.
      WHEN 1.
        lv_jobname = 'PROGRAM_A'.
        lv_submit  = 'ZSHM_PROGRAMM_A'.
        lv_key     = 'TEST20161201_A'.
        lt_tadir   = lt_split1.
      WHEN 2.
        lv_jobname = 'PROGRAM_B'.
        lv_submit  = 'ZSHM_PROGRAMM_B'.
        lv_key     = 'TEST20161201_B'.
        lt_tadir   = lt_split2.
    ENDCASE.

    TRY .
        EXPORT it_tadir = lt_tadir TO SHARED BUFFER indx(st) ID lv_key.
      CATCH cx_sy_export_buffer_no_memory INTO lx_err.
*       Fehlerbehandlung
        EXIT.
    ENDTRY.

*   Spool Druckparameter und Archivparameter lesen
    CALL FUNCTION 'GET_PRINT_PARAMETERS'
      EXPORTING
        no_dialog      = abap_true
      IMPORTING
        out_parameters = ls_out_params.

*   Eröffnen einer dialoglosen Job-Einplanung
    CALL FUNCTION 'JOB_OPEN'
      EXPORTING
        jobname  = lv_jobname
      IMPORTING
        jobcount = lv_jobcount.

    SUBMIT (lv_submit) VIA JOB lv_jobname
                       NUMBER  lv_jobcount
    TO SAP-SPOOL WITHOUT SPOOL 
    DYNPRO SPOOL PARAMETERS ls_out_params AND RETURN.

*   Hintergrundauftrag abschliessen
    CALL FUNCTION 'JOB_CLOSE'
      EXPORTING
        jobcount  = lv_jobcount
        jobname   = lv_jobname
        strtimmed = abap_true.
  ENDDO.

Programm A

REPORT zshm_programm_a.

DATA: it_tadir TYPE TABLE OF tadir,
      lv_key   TYPE c LENGTH 60,
      lv_count TYPE i.

lv_key = 'TEST20161201_A'.
IMPORT it_tadir = it_tadir FROM SHARED BUFFER indx(st) ID lv_key.
IF sy-subrc EQ 0.
  DELETE FROM SHARED BUFFER indx(st) ID lv_key.
ENDIF.

lv_count = lines( it_tadir ).
WRITE lv_count.

Programm B

REPORT zshm_programm_b.

DATA: it_tadir TYPE TABLE OF tadir,
      lv_key   TYPE c LENGTH 60,
      lv_count TYPE i.

lv_key = 'TEST20161201_B'.
IMPORT it_tadir = it_tadir FROM SHARED BUFFER indx(st) ID lv_key.
IF sy-subrc EQ 0.
  DELETE FROM SHARED BUFFER indx(st) ID lv_key.
ENDIF.

lv_count = lines( it_tadir ).
WRITE lv_count.

Ablauf

Im Hauptprogramm werden aus der Datenbanktabelle TADIR 40.000 Beispiel-Datensätze in die interne Tabelle lt_tadir gelesen. Würden Sie diese jetzt mit Hilfe der Anweisung EXPORTTO SHARED BUFFERID in den Shared Buffer schreiben, würde es zu der behandelbaren Ausnahme EXPORT_BUFFER_NO_MEMORY kommen, da der Speicher laut aktueller Konfiguration – dies ist in jedem System individuell eingestellt – eine so große Anzahl an Datensätzen nicht unterstützt. Stattdessen sollten die 40.000 Datensätze in zwei Tranchen á 20.000 Datensätze aufgespaltet werden. Anschließend kann man die Daten puffern, damit Programm A und Programm B parallel gestartet werden können.

Fazit

Der Shared Buffer ist ein wichtiger Bereich der Datenzwischenablage, um zum Beispiel sehr große Datenmengen performant lesen zu können. Jedoch bringt sie auch Nachteile mit sich. Mit der derzeitigen Sperrlogik können keine spezifischen Sperren für Lese- und Schreiboperationen und für häufige Schreibzugriffe gesetzt werden. Somit ist diese Methode nicht für die Dialogverarbeitung geeignet. Ein mögliches Szenario wäre hingegen einmalig pro Tag eine große Datenmenge im Shared Buffer abzulegen, wo im Nachhinein ein Hintergrundprogramm diese wieder aus dem Speicher liest und die Daten gemäß ihrer jeweiligen Anforderung weiterverarbeitet. Weiterhin ist die Nutzung dieses speziellen Speichers sehr ressourcenintensiv. Eventuell muss zusätzlicher physischer Speicher aufgerüstet werden.

Cihan Toraman ist SAP Development Consultant bei der Saxonia Systems AG. Er unterstützt schwerpunktmäßig Kunden der Versorgungswirtschaft und des Finanzwesens in verschiedensten Projekten. Sie erreichen ihn über cihan.toraman@saxsys.de

Xing 

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0