概述

在日常数据库维护过程中，我们会发现数据库中一些对象（包Package、存储过程Procedure、函数Function、视图View、同义词.....）会失效,呈现无效状态（INVALID）。有时候需要定期检查数据库中存在哪些失效对象，对于存在异常的对象需要重新编译，有些自动失效的对象，一般会在下次调用的时候，会被重新编译，所以这些不需要人工干预。那么为什么对象突然会失效呢？又如何快速、高效的编译失效对象呢？哪些失效的对象不需要我们去重新编译呢？

一、数据库对象失效原因

数据库对象失效的原因很多，这里大致归纳了一些常见的原因：

1、当被引用对象的结构变更时，都会使得相关的依赖对象转变为INVALID状态。

数据库中的对象（存储过程，函数，包，视图，触发器），它们往往需要直接或者间接的引用其它对象，对象的依赖包括直接和间接二种，其中直接依赖是指存储对象直接依赖于被引用对象，而间接依赖是指对象间接依赖于被引用对象

要查看被引用的对象，可以通过下面SQL查看

select * from dba_dependencies where name='&objectname';select * from all_dependencies where name='&objectname';select * from user_dependencies where name='&objectname';

其实不管视图，像存储过程，函数、包等，如果代码本身没有什么错误，只是引用的对象发生了变化。也会失效。但并不影响调用，因为ORACLE在调用时会自动重新编译的，如果其它对象变化后导致编译有错误。这时调用时重新编译后也是错误并处于失效状态，所以调用会出错。

2、发布SQL脚本时（包、存储过程、函数等），没有充分测试，编译时出错，这时对象变为无效。

3、数据库升级、迁移时，出现大量无效对象。

4、 诸如此类各种情况：例如，Oracle 会自动维护分区索引，对于全局索引，如果在对分区表操作时，没有指定update index，则会导致全局索引失效，需要重建。

二、查看失效对象

1、统计失效的对象：

select owner, object_type, status, count(*) from dba_objects where status='INVALID' group by owner, object_type, status order by owner, object_type;

2、查看具体失效对象

col owner for a20;col object_name for a32;col object_type for a16col status for a8select owner, object_name, object_type, status from dba_objects where status='INVALID' order by 1, 2,3;

1、使用ALTER *** COMPLIE语句手工进行编译，这个适用于少数、个别对象失效

alter package <schema name>.<package_name> compile;alter package <schema name>.<package_name> compile body;alter view <schema name>.<view_name> compile;alter trigger <schema).<trigger_name> compile;

2、执行@$ORACLE_HOME/rdbms/admin/utlrp.sql脚本编译数据库失效对象。

许多情况下，由于数据库的升级或迁移，会导致数据库中的对象失效。由于对象之间可能存在复杂的依赖关系，所以手工编译通常无法顺利通过。通常我们会在Oracle的升级指导中看到这个脚本，Oracle强烈推荐在迁移或者升级后，通过运行此脚本编译失效对象。但是此脚本需要用SQLPLUS以SYSDBA身份运行，并且当时数据库中最好不要有活动事物或DDL操作，否则极容易导致死锁的出现。

3、自动编译（慎用，可以手动就手动吧）

ORACLE提供了自动编译的接口dbms_utility.compile_schema(user,false); 调用这个过程就会编译所有失效的过程、函数、触发器、包

exec dbms_utility.compile_schema( 'SCOTT' )

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~