Сценарий, который создал этот вопрос:
У нас есть пакет, который является зависимостью от другого пакета, иногда внесение изменений в «родительский» пакет приводит к тому, что зависимый пакет становится недействительным, но иногда это не так.
Это застало нас врасплох раньше.
Было бы очень полезно просто понять, что вызывает недействительность, чтобы я мог предсказать/спланировать это.
Изменение любого объекта, на который опирается пакет (например, таблицы, представления, триггеры, другие пакеты), автоматически помечает пакет как недействительный. Как отмечает tuinstoel выше, Oracle достаточно умен, чтобы перекомпилировать пакет при первом использовании.
Если вас это беспокоит, каждый раз, когда вы вносите изменения в схему (например, таблицы, представления, триггеры, процедуры), запускайте DBMS_UTILITY.compile_schema (или попросите сделать это вашего администратора баз данных). Это заставит скомпилировать все пакеты и сообщит вам, где или если есть ошибки, прежде чем вы найдете их трудным путем.
Или вы можете запросить следующую таблицу, чтобы увидеть, какие у вас есть зависимости
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
Это покажет все зависимости. Для ваших объектов запросите user_dependencies.
Кстати, если я полностью ошибаюсь в ситуации... заранее приношу свои извинения
Застигнуты врасплох?
Не знаю, каковы последствия этого...
Что-то сломалось в производстве?
Что ТОЧНО произошло?
Причина, по которой я спрашиваю, заключается в том, что понять последствия каждого возможного изменения гораздо сложнее, чем иметь дело с результатом. Почему признание недействительным стало проблемой? Я предполагаю, что вы получили ошибку «Существующее состояние пакета было отброшено» в вашем приложении. Это НАСТОЯЩАЯ проблема?
Опять же, я подозреваю, что это так, и если это так, давайте просто разберемся с этим, а не со списком изменений, который, как я указал в комментарии, зависит от версии. (например, 11g отслеживает зависимость до столбца таблицы, а не до таблицы в целом).
Это может не показаться вам серьезной ошибкой, если вы не используете состояние пакета. Если бы вы были, это было бы серьезной ошибкой, и вы бы не удивились, так что я предполагаю, что это не так.
Поскольку вы не являетесь этой ошибкой, ее можно игнорировать. Поскольку вы можете безопасно игнорировать это, вы можете закодировать свое клиентское приложение, чтобы игнорировать эту ошибку и повторить вызов, потому что, как указывали другие, Oracle перекомпилирует ваш пакет для вас. Это полезное упражнение. Потому что вместо того, чтобы знать все возможные вещи, о которых вам нужно беспокоиться, когда вы вносите изменения, а затем в экстренном исправлении вы забываете одну из них, ваше приложение просто справится с этим и будет двигаться дальше, не беспокоясь.
SERIALLY_REUSABLE, которая удовлетворяет этому требованию, но немного по-другому, повторно инициализируя состояние пакета при каждом вызове.
- person Leigh Riffel; 08.08.2014
Я согласен с Томасом Джонсом-Лоу, однако есть еще пара проблем, связанных с длинными сессиями и перекомпиляцией.
Если вы ссылаетесь на пакет в сеансе, и этот пакет (или зависимый пакет) перекомпилируется в течение того же сеанса, вы получите ошибку оракула «ORA-06508: PL/SQL: не удалось найти вызываемый модуль программы»
Как только вы сослались на пакет в сеансе, вы, как правило, не можете изменить пакет, не сделав его недействительным для этого сеанса. Это особая проблема для сред разработки, где пакеты часто меняются, а также проблема для производственных сред, где вы хотите сделать небольшой патч, не отключая всю среду. Обратите внимание, что эта ошибка будет возникать, даже если в измененных пакетах нет ошибок.
В дополнение к ответу Томаса Джонса-Лоу, если вы измените только пакет BODY, зависимый объект может не быть помечен как недопустимый.
Однако, как только вы измените спецификацию пакета, это обязательно произойдет.
Если попытаться выполнить недопустимый пакет Oracle, Oracle попытается его скомпилировать. Только когда он останется недействительным после компиляции, Oracle выдаст исключение.
