Ich habe einen Anruf von jemandem erhalten, dass in seiner Anwendung TNS-12519-Fehler aufgetreten sind. Natürlich waren diese Nachrichten auch in der Datei listener.log enthalten.
TNS-12519: TNS:no appropriate service handler found
Für diejenigen, die mit diesem Fehler nicht vertraut sind, bedeutet dies normalerweise eines von zwei Dingen. Entweder ist der Dienstname nicht beim Listener registriert oder die Datenbank hat ihre maximale Anzahl von Prozessen erreicht. Bei letzterem passiert, dass der Listener weiß, dass die Datenbank keine neuen Prozesse akzeptieren kann, also nimmt er den Dienstnamen sozusagen außer Betrieb. Ein kurzer „lsnrctl status“ zeigt mir, dass der Dienstname korrekt registriert ist. Also muss es letzteres sein. Ich stelle dann die folgende Abfrage und bestätige meinen Verdacht.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 299 300
Sicher genug. Ich habe die maximale Anzahl an Prozessen erreicht, die in meiner SPFILE mit 300 definiert ist. Ich habe den Parameter auf 600 erhöht und die Instanz gebounct. Wir haben den Fehler erneut mit der doppelten Anzahl von Prozessen getroffen. Ich muss das natürlich weiter vertiefen.
Für einige Hintergrundinformationen und etwas, das später wichtig sein wird, ist es wichtig zu wissen, dass diese Datenbank unsere automatisierten Testbemühungen unterstützt. Wir haben einen Testrahmen, der unsere primäre Produktionsanwendung durchführt. Diese Testsuite startet die Anwendung, stellt eine Verbindung zur Datenbank her, drückt ein paar Tasten und wählt einige Menüpunkte aus und trennt dann die Verbindung.
Ich habe die Datei listener.log untersucht, um zu sehen, woher die Verbindungsanfragen kamen. Diese Anfragen kamen von einem betrügerischen Anwendungsserver, nicht von unserer Testsuite. Ich wusste, dass etwas nicht stimmte, weil wir die Testsuite noch nicht gestartet hatten und wir die Fehler bekamen. Wir haben den Anwendungsserver repariert und ich habe die Fehlerrückkehr nicht gesehen. Wir haben dann die Testsuite gestartet und einige Zeit später kehrten die TNS-12519-Fehler zurück. Hmmm … ich dachte, ich hätte den Übeltäter gefunden. Aber lassen Sie uns unsere Prozessauslastung überprüfen.
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 89 157
Ich sehe also derzeit 89 Prozesse mit einer maximalen Auslastung von 157. Ich bin noch lange nicht in der Nähe meines neuen Limits von 600. Was gibt es also? Es dauerte eine Weile, bis ich herausfand, was das Problem war. Der Dienstname ist korrekt registriert und ich bin noch lange nicht am Limit. MOS NOTE 552765.1 spricht darüber, wie der Listener zum Fehler TNS-12519 gelangt. Zuvor sah ich die häufigste Ursache. Max PROCESSES wurde erreicht. Aber diesmal nicht. Also was gibt's?
Nach Recherchen fand ich meine Antwort im Protokoll des Zuhörers. Aber es war nicht so offensichtlich wie eine große Fehlermeldung. Das erste Auftreten des Fehlers TNS-12519 war um 9:38 Uhr. Ich habe im Listener-Log nach „service_update“ gesucht und diese Einträge gesehen.
25-JUN-2015 09:17:08 * service_update * orcl * 0 25-JUN-2015 09:17:26 * service_update * orcl * 0 25-JUN-2015 09:17:29 * service_update * orcl * 0 25-JUN-2015 09:17:44 * service_update * orcl * 0 25-JUN-2015 09:17:50 * service_update * orcl * 0 25-JUN-2015 09:17:53 * service_update * orcl * 0 25-JUN-2015 09:18:56 * service_update * orcl * 0 25-JUN-2015 09:18:59 * service_update * orcl * 0 25-JUN-2015 09:19:50 * service_update * orcl * 0 25-JUN-2015 09:20:11 * service_update * orcl * 0 25-JUN-2015 09:21:27 * service_update * orcl * 0 25-JUN-2015 09:22:09 * service_update * orcl * 0 25-JUN-2015 09:24:05 * service_update * orcl * 0 25-JUN-2015 09:27:53 * service_update * orcl * 0 25-JUN-2015 09:29:32 * service_update * orcl * 0 25-JUN-2015 09:34:07 * service_update * orcl * 0 25-JUN-2015 09:41:45 * service_update * orcl * 0
Beachten Sie, dass diese Dienstaktualisierung regelmäßig um 9:17 und 9:18 Uhr erfolgt, aber die Zeit zwischen den Dienstaktualisierungen immer länger dauert. Beachten Sie, dass zwischen Dienstaktualisierungen am Ende (9:34 bis 9:41) 8 Minuten und 38 Sekunden lagen. Warum ist das wichtig?
Dies ist eine Oracle 11.2.0.4-Datenbank. Für 11.2 und früher ist PMON für die Bereinigung nach Prozessen und für die Weitergabe von Informationen an den Listener verantwortlich. Beim Datenbankstart versucht PMON, die Dienste beim Listener zu registrieren. Eine andere Sache, die PMON tut, ist, dem Listener mitzuteilen, wie viele Prozesse maximal bedient werden können. In diesem Fall teilt PMON dem Listener mit, dass es bis zu 600 Prozesse haben kann. PMON leistet mehr, aber für diese Diskussion ist das genug.
Ein wichtiger Punkt ist, dass der Listener nie weiß, wie viele Prozesse derzeit verbunden sind. Es weiß nur, wie viele Verbindungsanfragen es vermittelt hat. Der Listener weiß nie, ob Prozesse die Verbindung zur Datenbank trennen. Das obige service_update ist, wo PMON dem Listener mitteilt, wie viele Prozesse tatsächlich verwendet werden. Um 9:34:07 Uhr teilt die PMON-Dienstaktualisierung dem Listener mit, dass 145 Prozesse verwendet werden. Der Listener ist jetzt auf dem neuesten Stand. Wenn eine neue Verbindungsanforderung eingeht, erhöht der Listener diese auf 146 Prozesse. Zwischen den Dienstaktualisierungen ist sich der Listener überhaupt nicht bewusst, dass ein oder mehrere Prozesse normal oder abnormal beendet wurden. Es erhöht die Anzahl der Prozesse bis zum nächsten Service-Update, wenn der Listener eine genaue Angabe darüber erhält, wie viele Prozesse erzeugt werden.
Wir haben also diese 8,5-minütige Lücke zwischen Service-Updates. Warum hat PMON so lange gebraucht, um zum Listener zurückzukehren? Nun, der Hinweis dafür ist auch im listener.log. Ich habe vor dem Service-Update um 9:34 Uhr und nach dem Service-Update um 9:41 Uhr alles aus dem Protokoll entfernt. Von dort aus war es einfach, nach „(CONNECT_DATA=“ in dem, was übrig blieb, zu suchen und an „wc -l“ zu leiten, um die Anzahl der Zeilen zu erhalten.
Während dieses 8,5-Minuten-Intervalls hatte ich weit über 450 neue Verbindungsanfragen! Die meisten dieser neuen Verbindungen wurden jedoch beendet, was durch V$RESOURCE_LIMIT belegt wird, was mir zeigt, dass ich maximal 150 hatte. Für den Listener bedeuteten die 150 aktuellen Verbindungen plus die 450 neuen Verbindungen, dass er sein Limit von 600 erreicht hat.
Es kann bis zu 10 Minuten dauern, bis PMON mit seinem nächsten Service-Update zum Listener zurückkehrt. Das Aufräumen, nachdem Sitzungen die Instanz verlassen, hat eine höhere Priorität als Dienstaktualisierungen für den Listener. Bei der 10-Minuten-Marke macht PMON die Dienstaktualisierung zur obersten Priorität, wenn die Dienstaktualisierung zuvor nicht in diesem Zeitintervall durchgeführt wurde.
Denken Sie daran, dass dies eine Datenbank zur Unterstützung automatisierter Tests ist. Wir müssen mit so vielen Verbindungs-/Trennvorgängen leben, weil wir einen automatisierten Roboter haben, der unsere Anwendung im Schnellfeuer testet. Wir möchten die Funktionsweise der Anwendung nicht ändern, da sie sehr gut funktioniert, wenn sie von einem einzelnen Benutzer ausgeführt wird. Unsere automatisierte Testsuite führt die Anwendung anders aus als ursprünglich vorgesehen. Aber wir möchten die Anwendung so testen, wie sie geschrieben ist, um potenzielle Fehler aufzudecken, bevor die Codeänderungen die Produktion erreichen.
Fürs Erste habe ich den PROCESSES-Parameter auf einen Wert erhöht, den wir nie erreichen werden. All dies, damit der Listener nicht das Limit in seinem internen Zähler erreichen kann. Je mehr PROZESSE, desto mehr Speicher wird in der SGA benötigt, um diese höhere Zahl zu unterstützen. Aber diese Datenbank kann damit umgehen.
Wenn jemand eine Möglichkeit kennt, das Service-Update in einem 5-Minuten-Fenster durchzuführen, lassen Sie es mich bitte wissen. Es gibt keine dokumentierten Parameter, um dieses Verhalten zu steuern, und ich konnte auch keinen undokumentierten finden.
Schließlich befindet sich dieses Problem in einer meiner 11.2.0.4-Datenbanken. Oracle 12c ändert die Architektur ein wenig. Der neue Hintergrundprozess Listener Registration (LREG) übernimmt die Arbeit, die PMON früher erledigt hat. Ich habe noch kein System zum Testen, aber ich wette, dass LREG in 12c nicht das gleiche Problem haben wird, das PMON hier in 11g zeigt, da LREG nicht wie PMON Bereinigungsaufgaben übernehmen muss. MOS-Hinweis 1592184.1 zeigt, dass LREG die Service-Updates durchführen wird.
Update:Seit ich diesen Artikel geschrieben habe, hatte ich die Möglichkeit, die Datenbank mit ihrem neuen LREG-Prozess auf 12c zu aktualisieren. Da LREG die Dienstaktualisierungen des Listeners handhabt, ist das Problem verschwunden. Selbst in Zeiten starker Sitzungsaktivität, insbesondere beim Verbinden und Trennen, hat LREG regelmäßige Dienstaktualisierungen vorgenommen, die PMON nicht so oft hätte durchführen können.
