Varje gång vi distribuerar en ändring i ett databasobjekt ogiltigförklaras en kod som beror på den. Detta påverkar triggers, vyer och lagrade procedurer. Men nästa gång något anropar den koden kommer databasen automatiskt att kompilera om den.
Så vi behöver inte oroa oss för det här, eller hur? Nåväl, ja, upp till en punkt. Saken är att ogiltigförklaringen av triggers (eller vad som helst) är en flagga för oss att en förändring har gjorts som kan påverka funktionen av den triggern, vilket kan ha biverkningar. Den mest uppenbara bieffekten är att triggern inte kompilerar. Mer subtilt, utlösaren kompilerar men misslyckas under operationer.
Därför är det en bra idé att tvinga fram omkompileringen av triggers i en utvecklingsmiljö, för att säkerställa att vår förändring inte har brutit något i grunden. Men vi kan hoppa över det steget när vi implementerar vår förändring i produktionen, eftersom vi gör så säkra på att allt kommer att kompileras om på begäran. Beror på vår nerv :)
Oracle tillhandahåller mekanismer för att automatiskt kompilera om alla ogiltiga objekt i ett schema.
-
Det enklaste är att använda
DBMS_UTILITY.COMPILE_SCHEMA(). Men detta har varit tvivelaktigt sedan 8i (eftersom stöd för Java Stored Procedures introducerade potentialen för cirkulära beroenden) och det är inte längre garanterat att kompilera alla objekt framgångsrikt första gången. -
I 9i gav Oracle oss ett skript
$ORACLE_HOME/rdbms/admin/utlrp.sqlsom kompilerade om saker. Tyvärr kräver det SYSDBA-åtkomst. -
I 10g lade de till UTL_RECOMP-paketet, som i princip gör allt som det skriptet gör. Detta är det rekommenderade tillvägagångssättet för att kompilera om ett stort antal objekt. Tyvärr kräver det också SYSDBA-åtkomst. Läs mer .
I 11g introducerade Oracle finkornig beroendehantering. Detta innebär att ändringar av tabeller utvärderas med en finare granularitet (i princip kolumnnivå snarare än tabellnivå), och endast objekt som direkt påverkas av ändringarna påverkas. Ta reda på mer .