[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Sep 2005
    Beiträge
    385

    sql vs Nativ read delet ...

    Tach *all
    habe mal wieder ne Grundsatzdiskussion im Betrieb!

    LF
    5 keys

    die ersten 4 werden benötigt

    was ist schneller
    update date set f1 = :w1, f2 =:w2, f3 = :w3
    where key1 = :key1 and key2 = :key2 and key3=:key3 and key4=:key4

    oder

    setll
    reade
    dow not %eof()
    eval
    eval
    eval
    update
    reade
    enddo

    es werden zwischen 5 und 150 Sätzen geändert, je nach key1, 2, 3, 4


    oder
    set :zahl =(select count(*) from datei where key1 = :key1 and key2 = :key2 and key3=:key3 and key4=:key4 and 3 andere bedingungen

    VS

    setll
    reade
    dow not %eof()
    if bed.1 and bed.2 and bed.3
    eval zahl = Zahl +1
    endif
    reade
    enddo

    Ich meine das es mal eine abhandlung im Netz gab von jemand der das per 'versuch' ermittelt hatte. Mindestens 10 jahre alt.
    Find ich aber nicht mehr.
    und ob das noch gilt ...

    was denkt Ihr
    Max

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... SQL ist schneller programmiert, wesentlich flexibler, insbesondere bei Datenbankänderungen, braucht allerdings mehr Ressourcen und ist bei index sequentiellen Zugriffen langsamer. Sobald ich Funtionalitäten im SQL verwende, die im RLA nicht gehen (Aggregationen etc.) dreht sich das im Mittel um.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Ein Vergleich RLA und SQL hängt von vielen Faktoren ab und ist meist erst bei vielen 1000 Zugriffen nachweislich messbar. Durch Cache wird vieles im Speicher abgehandelt was zusätzlich noch von den anderen Mitbewerbern (Jobs) um Ressourcen beeinflusst wird.
    Bin ich wirklich alleine auf der Maschine kann ich halbwegs reelle Messergebnisse erwarten.

    Soviel zu RPG/LE:
    Jeder Read führt dazu, dass alle verwendeten Variablen zuerst aus dem Readbuffer übertragen werden müssen. Dabei ist es schädlich, eine DS aller Felder zu definieren da der Compiler so intelligent ist, dass nur tatsächlich referierte Felder generiert werden.
    Hier ist also die Zeit der Übertragung (merkbar bei Millionen von Zugriffen) hinzuzurechnen.
    In ILERPG kann ich den Update "beschleunigen" in dem ich die zu ändernde Feldliste aufführe, damit werden auch nur diese Inhalte in den Puffer zurückübertragen.

    Bei SQL kommt sicherlich ein Verwaltungsoverhead dazu der ODP's überprüfen muss bevor ein Zugriff erfolgt. Diese Zeiten sind u.U. nicht zu verachten wenn man (wie gesagt) Millionen von Operationen vorhat.

    Aber was macht es tatsächlich aus?
    Hier ein historischer Vergleich aus einer von mir betreuten Altanwendung:
    In eine Statistikdatei werden neue Sätze mit Verarbeitungsflag geschrieben.
    Ein Batchprogramm verarbeitet per Input Primary eine Statistikdatei von (Tendenz steigend) 100.000 Sätzen um neue Daten in andere Dateien zu verteilen. Dabei werden halt alle Sätze gelesen und nach den neuen Sätzen gesucht.
    Diese Verarbeitung dauerte ca. 1998 noch mehrere Minuten und wurde deshalb nur 1 x je Woche durchgeführt.
    Stand heute mit schnelleren Maschinen dauert die Verarbeitung nur wenige Sekunden und wird daher mehrmals täglich durchgeführt.

    Bei einem anderen Kunden musste ich aus mehreren Dateien statistische Werte berechnen.
    Hier habe ich mir die Programmierung gespart und per QM-Query einen mehrere Seiten umfassenden SQL gestrickt. er enthält viele CTE's, skalare Subselects, diverse Group-By's.
    Bei der Ausführung im Dialog weist mir SQL mehr als 12 Milliarden verarbeitet Sätze aus!
    Der SQL dauert aber nur ca. 1 Minute incl. Erstellung einer Ausgabedatei mit ca. 15.000 Ergebnisssätzen.
    Ich denke mit RLA hätte ich das so nicht hinbekommen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Also bei SQL gibt es immer einen gewissen Overhead den es bei Native I/O nicht gibt.
    Deshalb kann SQL durchaus "langsamer" sein.
    Wobei wir hier in bereich von milli sek. sprechen, wenn eben z.B. der Zugriffsplan erstellt wird.

    Wenn ich ein SQL sehe welches zu langsam wäre, vergleiche ich nicht ob es mit Native I/O schneller wäre, sondern analysiere warum es langsam ist (fehlende Indice, schlechte struktur des SQL Statements, usw.).

    Ich habe auch einmal eine Client Anwendung in der 10.000de INSERT INTOs gemacht wurden.
    Dies sollte beschläunigt werden und sebst bei einem simplen INSERT INTO mit VALUES konnte ich eine Performance steigerung durchführen nachdem ich die Struktur des SQLs geändert habe.
    Sowas ist aber nur notwendig wenn man um jede milli sek kämpfen muss/möchte.

    Ich glaube man muss bei Grundsatzdiskussionen etwas genauer hinschauen.
    Meist (wenn nicht nahezu immer) geht es darum, dass Kollegen, sich in der Native I/O welt wohler fühlen als mit SQL.
    Und dann kommt jemand daher und will einem aus der "Wohlfühlzone" reisen.
    Da holt man jedes Argument was nur irgendwie möglich ist um sein Weltbild zu verteidigen.
    Wenn man erkennt wo das eigentliche Problem liegt, und die diskussion dahingehend lenkt, so kann man (davon bin ich überzeugt) die beiden Seiten viel besser zusammen bringen.

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    ...sondern analysiere warum es langsam ist ...schlechte struktur des SQL Statements... konnte ich eine Performance steigerung durchführen nachdem ich die Struktur des SQLs geändert habe.
    ... wieder einer der Mythen: für SQL gilt das Kohl Prinzip (wer den Dicken nicht kennt: entscheidend ist, was hinten rauskommt!). Wenn ein SQL Statement durch Umformulierung schneller wird, hat der Query Optimizer einen Bug!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Was bei Inserts nicht zu verachten ist sind die Anzahl zu verwaltender indizes.
    Man kann diese ggf. deaktivieren und hinterher aktivieren.
    in Summe ist der (partielle) Neuaufbau von Indizes über mehrere parallele Jobs schneller als die Inserts mit aktiven Indizes (gemeinsame Erfahrungen mit D*B).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Sep 2005
    Beiträge
    385
    Ich habe nun den Aufwand betrieben und aus dem Pgm mit

    do *hival
    qrcvdtaq
    Update Datei set w1=:a, w2 = :b, w3=:c where key1=:key1 and key2 = :key2
    9 *mal auf verschiedene Dateien mit 5.000-18.000.000 Sätzen
    enddo

    ein Pgm mit 9 mal

    Setll
    read
    dow not %eof
    eval
    update
    read
    enddo

    zu machen


    das SQL schaffte im schnitt 2.200 Dataq Sätze in der Stunde
    Native schafft 60.000

    Blamabel!

    Fazit: (wie D*B schon erwähnte)
    Sql ist leichter und schneller programmiert, aber definitiv NICHT für alles geeignet

    Der
    ILEMax

  8. #8
    Registriert seit
    Dec 2014
    Beiträge
    310
    Zitat Zitat von BenderD Beitrag anzeigen
    ... wieder einer der Mythen: für SQL gilt das Kohl Prinzip (wer den Dicken nicht kennt: entscheidend ist, was hinten rauskommt!). Wenn ein SQL Statement durch Umformulierung schneller wird, hat der Query Optimizer einen Bug!
    Also wie jetzt ???

    Das Forum ist voll von brauchbaren SQL Beschleunigungs-Tipps, nur 2 Beispiele
    ein Praxistipp von Hrn. Fürchau (Beitrag #2)
    http://newsolutions.de/forum-systemi...6333#post96333

    oder im gleichen Thread von Hrn. Bender selbst (Beitrag #4):
    http://newsolutions.de/forum-systemi...6333#post96333

    Warum muss dann jetzt plötzlich der Optimizer kaputt sein ???

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Blamabel ist das eher nicht sondern hier fehlt die Analyse warum dein SQL so langsam ist.
    Ggf. machte dein SQL einen tablescan weil dein Index für RPG einen Select/Omit enthält und dieser deshalb nicht verwendet wird.
    Ein Faktor 30 ist da eher inwahrscheinlich. Ein Faktor nahe 1,1-1,2 sollte erreichbar sein.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Sep 2005
    Beiträge
    385
    Ich gebe zu, das ich das nicht untersucht habe.
    außer der strdbg - weg hab ich da nicht soviel Kenntnisse.

    Sicher ist, das auf den gekeyten PF max. 2 LF liegen, kein LF mit select / Ommit ist und
    es für jede Datei einen passenden Key gibt.
    Dieser ist jedoch i.d.r. länger (mehr als meine 2-4 Key Felder)

  11. #11
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Zitat Zitat von BenderD Beitrag anzeigen
    ... wieder einer der Mythen: für SQL gilt das Kohl Prinzip (wer den Dicken nicht kennt: entscheidend ist, was hinten rauskommt!). Wenn ein SQL Statement durch Umformulierung schneller wird, hat der Query Optimizer einen Bug!
    Jaja die böse IBM die böse DB2. Teilweise hast du ja recht, teilweise aber übertrieben. Wenn man all deine Postings zusammenfasst glaubt man, dass die IBM i die so ziemlich schlechteste Wahl ist die man treffen könnte. Da frag ich mich schon warum du in diesem Umfeld noch tätig bist?
    (Ist jetzt kein Angriff, oder böse gemeint, sondern würde mich und sicher viele andere auch wirklich interessieren!!)

    Zurück zum Thema:
    In solchen Fällen wie von mir schon hin und wieder beschrieben sehe ich es nicht als Bug. Der Optimizer ist halt nur nicht Optimal
    Und ich habe schon oft SQLs umstrukturieren müssen, um größere Performance gewinne erziehlen zu können. (Natürlich auch mit entsprechender Index Strategie)

    In Oracle haben wir z.B. das Problem dass der "Optimizer" für das gleiche Query einmal den entsprechenden Index benützt und einmal wieder nicht.
    Und das macht wirklich probleme. Ist im übrigen kein unbekanntes Problem bei Oracle!
    Aber solche Diskussionen hatten wir hier auch schon zu genüge.

  12. #12
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Zitat Zitat von ILEMax Beitrag anzeigen
    Ich gebe zu, das ich das nicht untersucht habe.
    außer der strdbg - weg hab ich da nicht soviel Kenntnisse.
    Welches Release habt ihr?
    Hast du aus dem Joblog heraus sehen können ob der entsprechende Index genommen wurde?
    Hat er den ODP wiederverwendet?

    Wenn du ein DB Monitoring startest kannst du da viel mehr informationen herauslesen.

Similar Threads

  1. Nicht lesbare Daten nach Read aus dem IFS
    By msost in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 25-07-14, 15:54
  2. READ / READE in free-rpg
    By Gimli in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 10-03-03, 13:08
  3. VA RPG Read anweisung schlägt fehl
    By Peter Kosel in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 18-10-01, 13:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •