[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Feb 2001
    Beiträge
    20.207

    SQL Cache Resultsets

    Hallo zusammen,

    mal ein seltsames Phänomen bei einem Kunden (aktuell V7R1 mit letzten PTF's).
    Irgendwo (das habe ich schon mal gelesen) hält SQL einen zentralen Cache von ausgeführten SQL's incl. des gesamten Ergebnisses.
    Der Kunde hatte ein SQL-Statement per QMQRY ausgeführt und bekam nicht das erwartete Ergebnis (in diesem Fall war z.B. ein Preis falsch).
    Diese Preis hat er korrigert, allerdings zeigte das SQL immer noch den falschen Preis.
    Daraufhin bekam ich den SQL zur Prüfung zugesendet.
    Ich habe den SQL dann per STRSQL eingegeben und ausgeführt und erhielt das korrekte Ergebnis.
    Erst nach Rücksprache erfuhr ich, dass QM verwendet wurde und habe den Befehl dann ebenso in QM eingegeben und ausgeführt.
    Nun zeigte sich das selbe falsche Ergebnis wie beim Kunden, es wurden nicht die aktuellen Daten somdern die Daten der 1. Ausführung angezeigt.
    QM und STRSQL haben somit unterschiedliche Ergebnisse des selben SQL's angezeigt.

    Um nun ins Detail zu gehen habe ich den SQL in QM nun leicht modifiziert und siehe da, ich erhielt das korrekte Ergebnis.

    Das hat mich dazu gebracht, den SQL mal per ODBC (Excel MS-Query) auszuführen.
    Und siehe da, auch in Excel wurde das falsche Ergebnis aus der ersten Ausführung angezeigt. Erst eine leichte Modifikation des SQL's brachte dann das richtige Ergebnis.

    Entscheidend ist hier auch, dass der identische SQL verwendet wird.

    Ergänzend sei noch gesagt, dass externe UDF's im Spiel sind, deren Ergebnisse ja auch von SQL gecached wird (Deterministic).

    Und somit erklärt sich das auch schon wieder:
    Deterministic in SQL geht davon aus, dass bei den selben Eingangsparametern immer auch das selbe Ergebnis geliefert wird.
    Somit cached SQL das Ergebnis, da SQL ja nicht weiß, dass die UDF ein anderes Ergebnis liefern muss wenn die Datenbasis sich ändert.

    Bei solchen UDF's, die also auf sich ändernde Datenbestände zugreifen muss "not deterministic" definiert sein selbst wenn es Performance kostet.
    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

  2. #2
    Registriert seit
    Nov 2003
    Beiträge
    2.304
    Was sagt denn die Dokumentation dazu?

    Zitat Zitat von Fuerchau Beitrag anzeigen
    Deterministic in SQL geht davon aus, dass bei den selben Eingangsparametern immer auch das selbe Ergebnis geliefert wird. Somit cached SQL das Ergebnis, da SQL ja nicht weiß, dass die UDF ein anderes Ergebnis liefern muss wenn die Datenbasis sich ändert.

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wieso seid ihr alle inzwischen zu faul, mal Handbücher selber zu lesen?

    DETERMINISTIC or NOT DETERMINISTIC
    Specifies whether the function returns the same results each time that the
    function is invoked with the same input arguments. The default is NOT
    DETERMINISTIC.
    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
    Dec 2004
    Beiträge
    203
    Hallo.

    Releasewechsel ? .... wir hatten das auch mit QMQRY. Auch wir bekamen nach einem Releasewechsel "verkehrte" Werte zurück. Also wenn Releaewechsel ja ... dann frage ich nachher mal meinen Kollegen. Ist irgendwas mit q...ini Dateien in denen man dem "sagen" muss mach es wie vorher ...

    Gruß,
    Ralf

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    DETERMINISTIC_UDF_SCOPE in der QAQQINI stellt den alten Zustand wieder her. Besser ist meist, den Finger von den UDTFs zu lassen. Ordentliches Datenbankdesign und ein passendes View Layer sind bei weitem nachhaltiger.

    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/

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nun, wenn man eine hierarchische Preisfindung mit bis zu 16 Stufen und verschiedenen sonstigen Varianten (Kundenstammfelder, Teilestammfelder, ...) sowie Preisstaffeln hat und genau 1 Ergebnis benötigst, sehe ich keine andere Chance als eine UDF zu verwenden.
    Zumal diese UDF auch noch ein Wrapper auf die Standard-Brain-Preisfindung ist.
    Hier war der Hintergrund einfach der, dass sich der Preis eben innerhalb kurzer Zeit verändert hat, wobei normalerweise Preise sich nur 1x im Monat ändern.
    Durch den Wrapper und die lange Rechenzeit mit zig Dateizugriffen erschien mir eben deterministic hier als richtig. Nach vielen Jahren (ca. 10-12) trat dieses Problem nun erstmalig auf und wurde halt durch not deterministic ersetzt. Inzwischen ist die Hardware ja auch um ein mehrfaches schneller geworden.
    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

Similar Threads

  1. SQL Cache löschen
    By Fuerchau in forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 05-08-14, 22:54

Berechtigungen

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