Når vi implementerer en ændring til et databaseobjekt, bliver enhver kode, der afhænger af den, ugyldig. Dette påvirker triggere, visninger og lagrede procedurer. Men næste gang noget kalder den kode, vil databasen automatisk rekompilere den.
Så vi behøver ikke bekymre os om dette, vel? Nå, ja, op til et punkt. Sagen er, at ugyldiggørelsen af triggerne (eller hvad som helst) er et flag for os om, at der er foretaget en ændring, som kan påvirke driften af den trigger, hvilket kan have bivirkninger. Den mest åbenlyse bivirkning er, at triggeren ikke vil kompilere. Mere subtilt kompilerer triggeren, men fejler under operationer.
Derfor er det en god idé at gennemtvinge genkompileringen af triggere i et udviklingsmiljø for at sikre, at vores forandring ikke grundlæggende har brudt noget. Men vi kan springe det trin over, når vi implementerer vores ændring i produktionen, fordi vi gør så overbeviste om, at alt vil re-kompilere efter behov. Afhænger af vores nerve :)
Oracle tilbyder mekanismer til automatisk at rekompilere alle de ugyldige objekter i et skema.
-
Det mest ligetil er at bruge
DBMS_UTILITY.COMPILE_SCHEMA(). Men dette har været risikable siden 8i (fordi understøttelse af Java Stored Procedures introducerede potentialet for cirkulære afhængigheder) og er ikke længere garanteret at kompilere alle objekter med succes første gang. -
I 9i gav Oracle os et script
$ORACLE_HOME/rdbms/admin/utlrp.sqlsom genkompilerede ting. Desværre kræver det SYSDBA-adgang. -
I 10g tilføjede de UTL_RECOMP-pakken, som stort set gør alt, hvad det script gør. Dette er den anbefalede tilgang til genkompilering af et stort antal objekter. Desværre kræver det også SYSDBA-adgang. Få mere at vide .
I 11g introducerede Oracle finkornet afhængighedsstyring. Det betyder, at ændringer af tabeller evalueres med en finere granularitet (grundlæggende kolonneniveau frem for tabelniveau), og kun objekter, der er direkte påvirket af ændringerne, påvirkes. Få mere at vide .