DBIF_RSQL_INVALID_RSQL Error
Hi,
ich habe schon die Erfahrung gemacht dass es performanter ist, sich die daten in interne tabellen zu laden (mit select * from und qualifizierten where)
und dann intern die jeweiligen tabellen zu verarbeiten und zusammen zu bringen, als einen join zu machen.
für kurze und prägnante Zugriffe ist der join super. aber sobald es viele daten sind kann es je nach definition einfach ein bisschen länger dauern. gerade bei 1.6mio einträgen - wobei das je nach tabelle noch gar nichts ist.
gruss
ich habe schon die Erfahrung gemacht dass es performanter ist, sich die daten in interne tabellen zu laden (mit select * from und qualifizierten where)
und dann intern die jeweiligen tabellen zu verarbeiten und zusammen zu bringen, als einen join zu machen.
für kurze und prägnante Zugriffe ist der join super. aber sobald es viele daten sind kann es je nach definition einfach ein bisschen länger dauern. gerade bei 1.6mio einträgen - wobei das je nach tabelle noch gar nichts ist.
gruss
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
du willst alle Partner die nicht in der Range Tabelle sind - korrekt ?
Wie schaut es damit dann aus
SELECT
b~partner
b~name_org1
b~name_org2
b~name_last
b~name_first
b~type
INTO corresponding fields of TABLE lt_customer
FROM
but000 AS b INNER JOIN ekun AS e ON b~partner = e~partner
INNER JOIN fkkvkp AS f ON f~gpart = b~partner
INNER JOIN ever AS v ON v~vkonto = f~vkont
WHERE
e~zvks_online_flag = 'X' AND
v~vbeginn < lv_mig_date AND
v~vende > lv_mig_date AND
b~partner not in IN lt_bu_partner_range.
Gruss Jens
du willst alle Partner die nicht in der Range Tabelle sind - korrekt ?
Wie schaut es damit dann aus
SELECT
b~partner
b~name_org1
b~name_org2
b~name_last
b~name_first
b~type
INTO corresponding fields of TABLE lt_customer
FROM
but000 AS b INNER JOIN ekun AS e ON b~partner = e~partner
INNER JOIN fkkvkp AS f ON f~gpart = b~partner
INNER JOIN ever AS v ON v~vkonto = f~vkont
WHERE
e~zvks_online_flag = 'X' AND
v~vbeginn < lv_mig_date AND
v~vende > lv_mig_date AND
b~partner not in IN lt_bu_partner_range.
Gruss Jens
thanks Jens
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
Zur Info:
Ein FOR ALL ENTRIES Ist nur mit einem '=' sinnvoll ein '<>' ist, wenn man sich die Hinweise zu FOR ALL ENTRIES anschaut nicht nur falsch sondern HOCHGRADIG inperformant.
SAP teilt nämlich die Einträg von FOR ALL ENTRIES in Blöcke von 10-20 Einträgen auf, deren Ergebnisse nach Durchführung zusammengefasst werden.
Sprich in deinem Fall werden min. 8.000 Select-Statements generiert und jeweils auf UNLGEICHHEIT abgefragt.
Wenn wir nur davon ausgehen, dass in der Tabelle NUR 100.000 Datensätze liegen werden bei jeder Abfrage 999.990 Datensätze ausgelesen. Mal 8.000 ergibt 7.9 Mrd. Datensätze.
Im günstigsten Fall haben die Datensätze NUR 10 Byte ergibt 74 GB die von der Datenbank übertragen werden.
JA, das dauert etwas!
lg ADT
Zur Info:
Ein FOR ALL ENTRIES Ist nur mit einem '=' sinnvoll ein '<>' ist, wenn man sich die Hinweise zu FOR ALL ENTRIES anschaut nicht nur falsch sondern HOCHGRADIG inperformant.
SAP teilt nämlich die Einträg von FOR ALL ENTRIES in Blöcke von 10-20 Einträgen auf, deren Ergebnisse nach Durchführung zusammengefasst werden.
Sprich in deinem Fall werden min. 8.000 Select-Statements generiert und jeweils auf UNLGEICHHEIT abgefragt.
Wenn wir nur davon ausgehen, dass in der Tabelle NUR 100.000 Datensätze liegen werden bei jeder Abfrage 999.990 Datensätze ausgelesen. Mal 8.000 ergibt 7.9 Mrd. Datensätze.
Im günstigsten Fall haben die Datensätze NUR 10 Byte ergibt 74 GB die von der Datenbank übertragen werden.
JA, das dauert etwas!
lg ADT
Zuletzt geändert von a-dead-trousers am 01.10.2012 08:13, insgesamt 1-mal geändert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Und genau das funktioniert ja nicht, weil mehr als 16.000 Einträge im Range stehen.jensschladitz hat geschrieben:b~partner not in IN lt_bu_partner_range.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hallo ABAP-User,
wie wäre es mit folgendem Ansatz.
Nimm dein Originalcoding und lass einfach die letzte Einschränkung "WHERE...b~partner IN lt_bu_partner_range" weg.
Damit selektierst du zwar zu viel - aber es dumpt zumindest nicht.
Danach wirfst du dann alles raus, was nicht in der Range drin steht. Und da ein DELETE ITAB ... WHERE partner NOT IN lt_bu_partner_range keine DB-Aktion nach sich zieht solltest du dann auch ohne Dump an deine Daten kommen.
Laufzeit müsstest du einfach mal ausprobieren - aber wenn man mit einer 16.000 Einträge großen Ausschlussrange arbeiten will, halte ich es für durchaus machbar so vorzugehen.
@Unit605
Ich mache so was durchaus von Zeit zu Zeit mal. Nicht händisch - aber wenn man eine erkleckliche Anzahl Daten im Zwischenspeicher hat (z.B. kopiert aus EXCEL ) ist das kein Problem.
wie wäre es mit folgendem Ansatz.
Nimm dein Originalcoding und lass einfach die letzte Einschränkung "WHERE...b~partner IN lt_bu_partner_range" weg.
Damit selektierst du zwar zu viel - aber es dumpt zumindest nicht.
Danach wirfst du dann alles raus, was nicht in der Range drin steht. Und da ein DELETE ITAB ... WHERE partner NOT IN lt_bu_partner_range keine DB-Aktion nach sich zieht solltest du dann auch ohne Dump an deine Daten kommen.
Laufzeit müsstest du einfach mal ausprobieren - aber wenn man mit einer 16.000 Einträge großen Ausschlussrange arbeiten will, halte ich es für durchaus machbar so vorzugehen.
@Unit605
*Räusper*Unit605 hat geschrieben:Die Frage ist aber nicht ernst gemeint (Das der User die 16.000 am Bildschirm eingibt), odera-dead-trousers hat geschrieben:hi!
Wo "entsteht" der Range? Sprich wird er vom Benutzer befüllt oder von einem anderen Select-Statement?
Wenn Ersteres: Da funktioniert FOR ALL ENTRIES nicht, da der Benutzer auch Einträge zum Ausschluss angegeben haben könnte (SIGN = 'E') oder mit Wildcards gearbeitet wurde (OPTION = 'CP')
Wenn zweiteres: Da würde ich überhaupt eine andere Tabelle empfehlen, die nur aus dem Feld besteht das du brauchst. Damit sparst du jede Menge Speicher (vorallem bei 16.000 Datenzeilen)
lg ADT
Ich mache so was durchaus von Zeit zu Zeit mal. Nicht händisch - aber wenn man eine erkleckliche Anzahl Daten im Zwischenspeicher hat (z.B. kopiert aus EXCEL ) ist das kein Problem.
Vergleichbare Themen
1
Antw.
Antw.
321
Views
Views
0
Antw.
Antw.
1895
Views
Views
DIM-00035: You have entered and invalid option for the -EDIT
von Pitzy007 » 07.02.2007 14:47 • Verfasst in SAP - Allgemeines
von Pitzy007 » 07.02.2007 14:47 • Verfasst in SAP - Allgemeines
7
Antw.
Antw.
4043
Views
Views
2
Antw.
Antw.
3333
Views
Views
ERROR bei der Installation von Web AS 6.40
von bohne » 25.09.2006 15:08 • Verfasst in Web Application Server
von bohne » 25.09.2006 15:08 • Verfasst in Web Application Server
2
Antw.
Antw.
5179
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.