1. 首页
  2. IT资讯

一例ORA-14097报错的分析与处理历程

同事说有一个分区表做分区交换时总是报:ORA-14097: ALTER TABLE EXCHANGE PARTITION 中的列类型或大小不匹配,而中间表是根据分区表CATS而来,理论上是一样的; 我首先对比了一下这个表的建表SQL,发现中间表除了default不一样外,其他都是一样的,会不会是default导致?于是我重新用分区表的SQL完整建了中间表,这下default也一样了,但仍然报这个错; 网上有文章说主键也要一致,于是加了主键后再试,还是报错,外键也建上,依然; 在ITPUB找到一个案例说如果分区表有unuser的字段,也会报这个错,于是drop unuser的字段(alter table tname drop unused columns),仍然未解决; 还有newkid大师提供了一种场景是分区后再增加了字段,这可能会触发BUG,需要加上跟踪事件语句: ALTER SESSION SET EVENTS ‘14529 TRACE NAME CONTEXT FOREVER, LEVEL 2’; 交换分区; ALTER SESSION SET EVENTS ‘14529 TRACE NAME CONTEXT OFF’; 但尝试了依然报错; 从sys.col$中比较两个表的字段,确实发现有一个字段的property是不一样的,正常的都是0,但源分区表却是一个很大的整数;不清楚代表什含义; 但newkid提到的分区后再增加字段这个思路比较靠谱,不过我奇怪的是这个不是最后增加的字段,为什么后面的字段不是这样? 然后另一个同事说曾经遇到了一种分区后增加字段默认值,而默认值修改了数据字典导致不能分区交换的案例,相对来说,这种说法更加靠谱,但我仍有疑问,排在后面还有一个字段也是有默认值的,但是却没有这个property的不同; 原因暂且就分析到这里了,先解决问题先,我先在测试环境作了一个对源分区表重建的操作,重新完整地创建表与索引等,就换了个名字,然后把数据插进来,一交换,成功! 但是生产环境这个表有好几亿,重建的方式根本不可行啊,于是我想如果把default值去掉,能不能让两边一致呢?修改后,一测,还是不行; 心一横,在两边把这个字段给删了,再尝试分区交换,可以了! 当然不可能这么做,但进一步确定了问题就出在这个字段上; 这个字段确实在property上不同,但这个数字代表什么意思呢?思维扩展一下,把查询的表名条件注释掉,以property值作查询条件,发现有好几个表有这种字段,选了其中一个表比对,突然有了眼前一亮的发现:这个表有3个字段有默认值,却只有两个字段是这个属性,有一个却是0,其中的区别是:这个字段是null,而那两个则是not null! 看来找到了问题的关键点了!尝试把其中的一个字段改成null,这个property果然变成0了,按这种思路,只需要改变这个字段的null属性,就能让两边保持一致,从而交换成功! 果断修改成null后测试,交换成功,击掌相庆啊!这种解决方法是可行的,大家都能接受。 重新再梳理一下,感觉终于理顺了:因为oracle11G有一个新特性,当给一个字段增加默认值时,如果这个字段是not null,则会非常快,因为只修改了字典,不会像以前那样去修改表中的每一行,而如果是null呢,那没办法,只能去修改现有的数据行,这算是大表增加字段及默认值的一个最佳实践,而这个property的大数字,可能就是oracle放置的判断标识,在对一个已有很多记录的表增加字段时,会置一个标识来表明走快捷方式还是传统方式,而当我们新建一张表时,由于记录是空的,所以估计压根就不做这样一个判断,从而也就没有修改property的值了,这就导致了分区交换时两边的字段不一致的问题了。 这正是:道是无晴却有晴,山穷水尽又花明,晓镜但愁头发白,加班常觉宵夜冷,为伊消得人憔悴,百转千回也不悔,蓬山此去多岐路,翻遍谷歌与百度,然领悟,答案就在,云深不知处。呵呵,尽瞎扯了

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13365316/viewspace-2127178/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:布吉卡,转转请注明出处:http://www.cxybcw.com/194602.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code