Cada vez que implementamos un cambio en un objeto de base de datos, se invalida cualquier código que dependa de él. Esto afecta a los disparadores, las vistas y los procedimientos almacenados. Sin embargo, la próxima vez que algo llame a ese código, la base de datos lo volverá a compilar automáticamente.
Así que no tenemos que preocuparnos por esto, ¿verdad? Bueno, sí, hasta cierto punto. La cuestión es que la invalidación de los disparadores (o lo que sea) es una señal para nosotros de que se ha realizado un cambio que podría afectar el funcionamiento de ese disparador, lo que podría tener efectos secundarios. El efecto secundario más obvio es que el activador no compilará. Más sutilmente, el disparador compila pero falla durante las operaciones.
Por lo tanto, es una buena idea forzar la recopilación de disparadores en un entorno de desarrollo, para asegurarse de que nuestro cambio no haya roto nada fundamentalmente. Pero podemos omitir ese paso cuando implementamos nuestro cambio en producción, porque confiamos en que todo se volverá a compilar a pedido. Depende de nuestro nervio :)
Oracle proporciona mecanismos para volver a compilar automáticamente todos los objetos no válidos en un esquema.
-
La más sencilla es usar
DBMS_UTILITY.COMPILE_SCHEMA(). Pero esto ha sido dudoso desde 8i (porque la compatibilidad con los procedimientos almacenados de Java introdujo la posibilidad de dependencias circulares) y ya no se garantiza que compilará todos los objetos con éxito la primera vez. -
En 9i Oracle nos dio un script
$ORACLE_HOME/rdbms/admin/utlrp.sqlque recopiló cosas. Desafortunadamente, requiere acceso SYSDBA. -
En 10g agregaron el paquete UTL_RECOMP, que básicamente hace todo lo que hace ese script. Este es el enfoque recomendado para volver a compilar un gran número de objetos. Desafortunadamente, también requiere acceso SYSDBA. Más información .
En 11g, Oracle introdujo una gestión de dependencias detallada. Esto significa que los cambios en las tablas se evalúan con una granularidad más fina (básicamente, a nivel de columna en lugar de a nivel de tabla), y solo se ven afectados los objetos que se ven afectados directamente por los cambios. Más información .
