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
Zitat Zitat von sim
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 ??

PHP-Code:
 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