Las actualizaciones, parches y cambios de librerias pueden invalidar objetos del esquema.
Una vez realizados los cambios los objetos dependientes serán revalidados de forma AUTOMATICA cuando se usan.
Esto puede tardar un rato e incluso tardar un tiempo inaceptable por lo que lo logico es recompilar las dependencias antes de las llamadas de los usuarios.
Esto además permite descubrir si los cambios han afecteado al resto del codigo.
Identificación de objetos descompilados:SELECT owner, object_type, object_name, status FROM dba_objects WHERE status = 'INVALID' ORDER BY owner, object_type, object_name;
Con esta información podemos decidir que metodo seguir para recompilar.
ALTER PACKAGE my_package COMPILE; ALTER PACKAGE my_package COMPILE BODY; ALTER PROCEDURE my_procedure COMPILE; ALTER FUNCTION my_function COMPILE; ALTER TRIGGER my_trigger COMPILE; ALTER VIEW my_view COMPILE;
Hay que tener en cuenta que es necesario recompilar cabecera y cuerpo del paquete por separado.
Alternativamente podemos usa el paquete DBMS_DDL:
EXEC DBMS_DDL('PACKAGE', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL('PACKAGE BODY', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL('PROCEDURE', 'MY_SCHEMA', 'MY_PROCEDURE');
EXEC DBMS_DDL('FUNCTION', 'MY_SCHEMA', 'MY_FUNCTION');
EXEC DBMS_DDL('TRIGGER', 'MY_SCHEMA', 'MY_TRIGGER');
Este metodo esta limitado a los objetos PL/SQL por lo que no es aplicable a vistas.
En algunos casos puede ser interesante escribir un script para identificar y compilar objetos descompilados.
Un ejemplo para PACKAGE y PACKAGE BODY seria:SET SERVEROUTPUT ON SIZE 1000000 BEGIN FOR cur_rec IN (SELECT owner, object_name, object_type, DECODE(object_type, 'PACKAGE', 1,'PACKAGE BODY', 2, 2) AS recompile_order FROM dba_objects WHERE object_type IN ('PACKAGE', 'PACKAGE BODY') AND status != 'VALID' ORDER BY 4) LOOP BEGIN IF cur_rec.object_type = 'PACKAGE' THEN EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type || ' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE'; ElSE EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE BODY'; END IF; EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner || ' : ' || cur_rec.object_name); END; END LOOP; END; /
Con este metodo hay que tener mucho cuidado ya que puedes acabar recompilando algunos objetos varias veces dependiendo del orden de ejecucion de la recompilación.
Los procedimientos que nos da oracle y que están explicados a continuación si que tiene en cuenta el orden adecuado.
El procedimiento COMPILE_SCHEMA del paquete DBMS_UTILITY compila todos los procedures, functions, packages, y triggers de un esquema. Hay que tener muy en cuenta que tampoco recompila las vistas.
EXEC DBMS_UTILITY.COMPILE_SCHEMA(schema => 'PROGRAMADOR');
El paquete UTL_RECOMP contiene 2 procedimientos para recompilar objetos descompilados.
RECOMP_SERIAL recompila los objetos uno por uno mientras que RECOMP_PARALLEL recompila en paralelo usando el numero de threads especificado.
Para esquemas:
EXEC UTL_RECOMP.RECOMP_SERIAL('PROGRAMADOR');
EXEC UTL_RECOMP.RECOMP_PARALLEL(4, 'PROGRAMADOR');-- 4 es el numero de threads a utilizar
Para base de datos:
EXEC UTL_RECOMP.RECOMP_SERIAL(); --todos los esquemas EXEC UTL_RECOMP.RECOMP_PARALLEL(4);Usando el valor de job_queue_processes
EXEC UTL_RECOMP.RECOMP_PARALLEL(); --se usa para theads el valor de "job_queue_processes" EXEC UTL_RECOMP.RECOMP_PARALLEL(NULL, 'PROGRAMADOR');Restricciones del paquete:
Explicación de la sintaxis utilizada para los comandos: Las palabras en mayusculas son comandos de oracle. Las palabras en minusculas son opiones modificables Las partes enmarcadas con [] son opcionales Las palabras en negrita son las opciones por defecto Las partes enmarcadas con {} son alternativas (una u otra). El simbolo | indica OR