Подтвердить что ты не робот

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

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

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

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

Любые идеи?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

Другое решение, которое я обнаружил для аналогичной ошибки, но то же сообщение об ошибке - увеличить количество найденных обработчиков. (Мой экземпляр этой ошибки был вызван слишком большим количеством подключений в пулах подключения 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/

Ответ 3

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

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

Я не знаю, как, но он работает хотя бы для меня.

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

Ответ 4

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

Ответ 5

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

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

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