[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2003
    Beiträge
    44

    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.

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.296
    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.
    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

  3. #3
    Registriert seit
    Aug 2003
    Beiträge
    44
    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

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.296
    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.
    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

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    2.882
    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
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 5. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  6. #6
    Registriert seit
    Aug 2003
    Beiträge
    44
    Vielen Dank für Euere Antworten, ich denke das hat mir weitergeholfen.

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.293
    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 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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Similar Threads

  1. Embedded SQL in VARPG
    By Squall in forum NEWSboard Programmierung
    Antworten: 23
    Letzter Beitrag: 18-10-06, 12:01
  2. embedded SQL in RPG
    By muadeep in forum IBM i Hauptforum
    Antworten: 5
    Letzter Beitrag: 03-08-06, 13:25
  3. SQL .. for update of (RPG embedded SQL)
    By loeweadolf in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 01-06-06, 09:43
  4. Character verbinden in Embedded SQL
    By e_sichert in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 03-05-06, 10:47
  5. Versch. Sql Berechtigung Dynamisch - Statisch ?
    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
  •