-
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
-
... 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
-
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.
-
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.
-
Zitat von andreaspr@aon.at
...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!
-
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).
-
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
-
Zitat von BenderD
... 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 ???
-
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.
-
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)
-
Zitat von BenderD
... 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.
-
Zitat von ILEMax
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
-
By msost in forum NEWSboard Programmierung
Antworten: 9
Letzter Beitrag: 25-07-14, 14:54
-
By Gimli in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 10-03-03, 12:08
-
By Peter Kosel in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 18-10-01, 12:49
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks