В каких ситуациях пакеты Oracle становятся недействительными?

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

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

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

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

8
dependencies oracle package plsql

6 ответов

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

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

12

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

   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.

5

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

застала врасплох?

Не уверен, каковы последствия этого...

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

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

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

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

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

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

3

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

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

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

3

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

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

2

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

1