Получих обаждане от някой, че получава TNS-12519 грешки в приложението си. Разбира се, тези съобщения също бяха във файла listener.log.
TNS-12519: TNS:no appropriate service handler found
За тези, които не са запознати с тази грешка, това обикновено означава едно от двете неща. Или името на услугата не е регистрирано в слушателя, или че базата данни е достигнала максималния си брой процеси. При последното това, което се случва, е, че слушателят знае, че базата данни не може да приеме нови процеси, така че така да се каже, че името на услугата е извън обслужване. Бързо „състояние на lsnrctl“ ми показва, че името на услугата е регистрирано правилно. Значи трябва да е последното. След това задавам следното запитване и потвърждавам подозренията си.
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
Разбира се. Достигнах максималния брой процеси, който е дефиниран в моя SPFILE на 300. Увеличих параметъра до 600 и отклоних инстанцията. Отново удряме грешката с двоен брой процеси. Очевидно трябва да се задълбоча в това.
За известна информация и за нещо, което ще бъде важно по-късно, е важно да знаете, че тази база данни поддържа нашите усилия за автоматизирано тестване. Имаме тестов колан, който упражнява основното ни производствено приложение. Този тестов пакет стартира приложението, свързва се с базата данни, натиска няколко бутона и избира няколко елемента от менюто и след това прекъсва връзката.
Разгледах файла listener.log, за да видя откъде идват заявките за връзка. Тези заявки идваха от фалшив сървър на приложения, а не от нашия тестов пакет. Знаех, че нещо не е наред, защото все още не сме стартирали тестовия пакет и получавахме грешките. Поправихме сървъра на приложения и не видях да се върнат грешките. След това стартирахме тестовия пакет и известно време по-късно се върнаха грешките на TNS-12519. Хммм… Мислех, че открих виновника. Но нека проверим използването на нашия процес.
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
Така че в момента виждам 89 процеса с максимално използване от 157. Не съм близо до новия си лимит от 600. И така, какво дава? Отне ми известно време, за да разбера какъв е проблемът. Името на услугата е регистрирано правилно и аз не съм близо до лимита си. MOS NOTE 552765.1 говори за това как слушателят достига до грешката TNS-12519. Преди това виждах най-честата причина. Максимум PROCESSES беше достигнат. Но не и този път И какво дава?
След разследване намерих отговора си в дневника на слушателя. Но не беше очевидно като някакво голямо съобщение за грешка. Първото появяване на грешката TNS-12519 беше в 9:38 сутринта. Потърсих „service_update“ в дневника на слушателя и видях тези записи.
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
Обърнете внимание, че тази актуализация на услугата се извършва редовно в 9:17 и 9:18, но времето между актуализациите на услугата отнема все повече и повече време. Забележете, че имаше 8 минути 38 секунди между актуализациите на услугата в края (9:34 до 9:41). Защо това е важно?
Това е база данни на Oracle 11.2.0.4. За 11.2 и по-стари, PMON е отговорен за почистването след процеси и за предаване на информация на слушателя. При стартиране на базата данни PMON се опитва да регистрира услугите със слушателя. Друго нещо, което PMON прави, е да каже на слушателя колко максимални процеси могат да бъдат обслужени. В този случай PMON казва на слушателя, че може да има до 600 процеса. PMON прави повече, но за целите на тази дискусия това е достатъчно.
Една важна част, която трябва да знаете, е, че слушателят никога не знае колко процеса са свързани в момента. Той знае само колко заявки за връзка е помогнал на брокера. Слушателят никога не знае дали процесите се прекъсват от базата данни. Service_update по-горе е мястото, където PMON казва на слушателя колко процеса всъщност се използват. Така в 9:34:07 актуализацията на услугата PMON казва на слушателя, че има 145 използвани процеса. Слушателят вече е актуален. Когато постъпи нова заявка за свързване, слушателят увеличава това до 146 процеса. Между актуализациите на услугата слушателят напълно не знае, че 1 или повече процеси може да са били прекратени, нормално или необичайно. Продължава да увеличава броя на процесите до следващата актуализация на услугата, когато слушателят получи точна сметка за това колко процеса са създадени.
Така че имаме тази 8,5 минути разлика между актуализациите на услугите. Защо на PMON отне толкова време, за да се върне към слушателя? Е, уликата за това също е в listener.log. Изчистих всичко от дневника преди 9:34 service_update и след 9:41 актуализацията на услугата. Оттам беше лесно да се извлече „(CONNECT_DATA=“ в това, което остана и да се направи „wc -l“, за да се получи броят на редовете.
През този интервал от 8,5 минути имах над 450 нови заявки за връзка! И все пак повечето от тези нови връзки бяха прекратени, както се вижда от V$RESOURCE_LIMIT, което ми показва, че имам максимум 150. PMON беше толкова зает с почистването на приложението, което излизаше от връзките си към базата данни, че имаше голямо забавяне преди да актуализира слушателя. Що се отнася до слушателя, 150-те текущи връзки плюс 450-те нови връзки означаваха, че той достигна лимита си от 600.
PMON може да отнеме до 10 минути, за да се върне към слушателя със следващата му актуализация на услугата. Почистването след излизане на сесиите от екземпляра има по-висок приоритет от актуализациите на услугата на слушателя. След 10 минути PMON прави актуализацията на услугата с основен приоритет, ако актуализацията на услугата не е била извършена преди това през този интервал от време.
Не забравяйте, че това е база данни за поддръжка на автоматизирано тестване. Трябва да живеем с толкова много операции за свързване/изключване, защото имаме автоматизиран робот, който тества нашето приложение по бърз начин. Не искаме да променяме как работи приложението, защото работи много добре, когато се изпълнява от един потребител. Нашият автоматизиран тестов пакет изпълнява приложението по различен начин от това, за което е проектирано. Но ние искаме да използваме приложението така, както е написано, за да разкрием евентуални грешки, преди промените в кода да достигнат до производството.
Засега увеличих параметъра PROCESSES до стойност, която никога няма да достигнем. Всичко това, за да не може слушателят да достигне лимита във вътрешния си брояч. Колкото повече ПРОЦЕСИ, толкова повече памет е необходима в SGA, за да поддържа това по-голямо число. Но тази база данни може да се справи.
Ако някой знае начин да накарам актуализацията на услугата да се случи в рамките на 5 минути, моля, уведомете ме. Няма документирани параметри за контролиране на това поведение и не успях да намеря и недокументиран.
И накрая, този проблем е в една от моята база данни 11.2.0.4. Oracle 12c променя малко архитектурата. Новият фонов процес за регистрация на слушател (LREG) се справя с работата, която PMON е вършил. Все още нямам система за тестване, но се обзалагам, че LREG няма да има същия проблем в 12c, който PMON излага тук в 11g, тъй като LREG няма да трябва да се справя със задълженията за почистване, които PMON прави. MOS Note 1592184.1 показва, че LREG ще извърши актуализациите на услугите.
Актуализация:Откакто написах тази статия, имах шанс да надстроя базата данни до 12c с нейния нов процес LREG. Тъй като LREG обработва актуализациите на услугата на слушателя, видяхме, че проблемът изчезва. Дори по време на тежки сесии, по-специално свързване и прекъсване на връзката, LREG правеше редовни актуализации на услугите, които PMON не би могъл да изпълнява толкова често.
