Ich verwende LINQ to SQL und ein Drittanbieter-SDK, das verteilte Transaktionen unterstützt. Wenn ich feststelle, dass ein ausstehendes Update sowohl SQL-Datensätze als auch Datensätze im SDK von Drittanbietern aktualisiert, erstelle ich ein TransactionScope mit einem Timeout von 0 (vermutlich unendlich) (obwohl ich auch 12 Stunden als Zeitspannenparameter probiert habe). Dann verwende ich GetDtcTransaction für die Ambient-Transaktion (erstellt von transactionscope), um eine DTC-Transaktion zur Verknüpfung mit dem SDK des Drittanbieters abzurufen. Die Dinge funktionieren gut für etwa 10 Minuten, aber nach 10 Minuten verschwindet die Transaktion und ein Fehler tritt auf. Wie ermittle ich, warum die Transaktion verschwindet? Ich vermute, es ist ein Timeout, weil es regelmäßig nach 10 Minuten auftritt, obwohl zu diesem Zeitpunkt etwas unterschiedliche Arbeit geleistet wurde. Aber ich bin ratlos darüber, wie ich feststellen kann, was die Transaktion beendet hat, warum und wie ich ihr Leben verlängern kann.
Ich habe versucht, die folgenden Ereignisse mit SQL Profiler zu verfolgen:
Alles was ich über die Zeit des Fehlers verstehe sind diese Ereignisse:
%Vor%EventSubClass 16 für das Ereignis DBTCransaction gibt an, dass die Transaktion abgebrochen wird.
Um das Zeitlimit zu verlängern, das standardmäßig 10 Minuten beträgt, wenn es nicht angegeben ist, muss C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ Machine.config auf dem Zielsystem aktualisiert werden (siehe C) : \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG, wenn Sie 64-Bit ausführen). Fügen Sie dies als letztes Element direkt unter der Stammebene hinzu:
%Vor%Dies wird (als Beispiel) das Timeout auf 23 Stunden setzen.
Der effektive Wert ist in System.Transactions.TransactionManager.MaximumTimeout
sichtbarKönnte es sein, dass das SqlConnection-Timing ausgeht und nicht die verteilte Transaktion?
Sie könnten den SQL Server Profiler verwenden, um einen unerwarteten Verbindungsabbruch zu versuchen und zu überwachen . Sie sollten nur darauf achten, dass das Trace-Profil nur die Ereignisse enthält, die Sie überwachen müssen, da die Ausgabe ziemlich ausführlich ist. Ich würde damit beginnen, nur die Ereignisse "Audit Login" und "Audit Logout" zu überwachen, die unter der Ereigniskategorie "Security Audit" zu finden sind.
Wenn Sie auf einer anderen als einer eigenständigen / allein verwendeten SQL Server-Instanz profilieren, sollten Sie wahrscheinlich einen Filter anwenden, sodass nur Ereignisse von Ihrem Host in der Ausgabe angezeigt werden.
Sie können explizit einen Zeitüberschreitungswert in Ihrer Verbindungszeichenfolge angeben - setze es wirklich niedrig und schau, ob du das gleiche Verhalten viel schneller bekommst.
In Ihrem Ablaufverfolgungsprotokoll werden zwei Ausnahmen angezeigt, deren Details lauten:
Das Googeln für die 1222-Ausnahme ergab Ссылка , das besagt:
Dieser Fehler bedeutet, dass eine Sperre war angefordert in msdb und abgelaufen. Normalerweise wird das bedeuten, dass es ein ist große Transaktion auf einem großen Temp-Tisch oder eine große Sorte oder etwas von diesem Typ.
Haben Sie besonders? lang laufende Abfragen, die sein könnten mit ihr verbundenen? Vielleicht schwer Dienstbericht oder etwas Ähnliches das?
Hoffentlich bringt dich das ein bisschen weiter.
Dies ist wahrscheinlich für alle Leser außer mir offensichtlich, aber ich habe mich gerade in diesem Thema festgefahren und wollte erwähnen, wie ich es behoben habe. Obwohl ich die Datei an dem von BlueMonkMN angegebenen Speicherort änderte, empfing ich immer noch das Standard-Transaktionszeitlimit von 10 Minuten. Da ich Windows 7 64 Bit ausführe, befindet sich der Speicherort der Datei machine.config für .NET am folgenden Speicherort:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG
Beachten Sie, dass der Ordner "Framework64" anders als oben ist.
Tags und Links .net linq-to-sql sql-server-2005 vb.net msdtc