-
embedded SQL statisch oder dynamisch
Hallo,
ich hab schon die Such-Funktion genutzt, aber zu meinem konkreten Problem habe ich keine Antworten gefunden.
Ich habe die Aufgabe die Performance in einigen Programmen zu verbessern. Der Knackpunkt ist der SQL den es zu verbessern gilt.
Ich habe ein Feld das nicht unbedingt gefüllt ist.
Momentan wir dieses Feld mit Feld = " " or Feld between [vonwert] and [biswert]. Der Von und Bis Wert wird zuvor gesetzt.
Da ich jetzt in einigen Threads verfolgt habe, dass statische Sqls schneller sind, habe ich jetzt die Frage: Was ist in diesem Fall??
Soll ich eher die unsinnige Abfrage (falls das Feld nicht gefüllt ist) statisch drin lassen oder alles auf dynamisch umstellen?
Bin schon auf euere Erfahrungswerte gespannt.
-
Da scheiden sich die Geister.
Wenn es über das Feld einen Index gibt, ist es fast egal.
Allerdings kannst du das "or" auch weglassen, wenn der Von- und Biswert dann leer sind.
Statische SQL's sind nur beim Open minimal schneller (kein Syntaxcheck, Prepare usw.), die spätere Laufzeit unterscheidet sich da dann gar nicht.
-
Hallo,
das würde ja bedeuten dass die Anzahl der Argumente im SQL sich nicht auf die Performance auswirken
Nochmal ein Beispiel zur Verdeutlichung
Datei xyz
Mandant, Sachbearbeiter, Name1, Name2, Name3, PLZ, ORT
Key = Mandant, Sachbearbeiter
Select * from xyz where mandant = "xx" and Sachbearbeiter = "yy" and PLZ between 00000 and 99999
wäre dann genauso schnell wie:
Select * from xyz where mandant = xx= and Sachbearbeiter = "yy"
Werden für die einzelnen Argumente nicht soetwas wie Entscheidungstabellen/ - bäume aufgebaut?
Ich bin bis jetzt der Meinungs gewesen umso mehr ich in einen SQL reinpacke, desto mehr muss dieser Entscheiden.
Viele Entscheidungen = Viele Rechenschritte
Deßhalb baue ich die SQL´s immer dynamisch, damit auch nur das verarbeitet wird was notwendig ist und nicht so Sinnlose Abfragen wie oben.
Jetzt bin ich verwirrt, könnte auch an der üblen Hitze liegen
-
Nein, so meine ich das nicht.
Aber an Stelle der Abfrage
where ... and (feld x = ' ' or feldx between 'aaa' and 'ZZZZ')
kannst du auch
where ... and feldx between ' ' and ' '
verwenden.
Wobei du auf jeden Fall Programmfelder vewrwenden solltest:
where ... and feldx between :vonx and :bisx
wobei Von/Bis eben auch leer sein können, wenn es hierfür keine Auswahl gibt.
Seit V5Rx werden auch Mapping-Tabellen verwendet (Bitmaps) um schnelle Zugriffe zu ermöglichen. Daher sollte dann eben über Feldx ein Index vorhanden sein.
Der Vorteil von statischen SQL's mit Paramtern liegt dann tasächlich in der Wiederverwendung von ODP's auch ggf. bei komplexen Abfragen.
-
Hallo,
wie Baldur sagt. Das OR weglassen!
Ansonsten ist der Quey Optimizer clever genug zu erkennen, ob im Von- und Bis-Wert das gleiche steht, um dann nach einem entsprechenden Index zu suchen.
Dynamisches SQL ist auf alle Fälle langsamer. Für statisches SQL werden die Access Pläne im Programm-Objekt gespreichert und brauchen nur validiert zu werden. Für dynamisches SQL werden keine Access Pläne im Programm-Objekt gespeichert. Wird die Abfrage von der CQE (classic Query Engine), muss der Access Plan jedes mal neu aufgebaut werden. Bei Verwendung der neuen SQE (SQL Query Engine) kann evt. ein im Plan Cache gespeicherter Access Plan validiert werden.
Was bei der Optimierung noch viel wichtiger ist, und was viele falsch machen! Die Zugriffs-Wege sollten nicht hart geschlossen werden (HARD CLOSE). Ein Hard Close wird erreicht durch die Compile Option CLOSQLCSR = *ENDMOD. In diesem Fall muss die Optimierung jedes Mal, wenn das Modul im gleichen Job aufgerufen wird, komplett durchlaufen werden. Erfolgt kein Hard Close, wird der offene Zugriffs-Pfad (ODP) nur nach der erste Ausführung komplett gelöscht. Ab dem zweiten Aufruf bleibt er (sofern er wiederverwenbar ist) offen. D.h. der Optimierungs-Prozess wird nicht mehr durchlaufen, sondern der Offene Daten Pfad wird immer wieder verwendet.
Birgitta
-
Vielen Dank für Euere Antworten, ich denke das hat mir weitergeholfen.
-
Hallo,
vorab zwei allgemeinere Hinweise zur SQL Performance:
- first do it right, then make it fast
klare Logik ist meist ausreichend schnell und lässt sich besser optimieren
- messen geht über vermuten und glauben zu wissen
mach dich mit dem Database Monitor vertraut, nur der sagt dir was die Datenbank wirklich macht (auch Visual Explain rät nur rum, was die Datenbank machen könnte!)
- zu deiner Frage im engeren:
die Lösung mit statischem SQL sollte mit entsprechenden Zugriffspfaden (die sich leichter prüfen lassen) in der Summe minimal schneller sein; zusätzliche Bedingungen können Queries sogar beschleunigen, da mehr Zugriffsmöglichkeiten bestehen (wenn das lauter betweens sind, die dann Highval/Lowval beinhalten freilich nicht), aber auch mit dynamischem SQL sollte das bei ausreichender Hardware und sorgfältiger Programmierung (Parameter Marker und Wiederverwendung des Prepare) und entsprechender Zentralisierung in Zugriffsmodulen keinerlei Problem verursachen.
- Bei reinem lesen von Daten hilft oft Blockung dramatisch (ob du einen oder 1000 Sätze in einem fetch holst ist fast gleich schnell
- bei read/update Logik ist der positioned update über Cursor wesentlich schneller als searched update mit Key (überkompensiert blocken)
- zur Durchsatzmaximierung bei Massenupdates hilft am Besten Parallelisierung
- keine Angst vor Journalisierung, die macht es eher schneller als langsamer (zumindest die Fehlersuche dramatisch!!!)
- keine Angst vor Commit, das ist keine Bremse, sondern für updates mit SQL unumgänglich, alles andere frei nach Ernst Bloch "Das Prinzip Hoffnung"
- Die Spielereien mit Close oder nicht Close habe ich noch nie mit DBMON verifiziert gesehen, das ist für mich die Erdnuss Abteilung. Ich würde im Gegensatz dazu raten beim Verlassen im Programm explizit zu closen und im Entry zu öffnen, das kommt der Applikationslogik entscheidend zu Gute (man hat immer einen kontrollierten Status eines Cursors, was ja immens wichtig ist!!!).
mfg
Dieter Bender
Zitat von Jamikl
Hallo,
ich hab schon die Such-Funktion genutzt, aber zu meinem konkreten Problem habe ich keine Antworten gefunden.
Ich habe die Aufgabe die Performance in einigen Programmen zu verbessern. Der Knackpunkt ist der SQL den es zu verbessern gilt.
Ich habe ein Feld das nicht unbedingt gefüllt ist.
Momentan wir dieses Feld mit Feld = " " or Feld between [vonwert] and [biswert]. Der Von und Bis Wert wird zuvor gesetzt.
Da ich jetzt in einigen Threads verfolgt habe, dass statische Sqls schneller sind, habe ich jetzt die Frage: Was ist in diesem Fall??
Soll ich eher die unsinnige Abfrage (falls das Feld nicht gefüllt ist) statisch drin lassen oder alles auf dynamisch umstellen?
Bin schon auf euere Erfahrungswerte gespannt.
Similar Threads
-
By Squall in forum NEWSboard Programmierung
Antworten: 23
Letzter Beitrag: 18-10-06, 12:01
-
By muadeep in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 03-08-06, 13:25
-
By loeweadolf in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 01-06-06, 09:43
-
By e_sichert in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 03-05-06, 10:47
-
By Rincewind in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 02-03-06, 09:54
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