Hallo Alfredo,

wenn Du SQL z.B. mit native I/O vergleichst, evt. auch mit OPNQRYF darfst Du niemals nach der ersten Ausführung gehen.

Bei der ersten Ausführung mit SQL läuft der komplette Optimierungs-Prozess, mit Erstellung/Validierung der Access Plans, Prüfen der vorhandenen Zugriffs-Wege und Aufbau/Öffnen des verwendeten Daten Pfades (ODPs). Nach der ersten Ausführung wird der ODP wieder geschlossen. Beim zweiten Durchlauf wird der Access Plan nochmals geprüft und der ODP erneut aufgebaut. Erst nach dem zweiten Aufruf bleibt der ODP geöffnet und kann immer wieder verwendet werden. Und erst nach diesem Aufruf kann SQL mit native I/O verglichen werden. Und erst ab dem 3. Aufruf wird SQL schneller als native I/O.

Wie Dieter bereits gesagt hat ist auch das Fetchen eines einzelnen Satzes signifikat langsamer als ein Fetch in eine Mehr-Dimensionale-Datenstruktur (vor V5R3) oder in eine Array-Datenstruktur (ab V5R3). Ebenso kann durch die Angabe von FOR READ ONLY oder FOR FETCH ONLY eine Performanceverbesserung erreicht werden, da in diesem Fall auf alle Fälle geblockt gelesen wird. Select-Statement, die über Cursor verarbeitet werden und nicht von Natur aus READ ONLY sind (z.B. durch Join-Anweisungen, Order By oder Group By-Anweisungen), sind updatefähig. Diese Update-Fähigkeit verhindert u.U. ein geblocktes Lesen.

Ich weiß jetzt nicht auf welcher Basis Du Deine Tests gemacht hast, aber solltest Du die logische Datei im SQL angegeben haben, muss ein rerouting von der SQE (SQL-Quera-Engine) zur CQE (Classic Query Engine) erfolgen, was bis zu 10% Performance kosten kann. OPNQRYF dagegen kann die logische Datei direkt verarbeiten, da OPNQRYF eine alte Technolgie und kein SQL ist.

Deine Ergebnisse in Ehren, aber ohne genauere Informationen, wie die Statements aussehen, bzw. aufgerufen wurden, kann man dazu nichts sagen. Weiterhin würde ich ihnen ohne detaillierte Analyse über DBMON keinen Glauben schenken.

Birgitta