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

Question

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

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

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

Есть идеи?

Answer 1

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

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

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

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

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

Answer 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/

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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