SQL Prepare - Verwendeter Zugriffspfad ?

[sim]

Hallo,

folgende Situation. Wir haben ein Programm mit dem der Anwender nach Adressen suchen kann. Für die Suche kann der User diverse Suchbegriffe angeben. z.Bsp nach Name, Vorname, Straße, Ort, Plz, etc.....

Das Programm verwendet für die suche SQL bzw SQL-CLI.
Der Such-SQL wird entsprechend dynamisch erstellt und mit
PREPARE vorbereitet.

Nun zu meiner Frage.

Vor dem FETCH möchte ich nun prüfen ob SQL für die Ausführung des Statements einen bestehenden Zugriffspfad verwendet oder einen Temporär erstellen muß.
Falls einer erstellt wird wäre es interessant zu wissen wie lange dies dauern würde.

Sollten die "Kosten" zu hoch sein könnte ich den Benutzer auffordern die Suchparameter zu ändern.

Kann vlt. jemand weiterhelfen ???

[Fuerchau]

Dazu gibt es leider keine Unterstützung, da die Analyse nur zur Laufzeit tatsächlich durchgeführt wird.
In der QAQQINI kann hinterlegt werden, ob Diagnose-Nachrichten ins Joblog kommen.
Mittels CHGQRYA kann das QRYTIMLMT z.B. auf 1 gesetzt werden, so dass eine Abfrage fast nie ausgeführt wird.
Gibts nun einen SQLCOD -666, wird das Limit überschritten und die Analyse des Joblogs kann starten.

Allerdings würde ich einfach den CHGQRYA generell vorziehen, das Limit z.B. auf 10 Sekunden setzen und bei -666 den User bitten seine Abfrage zu spezifizieren.

[Rincewind]

So etwas kann man übrigens auch über ein normales (nicht on-the-fly) SQL lösen..


Select a, b, c from datei where

(:EingabeA = ' ' or :EingabeA = a) and
(:EingabeB = ' ' or :EingabeB = b) and
(:EingabeC = ' ' or :EingabeC = c)


Damit hast du immer denselben Zugriffsweg und die angenehmen Performancevorteile.

Damit habe ich die prepare Statements bei mir auf flexible Sortierung bzw flexible Feldauswahl eingeschränkt (was einen erheblichen Performancegewinn bringt)

Schönen Gruß
Rince

[sim]

Dazu gibt es leider keine Unterstützung, da die Analyse nur zur Laufzeit tatsächlich durchgeführt wird.
In der QAQQINI kann hinterlegt werden, ob Diagnose-Nachrichten ins Joblog kommen.
Mittels CHGQRYA kann das QRYTIMLMT z.B. auf 1 gesetzt werden, so dass eine Abfrage fast nie ausgeführt wird.
Gibts nun einen SQLCOD -666, wird das Limit überschritten und die Analyse des Joblogs kann starten.

Allerdings würde ich einfach den CHGQRYA generell vorziehen, das Limit z.B. auf 10 Sekunden setzen und bei -666 den User bitten seine Abfrage zu spezifizieren.

Das die Analyse erst zur Laufzeit erfolgen soll kann ich nicht ganz nachvollziehen. Wenn ich vor dem FETCH den Befehl
PRTSQLINF OBJ(*JOB) ausführe erhalte ich einen Spool mit genau den Informationen die ich benötigen würde.
siehe Beispiel

Für diese sollte es doch auch APIs geben ??

 STATEMENT NAME:  SQLSTATEMENT000003                                           
 select * from stamm where stmcnam  = ? and stmcnam1 = ? and upper(stvnm) =    
     upper(?) and upper(stnam) = upper(?)                                      
   SQL4021  Zugriffsplan zuletzt am 24.03.06 um 11:03:43 gesichert.            
   SQL4020  Geschätzte Abfrageausführungszeit beträgt 1 Sekunden.              
   SQL4017  Host-Variablen als wiederverwendbarer ODP implementiert.           
   SQL4006  Alle Indizes für Tabelle 1 berücksichtigt.                         
   SQL4008  Index STAMMRC02 für Tabelle 1 verwendet. 

[Fuerchau]

API's kann ich leider keine finden, haber siehe mal hier:
http://publib.boulder.ibm.com/infoce...69%6e%66%22%20

Die Informationen können sich mit dem tatsächlichen FETCH immer noch ändern, so dass die Daten erst richtig gültig sind, wenn Daten gelesen wurden.
Ansonsten ist es ein vorläufiger Zugriffsplan.

Es bleibt dir nichts anderes übrig als CHGQRYA, QAQQINI und die Joblog-Nachrichten zu verwenden.

Besser finde ich allerdings die Methode von Rince, da die Zugriffspläne sich dann nicht ändern und man alle Varianten vorher testen kann um bereits selber Indizees anzulegen.

[BenderD]

Hallo,

