Anzeige restlicher Abfragezeit eines Select Command

verwendetes Datenbanksystem: MS SQL Server 2012

Hallo,

ich muss in meiner App anzeigen, wie lange meine DB Abfrage noch
benötigt. Sie läuft so ca. 70-120 min. Mein Kunde möchte also eine
Anzeige (ProgressBar), die Anzeigt wie lange die Select Abfrage noch benötigt.

Ich habe in sys.dm_exec_requests gesehen, das es da eine Spalte percent_complete
gibt.

SELECT * FROM sys.dm_exec_requests

...

Nur wird dieser Wert für ein Select Command nicht vom DBMS gefüllt.

Gibt es da eine andere Lösung?

Gruss Mike

TSQL : % Percentage complete of running requests
Der Rest lässt sich mittels 3-Satz ausrechnen, aber auch nur in etwa.

Danke für diese schnelle Antwort!

Nur wird diese percent_complete nicht für ein/mein SELECT befüllt!?

Percentage of work completed for the following commands:

ALTER INDEX REORGANIZE  

AUTO_SHRINK option with ALTER DATABASE  

BACKUP DATABASE  

DBCC CHECKDB  

DBCC CHECKFILEGROUP  

DBCC CHECKTABLE  

DBCC INDEXDEFRAG  

DBCC SHRINKDATABASE  

DBCC SHRINKFILE  

RECOVERY  

RESTORE DATABASE,  

ROLLBACK  

TDE ENCRYPTION  

ich weiss nicht ob da ein select bei ist?

Ach normale Queries, Sorry...percent_complete bezieht sich auf Backup bzw. Restore.
Ein simpler Query selbst, also Select XYZ FROM.. kann keine genaue Endzeit haben. Für die Dauer eines Queries gibt es viele Faktoren, zB Locks/Blocks von anderen Queries etc die unvorhersehbar sind.

In Oracle kann man den Zustand von "Long Operating Queries" anschauen, aber ich weiß nicht, ob das für jeden Query gilt oder für die genaue Zeit.
Bei Microsoft gibt es das nicht; Microsoft Reseach forscht aber an einer Möglichkeit der genauen Analyse (siehe Estimating Progress of Execution for SQL Queries ).

Dir bleibt bei einer normalen Abfrage nur aus Erfahrung zu schätzen, wann der Query zu Ende ist.

Was tut eine SELECT Abfrage die 2 Stunden läuft? Anzeigen und ansehen wollen kann diese Datenmenge ja keiner mehr.
Vielleicht hast du ein übles Performanceproblem in deiner Datenbank. Wenn dem so ist und du das lösen kannst, kriegst du möglicherweise so traumhafte Abfragezeiten dass keiner mehr an einer Zeitschätzung interessiert ist.

@chilic:

Sag das mal nicht zu laut ^^

Unsere Kunden starten manche Funktionen am Abend um am nächsten Tag das Ergebnis anschauen zu können.
Das sind dann aber auch enorme Datenmengen und ich rede nicht von ein paar 100.000 Datensätzen. Dazu kommt dann noch, dass das ganze System sehr komplex ist, die Abfragen sind teilweise recht komplex.
Klar, wie können sicher eine menbe Optimieren, aber so oder so braucht es seine Zeit, große Mengen von der Festplatte zu lesen.

Was die Anzeige der verbleibenden Zeit angeht, müssen unsere Kunden aber auch verzichten.
Sie bekommen nur eine ProgessBar, wo dann die Schritte angezeigt werden.

@mikefried:

Wenn es nur um das Anzeigen geht, dann würde ich Lazy Loading vorschlagen. Dann muss der Kunde nur solange warten, bis der sichtbare Bereich geladen wurde und das Programm lädt dann im Hintergrund unbemerkt weiter. Wenn er nicht zu schnell scrollt, merkt er das Laden kaum.
Bei sehr großen und komplexeren Datenmengen sollten die dann aber nicht im Speicher bleiben. Da bietet sich dann eine lokale Datenbank-Datei an, deren Schema so aufgebaut ist, dass die geladenen Daten optimal abgerufen oder durchsucht werden können. Dann müssen die Daten nicht mehr zusammen gesetzt, sondern einfach nur aus einer oder zwei Tabellen zusammen ausgelesen werden.

Eventuell bietet es sich auch an, eine feste Anzahl Zeilen zu erfragen, die gelesen werden sollen. In so einem Fall lässt sich leichter die Zeit abschätzen, aber auch hier kommen Faktoren dazu, die du unmöglich mit einplanen kannst.

Hallo!

Vielen Dank für Eure Antworten...

Meine Lösung wird woll irgendwo in der Mitte liegen.

Mike

Miss jedes mal die Zeit... dann den Durchschnitt + ein paar Prozent ... das ist die erwartete Laufzeit...

Je nachdem wie gross die Unterschiede von Tag zu Tag sind... triffst Du es dann besser oder schlechter.