Grund für das System.Transaktionen.TransactionInDoubtException
Ich habe 2 Jobs, Lesen und erzeugen von Daten in einer Sql Server-Datenbank. Jeder einmal in eine Weile die Arbeitsplätze Absturz mit System.Transaktionen.TransactionInDoubtException. Die genauen StackTrace:
Unhandled Exception: System.Transactions.TransactionInDoubtException: The transaction is in doubt. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception: The wait operation timed out. Exitcode: -532462766
--- End of inner exception stack trace ---
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
Googelte ich ein bisschen und fand etwas über MSDTC, aber ich glaube, das kann nicht das problem sein, da die Transaktion sollte lokal sein, da die jobs nur auf einer einzigen Datenbank. Die folgende Abfrage:
SELECT cntr_value AS NumOfDeadLocks
FROM sys.dm_os_performance_counters
WHERE object_name = 'SQLServer:Locks'
AND counter_name = 'Number of Deadlocks/sec'
AND instance_name = '_Total'
zeigt, dass es keine deadlocks auf der Datenbank, so dass deadlocks können nicht der Grund sein. Ich konnte nicht finden, dass jede andere Ressource auf dem internet, gibt genaue Informationen über die Ursache der Ausnahme. Also hat jemand eine Idee was der Grund sein könnte oder wie man die Wurzel dieses Fehlers?
InformationsquelleAutor Tim de Putter | 2014-04-16
Du musst angemeldet sein, um einen Kommentar abzugeben.
Selbst wenn die Transaktion lokale Transaktion wird noch eskaliert, um die MSDTC-wenn Sie öffnen mehrere verbindungen in derselben Transaktion Umfang, laut diesem Artikel: http://msdn.microsoft.com/en-us/library/ms229978(v=vs. 110).aspx
HINWEIS: ich habe einige Artikel, die erklären, dass dies nur für SQL 2005 und SQL 2008+ schlauer über die MSDTC-Förderung. Diese besagen, dass SQL 2008 nur Förderung für MSDTC, wenn mehrere verbindungen offen sind gleichzeitig. Siehe: TransactionScope automatisch eskalieren, um MSDTC auf einigen Maschinen?
Ebenfalls, Ihre innere Ausnahme ist ein
Timeout
(System.Daten.SqlClient.SqlException: Timeout abgelaufen ist), nicht eineDeadlock
. Während die beiden verwandt sind zu blockieren, werden Sie nicht die gleiche Sache. Eintimeout
tritt auf, wenn die Blockierung bewirkt, dass die Anwendung zu stoppen und warten auf eine Ressource blockiert ist, durch eine andere Verbindung, so dass die aktuelle Anweisung erhalten können sperren auf die Ressource. Eindeadlock
tritt auf, wenn zwei verschiedene Anschlüsse sind im Wettbewerb um die gleichen Ressourcen, und Sie blockiert sind, in einer Weise, die Sie nie in der Lage sein zu vervollständigen, wenn Sie eine der verbindungen ist beendet (deshalb das deadlock-Fehlermeldungen sagen "Transaktion... wurde als deadlock-Opfer ausgewählt"). Da Sie Ihre Fehler ein Timeout, das erklärt, warum Sie die deadlock-Abfrage eine 0 zu zählen.System.Transactions.TransactionInDoubtException
von der MSDN-Website (http://msdn.microsoft.com/en-us/library/system.transactions.transactionindoubtexception(v=vs. 110).aspx) Staaten:Grund: etwas ist aufgetreten, während die
TransactionScope
verursacht es ist-Status unbekannt, am Ende der Transaktion.Die Ursache: Es könnte eine Reihe verschiedener Ursachen, aber es ist schwer zu identifizieren, Ihre spezifische Ursache, ohne den source-code gepostet.
Dinge zu überprüfen:
System.Transactions.TransactionScope
ist, wegen der Art, dass SQL Server automatisch ein Rollback der Transaktion, wenn ein timeout oder ein deadlock Auftritt.InformationsquelleAutor BateTech
Ich hatte auch mal dieses ""Transaktion ist im Zweifel" beim Versuch, eine Transaktion abzuschließen Umfang enthalten Aufrufe an eine Datenbank zugeordnet, die via entity framework. Einer der Anrufe, die via entity framework wurde um eine gespeicherte Prozedur mit einer select-Anweisung mit dem Befehl "
with(tablock, holdlock)
". Die Lösung schien für mich arbeiten, war ein Telefonat mitDispose()
auf das Ergebnis von der gespeicherten Prozedur zurückgegeben -- dachte sogar, dass die gespeicherte Prozedur und sagte nur "Return 0
". Diese scheinbar befreit, bis die Ressource.InformationsquelleAutor Chris Ward
Hinzufügen @BateTech ausgezeichnete Antwort, falls dies jemandem hilft, ich hatte zu Debuggen genau das gleiche Szenario wie er beschreibt, mit mehreren offenen asynchronen verbindungen, die in einem Methode. Die asynchronen Aufrufe wurden individuell erwartete, aber die Signatur der Methode an sich war '
async void
' (!). Die wichtige Sache über async ist, dass, wenn du gehst, es zu tun, Sie sollte es tun, vom entry-Punkt bis ganz nach unten.InformationsquelleAutor Ciaran