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