重新編譯失效對像可執行utlrp.sql文件：
SQL> @?/rdbms/admin/utlrp.sql TIMESTAMP -------------------------------------------------------------------------------- COMP_TIMESTAMP UTLRP_BGN 2016-08-24 13:04:49 DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid DOC> objects in the database. Recompilation time is proportional to the DOC> number of invalid objects in the database, so this command may take DOC> a long time to execute on a database with a large number of invalid DOC> objects. DOC> DOC> Use the following queries to track recompilation progress: DOC> DOC> 1. Query returning the number of invalid objects remaining. This DOC> number should decrease with time. DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6); DOC> DOC> 2. Query returning the number of objects compiled so far. This number DOC> should increase with time. DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED; DOC> DOC> This script automatically chooses serial or parallel recompilation DOC> based on the number of CPUs available (parameter cpu_count) multiplied DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu). DOC> On RAC, this number is added across all RAC nodes. DOC> DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel DOC> recompilation. Jobs are created without instance affinity so that they DOC> can migrate across RAC nodes. Use the following queries to verify DOC> whether UTL_RECOMP jobs are being created and run correctly: DOC> DOC> 1. Query showing jobs created by UTL_RECOMP DOC> SELECT job_name FROM dba_scheduler_jobs DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%'; DOC> DOC> 2. Query showing UTL_RECOMP jobs that are running DOC> SELECT job_name FROM dba_scheduler_running_jobs DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%'; DOC># PL/SQL 過程已成功完成。 TIMESTAMP -------------------------------------------------------------------------------- COMP_TIMESTAMP UTLRP_END 2016-08-24 13:04:50 PL/SQL 過程已成功完成。 DOC> The following query reports the number of objects that have compiled DOC> with errors (objects that compile with errors have status set to 3 in DOC> obj$). If the number is higher than expected, please examine the error DOC> messages reported with each object (using SHOW ERRORS) to see if they DOC> point to system misconfiguration or resource constraints that must be DOC> fixed before attempting to recompile these objects. DOC># OBJECTS WITH ERRORS ------------------- 4 DOC> The following query reports the number of errors caught during DOC> recompilation. If this number is non-zero, please query the error DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors DOC> are due to misconfiguration or resource constraints that must be DOC> fixed before objects can compile successfully. DOC># ERRORS DURING RECOMPILATION --------------------------- 0 PL/SQL 過程已成功完成。
進一步研究文件sql文件，可以看到，在默認情況下Oracle會調用存儲過程utl_recomp.recomp_parallel並行編譯無效包：
begin sys.UTL_RECOMP.recomp_parallel(0); end;
當threads取值為0時，由Oracle根據參數cpu_count和parallel_threads_per_cpu自行決定並行度;
SQL> show parameter cpu NAME TYPE VALUE ------------------------------------ ----------- -------------- cpu_count integer 4 parallel_threads_per_cpu integer 2
有時候，由於Oracle bug 14065287，在啟用並行編譯無效對象時，腳本utlrp.sql會出現HANG現象，這時需要啟用串行編譯無效對象，如下所示：
BEGIN sys.utl_recomp.recomp_serial(); END;
注意：如果在執行中，中斷了，下次如果再次執行時，有可能會出現名稱已由現有對像使用,要在重編譯前先刪除下列索引
drop index SYS.UTL_RECOMP_COMP_IDX1;
使用並行執行時，會使用到SGA中的large pool,如果large pool大小不夠大，會報如下錯誤：
ORA-12801: 並行查詢服務器 P012 中發出錯誤信號 ORA-12853: PX 緩沖區的內存不足: 當前為 16336K, 最大需要 178560K ORA-04031: 無法分配 65560 字節的共享內存 ("large pool","unknown object","large pool","PX msg pool") ORA-06512: 在 "SYS.UTL_RECOMP", line 865 ORA-06512: 在 line 2
如果不是sys用戶執行，可先授予相關的執行權限：
grant execute on UTL_RECOMP to XXX;