das kann auch damit zusammen hängen für wieviele Zeilen des ResultSets optimiert wird! Die ermittelten Zeiten hängen zudem von der Balance der Indexbäume und den entsprechenden Runstats zusammen (müsste frei nach Theorie mit zunehmender SQE besser werden, tut aber oft nicht). Bei mehreren Join Dateien und Optimierung für alle Sätze kommen hier schnell krasse Fehler zusammen. Optimize for 10 rows ist da ein weiterer Workaround dem Hang zu full Table scans und Indexaufbauten auszuweichen.
Was generierte Zugriffe angeht ist bei solchen Joins das vorziehen der Selektion und anschließendem Join von Temp Tables für komplexe Queries im BI Bereich gerade auf stärkeren Maschinen nach meinen Erfahrungen im Schnitt die bessere Strategie.

D*B

Zitat Zitat von Fuerchau Beitrag anzeigen
Was einfach mein Hauptproblem ist, ist dieser blöde SQL0666 (Zeitlimit), der überhaupt nichts mit dem späteren tatsächlichen SQL zu tun hat.

Wie ist zu erklären, dass (ich nehme mal an) die CQE auf 40.000 Sekunden kommt (stelle ich den Timeout auf NOMAX (-1)) kommt der 1. Block aber nach ca. 100 Sekunden, und die SQE 400 Sekunden annimmt und das Ergebnis in 13 Sekunden liefert ?
Diese Zeitschätzungen halten meist mehr auf, als sie tatsächlich wert sind.
Ich habe ehrlich noch nie eine annähernd korrekte Schätzung erlebt.
Gut, ich gebe zu, dass meine SQL's manchmal nicht so einfach sind.

Da ich aber mit einem BI-Programm (das ist die FTSolutions) auf vorhandene ERP's zugreife kommt natürlich eine Umstellung der fremden ERP nicht in Frage.