Триггер недопустим в Oracle
Некоторые триггеры в моей базе данных становятся недопустимыми после определенных изменений на таблицах. Но кажется, что они все еще работают. Единственная проблема, которую я имею, состоит в том, если я использую Разработчика SQL существуют красные кресты на левой стороне триггеров, указывающих, что они недопустимы. Действительно ли это - большая проблема?
Я знаю, что могу перекомпилировать триггер для фиксации этого, но я не уверен, действительно ли это - ценность проблемы для касаний. Раз так я должен буду рассмотреть свои предыдущие сотни изменений и узнать то, что вызывает проблему.Спасибо.
3 ответа
Всякий раз, когда мы развертываем изменение объекта базы данных, любой код, который зависит от него, становится недействительным. Это затрагивает триггеры, представления и хранимые процедуры. Однако в следующий раз, когда что-то вызовет этот код, база данных автоматически перекомпилирует его.
Значит, нам не нужно беспокоиться об этом, верно? Ну, да, до определенного момента. Дело в том, что аннулирование триггеров (или чего бы то ни было) является для нас сигналом о том, что было сделано изменение, которое может повлиять на работу этого триггера, что может иметь побочные эффекты. Наиболее очевидным побочным эффектом является то, что триггер не будет компилироваться. Более тонкий эффект - триггер компилируется, но не работает во время выполнения операций.
Поэтому хорошей идеей является принудительная перекомпиляция триггеров в среде разработки, чтобы убедиться, что наше изменение ничего принципиально не нарушило. Но мы можем пропустить этот шаг, когда развертываем наше изменение в production, поскольку мы делаем это, будучи уверенными, что все будет перекомпилировано по требованию. Зависит от нашей наглости :)
Oracle предоставляет механизмы для автоматической перекомпиляции всех недопустимых объектов в схеме.
Наиболее простым является использование
DBMS_UTILITY.COMPILE_SCHEMA(). Однако, начиная с 8i, эта функция стала сомнительной (поскольку поддержка Java Stored Procedures создала потенциал для циклических зависимостей) и больше не гарантирует успешную компиляцию всех объектов с первого раза.В 9i Oracle предоставил нам скрипт
$ORACLE_HOME/rdbms/admin/utlrp.sql, который перекомпилировал все. К сожалению, он требует доступа SYSDBA.В 10g был добавлен пакет UTL_RECOMP, который в основном делает все то же самое, что и этот скрипт. Это рекомендуемый подход для перекомпиляции большого количества объектов. К сожалению, он также требует доступа SYSDBA. Узнайте больше.
В 11g Oracle ввел мелкозернистое управление зависимостями. Это означает, что изменения в таблицах оцениваются с более мелкой детализацией (в основном на уровне столбцов, а не таблиц), и затрагиваются только те объекты, которые непосредственно затронуты изменениями. Узнайте больше.
Если триггеры работают, то, вероятно, Oracle отлавливает ошибку ORA-04068 при срабатывании триггера и повторяет попытку срабатывания после его автоматической перекомпиляции.
Не такая уж большая проблема.
Просто щелкните на них правой кнопкой мыши, чтобы перекомпилировать, и все готово... Я пишу это из собственного опыта.
Если в коде, который вы только что изменили, есть ошибки, они появятся, и вы сможете их исправить. В случае ошибок компилятор подскажет вам, где именно возникли проблемы (номера строк, имена переменных и т.д.).