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

Глядя на ваш запрос и план напрашивается вопрос:
Действительно ли в вашей таблице ÂÛÐ_ÈÑÒ_ÑÈÃ_ÏÊ ровно одна строка со значением ÈÑÒ_ÑÈÃÍÀËÀ равным '1=0' ( см. предикат для 4й строчки)? Можете ли вы это проверить?
Оракл считает что 1, поэтому выбрал nested loop, но если их больше - то нестед луп на 800 * 185k разумеется умирает.
Далее - запросу на самом деле нужна только одна строчка - первая, таким образом время его на 100% зависит от того сколько итераций двойного цикла он сделает до того как найдет хоть одну строчку - т.е. время выполнения этого запроса очень "данные-зависимо". Вы легко можете отсортировать данные в двух сорсах независимо и посмотреть на какой итерации обычно бывает первое совпадение, и на какой итерации возникает совпадение в момент "затыка".

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