Někdo mi zavolal, že ve své aplikaci dostává chyby TNS-12519. Jistě, tyto zprávy byly také v souboru listener.log.
TNS-12519: TNS:no appropriate service handler found
Pro ty, kteří s touto chybou nejsou obeznámeni, to obvykle znamená jednu ze dvou věcí. Buď není název služby zaregistrován u posluchače, nebo že databáze dosáhla maximálního počtu procesů. V druhém případě se stane, že posluchač ví, že databáze nemůže přijmout žádné nové procesy, takže název služby takříkajíc vyřadí z provozu. Rychlé „lsnrctl status“ mi ukazuje, že název služby je zaregistrován správně. Takže to musí být to druhé. Poté zadávám následující dotaz a potvrzuji své podezření.
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
Dostatečně jistý. Dosáhl jsem maximálního počtu procesů, který je v mém SPFILE definován na 300. Zvýšil jsem parametr na 600 a instanci jsem vrátil. Znovu jsme narazili na chybu s dvojnásobným počtem procesů. Očividně se v tom musím ponořit dále.
Pro určité pozadí a pro něco, co bude důležité později, je důležité vědět, že tato databáze podporuje naše automatizované testování. Máme testovací postroj, který cvičí naši primární výrobní aplikaci. Tato testovací sada spustí aplikaci, připojí se k databázi, stiskne několik tlačítek a vybere několik položek nabídky a poté se odpojí.
Prozkoumal jsem soubor listener.log, abych zjistil, odkud přicházely požadavky na připojení. Tyto požadavky přicházely z podvodného aplikačního serveru, nikoli z naší testovací sady. Věděl jsem, že něco není v pořádku, protože jsme ještě nespustili testovací sadu a dostávali jsme chyby. Opravili jsme aplikační server a chyby se nevrátily. Poté jsme spustili testovací sadu a po nějaké době se chyby TNS-12519 vrátily. Hmmm...myslel jsem, že jsem našel viníka. Ale podívejme se na využití našeho 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
Aktuálně tedy vidím 89 procesů s maximálním využitím 157. Ani zdaleka se neblížím svému novému limitu 600. Co tedy dává? Chvíli mi trvalo, než jsem zjistil, v čem je problém. Název služby je správně zaregistrován a zdaleka se neblížím svému limitu. MOS NOTE 552765.1 hovoří o tom, jak posluchač dospěje k chybě TNS-12519. Dříve jsem viděl nejčastější příčinu. Bylo dosaženo maximálního počtu PROCESSES. Ale tentokrát ne. Co tedy dává?
Po prozkoumání jsem našel svou odpověď v deníku posluchače. Ale nebylo to zřejmé jako nějaká velká chybová zpráva. První výskyt chyby TNS-12519 byl v 9:38. Hledal jsem „service_update“ v protokolu posluchače a viděl jsem tyto záznamy.
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
Všimněte si, že tato aktualizace služby probíhá pravidelně v 9:17 a 9:18, ale doba mezi aktualizacemi služby trvá stále déle. Všimněte si, že mezi aktualizacemi služby na konci bylo 8 minut 38 sekund (9:34 až 9:41). Proč je to důležité?
Toto je databáze Oracle 11.2.0.4. Pro 11.2 a starší je PMON zodpovědný za čištění po procesech a za předávání informací posluchači. Při spuštění databáze se PMON pokusí zaregistrovat služby u Listeneru. Další věcí, kterou PMON dělá, je sdělit posluchači, kolik maximálních procesů lze obsluhovat. V tomto případě PMON sděluje posluchači, že může mít až 600 procesů. PMON umí více, ale pro účely této diskuse to stačí.
Jednou z důležitých informací je, že posluchač nikdy neví, kolik procesů je aktuálně připojeno. Ví pouze, kolik žádostí o připojení pomohlo zprostředkovat. Posluchač nikdy neví, zda se procesy odpojí od databáze. Service_update výše je místo, kde PMON sděluje posluchači, kolik procesů se skutečně používá. Takže v 9:34:07 aktualizace služby PMON sděluje posluchači, že se používá 145 procesů. Posluchač je nyní aktuální. Když přijde nový požadavek na připojení, Listener to zvýší na 146 procesů. Mezi aktualizacemi služby si posluchač vůbec neuvědomuje, že 1 nebo více procesů mohlo být ukončeno, normálně nebo abnormálně. Neustále zvyšuje počet procesů až do příští aktualizace služby, kdy Listener získá přesný přehled o tom, kolik procesů bylo vytvořeno.
Máme tedy 8,5minutovou mezeru mezi aktualizacemi služeb. Proč trvalo PMON tak dlouho, než se dostal zpět do Posluchače? Nápověda k tomu je také v listener.log. Před aktualizací service_update v 9:34 a po aktualizaci služby v 9:41 jsem z protokolu odstranil vše. Odtud bylo snadné vyhledat „(CONNECT_DATA=“ v tom, co zbylo, a pomocí kanálu „wc -l“ získat počet řádků.
Během tohoto 8,5minutového intervalu jsem měl více než 450 nových žádostí o připojení! Přesto byla většina těchto nových připojení ukončena, jak dokazuje V$RESOURCE_LIMIT, který mi ukázal, že mám maximum 150. PMON byl tak zaneprázdněn čištěním aplikace, která opouštěla svá databázová připojení, že došlo k velkému zpoždění, než aktualizoval Listener. Pokud jde o posluchače, 150 současných připojení plus 450 nových připojení znamenalo, že dosáhl svého limitu 600.
PMON může trvat až 10 minut, než se vrátí k Listeneru s další aktualizací služby. Čištění po ukončení relací instance má vyšší prioritu než aktualizace služby Listener. Po 10 minutách PMON učiní aktualizaci služby nejvyšší prioritou, pokud aktualizace služby nebyla dříve provedena v tomto časovém intervalu.
Pamatujte, že se jedná o databázi na podporu automatického testování. Musíme žít s tolika operacemi připojení/odpojení, protože máme automatizovaného robota, který testuje naši aplikaci rychlým způsobem. Nechceme měnit, jak aplikace funguje, protože funguje velmi dobře, když ji spouští jeden uživatel. Naše automatizovaná testovací sada spouští aplikaci jinak, než k čemu byla navržena. Ale chceme aplikaci používat tak, jak je napsaná, abychom potenciálně odhalili chyby předtím, než se změny kódu dostanou do produkce.
Prozatím jsem zvýšil parametr PROCESSES na hodnotu, které nikdy nedosáhneme. To vše proto, aby Posluchač nemohl narazit na limit ve svém vnitřním počítadle. Čím více PROCESŮ, tím více paměti potřebuje SGA k podpoře tohoto vyššího čísla. Ale tato databáze to zvládne.
Pokud někdo ví o způsobu, jak zajistit aktualizaci služby do 5 minut, dejte mi prosím vědět. Neexistují žádné zdokumentované parametry, které by toto chování ovládaly, a také se mi nepodařilo najít žádný nezdokumentovaný.
A konečně, tento problém je v jedné z mých databází 11.2.0.4. Oracle 12c trochu mění architekturu. Nový proces registrace posluchače (LREG) na pozadí zpracovává práci, kterou dříve dělal PMON. Ještě nemám systém, který bych mohl otestovat, ale vsadím se, že LREG nebude mít stejný problém v 12c, jaký zde PMON vykazuje v 11g, protože LREG nebude muset zvládnout úklidové povinnosti jako PMON. Poznámka MOS 1592184.1 ukazuje, že aktualizace služby provede LREG.
Aktualizace:Od doby, kdy jsem napsal tento článek, jsem měl šanci upgradovat databázi na 12c s novým procesem LREG. Když LREG zpracovával aktualizace služeb posluchače, viděli jsme, že problém zmizel. I v době intenzivní aktivity relace, konkrétně připojování a odpojování, LREG prováděl pravidelné aktualizace služeb, které by PMON nebyl schopen provádět tak často.