Hallo Birgitta,

da gehen mir doch ein paar Dinge an der Praxis vorbei:
eine unter Verwendung von SQL geschriebene Anwendung hat hunderte von SQL Statements, wenn nicht tausende, da helfen mir Werkzeuge wie Ooops Nerv überhaupt nichts und eine Optimierung Statement für Statement ist völlig inakzeptabel. Die gängige Vorgehensweise ist dabei:
- sauberes Design der Datenbank mit primary Keys für jede Table und referential Constraints für alle Key Beziehungen der Normalisierung, damit sind die wichtigsten Keys angelegt.
- klare Schichtentrennung in der Anwendung mit einer klar definierten Datenbank Zugriffs Schicht, damit ist alles für Optimierungen zentralisiert.
- first do it right, then make it fast also schreiben der Datenbankzugriffe orientiert am Anwender, nicht an der Datenbank (und kein Anwender versteht, wenn ihm die Datenbank Engine nach jedem PTF eine andere Reihenfolge präsentiert!!!)
- Messung mit Database Monitor und Optimierung des Index Designs
- jetzt bleiben maximal 1 % der Zugriffe über, die man in der Anwendung noch optimiert und das wars.

Zu deinen Messungen noch: die Laufzeiten sind allesamt völlig inakzeptabel (sowohl 56, wie auch 200 sec sind für jede Anwendung zuviel!) und man sollte zuerst der Sache auf den Grund gehen, warum da full Table Scans gemacht werden!!!

Zu den EVIs: ich habe noch keine Konstellation gefunden, in der ein EVI jemals verwendet wurde, geschweige denn was gebracht hätte und die Empfehlung in den Handbüchern diese Dinger vor Updates zu löschen und danach wieder aufzubauen (hat bei 500 Millionen Sätzen und 2 Ausprägungen eines 3 stelligen Mandanten Keys ca. 90 Minuten gedauert!!! und anschließend hat die famose neue Query Engine einen full tablescan gemacht???), kann ja nur ein Scherz sein.

mfg

Dieter