Современные корпорации выпускают тиражируемые решения.
Самый базовый уровень - стандартизованы и промышленно выпускаются инфраструктурные компоненты (ОС, СУБД, App-сервера).
Более-менее освоен промышленный выпуск "станков" (т.н. "платформ" разработки/интеграции) и идет активное становление промышленного производства прикладных систем.


Ремесленники промышленниками стали далеко не за 30 лет.
Дайте срок.


Это как раз признак пром. производства. Узкая специализация и конвейеризация процесса + штат управляющего персонала, ручки не пачкающего.

No_data_found - тоже не ошибка, а исключение.
На этом общность заканчивается, поскольку No_data_found непосредственно связана с серверным кодом и данными, в то время как 4068 и 3113 - с технологическими процессами, от кода не зависящими.
Вся разница в деталях - конкретных причинах, по которым что-то пошло не так, как предполагает основной поток операций.
Если эти причины не разделять и искать столь же общее решение - Вас ждет неизбежный fail.
И да, на проекте виднее.

Мы не хотим привязываться к твое затычке типо повторно постучи дважды)))))

Ок, я не навязываю.
Не хотите реагировать на конкретное исключение так, как предписывает вендор - Ваше право.
Откатывайте транзакции, покупайте сервера и морочьте голову админам.

Вах баюс-баюс...

Смотрим очередной раз:
- PL изменения - покажите какие надо сделать изменения на примере приведенных тестовых пакетов. Без конкретных предложений совет бесполезен.
- выкинуть - рассматривать надо в комплексе. Включая в скоуп рассмотрения "выкинуть джаву, выкинуть сервер, выкинуть проект, выкинуть сотрудников". Повода для таких "рассмотрений" в настоящее время у меня нет, совет бесполезен.
- рестарт пула - не отвечает требованиям непрерывности сервиса, бесполезен.
- зеркало и балансировщик 24х7 не решает задачу без существенного объема работ по синхронизации "зеркал" , общего увеличения стоимости проекта и увеличения эксплуатационных расходов. Это примерно как экскаватором огородик вскапывать - теоретически можно, но окружающие будут пальцем у виска крутить.
- тех окно - не отвечает требованиям непрерывности сервиса, совет бесполезен
- клиент умеющий перезагружаться а ля интернет эксплорер - не решает задачу, поскольку пробема не у клиента, а у бэка.

Итоговая ценность озвученных Вами предложений в контексте проекта исчезающе мала.

- погасить ошибку молча
Во-первых не молча, а с логированием.
Во-вторых, именно эта исключительная ситуация требует именно такого решения, потому как:

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

Единственное противопоказание - использование пакетных переменных для передачи состояния между вызовами - вполне разумно при использовании пула соединений. Подобное использование пакетных переменных суть bad design и не применяется на практике в моих проектах ни-ког-да, что делает противопоказание не актуальным.
В третьих, уже разберитесь наконец, чем ошибка отличается от исключения . Это блондинке в бухгалтерии позволительно выражаться в стиле "у меня ошибка вылезает, сделайте что-нибудь".