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

Question

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

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

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

Есть какие-нибудь идеи?

Answer 1

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

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

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

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

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

Answer 2

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

• Бежать 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

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

Answer 5

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

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

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