ODP.NET: Vermeiden von Verbindungs-Timeouts mit Anschluss

Question

Pooling

An einem Standort kann mich auf die Oracle-Datenbank mit SQL Developer verbinden, lassen Sie es für eine lange Zeit im Leerlauf (z.B.> 60 Minuten), und zurück, und es ist in Ordnung. Wenn es an einem zweiten Standort länger als 5-10 Minuten inaktiv ist (ich habe nicht genau gezählt), bleibt SQL Developer in einem Zustand, in dem neue Vorgänge Zeitüberschreitung verursachen und ich manuell "Trennen" muss und dann erneut in der Reihenfolge verbinden muss etwas Nützliches tun. Dies scheint ein Verbindungstimeout bei der zweiten Seite zu sein, und ich weiß nicht, was es verursacht (und ich würde gerne wissen, wie ich es abstellen kann, obwohl das nicht meine Hauptfrage ist).

Mein Programm verwendet ODP.NET und verarbeitet Daten, die in Schüben kommen. Alle 30 Minuten (um der Diskussion willen) wird eine Reihe von Daten verarbeitet, die eine Anzahl von wiederholten Verbindungen beinhalten. Es verwendet auch Verbindungspooling. Ich habe den Verbindungspool auf eine Lebensdauer von 5 Minuten eingestellt.

Was ich an der zweiten Seite (und nicht an der ersten) sehe, ist, dass mein Programm zu Beginn jedes Datenstoßes Verbindungszeitüberschreitungsausnahmen (z.B. ORA-03113) erhält. Was ich glaube, ist, dass während des Datenstarts der Verbindungspool wie vorgesehen verwendet wird. Am Ende des Spurts ist die "Connection Lifetime" aktiviert, und die Verbindung ist nicht zu alt, so dass sie im Verbindungspool verbleibt. Dann wird 30 Minuten später, wenn neue Daten ankommen, wird die Verbindung aus dem Pool genommen (und nicht ein Leben lang oder Timeout geprüft) und verwendete und wird timeing aus, so wie ich in SQL Developer zu sehen.

Wie kann ich die Verbindung Timeout vermeiden, aber immer noch in den Schüben Vorteil der Connection Pool nehmen? Aus der Dokumentation (und meiner Erfahrung) geht hervor, dass die Verbindung nur dann auf Lebenszeit geprüft wird, wenn sie in den Pool gelangt, und nicht, wenn sie herauskommt.

Answer 1

Sie können eine unendliche Zeitüberschreitung festlegen, indem Sie die Eigenschaft OracleCommand.ConnectionTimeout auf 0 setzen. In diesem Fall gibt es kein Timeout (zumindest auf der Client-Seite).

ConnectionPool wird auch in diesem Fall verwendet.

Answer 2

Wenn die 5 Minuten Lebenszeit-Einstellung wird in erster Stelle geht es gut, dann denke ich, dass dies von jemandem verursacht werden könnte, den Leerlauf Session-Timeout in einem Profil in der Oracle-Server-Seite zu setzen.

Doch mit der 5 min Lebensdauer Sie Einstellung noch Timeout treffen könnte, wenn Ihr Spurt größer wird, denn wenn man Verbindungen zum Pool im nächsten Spurt zurückkehren werden sie zerstört werden. Der Pool ist dann damit beschäftigt, Verbindungen zu erstellen und zu löschen und führt möglicherweise zu einem Verbindungstimeout, wenn die Last wirklich groß ist.

Answer 3

Dies ist eine wirklich alte Frage, aber ich habe einige ähnliche Probleme mit einer Anwendung erlebt und so denke ich, einige der Informationen sonst jemand helfen könnte, die über diese Frage stellt.

Die Zusammenfassung von TL; DR ist, dass ODP.NET-Treiber und die .NET-Implementierung nicht gut miteinander funktionieren und Ihre normalen Einstellungen für die Verbindungspooling-Verbindung daher nicht so funktionieren, wie Sie es erwarten würden .

Lebensdauer der Verbindung ist der primäre Täter. Ich bin mir nicht sicher, ob this blog noch anwendbar ist, da es ziemlich alt ist, aber ich habe noch keine Dokumentation gefunden, um es zu widerlegen und es scheint das Verhalten zu bestätigen, das ich sehe. Laut dem Blog, Verbindung Lebensdauer tötet eine ältere Sitzung wie erwartet, aber die Prüfung gegen diesen Parameter geschieht nur, wenn ein Aufruf der Datenbank gemacht wird. In anderen Worten, lange im Leerlauf laufende Sitzungen werden niemals von .NET beendet.

Wenn Sie IDLE_TIME auf einen Wert in Ihrem Oracle-Benutzerprofil (und nicht UNLIMITED) eingestellt haben, dann werden diese lang laufenden Leerlaufparameter SNIPED von der Datenbank sein. Dies kann Probleme auf der .NET-Seite verursachen, denn wenn Sie nicht explizit überprüfen, dass Ihre Verbindungen noch geöffnet sind, wird .NET diese SNIPED-Verbindungen so bereitstellen, als ob sie noch verfügbar wären (wodurch der obige Zeitüberschreitungs-ORA-Fehler ausgelöst wird).

Der Trick um dieses Problem besteht darin, sicherzustellen, dass Sie Data Validation=True; in Ihrer Verbindungszeichenfolge haben. Auf diese Weise wird sichergestellt, dass .NET die Sitzungskonnektivität überprüft, bevor die Verbindung bis zum nächsten Serviceanruf bereitgestellt wird. Wenn diese Überprüfung eine SNIPED Sitzung anzeigt, wird sie aus dem .NET-Verbindungspool entfernt.

Angesichts dieser Informationen ist es am wahrscheinlichsten, dass das ursprüngliche Problem des OP nur in der einen Site aus einer Kombination verschiedener Datenbankeinstellungen und/oder der Häufigkeit der .NET-Aufrufe an die Datenbank auftrat. Er könnte das Problem in beiden Umgebungen gehabt haben, aber wenn Benutzer in einer Umgebung häufig genug Anrufe für Connection Lifetime täten, würde er diese Timeouts nie in dieser Datenbank sehen.

Jetzt habe ich noch nicht herausgefunden, wie man eine inaktive Verbindung in .NET beendet, bevor Oracle IDLE_TIME Sniping stattfindet, aber solange Sie diesen Data Validation = True Parameter verwenden, sollten Sie dieses Problem hoffentlich umgehen können.