Telkens wanneer we een wijziging in een databaseobject implementeren, wordt elke code die ervan afhankelijk is ongeldig gemaakt. Dit heeft invloed op triggers, views en opgeslagen procedures. De volgende keer dat iets die code aanroept, zal de database deze echter automatisch opnieuw compileren.
Hier hoeven we ons dus geen zorgen over te maken, toch? Nou ja, tot op zekere hoogte. Het punt is dat de ongeldigverklaring van de triggers (of wat dan ook) voor ons een teken is dat er een wijziging is aangebracht die de werking van die trigger kan beïnvloeden, wat bijwerkingen kan hebben. Het meest voor de hand liggende neveneffect is dat de trigger niet compileert. Meer subtiel, de trigger compileert maar mislukt tijdens bewerkingen.
Daarom is het een goed idee om de hercompilatie van triggers in een ontwikkelomgeving te forceren, om ervoor te zorgen dat onze verandering niets fundamenteel heeft gebroken. Maar we kunnen die stap overslaan wanneer we onze wijziging in productie implementeren, omdat we er zeker van zijn dat alles op aanvraag opnieuw wordt gecompileerd. Hangt van onze zenuwen af :)
Oracle biedt mechanismen voor het automatisch hercompileren van alle ongeldige objecten in een schema.
-
Het meest eenvoudig is om
DBMS_UTILITY.COMPILE_SCHEMA(). te gebruiken . Maar dit is onbetrouwbaar sinds 8i (omdat ondersteuning voor Java Stored Procedures het potentieel voor circulaire afhankelijkheden introduceerde) en het is niet langer gegarandeerd dat alle objecten de eerste keer met succes worden gecompileerd. -
In 9i gaf Oracle ons een script
$ORACLE_HOME/rdbms/admin/utlrp.sqldie dingen opnieuw compileerde. Helaas vereist het SYSDBA-toegang. -
In 10g hebben ze het pakket UTL_RECOMP toegevoegd, dat in feite alles doet wat dat script doet. Dit is de aanbevolen aanpak voor het opnieuw compileren van grote aantallen objecten. Helaas vereist het ook SYSDBA-toegang. Meer informatie .
In 11g introduceerde Oracle fijnmazig afhankelijkheidsbeheer. Dit betekent dat wijzigingen in tabellen nauwkeuriger worden geëvalueerd (in feite kolomniveau in plaats van tabelniveau) en dat alleen objecten worden beïnvloed die rechtstreeks door de wijzigingen worden beïnvloed. Meer informatie .