OPEN CURSOR bricht wegen Datenbank-Commit ab
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Hi,
ich bastel mir gerade ein kleinen Report zu Recht, in welchem unter anderem aus einer zu bestimmenden Tabelle entweder alle oder nur teilweise Datensaetze ausgelesen (bzw. auf Frontend gespeichert) werden sollen. Bei einer kleinen Tabelle funktioniert es. Aber bei einer Testtabelle mit 21 Mio Datensaetzen bricht der Report wegen Speicherplatzmangel ab.
Okay, sehe ich ein. Bin bei meinen Recherchen auf OPEN CURSOR usw. gestossen. Habe dies auch implementiert. Leider bricht er immer noch ab, da anscheinend die zu speichernde Itab zu gross wird. Als der Weisheit letzter Schluss habe ich den Aufruf der Form zum Datendownload innerhalb die Verarbeitung der Datensaetze mit reingenommen und leere anschliessend vor der Neubefuellung die itabs. Leider bricht er mir jetzt wegen einem Datenbank-Commit ab, der durch den Aufruf des Fubas GUI_Download in der FORM data_download verursacht wird.
Wie kann ich den FuBa aufrufen und trotzdem die Verbindung zur Datenbank aufrechterhalten?
Dankbar fuer jede Antwort 
ich bastel mir gerade ein kleinen Report zu Recht, in welchem unter anderem aus einer zu bestimmenden Tabelle entweder alle oder nur teilweise Datensaetze ausgelesen (bzw. auf Frontend gespeichert) werden sollen. Bei einer kleinen Tabelle funktioniert es. Aber bei einer Testtabelle mit 21 Mio Datensaetzen bricht der Report wegen Speicherplatzmangel ab.
Okay, sehe ich ein. Bin bei meinen Recherchen auf OPEN CURSOR usw. gestossen. Habe dies auch implementiert. Leider bricht er immer noch ab, da anscheinend die zu speichernde Itab zu gross wird. Als der Weisheit letzter Schluss habe ich den Aufruf der Form zum Datendownload innerhalb die Verarbeitung der Datensaetze mit reingenommen und leere anschliessend vor der Neubefuellung die itabs. Leider bricht er mir jetzt wegen einem Datenbank-Commit ab, der durch den Aufruf des Fubas GUI_Download in der FORM data_download verursacht wird.
Wie kann ich den FuBa aufrufen und trotzdem die Verbindung zur Datenbank aufrechterhalten?
Code: Alles auswählen.
OPEN CURSOR g_cursor FOR
SELECT DISTINCT (v_columns) FROM XYZ.
DO.
FETCH NEXT CURSOR g_cursor
INTO TABLE <dyntable_2>
PACKAGE SIZE 1000.
IF sy-subrc NE 0.
CLOSE CURSOR g_cursor.
EXIT.
ENDIF.
LOOP AT <t_dyntable_2> ASSIGNING
<wa_dyntable>.
* Verarbeitung
IF ...
INSERT <wa_t_dyntable> INTO TABLE <dyntable>.
...
ENDIF.
PERFORM download.
ENDLOOP.
FREE <wa_dyntable>.
FREE <dyntable>.
FREE <dyntable_2>.
ENDDO.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi,
Deine 21 Mio Datensätze kann man doch bestimmt nach ausgewählten Feldern gruppieren?
Beispiel: Werke / oder Buchungskreise
loop at it_w-werks.
SELECT (v_columns) FROM XYZ
INTO TABLE <dyntable_2>
..
where werks = it_w-werks
...
loop at <dyntable_2> ...
perform download.
endloop.
endloop.
lg Andreas
Deine 21 Mio Datensätze kann man doch bestimmt nach ausgewählten Feldern gruppieren?
Beispiel: Werke / oder Buchungskreise
loop at it_w-werks.
SELECT (v_columns) FROM XYZ
INTO TABLE <dyntable_2>
..
where werks = it_w-werks
...
loop at <dyntable_2> ...
perform download.
endloop.
endloop.
lg Andreas
Danke erstmal für die Antwort.
Leider kann ich nicht mit einem Where-Zusatz arbeiten. Da die zu lesenden Datensätze nach einer Formel ausgewält als Stichprobe herhalten sollen. Momentan ist die Stichprobe aber 100% der Daten, um einen Stresstest mit dem Report durchzuführen. Vielleicht möchte mal wirklich jemand dies machen.
Die Tabelle mit Name, Felder usw. ist am Anfang nicht bekannt. Es handelt sich um Faktentabellen im BW-System. Deshalb muss alles dynamisch sein.
Es muss doch eine Möglichkeit geben den Commit zu umgehen / zu unterdrücken (wie der Zusatz WITH HOLD).
Oder gibt es die Möglichkeit, nachdem der Commit (leider) stattgefunden hat, wieder den CURSOR zu erstellen, aber an der nächsten zu setzenden Cursorposition? Ich hoffe, ich habe es verständlich gemacht, was ich will.
Leider kann ich nicht mit einem Where-Zusatz arbeiten. Da die zu lesenden Datensätze nach einer Formel ausgewält als Stichprobe herhalten sollen. Momentan ist die Stichprobe aber 100% der Daten, um einen Stresstest mit dem Report durchzuführen. Vielleicht möchte mal wirklich jemand dies machen.
Die Tabelle mit Name, Felder usw. ist am Anfang nicht bekannt. Es handelt sich um Faktentabellen im BW-System. Deshalb muss alles dynamisch sein.
Es muss doch eine Möglichkeit geben den Commit zu umgehen / zu unterdrücken (wie der Zusatz WITH HOLD).
Oder gibt es die Möglichkeit, nachdem der Commit (leider) stattgefunden hat, wieder den CURSOR zu erstellen, aber an der nächsten zu setzenden Cursorposition? Ich hoffe, ich habe es verständlich gemacht, was ich will.
Moinsen.
Vorschlag: Von allen zu exportierenden Tabellenzeilen im ersten Schritt nur die Schlüssel lesen und diese in einer ITab zwischenspeichern. Im zweiten Schritt wird diese Tabelle satzweise oder paketweise gelesen und für den Satz/das Paket die DB-Tabelle mit allen benötigten Spalten gelesen.
Vorteil: Die Schlüsselbegriffe sind verglichen mit der Gesamtbreite einer Tabelle meistens relativ schmal. Der erste Schritt belastet also den Hauptspeicher nicht so intensiv (Man sollte trotzdem mal rechnen: eine Schlüssellänge von 20 Bytes lässt allein die Schlüsseltabelle in Deinem Beispiel auf ~400MB anwachsen...
)
Nachteil: Laufzeit (Es wird 2x selektiert)
Gruss,
Haubi
Vorschlag: Von allen zu exportierenden Tabellenzeilen im ersten Schritt nur die Schlüssel lesen und diese in einer ITab zwischenspeichern. Im zweiten Schritt wird diese Tabelle satzweise oder paketweise gelesen und für den Satz/das Paket die DB-Tabelle mit allen benötigten Spalten gelesen.
Vorteil: Die Schlüsselbegriffe sind verglichen mit der Gesamtbreite einer Tabelle meistens relativ schmal. Der erste Schritt belastet also den Hauptspeicher nicht so intensiv (Man sollte trotzdem mal rechnen: eine Schlüssellänge von 20 Bytes lässt allein die Schlüsseltabelle in Deinem Beispiel auf ~400MB anwachsen...
)Nachteil: Laufzeit (Es wird 2x selektiert)
Gruss,
Haubi
Hallo,
danke für den Vorschlag. Aber leider wird dann wieder die Tablle so groß. Die Tabellen, um die es hier geht, können bis zu 16 Schlüsselfelder aufnehmen. Dürfte sie bei der Größe wahrscheinlich auch haben. Da wird die itab bei Deiner Rechnung noch größer werden.
Habe inzwischen noch ein zwei andere Lösungsmöglichkeiten im WWW gefunden, die mit unter aber auch nicht performanter sind bzw. über den Applikationsserver und dann File-Download gehen. Den Zeitverbrauch für den Weg will ich gar nicht erst wissen
Ich schreibe es, wenn ich eine Lösung gefunden habe.
danke für den Vorschlag. Aber leider wird dann wieder die Tablle so groß. Die Tabellen, um die es hier geht, können bis zu 16 Schlüsselfelder aufnehmen. Dürfte sie bei der Größe wahrscheinlich auch haben. Da wird die itab bei Deiner Rechnung noch größer werden.
Habe inzwischen noch ein zwei andere Lösungsmöglichkeiten im WWW gefunden, die mit unter aber auch nicht performanter sind bzw. über den Applikationsserver und dann File-Download gehen. Den Zeitverbrauch für den Weg will ich gar nicht erst wissen
Ich schreibe es, wenn ich eine Lösung gefunden habe.
Moinsen nochmal.
Wie wäre es dann mit dem Zusatz "PACKAGE SIZE" beim SELECT? Du bekommst dann entsprechend viele Zeilen in Deine ITab gestellt und kannst diese speichern. Allerdings darf zwischen zwei Paketen ebenfalls kein COMMIT kommen. Es empfiehlt sich also, die Datei zunächst auf dem App-Server abzulegen und erst im Nachgang einen Download auf den Frontend-Rechner vorzunehmen.
Gruss,
Haubi
Wie wäre es dann mit dem Zusatz "PACKAGE SIZE" beim SELECT? Du bekommst dann entsprechend viele Zeilen in Deine ITab gestellt und kannst diese speichern. Allerdings darf zwischen zwei Paketen ebenfalls kein COMMIT kommen. Es empfiehlt sich also, die Datei zunächst auf dem App-Server abzulegen und erst im Nachgang einen Download auf den Frontend-Rechner vorzunehmen.
Gruss,
Haubi
Hi,
nach Rücksprache mit den zukünftigen Usern des Reports, schreibe ich ihn so um, dass die Daten auf dem Applikationsserver abgelegt werden. Die Berechtigungen werden wenigstens immer dazu vorhanden sein
Keine Lust auf größere Baustelle.
Danke Euch nochmal
nach Rücksprache mit den zukünftigen Usern des Reports, schreibe ich ihn so um, dass die Daten auf dem Applikationsserver abgelegt werden. Die Berechtigungen werden wenigstens immer dazu vorhanden sein
Keine Lust auf größere Baustelle. Danke Euch nochmal
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1667
Views
Views
1
Antw.
Antw.
1167
Views
Views
4
Antw.
Antw.
3103
Views
Views
4
Antw.
Antw.
2320
Views
Views
2
Antw.
Antw.
2224
Views
Views
Installation MiniWAS 620 bricht ab
von Svenson » 02.11.2005 14:31 • Verfasst in Web Application Server
von Svenson » 02.11.2005 14:31 • Verfasst in Web Application Server
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.