im Package stehen nur Informationen drin für "Varianten", die bereits ausgeführt wurden und selbst diese Informationen sind nicht zuverlässig: die Schätzun kann (grob) falsch sein und der Zugriffsplan kann bei der nächsten Ausführung ein anderer sein.
Bei dem Weg über QRYA, egal ob Job oder QAQQINI ist die Krux ebenfalls, dass die estimates ses Query Optimizers zuweilen per würfeln ermittelt werden - das hat mit der realen Ausführung oft nix zu tun; da werden aus 0 Sekunden schon mal Minuten und 20 Sekunden können ratz fatz um sein.
Kontrollieren lässt sich das nur über Restriktionen und weniger Dynamik, oder man kann durch entsprechendes Datenbank Design und Indexe vorbeugen und Problemkandidaten (per DBMON) ermitteln und nachbessern.

mfg

Dieter Bender

Das die Analyse erst zur Laufzeit erfolgen soll kann ich nicht ganz nachvollziehen. Wenn ich vor dem FETCH den Befehl
PRTSQLINF OBJ(*JOB) ausführe erhalte ich einen Spool mit genau den Informationen die ich benötigen würde.
siehe Beispiel

Für diese sollte es doch auch APIs geben ??

 STATEMENT NAME:  SQLSTATEMENT000003                                           
 select * from stamm where stmcnam  = ? and stmcnam1 = ? and upper(stvnm) =    
     upper(?) and upper(stnam) = upper(?)                                      
   SQL4021  Zugriffsplan zuletzt am 24.03.06 um 11:03:43 gesichert.            
   SQL4020  Geschätzte Abfrageausführungszeit beträgt 1 Sekunden.              
   SQL4017  Host-Variablen als wiederverwendbarer ODP implementiert.           
   SQL4006  Alle Indizes für Tabelle 1 berücksichtigt.                         
   SQL4008  Index STAMMRC02 für Tabelle 1 verwendet. 

[Fuerchau]

Dem kann ich auch nur zustimmen.
Es gibt schon mal wesentliche Unterschiede zwischen STRSQL (weil Dialog) und embedded SQL/ODBC (weil Batch).
Bei ODBC setze ich die QueryTimeouts mittlerweile auf 30.000 Sekunden, da die Schätzungen häufig um Faktor 1000! daneben liegen. Die tatsächliche spätere Abfragezeit bewegt sich dann zwischen 1 und 30 Sekunden.

Da fragt man sich, was der Optimizer? da wohl so treibt !

[BenderD]

Hallo,

mit der angeblich so grandiosen neuen Query Engine zunehmend Dummfug, mit parallel Database Feature entdeckt die Query engine ihr Herz für full table scans mit grandiosem Ressourcenverbrauch wahrscheinlich wird mit dem nächsten Group PTF dann die automatische Hardwarebestellung ermöglicht...

mfg

Dieter Bender

Dem kann ich auch nur zustimmen.
Es gibt schon mal wesentliche Unterschiede zwischen STRSQL (weil Dialog) und embedded SQL/ODBC (weil Batch).
Bei ODBC setze ich die QueryTimeouts mittlerweile auf 30.000 Sekunden, da die Schätzungen häufig um Faktor 1000! daneben liegen. Die tatsächliche spätere Abfragezeit bewegt sich dann zwischen 1 und 30 Sekunden.

Da fragt man sich, was der Optimizer? da wohl so treibt !

[mwithake]

So etwas kann man übrigens auch über ein normales (nicht on-the-fly) SQL lösen..


Select a, b, c from datei where

(:EingabeA = ' ' or :EingabeA = a) and
(:EingabeB = ' ' or :EingabeB = b) and
(:EingabeC = ' ' or :EingabeC = c)


Damit hast du immer denselben Zugriffsweg und die angenehmen Performancevorteile.

Damit habe ich die prepare Statements bei mir auf flexible Sortierung bzw flexible Feldauswahl eingeschränkt (was einen erheblichen Performancegewinn bringt)

Schönen Gruß
Rince

So etwas hat mit performanten SQL nichts mehr zu tun. Diese Logik führt dazu, das die Abfrage immer in einem kompletten Table-Scan endet.

Ich habe das einmal Beispielhaft an eine Datei mit 2.1 Mio Sätzen durchgeführt. In der WHERE-Bedingung stehen zwei Parameter, einmal direkt angegeben und einmal mit der geklammerten OR-Angabe, Index über diese beiden Werte vorhanden.
Zeiten aus dem VE:
195234 Mikrosekunden Direktangabe
12920528 Mikrosekungen geklammerte OR-Angabe.

Mit solchen OR-Abfrage kann der Optimizer nichts mehr anfangen. Da ist eine prepare-Abfrage immer vorzuziehen. Statisches SQL macht nur bei bekannter Parameter-Anzahl Sinn.

Bei dem Problem von sim wäre es besser, für gängige Abfragefelder Indizies aufzubauen. Nicht so häufig benutzte Felder sollten separat mit dem Hinweis auf die lange Ausführdauer aufgeführt werden (eventuell separatem Window über Funktionstaste).

Gruß
M.Withake