Oracle-Sitzung über VPN abgebrochen? Keepalive-Ebenen prüfen
Stille Datenbankarbeit kann einen untätigen Netzwerkfluss überleben. Gehen Sie den Socket-Schalter, die Kernel-Vorgaben und die Oracle-Net-Einstellung in der richtigen Reihenfolge durch.
Fünfundzwanzig Minuten nützlicher Datenbankarbeit erzeugen fast keine Ausgabe, und aus Sicht jedes Geräts auf dem Pfad wirkt dieser Fluss untätig. Untätigkeit ist genau der Zustand, der eingesammelt wird. Der Bericht danach hat immer dieselbe Form: Die Abfrage lief, dann verschwand die Sitzung, und das Ergebnis kam nie an.
Vier Prüfungen entscheiden, ob eine stille Sitzung überlebt, und sie laufen vom Socket nach außen. Führen Sie sie der Reihe nach aus, denn jede setzt voraus, dass die vorherige Ebene ihre Aufgabe erfüllt.
Welcher Fluss wird still
Die Verbindung, auf die es ankommt, ist die, die den Datenbankverkehr trägt, erkennbar an ihren eigenen Adressen und Ports. Nichts anderes frischt sie auf. Ein Ping an ein Gateway, eine zweite SQL-Verbindung vom selben Host und der eigene Herzschlag des Tunnels sind getrennte Flüsse mit getrenntem Zustand auf jedem Gerät, das sie verfolgt.
ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
Die Socket-Auflistung zeigt Timer und Warteschlangenzustand für die lebende Verbindung, was aussagekräftiger ist als ein Erreichbarkeitstest. Die sysctl-Werte sind die Kernel-Vorgaben für das Keepalive-Verhalten, und der nächste Abschnitt erklärt, warum sie für Ihre Sitzung möglicherweise nie gelten. Eine Vorgabe, die nie auslöst, ist von keiner Vorgabe zu unterscheiden.
Notieren Sie die Adressen, die Ports und die Schnittstelle, die die Verbindung nutzt. Wenn eine Sitzung stirbt, sind es diese Details, mit denen Sie das richtige Gerät fragen können, was es getan hat, statt zu fragen, ob das Netzwerk verfügbar war.
Ob die Leerlauf-Richtlinie abläuft oder begrenzt
Zwei Richtlinien erzeugen dasselbe Symptom und erfordern entgegengesetzte Reaktionen. Ein Leerlauf-Timeout entfernt Zustand, den qualifizierender Verkehr hätte auffrischen können, und ein Keepalive kann das verhindern. Ein absolutes Sitzungslimit entfernt den Fluss nach einer festen Dauer unabhängig von Aktivität, und kein Keepalive ändert das.
Fragen Sie den Eigentümer jedes Zwischengeräts, welche der beiden es umsetzt. Eine Firewall, ein NAT-Gerät, ein Load Balancer und ein Cloud-Gateway können alle Zustand halten, und sie müssen nicht übereinstimmen. Das engste setzt die Frist, die Sie unterbieten müssen.
Diese Unterscheidung sagt Ihnen auch, wann Sie aufhören sollten zu justieren. Ist die Richtlinie ein absolutes Limit, ist die richtige Lösung eine kürzere Arbeitseinheit, ein wiederaufnehmbarer Job oder eine genehmigte Ausnahme, und die Prüfung unten bestätigt dann nur, dass Keepalives nichts geändert haben.
Der Socket-Schalter hinter den Linux-Vorgaben
Keepalive ist pro Socket optional. Die Kernel-Vorgaben beschreiben, wie Sonden sich verhalten, sobald ein Socket den Mechanismus aktiviert hat, und sie aktivieren ihn nicht für bestehende Verbindungen. Eine Anwendung, die ihn nie anfordert, bekommt keine Sonden, egal was die sysctl-Werte sagen.
Deshalb ändert das bloße Erhöhen der Zahlen für einen Datenbankclient nichts. Die Client-Bibliothek oder die Anwendung muss den Mechanismus aktivieren, und wo der Stack Steuerungen pro Verbindung bietet, ist eine begrenzte Einstellung besser als eine hostweite Änderung, die fremde Dienste betrifft.
Das Intervall bis zur ersten Sonde ist auch kein Abfrage-Timeout. Eine gesunde Verbindung bleibt zwischen Sonden still, und ein toter Peer wird gemäß Sondenintervall und -anzahl erkannt. Diese drei Werte als ein Timeout zu lesen, führt zu Einstellungen, die einen Ausfall entweder viel zu spät oder viel zu eifrig erkennen. Sie steuern die Erkennung, nicht die Geduld der Anwendung.
EXPIRE_TIME ist eine Datenbankeinstellung, keine Netzwerk-Lösung
Oracle Net bietet einen eigenen Lebendigkeitsmechanismus, der im effektiven Profil des Prozesses konfiguriert wird und nicht in einer beliebigen Datei mit ähnlichem Namen. Der Wert wird in Minuten angegeben.
SQLNET.EXPIRE_TIME = 5
Sein Hauptzweck ist die serverseitige Erkennung toter Verbindungen, und auf Plattformen, die das erweiterte Modell unterstützen, stimmt es zusätzlich das TCP-Keepalive-Verhalten für diese Verbindungen ab. Das ist eine nützliche Eigenschaft: Die Datenbankschicht kann Sonden veranlassen, ohne die Client-Anwendung ändern zu müssen.
Der oben gezeigte Beispielwert ist eine abgestimmte Wahl gegen eine angenommene Frist, keine Empfehlung. Die dokumentierte allgemeine Empfehlung ist ein längeres Intervall, und die richtige Zahl hängt von der installierten Implementierung, dem akzeptierten Sondenaufwand und den tatsächlichen Auffrischungsregeln auf dem Pfad ab. Setzen Sie die Einstellung in das Profil, das der betreffende Prozess liest, und bestätigen Sie, dass der Prozess sie übernommen hat. Oracle dokumentiert die Profilspeicherorte und das Erkennungsverhalten in seiner Parameterreferenz.
Testen Sie das stille Intervall, dann planen Sie die Erholung
Führen Sie eine neue erlaubte Verbindung durch eine stille Phase, die länger ist als die Frist, die Sie unterbieten wollen, und beobachten Sie den Lebendigkeitsverkehr und das Anwendungsergebnis. Erfassen Sie keine Nutzlastinhalte, die Sie nicht brauchen; Timer und Verbindungszustand beantworten die Frage.
ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"
Wenn die Sitzung trotzdem verschwindet, gehört die Frist zu einem Gerät, das Sie noch nicht gefragt haben, oder die Richtlinie ist ein absolutes Limit. Wenn sie überlebt, halten Sie fest, welche Ebene sich geändert hat, damit der nächste stille Vorgang die Untersuchung nicht wiederholt.
Entscheiden Sie schließlich, was passiert, wenn die Verbindung tatsächlich abbricht, denn Lebendigkeitsprüfungen verringern die Häufigkeit und beseitigen die Möglichkeit nie. Stellen Sie das aufgezeichnete Ergebnis des Datenbankvorgangs fest, bevor Sie ihn erneut senden: Der Verlust der Antwort beweist nichts darüber, ob die Arbeit festgeschrieben wurde. Für alles, was das Schließen eines Laptops oder einen Tunnel-Neustart überleben muss, ist ein servereigener Job mit dauerhaftem Ergebnis das stärkere Design, und ein Keepalive ist kein Scheduler.