Какие ситуации приводят к тому, что пакеты Oracle становятся недействительными?

Question

Сценарий, который создал этот вопрос:

У нас есть пакет, который является зависимостью от другого пакета, иногда внося изменения в " parent " пакет заставляет зависимый пакет становиться недействительным, но иногда это не так.

Это застало нас врасплох раньше.

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

Answer 1

Изменение любого объекта, на который опирается пакет (например, таблиц, представлений, триггеров, других пакетов), автоматически помечает пакет как недействительный. Как указано выше в Tuinstoel, Oracle достаточно умен, чтобы перекомпилировать пакет при первом его использовании.

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

Answer 2

Или вы можете запросить следующую таблицу, чтобы узнать, какие у вас зависимости

   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.

Answer 3

Кстати, если я полностью ошибаюсь из-за ситуации ... заранее извиняюсь

застигнуты врасплох?

Не уверен, что это означает ...

Что-то сломалось в производстве?

Что именно произошло?

Причина, по которой я спрашиваю, состоит в том, что понять последствия каждого возможного изменения гораздо сложнее, чем иметь дело с результатом. Почему недействительность стала проблемой? Я предполагаю, что вы получили "существующее состояние пакета", которое было отклонено ". ошибка в вашем приложении. Это REAL проблема?

Опять же, я подозреваю, что это так, и если так, давайте просто разберемся с этим, а не со списком изменений, который, как я добавил в комментарии, зависит от версии. (11g отслеживает зависимость вплоть до столбца таблицы, а не таблицы в целом, например).

Это может показаться вам не важной ошибкой, если вы не используете состояние пакета. Если бы вы были, это было бы важной ошибкой, и вы бы не удивились, так что я полагаю, что это не так.

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

Answer 4

Я согласен с Томасом Джонсом-Лоу, однако есть еще пара вопросов, связанных с длинными сеансами и перекомпиляцией.

Если вы ссылаетесь на пакет в сеансе, и этот пакет (или зависимый пакет) перекомпилируется во время того же сеанса, то вы получите сообщение об ошибке "ORA-06508: PL / SQL: не удалось найти программный модуль, вызываемый "" ;

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

Answer 5

В дополнение к ответу Томаса Джонса-Лоу, если вы измените только пакет BODY, зависимый объект может быть не помечен как недействительный.

Однако, как только вы измените спецификацию пакета, это обязательно произойдет.

Answer 6

Если попытаться выполнить неверный пакет Oracle, Oracle попытается скомпилировать его. Только когда он останется недействительным после компиляции, Oracle выдаст исключение.