Что может вызвать прерывистые ошибки ORA-12519 (TNS: соответствующий обработчик не найден)

мы запускаем наш Junit 4 Test suite против Weblogic 9 перед базой данных Oracle 10 (используя Hudson в качестве сервера непрерывной интеграции), и иногда мы получим сбой ORA-12519 во время демонтажа скрипта. Однако ошибка очень прерывистая:

  • это обычно происходит для одного и того же тестового класса
  • это не всегда происходит для одних и тех же тестовых случаев (иногда они проходят)
  • Это не происходит для того же количества тестовых случаев (где-то от 3-9)
  • иногда этого вообще не происходит, все проходит

хотя я не могу гарантировать, что это не произойдет локально (при работе с одной и той же базой данных, конечно), я запускал один и тот же набор классов несколько раз без проблем.

какие идеи?

38
junit ora-12519 oracle oracle10g

5 ответов

Не знаю, будет ли это ответом для всех, но после некоторых раскопок, вот что мы придумали.

ошибка, очевидно, вызвана тем, что прослушиватель не принимал соединения, но почему мы получим эту ошибку, когда другие тесты могут подключиться нормально (мы также не могли подключить проблему через sqlplus)? Ключом к проблеме было не то, что мы не могли подключиться, но это было перемежающейся

после некоторого расследования мы обнаружили, что во время настройки класса были созданы некоторые статические данные, которые сохраняли бы открытые соединения в течение жизни тестового класса, создавая новые. Теперь, хотя все ресурсы были правильно освобождены, когда этот класс вышел из области (через блок finally {}, конечно), были некоторые случаи во время выполнения, когда этот класс поглощал все доступные соединения (хорошо, предупреждение о плохой практике - это был модульный тестовый код, который подключался напрямую, а не с помощью пула, так что то же самое проблема не могла произойти в производстве).

исправление состояло в том, чтобы не сделать этот класс статическим и запустить в настройке класса, а вместо этого использовать его в методах настройки и демонтажа метода.

поэтому, если вы получите эту ошибку в своих приложениях, похлопайте профилировщика по этому плохому мальчику и посмотрите, может ли у вас утечка соединения. Надеюсь, это поможет.

35

другое решение, которое я нашел для аналогичной ошибки, но то же сообщение об ошибке-увеличить количество найденных обработчиков служб. (Мой экземпляр этой ошибки был вызван слишком большим количеством соединений в пулах соединений WebLogic Portal.)

  • выполнить SQL*Plus и войдите в систему как SYSTEM. Вы должны знать, какой пароль вы использовали во время установки Oracle DB XE.
  • выполнить команду alter system set processes=150 scope=spfile; в SQL * Plus
  • очень важно: перезапустите база данных.

отсюда:

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

26

у меня также была та же проблема, я искал ответы во многих местах. Я получил много похожих ответов, чтобы изменить количество обработчиков процессов/услуг. Но я подумала, что если я забуду вернуть его обратно?

затем я попытался с помощью Thread.sleep() метод после каждого моего connection.close();.

Я не знаю как, но это работает, по крайней мере для меня.

Если кто-то хочет попробовать и выяснить, как это работает, пожалуйста, продолжайте. Я также хотел бы знать, как я новичок в мире программирования.

3

у меня была аналогичная проблема. Это происходило каждый раз, когда я запускал пакет тестов базы данных (Spring JDBC) с SpringJUnit4ClassRunner, поэтому я решил вопрос поставив @DirtiesContext аннотация для каждого теста для очистки контекста приложения и освобождения всех ресурсов, таким образом, каждый тест может выполняться с новой инициализацией контекста приложения.

1

У меня была эта проблема в модульном тесте, который открыл много соединений с БД через пул соединений, а затем "остановил" пул соединений (фактически ManagedDataSource), чтобы освободить соединения в конце каждого теста. У меня всегда заканчивались связи в какой-то момент в наборе тестов.

добавлена нить.сон (500) в teardown () моих тестов, и это решило проблему. Я думаю, что происходило то, что пул соединений stop () выпускает активный соединения в другом потоке, так что если основной поток продолжает выполнять тесты, поток(ы) очистки настолько отстал, что сервер Oracle исчерпал соединения. Добавление сна позволяет фоновым потокам освободить объединенные соединения.

Это гораздо меньше проблемы в реальном мире, потому что серверы БД намного больше, и существует здоровое сочетание операций (а не только бесконечные операции подключения/отключения БД).

1