Ausführungstimeout

  • VB.NET

Es gibt 19 Antworten in diesem Thema. Der letzte Beitrag () ist von broesel68.

    Ausführungstimeout

    Hallo zusammen!

    Ich fülle ein Datagridview in VB.NET mit folgender SQL Abfrage:

    SQL-Abfrage

    1. SELECT DISTINCT ISNULL
    2. ((SELECT Kennzeichen FROM dbo.Tourenzuordnung
    3. WHERE (Fahrzeug = dbo.tbl_Kommissionierung.Fahrzeug)), 'Abholer') AS KennzeichenNeu, Fixdatum, TourNr, Gedruckt, ISNULL(TourID, N'800 | ' + CONVERT(varchar(12), Fixdatum, 104)) AS TourID, RIGHT(TourNr, 1) AS TourErmittelt
    4. FROM dbo.tbl_Kommissionierung
    5. WHERE (Fixdatum = CONVERT(DATETIME, '2024-06-26 00:00:00', 102))

    Zwischendurch kommt immer mal wieder: Das Ausführungstimeout ist abgelaufen: Der Timeoutzeitraum wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht.
    Wenn ich dann die Abfrage im Managementstudio laufen lasse, dann dauert die Abfrage fast 2 Minuten.

    Kurze Zeit später läuft sie wieder normal.
    Kann das mit der Abfrage zusammen hängen oder mit der Verbindung zum MS SQL-Server?

    Ich habe auch schon probiert, eine VIEW mit der Abfrage zu erstellen, und dann das Datagridview damit zu füllen.
    Aber das gleiche Ergebnis.
    Die Timeout-Meldung kommt ca. 5 mal am Tag.

    Welche Methode ist generell sinnvoller? Eine View zu erstellen oder direkt über die SQL-Abfrage?

    Bei einer View ist der Code in VB.Net dann dementsprechend kürzer.


    Vielen Dank und Grüße!

    Nun, wenn die Abfrage auch im SQL Studio so lange dauert, dann liegt es erst mal nicht an der VB.NET.
    Was bei DB erst Mal ganz entscheidend ist, ob die Spalten, über die man die Abfrage laufen lässt auch einen Index haben?

    Ich habe mir generell Views im SQL Server gebaut, von den größeren Abfragen, die ich an vielen Stellen benötige. Das macht den Code im VB.NET erst mal übersichtlicher. Eine direkte Leistungssteigerung habe ich nicht bemerkt.

    Welche Größe bzw. exakter Wiviel Zeilen hat denn die Tabelle TourErmittelt und tbl_Kommissionierung?

    broesel68 schrieb:

    Das Ausführungstimeout ist abgelaufen
    Das lässt sich notfalls mit dem CommandTimeout erhöhen. Aber welcher User wartet freiwillig so lange?

    broesel68 schrieb:

    Wenn ich dann die Abfrage im Managementstudio laufen lasse, dann dauert die Abfrage fast 2 Minuten.
    Dann würde ich wirklich die DB optimieren (Indexe etc.).

    broesel68 schrieb:

    Die Tabelle tbl_Kommissionierung hat rund 230.000 Zeilen.
    Für einen MS-SQL-Server ist das Kleinkram.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    broesel68 schrieb:

    Wenn ich dann die Abfrage im Managementstudio laufen lasse, dann dauert die Abfrage fast 2 Minuten.

    Kurze Zeit später läuft sie wieder normal.
    Teste zu einem solchen Zeitpunkt nicht die richtige Query, sondern eine super simple Query Select Top 1 Kennzeichen From Tourenzuordnung, wenn die auch Zeit beansprucht, dann ist da irgendein anderer Prozess in diesem Moment mit der Tabelle oder der ganzen Datenbank zu Gange. Da hilft auch kein Index.

    Fünf mal am Tag, sind das vielleicht feste Uhrzeiten?

    Als Join, aber ich denke das hat damit nichts zu tun; die Query schafft es ja meistens schnell zu laufen. Wobei wir nicht wissen was schnell ist, in diesem Fall.

    SQL-Abfrage

    1. Select Distinct Isnull(t.Kennzeichen, 'Abholer') As KennzeichenNeu, k.Fixdatum, k.TourNr, k.Gedruckt,
    2. Isnull(k.TourID, N'800 | ' + CONVERT(varchar(12), k.Fixdatum, 104)) AS TourID, Right(k.TourNr, 1) As TourErmittelt
    3. From tbl_Kommissionierung k
    4. Left Join Tourenzuordnung t On t.Fahrzeug = k.Fahrzeug
    5. Where k.Fixdatum = '2024-06-26T00:00:00'

    Dann ist zu der Zeit der SQL-Server überlastet.
    Ich nehme an, du hast keine Möglichkeit und keinen Einfluss, das zu analysieren und ggf. zu beheben.

    Dann gibt's nur die Möglichkeit, dass du den CommandTimeout höher setzt oder aber bei Abbruch eine Fehlermeldung ausgibst.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Bin jetzt zufällig bei dem Problem auf dem SQL-Server angemeldet als das Problem aufgetreten ist.
    Da habe ich die Abfrage im Sql Fenster ausgeführt, und es kam die Meldung

    "Die Transaktion (Prozess-ID 79) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus."
    Scheint also eine Transaktion zu sein, die blockiert.
    Wenn ich das richtig verstehe, dann wird in die Tabelle geschrieben, während die Abfrage darauf zugreifen möchte.

    Coldfire schrieb:

    READ UNCOMMITTED
    Kenne ich nur für T-SQL als Isolation Level.

    Ich glaube allerdings nicht, dass für das ursprüngliche Problem Locks die Ursache sind, sondern eher die Server-Auslastung durch gelegentliche Massen-Updates (oder sonstige umfangreiche Transaktionen).
    Das würde zumindest meine Erfahrung widerspiegeln.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Es geht definitiv nicht darum einen Deadlock hier zu beseitigen.
    Jetzt weiß ich nicht was ein verringertes Isolationslevel bewirkt. Heißt das, die Abfrage setzt selbst ein schwächeres Lock oder ignoriert sie bestimmte Locks anderer Transaktionen?
    Im letzteren Fall würde das dann eventuell auch Effekt haben auf das sporadische Warten, aber das Ergebnis wird dadurch unzuverlässig. Das ist kann alles andere als erwünscht sein.

    Also aus Post nr 13 schließe ich auf Deadlock. Die sind eigentlich nur bei 2 schreibenden Porzessen unlösbar. Da die Abfrage aber lesend ist, ist diese Lese-Abfrage möglicherweise mit Isolation level DatenSperre versehen sprich: ich will beim Lesen nicht dass irgendein anderer Prozess währenddessen die Daten ändert. Mit READ UNCOMMITTED sagst du nun, egal nicht so schlimm. Wenn dann die Timeouts weg sind, ist der Schuldige besser zu identifizieren. Denn welcher 2. Prozess macht da Ärger ? dazu Gibts für MS SQL Server Performance Monitoring and Tuning Tools. Das ist aber meinen Erinnerungen nach nicht simpel.

    Jo, das ist ein Deadlock in Post 13 und in Post 14 steht auch wo der vermutlich (Auch da müssten die Sterne günstig stehen würde ich sagen) herkommt.
    Ist hier nicht das eigentliche Problem. Das eigentliche Problem ist eine Abfrage die sporadisch warten muss auf parallele Datenbank-Aktivitäten. Siehe Post 1

    Weiß nicht ob ein geringeres Isolationslevel da auch helfen kann. Für unmöglich halte ich es nicht aber ich kenn mich nicht aus. Was ich jedoch weiß ist, dass uncommitede Daten lesen in vielen Szenarien unerwünschte Falschinformation liefert.