2
MSSql Server - Select gibt sporadisch keinen Wert zurück
Hallo zusammen,
ich stehe vor einem kuriosen Verhalten und hoffe auf Tipps, wie ich dem auf die Spur kommen kann:
Wir haben eine Anwendung, die laufend Datensätze in einer Datenbank abfragt und z.T. auch aktualisiert. Parallel dazu haben wir eine zweite Anwendung, die auf eine der Tabellen Select-Statements absetzt und mit dem zurückgelieferten Wert innerhalb der Anwendung weiterarbeiten soll.
Vor kurzem bekamen wir nun die Meldung, dass die zweite Anwendung sporadisch keine Ergebnisse zurückerhält. Das Verhalten ist reproduzierbar, hängt nicht vom gewählten datensatz ab und tritt bei allen Anwendern an allen Rechnern sporadisch auf. Nach erster Analyse per Trace-Log wird in der Datenbank der jeweils scheiternde Datensatz zu diesem Zeitpunkt weder selektiert noch aktualisiert / gelöscht. Kurz zuvor wird durch Anwendung 1 jedoch eine Transaktion ausgeführt, durch welche ein Update auf einer anderen Tabelle und ein Select auf die benötigte Tabelle durchgeführt wird.
Setze ich das scheinbar nichts zurück gebende Select-Statement der Anwendung 2 anschließend erneut ab, erhalte ich das gewünschte Ergebnis.
Für mich macht es den Eindruck, als würde die Anwendung 2 aufgrund einer Sperre, ausgelöst durch Anwendung 1, kein Ergebnis zurück erhalten. Ich hätte in einem solchen Fall jedoch eine Fehlermeldung erwartet (Deadlock, TimeOut, o.ä.). Davon ist im Log allerdings nichts zu sehen. Statt dessen wird "einfach" nur kein Ergebnis zurückgeliefert. Im Log ist ersichtlich, dass die Anfrage meiner Anwendung 2 am SQL-Server ankommt und in diesem Moment tatsächlich 0 Rows zurückliefert.
Habt ihr eine Idee, wie es zu diesem Systemverhalten kommen kann? Ich mache mich auch gerne über Links oder Stichworte per Recherche dann selbst schlau, mir fehlt aber der Suchansatz.
Danke vorab & viele Grüße
mkdeluxe
ich stehe vor einem kuriosen Verhalten und hoffe auf Tipps, wie ich dem auf die Spur kommen kann:
Wir haben eine Anwendung, die laufend Datensätze in einer Datenbank abfragt und z.T. auch aktualisiert. Parallel dazu haben wir eine zweite Anwendung, die auf eine der Tabellen Select-Statements absetzt und mit dem zurückgelieferten Wert innerhalb der Anwendung weiterarbeiten soll.
Vor kurzem bekamen wir nun die Meldung, dass die zweite Anwendung sporadisch keine Ergebnisse zurückerhält. Das Verhalten ist reproduzierbar, hängt nicht vom gewählten datensatz ab und tritt bei allen Anwendern an allen Rechnern sporadisch auf. Nach erster Analyse per Trace-Log wird in der Datenbank der jeweils scheiternde Datensatz zu diesem Zeitpunkt weder selektiert noch aktualisiert / gelöscht. Kurz zuvor wird durch Anwendung 1 jedoch eine Transaktion ausgeführt, durch welche ein Update auf einer anderen Tabelle und ein Select auf die benötigte Tabelle durchgeführt wird.
Setze ich das scheinbar nichts zurück gebende Select-Statement der Anwendung 2 anschließend erneut ab, erhalte ich das gewünschte Ergebnis.
Für mich macht es den Eindruck, als würde die Anwendung 2 aufgrund einer Sperre, ausgelöst durch Anwendung 1, kein Ergebnis zurück erhalten. Ich hätte in einem solchen Fall jedoch eine Fehlermeldung erwartet (Deadlock, TimeOut, o.ä.). Davon ist im Log allerdings nichts zu sehen. Statt dessen wird "einfach" nur kein Ergebnis zurückgeliefert. Im Log ist ersichtlich, dass die Anfrage meiner Anwendung 2 am SQL-Server ankommt und in diesem Moment tatsächlich 0 Rows zurückliefert.
Habt ihr eine Idee, wie es zu diesem Systemverhalten kommen kann? Ich mache mich auch gerne über Links oder Stichworte per Recherche dann selbst schlau, mir fehlt aber der Suchansatz.
Danke vorab & viele Grüße
mkdeluxe
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 265095
Url: https://administrator.de/contentid/265095
Ausgedruckt am: 25.11.2024 um 07:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo mkdeluxe,
wie sieht es mit Triggern und Fremdschlüsseln auf den betroffenen Tabellen aus?
Hast Du das Lesen schonmal mit den Tabellenhinweisen readpast (Stand vor der Transaktion) oder nolock (momentaner Stand, dirty) probiert?
Hast Du den Profiler schonmal die einzelnen Befehle mitprotokollieren lassen?
Und wenn das Ganze reproduzierbar ist, dann muß doch schon ein erster Hinweis auf die Ursache da sein, oder wie kannst Du den Fehler erzeugen?
Gruß, Mad Max
wie sieht es mit Triggern und Fremdschlüsseln auf den betroffenen Tabellen aus?
Hast Du das Lesen schonmal mit den Tabellenhinweisen readpast (Stand vor der Transaktion) oder nolock (momentaner Stand, dirty) probiert?
Hast Du den Profiler schonmal die einzelnen Befehle mitprotokollieren lassen?
Und wenn das Ganze reproduzierbar ist, dann muß doch schon ein erster Hinweis auf die Ursache da sein, oder wie kannst Du den Fehler erzeugen?
Gruß, Mad Max
Hallo Mad Max,
vielen Dank für deine Antwort! Ich war leider ein paar Tage ohne Netz unterwegs, sorry für die späte Rückmeldung!
Reproduzierbar ist es, indem ich nach dem Zufallsprinzip durch eine Auswahlliste klicke, die dann für den jeweils ausgewählten Eintrag das Select-Statement absetzt, um zusätzliche Daten abzuholen. Inhaltlich ist da für mich kein Ansatzpunkt, weil es bei den gleichen Datensätzen mal funktioniert und ein anderes mal nicht. Von Zeitpunkt her sieht man im Profilerlog, dass, ausgelöst durch die erste Anwendung, zu diesem Zeitpunkt eine Transaktion mit Updates auf eine andere Tabelle in der DB ausgeführt wird. Danke für die Hinweise zu den Triggern und zum Lesen mit Tabellenhinweisen. Das werde ich mir gleich mal am System ansehen.
Viele Grüße
mkdeluxe
vielen Dank für deine Antwort! Ich war leider ein paar Tage ohne Netz unterwegs, sorry für die späte Rückmeldung!
Reproduzierbar ist es, indem ich nach dem Zufallsprinzip durch eine Auswahlliste klicke, die dann für den jeweils ausgewählten Eintrag das Select-Statement absetzt, um zusätzliche Daten abzuholen. Inhaltlich ist da für mich kein Ansatzpunkt, weil es bei den gleichen Datensätzen mal funktioniert und ein anderes mal nicht. Von Zeitpunkt her sieht man im Profilerlog, dass, ausgelöst durch die erste Anwendung, zu diesem Zeitpunkt eine Transaktion mit Updates auf eine andere Tabelle in der DB ausgeführt wird. Danke für die Hinweise zu den Triggern und zum Lesen mit Tabellenhinweisen. Das werde ich mir gleich mal am System ansehen.
Viele Grüße
mkdeluxe
