SQL Prepare - Verwendeter Zugriffspfad ?

[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 !