Chaque fois que nous déployons une modification sur un objet de base de données, tout code qui en dépend est invalidé. Cela affecte les déclencheurs, les vues et les procédures stockées. Cependant, la prochaine fois que quelque chose appellera ce code, la base de données le recompilera automatiquement.
Nous n'avons donc pas à nous en soucier, n'est-ce pas ? Eh bien, oui, jusqu'à un certain point. Le fait est que l'invalidation des déclencheurs (ou autre) nous signale qu'un changement a été apporté qui pourrait affecter le fonctionnement de ce déclencheur, ce qui pourrait avoir des effets secondaires. L'effet secondaire le plus évident est que le déclencheur ne compilera pas. Plus subtilement, le déclencheur se compile mais échoue lors des opérations.
Par conséquent, c'est une bonne idée de forcer la recompilation des déclencheurs dans un environnement de développement, pour s'assurer que notre changement n'a rien cassé fondamentalement. Mais nous pouvons sauter cette étape lorsque nous déployons notre changement en production, car nous le faisons en étant sûrs que tout se recompilera à la demande. Ça dépend de notre culot :)
Oracle fournit des mécanismes pour recompiler automatiquement tous les objets invalides dans un schéma.
-
Le plus simple est d'utiliser
DBMS_UTILITY.COMPILE_SCHEMA(). Mais cela a été douteux depuis 8i (parce que la prise en charge des procédures stockées Java a introduit le potentiel de dépendances circulaires) et n'est plus garanti pour compiler tous les objets avec succès la première fois. -
Dans 9i Oracle nous a donné un script
$ORACLE_HOME/rdbms/admin/utlrp.sqlqui a recompilé les choses. Malheureusement, il nécessite un accès SYSDBA. -
Dans 10g, ils ont ajouté le package UTL_RECOMP, qui fait essentiellement tout ce que fait ce script. Il s'agit de l'approche recommandée pour recompiler un grand nombre d'objets. Malheureusement, il nécessite également un accès SYSDBA. En savoir plus .
Dans la version 11g, Oracle a introduit une gestion fine des dépendances. Cela signifie que les modifications apportées aux tables sont évaluées avec une granularité plus fine (essentiellement au niveau de la colonne plutôt qu'au niveau de la table) , et seuls les objets qui sont directement affectés par les modifications sont affectés. En savoir plus .
