Native SQL
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo!
Ich habe ein ABAP Programm das Daten aus einer externen Quelle (nicht DDIC) mit Native SQL ausliest. Durch das zeilenweise auslesen des Programms scheint das Ganze etwas inperformant. Ist es möglich sich den gesammten Datensatz auf einmal zu holen statt zeilenweise?
Ist es performanter nach dem select direkt in eine interne Tabelle zu schreiben, statt in einen arbeitsbereich, der dann an die interne tabelle angehängt wird?
Dann habe ich gehört: Durch die Benutzung des Cursors ist es möglich das wenn jemand gleichzeitig auf die zugehörige Datenbank lesend oder schreibend zugreift, der select abbrechen kann (tut es bei uns in unregelmäßigen abständen und wir sind auf fehlersuche
). Stimmt das? Wäre ja seltsam....
Danke und gruß,
bliP!
Ich habe ein ABAP Programm das Daten aus einer externen Quelle (nicht DDIC) mit Native SQL ausliest. Durch das zeilenweise auslesen des Programms scheint das Ganze etwas inperformant. Ist es möglich sich den gesammten Datensatz auf einmal zu holen statt zeilenweise?
Ist es performanter nach dem select direkt in eine interne Tabelle zu schreiben, statt in einen arbeitsbereich, der dann an die interne tabelle angehängt wird?
Dann habe ich gehört: Durch die Benutzung des Cursors ist es möglich das wenn jemand gleichzeitig auf die zugehörige Datenbank lesend oder schreibend zugreift, der select abbrechen kann (tut es bei uns in unregelmäßigen abständen und wir sind auf fehlersuche
). Stimmt das? Wäre ja seltsam....Danke und gruß,
bliP!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hierzu ein Auszug aus der ABAP Schlüsselwortdokumentation:bliP! hat geschrieben:Ist es performanter nach dem select direkt in eine interne Tabelle zu schreiben, statt in einen arbeitsbereich, der dann an die interne tabelle angehängt wird?
Performance:
Ob Daten besser in eine interne Tabelle oder in einen Arbeitsbereich eingelesen werden sollen, hängt von der Art der weiteren Verarbeitung ab: Werden Daten in einem Programm nur einmal benötigt, so sollten sie mit einer SELECT-ENDSELECT-Schleife zeilenweise in einen Arbeitsbereich eingelesen werden. Das Einlesen in eine interne Tabelle benötigt mehr Speicherplatz, ohne diesen Nachteil durch eine wesentlich höhere Lesegeschwindigkeit auszugleichen. Werden Daten dagegen in einem Programm mehrfach benötigt, so sollten sie in eine interne Tabelle eingelesen werden. Der Nachteil des höheren Speicherbedarfs wird hier durch den Vorteil der einmaligen Selektion mehr als kompensiert.
Sollen Daten in eine interne Tabelle eingelesen werden, so ist es günstiger, sie auf einen Schlag in die interne Tabelle einzulesen, als sie Zeile für Zeile in einen Arbeitsbereich und anschließend mit APPEND an die interne Tabelle anzufügen.
Die Varianten ... INTO CORRESPONDING FIELDS OF wa, ... INTO CORRESPONDING FIELDS OF TABLE itab und ... APPENDING CORRESPONDING FIELDS OF TABLE itab benötigen im Vergleich zu den entsprechenden Varianten ohne CORRESPONDING FIELDS eine etwas höhere - von der Größe der Lösungsmenge aber unabhängige - Laufzeit. Sie sollten deshalb möglichst nur bei der Selektion von größeren Datenmengen benutzt werden.
Gruß,
Charadin
Charadin
Hallo bliP!
NativeSQL ist SAP-seitig nicht darauf ausgelegt, eine Massenverarbeitung durchzuführen, weshalb Du die aktuelle Zeile in den global definierten Variablen im definierten Unterprogramm zum EXEC SQL zur Verfügung bekommst.
Dazu der Auszug aus der Hilfe:
Natürlich wäre es schöner, wenn man hier eine Tabelle angeben könnte, was mir aber nicht bekannt ist...
NativeSQL ist SAP-seitig nicht darauf ausgelegt, eine Massenverarbeitung durchzuführen, weshalb Du die aktuelle Zeile in den global definierten Variablen im definierten Unterprogramm zum EXEC SQL zur Verfügung bekommst.
Dazu der Auszug aus der Hilfe:
Code: Alles auswählen.
Zusatz
... PERFORMING form
Dieser Zusatz ist im Kontext von ABAP Objects verboten. Siehe Verbot des Unterprogrammaufrufs in EXEC SQL.
Wirkung
Ist das Ergebnis eines SELECT-Befehls eine Tabelle, so erfolgt das Lesen Zeile für Zeile in einer Verarbeitungsschleife. Pro Zeile wird einmal das Unterprogramm form aufgerufen. Die Verarbeitungsschleife kann mit EXIT FROM SQL im Unterprogramm form abgebrochen werden. Ist das Ergebnis der Selektion ein Einzelsatz, so wird form nur einmal aufgerufen.
Beispiel
Anzeigen eines Ausschnitts der Tabelle AVERI_CLNT:
DATA: F1(3), F2(3), F3(3).
F3 = ' 1 '.
EXEC SQL PERFORMING WRITE_AVERI_CLNT.
SELECT CLIENT, ARG1 INTO :F1, :F2 FROM AVERI_CLNT
WHERE ARG2 = :F3
ENDEXEC.
FORM WRITE_AVERI_CLNT.
WRITE: / F1, F2.
ENDFORM.
Hinweis
Dieser Zusatz ist nur bei einem SELECT-Befehl erlaubt.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Dann nochmal eine Frage dazu:
Unser konkretes problem:
Wir haben eine Datenbankquelle außerhalb des DDIC. Im SAP BW System werden die Daten dann durch ein ABAP ausgelesen. Bei dem Auslesevorgang kommt es zu unregelmäßigen Programmabbrüchen. Als Fehlermeldung kommt ORA-01410 (Invalid Row-ID) und ORA-08103 (Object no longer exists).
Wir gehen davon aus, dass während dem Auslesen per Native SQL ein Satz auf den noch per Cursor referenziert wird, gelöscht wird. Das führt zum Abbruch des Programms.
Laufzeitfehler DBIF_DSQL2_SQL_ERROR
Ausnahme CX_SY_NATIVE_SQL_ERROR
Könnte man das über Try-Catch lösen?
Kann man diesen Abbruch verhindern?
Danke und Gruß,
bliP!
Unser konkretes problem:
Wir haben eine Datenbankquelle außerhalb des DDIC. Im SAP BW System werden die Daten dann durch ein ABAP ausgelesen. Bei dem Auslesevorgang kommt es zu unregelmäßigen Programmabbrüchen. Als Fehlermeldung kommt ORA-01410 (Invalid Row-ID) und ORA-08103 (Object no longer exists).
Wir gehen davon aus, dass während dem Auslesen per Native SQL ein Satz auf den noch per Cursor referenziert wird, gelöscht wird. Das führt zum Abbruch des Programms.
Laufzeitfehler DBIF_DSQL2_SQL_ERROR
Ausnahme CX_SY_NATIVE_SQL_ERROR
Könnte man das über Try-Catch lösen?
Kann man diesen Abbruch verhindern?
Danke und Gruß,
bliP!
Seite 1 von 1
Vergleichbare Themen
10
Antw.
Antw.
4183
Views
Views
0
Antw.
Antw.
1057
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 13 Stunden von DeathAndPain 4 / 788
vor 13 Stunden von DeathAndPain 4 / 788
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 13 Stunden von DeathAndPain 4 / 788
vor 13 Stunden von DeathAndPain 4 / 788