细粒度依赖(二)依赖关系导致的对象失效

本文探讨了Oracle数据库中不同版本依赖关系的变化,特别是在Oracle11g引入的细粒度依赖特性。通过实例说明了当表结构发生变化时,哪些类型的依赖会导致相关对象失效。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

上次说到可以通过数据字典找到Oracle数据对象的依赖关系,从而做好DDL操作的关联操作,以避免数据库对象失效。

在Oracle10g以及更早的版本中,依赖关系是以程序单元的粒度进行跟踪的,比如一张表的一个字段被修改,即使程序中没有用到这个字段,也会失效。

从Oracle11g开始,细粒度依赖已经优化到单元中的元素,比如上述的情况中,程序只在引用字段被修改时才会失效。

比如我有一张表T_CUR2,有ID和NAME两个字段

表被V_T_CUR引用,其中ID字段设为别名ID2


而V_T_CUR又被个存储过程P_DEPENDENCY1引用


同时,基表T_CUR2又同时被4个存储过程P_DEPENDENCY2、P_DEPENDENCY3、P_DEPENDENCY4、P_DEPENDENCY5引用,4个存储过程的区别仅在于COUNT的字段不一样:



这些对象刚开始都是有效的:



现在对T_CUR2表的ID字段进行DDL操作,看下其他对象的状态:


我们发现表结构修改后,被依赖的视图和存储过程状态如下:

视图V_T_CUR,失效,因为引用了被修改的字段;

存储过程P_DEPENDENCY1,失效,因为引用了已经失效的V_T_CUR视图;

存储过程P_DEPENDENCY2,有效,COUNT(*)按常规理解应该是可能会解析到ID字段引用,有点出乎意料;

存储过程P_DEPENDENCY3,失效,COUNT(A.ID)引用了被修改的ID字段;

存储过程P_DEPENDENCY4,失效,COUNT(1)按常规理解应该是没用到ID字段,也有点出乎意料;

存储过程P_DEPENDENCY5,有效,COUNT(DISTINCT NAME)没有引用被修改的ID字段。

居然意外得出一个用COUNT(*)好还是COUNT(xxx)好的佐证。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值