Dostałem telefon od kogoś, że otrzymują błędy TNS-12519 w swojej aplikacji. Oczywiście te wiadomości również znajdowały się w pliku listener.log.
TNS-12519: TNS:no appropriate service handler found
Dla tych, którzy nie są zaznajomieni z tym błędem, zwykle oznacza to jedną z dwóch rzeczy. Albo nazwa usługi nie jest zarejestrowana w odbiorniku, albo baza danych osiągnęła maksymalną liczbę procesów. W przypadku tych ostatnich dzieje się tak, że Listener wie, że baza danych nie może zaakceptować żadnych nowych procesów, więc nazwa usługi jest niedostępna, że tak powiem. Szybki „stan lsnrctl” pokazuje mi, że nazwa usługi jest zarejestrowana poprawnie. Więc to musi być to drugie. Następnie wysyłam następujące zapytanie i potwierdzam moje podejrzenia.
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
Jasne. Osiągnąłem maksymalną liczbę procesów, która jest zdefiniowana w moim SPFILE na 300. Zwiększyłem parametr do 600 i odbiłem instancję. Ponownie trafiamy na błąd z podwojoną liczbą procesów. Oczywiście muszę zagłębić się w to dalej.
Dla pewnego tła i dla czegoś, co będzie ważne później, ważne jest, aby wiedzieć, że ta baza danych obsługuje nasze zautomatyzowane testy. Posiadamy uprząż testową, która sprawdza naszą podstawową aplikację produkcyjną. Ten zestaw testów uruchamia aplikację, łączy się z bazą danych, naciska kilka przycisków i wybiera kilka pozycji menu, a następnie rozłącza się.
Sprawdziłem plik listener.log, aby zobaczyć, skąd pochodzą żądania połączenia. Te żądania pochodziły z nieuczciwego serwera aplikacji, a nie z naszego zestawu testowego. Wiedziałem, że coś jest nie tak, ponieważ nie rozpoczęliśmy jeszcze zestawu testowego i otrzymywaliśmy błędy. Naprawiliśmy serwer aplikacji i nie zauważyłem powrotu błędów. Następnie uruchomiliśmy zestaw testowy i jakiś czas później powróciły błędy TNS-12519. Hmmm… Myślałem, że znalazłem winowajcę. Sprawdźmy jednak wykorzystanie naszego procesu.
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
Więc obecnie widzę 89 procesów z maksymalnym wykorzystaniem 157. Nie zbliżam się do mojego nowego limitu 600. Więc co daje? Zajęło mi trochę czasu, aby dowiedzieć się, na czym polega problem. Nazwa usługi jest poprawnie zarejestrowana i nie zbliżam się do mojego limitu. MOS NOTE 552765.1 mówi o tym, jak słuchacz dochodzi do błędu TNS-12519. Wcześniej widziałem najczęstszą przyczynę. Osiągnięto maksymalną liczbę PROCESÓW. Ale nie tym razem Więc co daje?
Po dochodzeniu znalazłem swoją odpowiedź w dzienniku słuchacza. Ale to nie było oczywiste, jak jakiś duży komunikat o błędzie. Pierwsze wystąpienie błędu TNS-12519 miało miejsce o godzinie 9:38. Poszukałem „service_update” w dzienniku słuchacza i zobaczyłem te wpisy.
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
Zauważ, że ta aktualizacja usługi odbywa się regularnie o 9:17 i 9:18, ale czas między aktualizacjami usługi jest coraz dłuższy. Zwróć uwagę, że między aktualizacjami usługi na końcu upłynęło 8 minut i 38 sekund (od 9:34 do 9:41). Dlaczego jest to ważne?
To jest baza danych Oracle 11.2.0.4. Od wersji 11.2 i wcześniejszych PMON jest odpowiedzialny za sprzątanie po procesach i przekazywanie informacji do Listener. Podczas uruchamiania bazy danych PMON próbuje zarejestrować usługi w Listener. Inną rzeczą, jaką robi PMON, jest poinformowanie Listener, ile max procesów może obsłużyć. W tym przypadku PMON mówi słuchaczowi, że może mieć do 600 procesów. PMON robi więcej, ale na potrzeby tej dyskusji to wystarczy.
Ważną rzeczą, o której należy wiedzieć, jest to, że Listener nigdy nie wie, ile procesów jest aktualnie połączonych. Wie tylko, ile żądań połączeń pomogło brokerowi. Listener nigdy nie wie, czy procesy rozłączają się z bazą danych. Service_update powyżej to miejsce, w którym PMON informuje słuchacza, ile procesów jest faktycznie używanych. Tak więc o 9:34:07 aktualizacja usługi PMON informuje słuchacza, że w użyciu jest 145 procesów. Odbiornik jest teraz aktualny. Kiedy nadejdzie nowe żądanie połączenia, Listener zwiększa to do 146 procesów. Pomiędzy aktualizacjami usługi nasłuchiwanie jest całkowicie nieświadome, że 1 lub więcej procesów mogło zostać zakończonych normalnie lub nienormalnie. Kontynuuje zwiększanie liczby procesów aż do następnej aktualizacji usługi, kiedy Listener otrzyma dokładne konto, ile procesów jest generowanych.
Mamy więc 8,5 minuty przerwy między aktualizacjami usług. Dlaczego tak długo zajęło PMON powrót do słuchacza? Cóż, wskazówka do tego znajduje się również w listener.log. Usunąłem wszystko z dziennika przed aktualizacją service_update o 9:34 i po aktualizacji usługi o 9:41. Stamtąd łatwo było wyszukać „(CONNECT_DATA=” w tym, co pozostało i przejść do „wc -l”, aby uzyskać liczbę wierszy.
Podczas tego 8,5-minutowego interwału miałem ponad 450 nowych próśb o połączenie! Jednak większość tych nowych połączeń została zakończona, o czym świadczy V$RESOURCE_LIMIT, który pokazuje mi, że mam maksymalnie 150. PMON był tak zajęty czyszczeniem aplikacji po wyjściu z połączeń z bazą danych, że miał duże opóźnienie przed zaktualizowaniem odbiornika. Jeśli chodzi o słuchacza, 150 obecnych połączeń plus 450 nowych połączeń oznaczało, że osiągnął limit 600.
Powrót do programu Listener z następną aktualizacją usługi może zająć PMON do 10 minut. Czyszczenie po wyjściu sesji z instancji ma wyższy priorytet niż aktualizacje usług dla odbiornika. Po upływie 10 minut PMON nadaje najwyższy priorytet aktualizacji usługi, jeśli aktualizacja usługi nie została wcześniej wykonana w tym przedziale czasowym.
Pamiętaj, że jest to baza danych wspierająca testy automatyczne. Musimy żyć z tyloma operacjami łączenia/rozłączania, ponieważ mamy zautomatyzowanego robota, który błyskawicznie testuje naszą aplikację. Nie chcemy zmieniać sposobu działania aplikacji, ponieważ działa bardzo dobrze, gdy jest uruchamiana przez jednego użytkownika. Nasz zautomatyzowany zestaw testów wykonuje aplikację inaczej niż to, do czego została zaprojektowana. Ale chcemy wykorzystać aplikację tak, jak została napisana, aby potencjalnie ujawnić błędy, zanim zmiany w kodzie trafią do produkcji.
Na razie podniosłem parametr PROCESSES do wartości, której nigdy nie osiągniemy. Wszystko po to, aby Słuchacz nie mógł przekroczyć limitu w swoim wewnętrznym liczniku. Im więcej PROCESÓW, tym więcej pamięci potrzebnej w SGA do obsługi większej liczby. Ale ta baza danych sobie z tym poradzi.
Jeśli ktoś wie, jak uzyskać aktualizację usługi w ciągu 5 minut, daj mi znać. Nie ma żadnych udokumentowanych parametrów do kontrolowania tego zachowania i nie mogłem znaleźć również nieudokumentowanego.
Wreszcie, ten problem znajduje się w jednej z moich baz danych 11.2.0.4. Oracle 12c zmienia nieco architekturę. Nowy proces rejestracji nasłuchiwania (LREG) w tle obsługuje pracę wykonywaną przez PMON. Nie mam jeszcze systemu do przetestowania, ale założę się, że LREG nie będzie miał tego samego problemu w 12c, który PMON wystawia tutaj w 11g, ponieważ LREG nie będzie musiał zajmować się zadaniami porządkowymi, które robi PMON. Notatka MOS 1592184.1 pokazuje, że LREG wykona aktualizacje usługi.
Aktualizacja:Odkąd napisałem ten artykuł, miałem szansę zaktualizować bazę danych do 12c z nowym procesem LREG. Wraz z obsługą aktualizacji usługi Listener przez LREG, zauważyliśmy, że problem zniknął. Nawet w okresach intensywnej aktywności sesji, w szczególności łączenia i rozłączania, LREG regularnie aktualizował usługi, których PMON nie byłby w stanie wykonywać tak często.
