El escenario que creó esta pregunta:¿Qué situaciones hacen que los paquetes de Oracle se vuelvan inválidos?
Tenemos un paquete que es una dependencia de otro paquete, a veces hacer cambios en el paquete "principal" hace que el paquete dependiente se vuelva inválido, pero a veces no lo hace.
Nos ha cogido por sorpresa antes.
Sería muy útil para comprender simplemente lo que hace que la invalidación por lo que podría predecir/plan para ello.
Cambio de objeto cualquier cosa que un paquete se basa en (por ejemplo, tablas, vistas, disparadores, otros paquetes) automáticamente marcará el paquete como válido. Como notas tuinstoel anteriores, Oracle es lo suficientemente inteligente como para recompilar el paquete cuando se utiliza por primera vez.
Si le preocupa esto, cada vez que realice cambios en el esquema (por ejemplo, tablas, vistas, desencadenantes, procedimientos), ejecute un DBMS_UTILITY.compile_schema (o haga que lo haga su DBA). Esto obligará a compilar todos los paquetes y le permitirá saber dónde o si hay errores antes de que los encuentre de la manera difícil.
Advertencia: DBMS_UTILITY.COMPILE_SCHEMA() no se recomienda su uso realmente desde Oracle8i y definitivamente desde 9i. Podemos salirse con la tuya, pero aquí hay alternativas más confiables. Ver mi respuesta a este otro hilo http://stackoverflow.com/questions/3200202/trigger-is-invalid-in-oracle/3200439#3200439 – APC
Si intenta ejecutar un paquete Oracle no válido, Oracle intentará compilarlo. Solo cuando permanezca inválido después de la compilación Oracle arrojará una excepción.
Además de la respuesta de Thomas Jones-baja, si sólo se modifica el cuerpo del paquete, un objeto dependiente podría no ser marcados como no válidos.
Sin embargo, tan pronto como se modifica la especificación del paquete, que está obligado a pasar.
Por cierto, si estoy completamente equivocado acerca de la situación ... Disculpas por adelantado
cogido por sorpresa?
Noseguro de lo que las consecuencias de eso son ...
hizo algo interrupción en la producción?
¿Qué sucedió EXACTAMENTE?
La razón que pido es porque la comprensión ramificaciones de cada posible cambio es mucho más difícil de tratar con el resultado. ¿Por qué la invalidación se convierte en un problema? Mi suposición es porque obtuviste un error de "estado existente de paquete descartado" en tu aplicación. ¿Es ese el problema REAL?
Una vez más Sospecho que se trata y si es así, vamos a tratar con que en lugar de la lista de cambios que, como he puesto en un comentario es la versión específica. (11g rastrea la dependencia hasta la columna de una tabla en lugar de la tabla como un todo, por ejemplo).
Esto puede no parecer un error importante para usted si no está utilizando el estado del paquete. Si fuera así, sería un error importante y no se habría sorprendido, así que supongo que no.
Dado que no es este error, puede ignorarlo. Como puede ignorarlo con seguridad, puede codificar su aplicación cliente para ignorar este error y volver a intentar su llamada, ya que, como han señalado otros, Oracle recompilará su paquete por usted. Este es un ejercicio que vale la pena.Porque en lugar de conocer todas las cosas posibles de las que tienes que preocuparte cuando realizas un cambio, y luego, en la solución de emergencia, te olvidas de una de ellas, tu aplicación simplemente se encargará y seguirá adelante, sin preocupaciones.
Es una pena que no haya un pragma o algo así como "No me importa cambio de estado de paquete " –
Hay un pragma, 'SERIALLY_REUSABLE', que satisface el requisito, pero de una manera ligeramente diferente al reiniciar el estado del paquete con cada llamada. –
Estoy de acuerdo con Thomas Jones-Low, sin embargo, hay un par de cuestiones más que hacer con las largas sesiones y la recopilación.
Si hace referencia a un paquete en una sesión y ese paquete (o un paquete dependiente) se vuelve a compilar durante la misma sesión, obtendrá el error de oráculo "ORA-06508: PL/SQL: no se pudo encontrar la unidad de programa llamada "
Una vez que ha hecho referencia al paquete en una sesión, generalmente no puede cambiar el paquete sin invalidarlo para esa sesión. Este es un problema particular para los entornos de desarrollo en los que los paquetes cambian con frecuencia, pero también es un problema para los entornos de producción en los que desea hacer un pequeño parche sin tener que derribar todo el entorno. Tenga en cuenta que este error ocurrirá incluso cuando no haya errores en los paquetes modificados.
o se puede consultar la tabla siguiente para ver qué dependencias tiene
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
Esto mostrará todas las dependencias. Para sus objetos consulta user_dependencies.
¿Qué versión? En realidad es diferente de una versión a otra. –
Esa es la versión de aplicaciones de Oracle, afaik. No hay RDBMS con ese identificador. seleccione * de v $ versión le dirá. –