Cada vez que implementamos un cambio en un objeto de base de datos, cualquier código que dependa de él se invalida. Esto afecta los desencadenantes, vistas y procedimientos almacenados. Sin embargo, la próxima vez que algo llame a ese código, la base de datos lo recompilará automáticamente.
Así que no tenemos que preocuparnos por esto, ¿verdad? Bueno, sí, hasta cierto punto. El hecho es que la invalidación de los desencadenantes (o lo que sea) es una señal de que se ha realizado un cambio que podría afectar el funcionamiento de ese activador, que podría tener efectos secundarios. El efecto secundario más obvio es que el desencadenador no se compilará. Más sutilmente, el gatillo se compila pero falla durante las operaciones.
Por lo tanto, es una buena idea forzar la recompilación de desencadenantes en un entorno de desarrollo, para garantizar que nuestro cambio no haya roto nada. Pero podemos omitir ese paso cuando implementamos nuestro cambio en la producción, porque lo hacemos con la confianza de que todo volverá a compilarse a pedido. Depende de nuestro nervio :)
Oracle proporciona mecanismos para recompilar automáticamente todos los objetos no válidos en un esquema.
Lo más sencillo es usar DBMS_UTILITY.COMPILE_SCHEMA()
. Pero esto ha sido dudoso desde 8i (porque el soporte para Java Stored Procedures introdujo el potencial de dependencias circulares) y ya no se garantiza la compilación de todos los objetos con éxito la primera vez.
En 9i, Oracle nos dio un script $ORACLE_HOME/rdbms/admin/utlrp.sql
que recompilaba las cosas. Desafortunadamente requiere acceso a SYSDBA.
En 10g agregaron el paquete UTL_RECOMP, que básicamente hace todo lo que hace esa secuencia de comandos. Este es el enfoque recomendado para recompilar grandes cantidades de objetos. Desafortunadamente también requiere acceso a SYSDBA. Find out more.
En 11g Oracle introdujo la administración de dependencias de grano fino. Esto significa que los cambios en las tablas se evalúan con una granularidad más fina (básicamente el nivel de columna en lugar de la tabla) y solo se ven afectados los objetos que se ven directamente afectados por los cambios. Find out more.
Gracias, esta explicación se ve muy bien. Hice clic en el enlace de arriba de la documentación de 10g y dice Debe estar conectado COMO SYSDBA para ejecutar este script. Parece que tengo que iniciar sesión como SYSDBA de todos modos. – newguy
@Newguy - oops tienes razón. – APC