资讯专栏INFORMATION COLUMN

Oracle 19C错误查询结果集案例

IT那活儿 / 771人阅读
Oracle 19C错误查询结果集案例
基础环境
操作系统linux7.6 +数据库19.6
问题描述

执行如下sql:

select * from   test

where (from_id=89090909090909 or to_id=89090909090909);

每次新建会话第一次查询返回的结果集最后一列值出现错误的概率很高,当再次执行该sql时结果正确。
发现过程

某天应用突然联系说查询出错误结果集,因为涉及核心数据库,这让我紧张了一下。经过与应用沟通,可以判断,不管是程序jdbc连接还是plsql客户端连接都可以复现问题。与应用沟通后,我也拿到sql进行了测试,问题复现的概率很高。到这里这个问题已经很难进行下去了,sql比较简单,mos上搜索后未发现相关的bug。于是提交oracle后台分析,大家都懂的,oracle后台提供了相应的文档脚本收集相关日志。但效果并不好,来来回回收集了很多次日志也未能抓到异常信息。

再次与应用沟通,发现最后一列是通过addcloumn方式添加的,且是notnull的。通过mos搜索发现,还真有符合这种情况的bug:

可惜没有符合当前你19.6版本数据库的。

在沟通过程中已经发现了可能和addcolumn,且是notnull方式添加字段有关。于是按原表表结构新建一张表:

场景一、最后一个字段建表后再添加,问题可以复现;

场景二、最后一个字段建表时一起建上,问题未能复现。

通过以上测试,可以明确是addcolumn且是notnull相关的bug。
解决方案:

当前:按以上场景二方式重建表即可。

远期:提供相关信息至oracle后台,由后台分析并提供相关workground或者开发补丁。
END


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129948.html

相关文章

  • 19C DG Broker配置和测试

    19C DG Broker配置和测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...

    IT那活儿 评论0 收藏2941
  • 数据库收 - 收藏 - 掘金

    摘要:前言在使用加载数据数据库常见的优化操作后端掘金一索引将放第一位,不用说,这种优化方式我们一直都在悄悄使用,那便是主键索引。 Redis 内存压缩实战 - 后端 - 掘金在讨论Redis内存压缩的时候,我们需要了解一下几个Redis的相关知识。 压缩列表 ziplist Redis的ziplist是用一段连续的内存来存储列表数据的一个数据结构,它的结构示例如下图 zlbytes: 记录整...

    Little_XM 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<