Kdykoli nasadíme změnu do databázového objektu, jakýkoli kód, který na něm závisí, je zneplatněn. To ovlivňuje spouštěče, pohledy a uložené procedury. Nicméně příště, když něco zavolá tento kód, databáze jej automaticky znovu zkompiluje.
Takže si s tím nemusíme dělat starosti, ne? No ano, do jisté míry. Jde o to, že zneplatnění spouštěčů (nebo čehokoli jiného) je pro nás příznakem, že byla provedena změna, která by mohla ovlivnit fungování tohoto spouštěče, což může mít vedlejší účinky. Nejviditelnějším vedlejším účinkem je, že se spoušť nezkompiluje. Spouštěč se zkompiluje, ale během operací selže.
Proto je dobré vynutit si rekompilaci spouštěčů ve vývojovém prostředí, abychom zajistili, že naše změna zásadně nic nezlomila. Ale můžeme tento krok přeskočit, když implementujeme naši změnu ve výrobě, protože jsme si tak jisti, že vše bude znovu zkompilováno na vyžádání. Záleží na našich nervech :)
Oracle poskytuje mechanismy pro automatickou rekompilaci všech neplatných objektů ve schématu.
-
Nejjednodušší je použít
DBMS_UTILITY.COMPILE_SCHEMA(). Ale to bylo od 8i riskantní (protože podpora pro Java Stored Procedures přinesla potenciál pro cyklické závislosti) a již není zaručeno úspěšné zkompilování všech objektů napoprvé. -
V 9i nám Oracle dal skript
$ORACLE_HOME/rdbms/admin/utlrp.sqlkterý překompiloval věci. Bohužel vyžaduje přístup SYSDBA. -
V 10g přidali balíček UTL_RECOMP, který v podstatě dělá vše, co ten skript. Toto je doporučený přístup pro rekompilaci velkého počtu objektů. Bohužel také vyžaduje přístup SYSDBA. Další informace .
V 11g Oracle představil jemnou správu závislostí. To znamená, že změny v tabulkách jsou vyhodnocovány s jemnější granularitou (v zásadě na úrovni sloupců spíše než na úrovni tabulky) a jsou ovlivněny pouze objekty, které jsou změnami přímo ovlivněny. Další informace .